マクロメディアが7月25日附で《Dreamweaver 4 日本語版》のアップデータ《Dreamweaver 4.02 Updater Ja》を公開した。製品版の 4.0J・4.01J を対象とするこのアップデートを実行することにより、《Dreamweaver》で UTF-8 による多言語混在ページを作成できるようになる。Mac 版アップデータのサイズは 10.3 MB。
《Dreamweaver 4.02J》上で新たに日中・繁簡混在の内容を入力したり、 UTF-8 による既存の Web ページを開いて編集する分には不便はない。ただし《SimpleText》などからスタイル付きテキストの形の複数スクリプトが混在した文を直接ペーストすると、文字化けしてしまう。既存の多言語混在文書から UTF-8 ページを作成する場合の文字化け回避法は研究が必要なようだ。(追記参照)
Mac 版 4.02J では、UTF-8 への対応にともなって、多少振舞が変っている点がある。
数値文字参照の部分は、4.01 までは、WYSIWYG に近いデザインビューにおいても「蘋」や「蘋」のようにそのまま表示されていたが、4.02J では文字に変換して表示しようとするようになった。この数値文字参照の数値は、本来 UCS (≒Unicode) の符号位置として解釈されるべきものだ。そのとおりなら歓迎なのだが、4.02J では UTF-8 以外のいわゆる“ローカルコード”を選んでいる場合は、正常に表示されず文字化けしてしまう。4.02J では、編集している文書が指定しているエンコード方法を元に解釈しようとするらしい。
UTF-8 を選んでいる場合にのみ期待されるとおりに Unicode のコードポイントとして解釈する、という 4.02J の現状はあまり有難みがない。UTF-8 は、複数の文字セットを統合した Unicode 文字セットのエンコード方法であり、UTF-8 文書の中なら、わざわざ数値文字参照のような面倒な方法を使わず、普通に入力しても同様の効果を得られる場合がほとんどだ。数値文字参照を使うのは、多くの場合“ローカル”な文字セットに含まれない文字を Unicode を使って挿入するためであり、本当に必要なときに化けてしまっては仕方がないのだ。この状態なら、以前のようにコードのままの方が気が利いている。
このほか、UTF-8 を指定したページを編集している間は、入力メニューから「Extended Roman(U)」と「Unicode Hex Input」が選べるようになる。これら「Unicode スクリプト」のキー配列は、《Dreamweaver 4.02J》では淡色表示にならず選べるものの、実際には機能しない。部分的な Unicode ベースアプリケーションのようだ。
Unicode 関連の機能が中途半端なことによる困った点も確かにあるが、ともかく、現にニーズがあり、これから重要度が増すと思われる UTF-8 による Web ページが《Dreamweaver》で直接編集・制作できるようになったことは評価・歓迎したい。
なお、既存の多言語混在文書から UTF-8 書類を作成する方法としては、以下の方法がある。煩雑な方法なので、面倒に思われる方は手間のかからない《Muwse》などを購入・利用すると良いだろう。
《Mozilla》を日本語環境で走らせている場合、
このほか、0.9.1 以降のビルドでは「
GB18030 は、中国大陸で昨年 (2000年) 制定された新たな文字規格で、既存の GB 2312・GBK に対する上位互換性があり、可変長コードを採用することで、収録できる文字数を大幅に拡張している。2001年元日以降、中華人民共和国内の文字情報処理製品に採用することが「要求」(漢字文献情報処理研究会のGB 18030関連情報によれば「義務づけ」) されると報じられている。
これまでのところ、5月19日附で触れたように、Unicode 漢字をフルカバーしたフォントをインストールしておけば、Mac OS X 用の《OmniWeb 4.0》で GBK の Web ページをきちんと表示することができる。けれども《Mozilla》にはある「GB18030」や「
マキエンタープライズが4日、マルチスクリプトにより
このバージョンでは、メールの分類・一覧であるビュー表示の振舞が改善されている。一度表示させたビューは、以降高速表示されるようになり、また指定したビューに含まれるメールは、他のビューで表示されないよう設定できるようになった。今回は、外観・多言語処理関連などでの変更ではないが、“メールデータベース”としての利便性が大きく向上している。
新規ユーザは20日試用でき、価格は5800円。バージョン 1.8 以降に有効なシリアルを持っているユーザは、無料でアップデートできる。
《Mozilla》は、6月末にマイルストーンリリース 0.9.2 がリリースされ、毎日のように更新される「Nightly Build」は、0.9.2+ ということになっている。最近の《Mozilla》は、それ以前のものに比べて、Preference やメニュー周りの振舞いも安定してきて、Nightly Build が楽しみになってきた。また Mac OS X 用の Carbon 版も Nightly Build として頻繁に更新されるようになった。
余談だが私は《Netscape 6.1 PR1》をアンインストールした。《Netscape 6》の次のバージョンもダウンロードはするだろうが、常用はしないだろう。安定度の向上や誰かの影響もあってか、最近私は《Mozilla》のほうに特に好感をもっている。
さらに余談。最近 iBook を買った友人に《Netscape 6.1 PR》と《Mozilla》を紹介したところ、友人は《Mozilla》を選んだ。もしかすると、《Mozilla》に必要なのは普通のユーザへの知名度ともっと気軽な常時接続環境なのかもしれない。当サイトのアクセス記録では、《Netscape 6》と《Mozilla》を合わせてもシェアは3％未満だが、もっと普及して欲しいところだ。逆に《Netscape Communicator 4.7》のシェアは、2000年9月頃の20％から徐々に減る傾向にあるが、まだ10％近くもある。次回も《Mozilla》について取上げる予定だ。
Mac 用ブラウザ《iCab》は、6月末に新バージョン Preview Release 2.5.2 が公開された。中文版については、例によって iCab 公式サイトで基本構成のパッケージが配布されているが、台湾・成功大学の FTP サーバ「聖堂」と淡江大学のミラーサーバにこのほど中文豪華版がアップロードされた。JavaScript サポートの改善や各種のバグ解消などが施されているが、見たところ改善・変更は小規模なようだ。CSS 周りの大幅なサポート改善・強化が待ち望まれる。
今回の更新以降、当『蘋果派』は XHTML 1.1 に準拠してページを作成していくこととしました。
これに伴って、これまで使ってきた HTML 4.0 以降で「非推奨」とされた要素・属性を排除し、レイアウトについては、ほぼ完全に
《Netscape Communicator 4.7x》以前の Netscape ブラウザでは、スタイルシートのサポートに問題があるため、今後表示が当方の意図したものから著しく乖離します。また《Netscape 4.x》では、OS に
また、XHTML 1.1 への移行に合わせて、漢字の読みや中国語―日本語の対応の説明その他相応しいと思われる補足に ruby 要素を使うことにしました。《Internet Explorer 5》以降では、親文字の上に振り仮名を添える形式での表示を W3C 勧告以前から独自に先取りサポートしています。
例：
場合によって親文字上のruby 要素の内容や位置・フォントサイズなどが影響しているようです。
《Internet Explorer 5.x》以外の Mac 用ブラウザでは、ruby 要素はまだサポートされていませんので、ルビテキストを括弧にいれて親文字に続けてインライン表示するようにしています。スタイルシートを修正し、《Mozilla》・《Netscape 6》以降・《Internet Explorer》では、ルビテキストがふた回り小さく表示されるようにしました。
