【解決編】Mac版IE5.2.3でのプルダウンメニュー表示不具合

昨日からずっと取り組んできた、この問題。経緯は、「Mac版IE5.2のプルダウンメニュー表示不具合」という記事を読んでいただきたいのですが、解決しました。

結論から言えば、「Windows-31J」が犯人でした。問題のあるサイトともメタタグでは「Shift_JIS」と記述されていたのですから、てっきり「Shift_JIS」だと思っていました。しかし、network sniffer VIGIL（このソフトはWindows用ソフトのため、WindowsXPの端末からアクセス）を使って、HTTPヘッダーを見て見ました。すると、両サイトともアクセス時に"Content-type: text/html; charset=Windows-31J"というヘッダーを吐き出しています。HTMLソース内のメタタグでは<meta http-equiv="Content-Type" content="text/html; charset=Shift_JIS">となっていましたが、HTTPヘッダーは違ったわけです。

早速、2種類のファイルを準備して、テストして見ました。するとビンゴでした!!

●1. HTTPヘッダーに「Content-type: text/html; charset=Shift_JIS」を吐き出す場合。  サンプル

●2. HTTPヘッダーに「Content-type: text/html; charset=Windows-31J」を吐き出す場合。  サンプル

前者のサンプルでは、Mac版IE5.2.3でも日本語のプルダウンメニューが表示されますが、後者の場合、日本語は空白となります。昨日、問題のあるページをローカルに保存して、IEに再表示しても問題が再現できなかったのはHTTPヘッダーに問題があるためだったのです。ローカルで保存して表示した場合には、HTTPヘッダーは出力されませんので、メタタグで指定されていた「Shift_JIS」がイキになったようです。そのため、問題の解決の糸口をHTMLソース内に求めつづけている限り、問題の原因が分かりませんでした。

では、これはサイト側の問題でしょうか？　Mac版IEの問題でしょうか？　ここからは推論ですが、Mac版IEの問題である可能性が高いです。Mac版IE5.2.3では日本語の文字コードごとにフォントの設定が可能ですが、設定可能な文字コードは、

• 日本語（JIS）
• 日本語（シフト　JIS）
• 日本語（EUC）
• ユニバーサル文字（UTF-8）

の4種類しかありません。「日本語（自動選択）」で日本語用フォントを設定してもWindows-31Jのページの表示に問題があるということは、Mac版IE5.2.3ではWindows-31Jのサイトに問題がある可能性が高いと思います。Windows-31Jなる文字コードを想定していないというべきか・・・・。

実際、HTTPヘッダーという形を取らず、メタタグで<meta http-equiv="Content-Type" content="text/html; charset=Shift_JIS">とした場合でも、Mac版IE5.2.3では、プルダウンメニュー内の日本語が正しく表示されませんでした（サンプル）。プルダウンメニューとは関係の無い日本語テキスト部分は全く問題ありません。

結論: Mac版IE5.2.3にとってWindows-31Jは鬼門である。

Windows-31Jのページにプルダウンメニューを設置してはならない。

となります。

しかし、Windows-31Jをどうしても使いたい場合もあるようです。例えば、

●JSPで特殊文字が文字化けする場合の対処方法
http://www.atmarkit.co.jp/fjava/rensai3/mojibake02/mojibake02.html

には、Windows-31Jを使用せざるをえないシチュエーションについて説明されています。昨日見た問題発生ページが、いみじくも、JSPや、JavaをベースにしたColdFusionのページ（拡張子.cfm）であったのは、こういうことが関係しているのかもしれない。しかし、Mac版IE5.2.3のゆーざーだって約100人に１人ぐらいはいます（私のサイトのアクセス統計より）。できれば、無視して欲しくないですね。

結局、機種依存文字の関係で「Windows-31J」を使うということならば（たしかに、Safariではこの方法は有効。しかし、Mac版IEでは、AppleのTech Info LibraryにもありますようにWindows-31Jにしても機種依存文字の問題は解決しません。）、いっそうのこと、素直にUTF-8を使ったほうが良いですね。UTF-8だと、対策しないとテキストエリアの文字化けになるのですが・・・・（参照バックナンバー：「Mac版IE+ココログのコメント・文字化け」）。うーん、Mac版IE君、君はマイクロソフトに見捨てられているのか？

【MacIE5.X】特定の web ページにて Select タグのメニュー候補が表示されない

昨日の記事「Mac版IE5.2のプルダウンメニュー表示不具合」の続編です。

マイクロソフトのサイトを調べてみると、それらしきものが・・・。

● [M_IE5] 特定の web ページにて Select タグのメニュー候補が表示されない
http://support.microsoft.com/?scid=kb;ja;436941&spid=2071&sid=global

これによると、現象は確認されているものの、原因は解明できていない模様。また、この文書では、UTF-8のページで起こると説明しているが、昨日の例で挙げたサイトは二つともShift_JISでした。むむ。

ただ、文字コードが関連しているとなると、「Mac版IE+ココログのコメント・文字化け」の記事で紹介しましたように、Mac版IE5.2.3では文字コードごとにフォントを設定できます。特定の文字コードでのみこの問題が発生するのであれば、このフォント関連の設定による可能性が高そうです。でも、実際にはまだ理由がわかりません。分かりそうで、分かりません。

その他、マイクロソフトでは、Mac版IEに関するトラブルシューティングをこちらに公開しています。ご参考までに。

<<2005年1月25日14時48分追記>>
解決しました。犯人は、「Windows-31J」という文字コードでした。解決編はこちら。

Mac版IE5.2のプルダウンメニュー表示不具合

今日、人力検索サイト「hatena」を見ていて、私にとって興味深い投稿がありました。

http://www.hatena.ne.jp/1106378332
に掲載されているものです。Mac版IEにおける、プルダウンメニュー（コンボボックス。都道府県や生年月日などの選択によく用いられるものです。）の表示不具合についてです。

相談内容（全文引用）

こちらMacintoshのiBookG4 (OS10.3.6)で、IE5.2を使っています。
あちこちのサイトで、フォームのリスト（都道府県名などを選択するもの）を選択しようとクリックすると、内容が表示されないトラブルに見舞われています。
どう対処したら良いでしょう？
Windows搭載マシンでみる／バーチャルPCでみる　以外で対処方法をお願いします。

ちなみにみられなかったのは、リクナビ／エンジャパンなど、でした。
試しに手元でDream Weaverで適当に作ったものについては表示されています。

私はこういう問題の原因を考えるのが大好きです。Windowsでは問題が無いのに、Mac・Linuxでのみ不具合があるページの原因解明です。早速、自分でも取り組んで見ました。

まずは、この質問者が言われている「リクナビ」「エンジャパン」の該当ページを探すところから。両サイトとも複数の登録フォームがあるため、このページだとは言い切れないのですが、

http://rikunabi-next.yahoo.co.jp/rnc/docs/cp_s00940.jsp?html_nm=ablic/syoukai.html
及び
http://haken.en-japan.com/member_registration/index.cfm

のページから送信ボタンをクリックして、（Submit→POST）して表示されるページでは、確かにMac版IE5.2（正確にはIE5.2.3）では、都道府県のリストが正しく表示されませんでした（2005年1月24日現在の話です。下のキャプチャー画像参照）。

Windowsでの正常表示

Mac版IE5.2での表示

このように、Mac版IE5.2では、正常に表示されませんでした。そのため、例えば東京都ならこのあたりだろうと勘で選ばないといけません。もし、あたりをつけて選択したものが「千葉県」であったら、その一つ下のものを選べば「東京都」になりますが、これはあまりにも非現実的。原因は何なのでしょうか？

しかし、おかしな表示になるページのHTMLソースをローカルに保存して、Mac版IE5.2で表示しても問題が再現しませんでした。さらに、スタイルシートがおかしくさせているのか？と、cssファイルやjavascriptのパスをhttp://～に変えて表示させても、問題は再現しません。

さらに、問題となるフォームは二つともPOSTして表示されるページであるため、それが関係しているのかとローカルで同じようなページを作成して、テストして見ましたが駄目でした。

ただし、プルダウンメニューのリストで表示されないのは、日本語の選択肢だけで、誕生日の月や日など数字だけのものはちゃんと表示されます。また、「UAE」という英字だけの選択肢も正しく表示されています。しかも、同じサイト内のページでもプルダウンメニューが、日本語を含めて正しく表示されるところもあります。ということは、やはりフォント関連のような気がしてなりません。非日本語フォントが該当箇所に適用されてしまっているために、何も表示されないのではと？　でも、スタイルシートをいじっても駄目だったし・・・。むむ。

以前、非力なノート型パソコン（Windows。メモリの搭載量が128MBぐらいでした。）で、コンボボックス（プルダウンメニュー）がたくさんあるフォームを表示させたところ、忍法分身の術宜しく、画面が以上に乱れたことがありますが、Macでも同じような理由でこのような現象が起こっているのでしょうか？（参照文献：マイクロソフトFAQ「[IE]<SELECT>タグを多用したWebページを完全に表示できない件」。ただし、このマイクロソフトの文書では、Windows95、Windows98、Windows98SE、WindowsMEの仕様により発生するとありますので、Mac版IEは関係ないのかもしれません。）　であれば、なぜ問題のHTMLソースをローカルに保存しても問題が再現しないのでしょうか？　分からないことだらけです。

ますます、この問題を解きたくなりました。でも、今日はもう遅いので明日にしようと思います。

<<2005年1月25日0時32分追記>>
ちなみに、MacOS9.22+IE5.0（及び5.17及び4.5）では、問題は発生しませんでした。なぜ、MacOSX（私の環境は10.3.7ですが、hatenaの質問者の環境は10.3.6。）+IE5.2でのみ発生するのか、ますます不明です。また、同じMacOSXでも、SafariやFirefox、Operaでは問題が発生しません。あくまでも、IE5.2のみの問題であり、特定のページでのみ発生し、特定のページでは一切発生しないという不思議な現象です。

<<2005年1月25日14時48分追記>>
解決しました。犯人は、「Windows-31J」という文字コードでした。解決編はこちら。

PostgreSQL 8.0がリリース - Windowsに正式対応

私は、WindowsXP、Windows2000、WindowsME、それぞれの端末にMySQLをインストールしています。本当はPostgreSQLのほうが使い慣れているのですが、今まではWindowsでPostgreSQLを利用しようと思えば、Cygwinを導入する必要があったのですが、私の場合、このCygwinのインストールがなぜかうまくいかず、断念していました。

正確に言えば、PowerGres onWindowsの評価版を1ヶ月使ったことがありますが、購入するには高かったので、評価版だけでやめました。また、MacOSX（Panther）にPostgreSQLをインストールし、WindowsからTCP/IPでの接続を行うようなこともやっていましたが、ある時、Macのxinetd.dがおかしくなって接続できなくなったのを気に、WindowsにMySQLをインストールしたという経緯がありました。また、「MySQLをサポートしているもののPostgresをサポートしていない」というレンタルサーバが多かったのも影響しました。テスト環境としてMySQLを準備するほうが好都合だったのです。

ただ、最初に覚えたのがPostgreSQLの方であったということもありますので、本当はPostgreSQLを使いたいのですが、前述のPowerGresは4万だか5万とかしますので、手が出せずにいました。すると、朗報が入ってきました。

● PostgreSQL 8.0がリリース - Windowsに正式対応
http://pcweb.mycom.co.jp/news/2005/01/19/013.html

というニュースです。まだ、ダウンロードもインストールもしていませんが、いずれ行いたいと思います。

インストール・設定の方法は、下記のサイト：
● Windows版PostgreSQL V8 RC5 - ［データベース］All About
http://allabout.co.jp/career/database/closeup/CU20050113A/

が詳しそうですので、こちらを参考にしてやってみたいです。

実は、以前、MacOSXにPostgreSQLをインストールして使用している場合には、私のやり方が悪いのか、「使い込んでいくと、データベースへの接続が著しく遅くなり、vacuumdbしても何してもあまり改善されない」というような状況もありました。ところが、WindowsにMySQLをインストールして運営するようにしたら、一気にパフォーマンスが上がった記憶があります。）。そのため、「MySQLのほうがもしかしてPostgresより高速なのではないか？」という思いも最近はありました。これには、「PostgreSQLをインストールしていたMacが非力（CPU600MHZ、メモリ256MB）ということも大きく関係している」と思いますが、どれぐらいパソコンのスペックが関係しているのか、この機会に調べて見たいです。（そもそもローカル接続とTCP/IPでの接続では差が出て当然なのかもしれませんし・・・）。「MySQLのほうがもしかしてPostgresより高速なのではないか？」というのは私の思い込みだったと証明してみたいです。

なんかだんだんLinuxを触る機会が減ってきているな。もっとLinuxも勉強しないと・・・。

Mac版IE+ココログのコメント・文字化け

別のことを調べていて、思わぬ見っけものを見つけることがあります。今回のもそれです。Macで韓国語をコピー＆ペーストすると文字化けすることがあるという件を調べていましたら（これも理由は分かりましたが、いつか時間ができたらまとめます。）、このココログの記事に対するコメント欄（textarea内）にMac版IE（5.2.3）で書き込もうとすると、左のように文字化けすることがあることが分かりました。

（私の環境でのOS9+IE5.17やOS9+IE5.0では文字化けは発生しませんでした。しかし、これはデフォルトでそうなのか、それとも私が記憶にないだけで、いつだったか設定を自分で変更していて、文字化けが発生しないのかは不明です。とにかく、MacOSX 10.3.7+ Mac版IE5.2.3では文字化けが発生していました。）

なぜ、ココログでのみ発生するのでしょうか？　他の掲示板などへの書き込みなどでは発生しません。実は、「ココログの文字コードはUTF-8である」ことが大きく関係しています。文字化けしていない掲示板ではShift_JISやEUC-JPであったために文字化けしていなかったのです。逆に言えば、ココログに限らず、UTF-8で書かれたサイトでは、Mac版IEではtextarea内に入力した文字が文字化けすることがあるわけです。

ただし、UTF-8だったらすべて文字化けするというわけでなく、textarea内で利用されるフォントをスタイルシートで指定している場合には文字化けしません。実際、ココログのライバルであるエキサイトブログでは、Mac版IEで入力しても文字化けしません。Osakaフォントをスタイルシート内で明示的に指定しているからです。

ココログでは、なぜこの対策が取られていないかは不明ですが、もちろんココログでもBLOGを作成している人間（私たちのような立場）で対応は可能です。まず、自作スタイルシートをココログで利用する方法を

●詞織: 自作スタイルシートの適用
http://siolli.cocolog-nifty.com/blog/2003/12/post_1.html
を読んで、

ココログ管理ページにログインしたあと「ウェブログ＞設定＞ウェブログ／サブタイトル名称変更」のページにある「ウェブログのサブタイトル（キャッチフレーズ）」のテキストエリア

に、スタイルシートへのパスを書いた<link rel="stylesheet" type="text/css" href="スタイルシートのURL">を書けば良いと分かりました。結果的に生成されるタグは、
「<h2>Linuxに限りませんが、（中略）検索しまくっています。<link rel="stylesheet" type="text/css" href="http://www.webfaq.jp/cocolog.css"></h2>」のようになりました。つまり、「<h2>」と「</h2>」の間にスタイルシートをサンドイッチさせているわけです。HTML文法的には問題があるようですが、これでリンクの上にマウスが乗っかったときに色を変えたり（hover）することもできましたし、まあいいかと思っています。

さらに、今回、テキストエリア内のフォントをMacではOsakaフォントが適用されるように、スタイルシート内に

textarea{
font-family:Osaka,Verdana,Arial;
}

と書きました。現在は対策済みですので、私のサイト内では、Mac版IEでもコメント入力欄が上記画像のような文字化けが発生することはないと思います。こちらに現象確認用のページを作成しましたので、Mac版IEの方はテストしてみてください。

● BLOG質問箱: Mac IEによるコメントの文字化け
http://www.mylog.jp/blogs/q-box/archives/001330.html

にも、同様な解法が紹介されています。また、多数のtrackbackが貼られているところを見ると、この問題はかなりみなさんを悩ませてきた問題であることが分かります。

では、そもそも、この問題はなぜ起こるのでしょうか？　ココログの責任でしょうか？　いいえ、そのようなことはありません。これは基本的にはMac版IEの問題です。

Mac版IEでは、上の画像のような画面でフォント設定が可能なようになっています（上の画像はIE5.2.3）。5.2.3の場合、メニューの「Explorer」→「環境設定」で「言語／フォント」で設定でこの画面が表示されます。ここで、赤色でしるしをつけた部分はプルダウンになっています。「日本語（自動選択）」がこの画面では設定されていますが、プルダウンを動かすと、一番下に「ユニバーサル文字（UTF-8）」というのがあります。その他、Mac版IE5.2.3には「日本語（JIS）」「日本語（シフトJIS）」「日本語（EUC）」も個別にフォントが設定可能になっています。

Windows版IEでは、メニューの「ツール」→「インターネットオプション」→「全般タブ」→「フォント」でフォントの設定が可能ですが、日本語・韓国語・・・・とあるだけで、Macのように日本語の中でさらに細分化されて文字コードを設定するようなやり方にはなっていません。なぜ、Mac版IEでこのようになっているかは不明です。Macだと、やろうと思えば、EUC-JPで作成されたページと、Shift_JISで作成されたページとでフォントを分けることが可能なのだと思います（試していません。また、スタイルシートなどでフォントが設定されている場合には、ブラウザで設定したフォントどおりには表示されないことがあります）。

話を元に戻します。Mac版IE5.2.3の「日本語（JIS）」「日本語（シフトJIS）」「日本語（EUC）」の設定画面を見てみると、Osakaフォントなどが設定されており確かに問題はありませんが、日本語を表記できる文字コードはこの３種類だけではありません。多言語の混在が可能なUTF-8でも日本語を扱うことができます。そして、このココログではUTF-8を採用しています。ですから、この「ユニバーサル文字（UTF-8）」がMac版IE（5.2.3）でのココログの見え方の基本を決定してしまうわけです。

この「ユニバーサル文字（UTF-8）」の設定画面でデフォルトでは英文フォントが指定されてしまっていることがtextarea内で文字化けする原因です。（これはMac版IEを製作したマイクロソフトの責任だと思います、多分。）Osakaフォントや「ヒラギノ明朝Pro W6」など日本語の表示が可能なフォントを設定してあげれば文字化けは解消するはずです。

ただ、Macユーザー全員に設定をわざわざ変えてもらうのも大変な話なので、ホームページ製作者やBLOGGERの方でスタイルシートなどでフォント設定しておくのが親切ですね。ココログでの自作スタイルシートの設定方法は上述しました。

なお、この日本語フォントの設定に関しては、

●ぞうさんちv2: Mac版IEのコメント欄の文字化け解消法
ぞうさんちv2: Mac版IEのコメント欄の文字化け解消法

を参考にさせてもらいました。

Wakwak、 「Outbound Port25 Blocking」を開始！

今日の夕方、利用しているプロバイダのWakwakから「[WAKWAK-information] 【重要】WAKWAK セキュリティ対策及び迷惑メール対策の更なる強化について」という件名のメールが届いた。

詳細は、
●セキュリティ対策及び迷惑メール対策の更なる強化について
～「Outbound Port25 Blocking」を開始！～
http://www.wakwak.com/info/news/2005/port25blocking0107.html
でも参照可能です。

メール送信時に使われる25番ポートを制限するらしい。wakwakのメール送信サーバを使う場合は影響がないが、他のISPやホスティングで提供されているsmtpサーバは、（通常は25番ポートを使っているはずだから）そのままでは使えないというのだ。

がーん!!　あまりにもショックで、これはプロバイダ乗り換えも真剣に考えないとなと思いました。というのは、私は10以上のメールアドレスを持っています。ドメインも結構取得して、その全てでsmtpサーバを利用しているわけではありませんが、いくつか使っているからです。もちろん、Wakwakのsmtpサーバに一本化すれば良いのでしょうけれど、実はそれができない理由が・・・。

Wakwakでは、メールを送信できる件数が制限されています。1日500通。実は、以前、私はローカルサーバ（Windows+Apache）の異常を知らすメール（及びプログラムが正常に処理しえたことを知らせるメールなど。）を自分自身に送信するようにプログラムしていたら、そのプログラムが暴走してしまい、一日に3千通以上を送ってしまう失態をおかしてしまったことがあるのです。そのとき、ちょうど旅行に出ていて、その暴走に気づかず、旅行から帰ってくると、インターネットに接続できなくなっていました。仕方がないので、別に契約しているプロバイダで接続して、メールを受信すると、Wakwakからメールが来ていて、「メール送信しすぎですので、アカウントを一時停止します」という警告メールが届いていたのです。慌てて、サポートに電話して、事情を説明した上で、かつ、二度とそのようなことはしませんみたいな誓約書みたいなものを書いて、やっと元に戻してもらった経緯があるのです。

（こういう場合、あて先が誰であるかは問題ないんですね。自分に送っているのでスパムメールでないことはあきらかですが、それでもネットワークの濫用であることは間違いないですね。チェソンハムニダ。）

そもそも1日500通までという制限は知らなかったのですが（規約には書いているのでしょうけれど、皆さんも大抵そうでしょうが、規約はいつも読み飛ばしてサインアップしてしまいます。）、悪いのは当然私です。そのことがあって、まず、どんなに異常が発生しても一定件数以上のメール送信はされないようにプログラムを変更し、かつsmtpサーバをWakwak以外のものも設定し、3つのsmtpサーバでメール送信を分割するようにしました（Windows+Apacheの話です。Windows環境なので、たとえばphp.iniの中でプロバイダのsmtpサーバを設定する必要があるということです）。1日500通だと、プログラムの暴走がなくても、送ってしまうことがあるかもしれないからです。

ところが、今回の措置が実施されると他のsmtpサーバが使えなくなり、いよいよ500通の制限がやばくなってしまいます。他の送信サーバが「Smtp over SSL」に対応していればOKのようですが、ざっくりと思い出した感じでは、なんだか難しそうです。例えば、私は、このココログを使っていますので、当然@niftyのメールアカウントも持っていますが、@niftyの場合、「@nifty:メール送信時の制限について」のページにも書いてありますが、セカンドメールＰＲＯでは、「Smpt over SSL」には対応していますが、通常のメールアカウントでは利用できないようです。私はセカンドメールＰＲＯは使っていませんので、無理っぽいです。他に借りているホスティング会社のメールアカウントでもやっぱり「Smtp over SSL」には対応していなかったように思います。

困りました。とりあえず夕食を食べて、もう一度メールを読み返しました。すると、http://www.wakwak.com/info/faq/index.html#port25にちゃんと、今回の「Outbound Port25 Blocking 」についてのFAQが準備されていました。さらに、

●他ISP、ホスティング会社、自社のメールでは、1日500通以上のメールを送信しています。WAKWAKの送信用メールサーバを利用すると1日500通以上送信できなくなります。何か対応策はありますか。
http://www.wakwak.com/info/faq/member_faq.html#p25_13

に、「1日500通以上送信できる送信用メールサーバをご用意する予定です。用意が整いましたら、別途ご連絡させていただきます。」と回答があるではありませんか？

何だ、だったらプロバイダを乗り換える必要もないですね。でも、この1日500通以上送信できる送信用メールサーバって無料ですよね？　有料オプションだったら、考えてしまいます。3月1日実施のようですから、もう少し時間がありますから、ちょっと様子を見てみます。

それにしても、インターネット初心者がウイルスに感染して知らないままに大量にウイルスメールを他人に送りつけるようなことはたしかに減るから良い制度なのでしょうが、ウイルス対策ぐらい自分でしますし、私にとってはありがた迷惑なシステムでしかないです。困ったものです。

Fedora Core 3 + Opera7.52の文字化け解消!!

フォントを変更することで文字化けが解決しました。
昨年暮れに書いた「Fedora Core 3 + Opera7.52メニューの文字化け」という問題（メニューの「ホームページ」が「ホ＋ムペ＋ジ」などと表示される件。）ですが、今日解決できました。やはり、Googleで事前に調べたとおり、フォントを設定することで解決できました。

なお、ここでいうFedora3.0というのは、Linux MLD mini 3.0 F（coLinuxを利用することで、Windows上で動作するFedoraCore3ベースのLinux）のことです。Windowsで動作するWindows用ソフトであるため、Windows用フォントを設定していますが、純粋Linux環境でWindows用フォントを流用することはライセンス的に問題がある可能性が高いです。「Linux MLD mini 3.0 F」のPDFマニュアルには、Windows用フォントのインストール方法が紹介されていますが、同時に以下のように注意書きが書かれています。

colinuxはWindows上で動作するソフトウエアです。colinuxがWindows上にインストールされ たフォントを使用することは全く問題がないと考えられますが、各フォントのライセンスや利用許 諾などの正当性の判断は最終的には裁判で決定されます。弊社では責任を負いかねますの で、お客様の自己責任においてご利用ください。

ですから、いわんや純粋Linux環境においてはです。

前置きが長くなりましたが、Operaを起動し、メニューの「ツール」→「設定」→「フォント」で、「インターフェイスのメニュー」だとか「インターフェイスパネル」だとかあると思います。フォント変更前は、実際には「インタ＋フェイスのメニュ＋」だとかいうふうに長音「ー」が「＋」になって、この設定画面自体がことごとく文字化けしていると思います。この各項目の「Nimbus Sans [urw]」などとあるものを、「MS Gothic」や「Arial Unicode MS」などに選択しなおします。これで文字化けが直りました。

つまり、この「Nimbus Sans [urw]」なるフォントが文字化けの原因だったようです。さらに、「Wandering Linux 5-1 font　test」というサイトで適切に設定されているかテストしてみました。すると、本文でも一部の漢字が文字化けしていることが分かりました。全部ではなく、本当に一部です。例えば、「試験」が「試蛸」と文字化けします。あるいは「検証」という言葉が「検贊」のように文字化けしています。とりあえず、先ほどのフォント設定画面で関係のありそうなもの（「ＣＳＳフォントファミリーセリフ」などのフォント。）を全て、Windowsから持ってきたフォントで設定したところ、本文中の文字化けも解消しました。

オフィスを飛び出し、家庭にも進出するLinux

今、年末年始に、たまっていたメールを片付けています。そんな中、目に入ったのがITmediaの

● オフィスを飛び出し、家庭にも進出するLinux
http://www.itmedia.co.jp/pcupdate/articles/0412/27/news014.html

という記事。元記事はロイターのニュースで、アメリカの話ですが、日本でも同様な現象は増えていくと思います。例えば、Turbolinux 10 Desktop Basicは、Windowsと比べても遜色の少ないデスクトップ環境を提供しています。無料ではありませんが、3千円台と非常に安い。パーティションの分割さえ、Acronis Disk Director Suite 9.0 などのパーティション操作ソフトを使って作成できれば、Linux用に新しくパソコンを買うことなく、既存のWindowsシステムとの併用（デュアルブート環境）が可能でしょう。私も、Acronis Disk Director Suite 9.0 でパーティションを分割し、デュアルブート環境にしています。Turbolinux 10 Desktopも使っていますが、概ね満足しています。

ただ、パーティション操作はなんだかちょっと難しそうと考えられる方もおられるでしょう。それでも、Linuxに触ってみたいと考える場合、Knoppixなどの1CD Linuxを試すか、もしくはOSの入っていないパソコンを購入して、さらの状態からLinuxをインストールするかですね。前者の場合、データの保存などで少し敷居がありますし、セキュリティアップデートのたびにCDを焼きなおさなければならないなどの問題があります。後者の場合は、すっきりしたやり方ですが、必ずしもインストールに成功して、さまざまな機器・サービス（X環境・サウンド・インターネット）で問題なく動作するか保障がありません。

ですから一番確実なのは、Linuxがプリインストールされたパソコンを購入することです。であれば、周辺機器との相性問題は分かりませんが、少なくともサウンドが鳴らない、Xが起動しない、などの問題に苦しむことはないでしょう。メーカーから販売されているプリインストールLinux機が、何もしないのに音が鳴らなかったりしたら、完全な欠陥商品ですから、そんなことはまずないでしょう。

実際、最近、相次いでLinuxがプリインストールされたパソコンが販売されてきています。少し、まとめてみました。

● Linuxがプリインストールされたパソコン・PDA
http://www.webfaq.jp/linux/

探してみれば、Turbolinuxだけでなく、Vine Linux、Lindowsがプリインストールされたパソコンなどが販売されています。

ただ、唯一気になるのが、「LinuxはWindowsよりセキュリティがしっかりしている」というイメージ先行です。詳細に検証した結果、そういう結論に至るのなら良いのですが、イメージだけが先行していないか心配です。単なるアンチ・マイクロソフト的な考えの人（こういう人はたいていアンチ・ジャイアンツ？かアンチ・自民党？　って、それこそ偏見ですね。失礼!）がそういう発言をしていないか気がかりです。Linuxがメジャーになるなら、ウイルスだって、わんさと出てくるでしょうし、オープンソースゆえに、攻撃者にも脆弱性が見えやすいという懸念はないのかと心配になります。

Macでも同様のイメージがあり、「MacはWindowsよりセキュリティがしっかりしている」というイメージがあります。しかし、実際には、Windows Updateのように、Appleも、たびたびセキュリティ・アップデートを公開しています。また、ウイルスも実際、いくつか存在します。ですから、私の場合、Mac（Panther）にはしっかりウイルス対策ソフト（Norton Antivirus）を入れています。

（今のところ、お金の問題もあり、Linux環境には、ウイルス対策ソフトは入れていません。今後、家庭でのLinuxユーザーが増えていくなら、ウイルスの増加も十分に考えられ、ウイルス対策ソフトの導入は家庭用Linux環境でも「must」になっていくことでしょう。Linuxにおけるウイルス対策について、近日中にGoogleでまた調べようと思います。）

文字コードとサーチエンジン

BLOG（ブログ）に限らずホームページを運営しているものは、サイトを公開している以上、基本的にはアクセスが欲しいものです。誰にも読んでもらえない場合よりは読んでもらったほうが良いからです。ましてや広告収入で食っていこうと思ったら、アクセス数は絶対です。

必然的に、サイト運営者はアクセスを稼ぐために、さまざまなプロモーションを行うわけですが、その代表的な方法としてサーチエンジン登録があります。ところが、サイトを登録したくてもサーチエンジンに登録できない場合があります。それは、Yahoo!のサーファーの審査に通らないとかいう話ではなく、Infoseekというロボット型検索エンジンでの話です。Infoseekには、Googleとの提携により表示されるGoogle検索と、独自の検索技術に基づくinfoseek検索があります。このInfoseek検索で検索されるようにするために、こちらでサイト登録することが可能です。この登録フォームでは、サイトの文字コードをまず自己申告しないと登録できないようになっています。「Shift_JIS」「EUC-JP」「JIS」はありますが、「UTF-8」はありません。このココログの文字コードはUTF-8ですから、登録できないのでしょうか？　ためしに、デフォルトで選択されている「SJIS」を選択して送信してみました。

エラー(C03)

・ページ内に指定された文字コードでは解釈出来ない文字を発見しました。

ページ内で２種類以上の文字コードが使用されている可能性があります。
ソースの文字コードは１種類に統一してください。

のように表示されます。つまり、「自分で『SJIS』だと言いながら、『SJIS』には存在するはずのない文字コードが混じっている！！」って怒っているわけです。それもそのはず、「UTF-8」なのですから。「SJIS」でないコードが 混じっている 　という次元ではありません。

Infoseekでは、ココログの登録は不可能なのでしょうか？　むむむと1分ほど悩んで、もしかしてと、文字コードの自己申告箇所に「わからない」という項目（ラジオボタン）があることに着目しました。もしかして、これは「SJISなのかEUCなのかJISなのか分からない人は、こちらでチェックしてください」という意味ではなく、「SJISなのかEUCなのかJISなのか、それともUTF-8なのか分からない人は、こちらでチェックしてください」の意味なのかも。はやる思いを抑えつつ（ちょっとオーバー）、「わからない」を選択して、登録作業開始。今度はエラーが表示されません。こうして、無事に登録できました。

「わからない」と書いてあるので、言葉尻に惑わされました。私は明確にこのココログの文字コードは「UTF-8」だと「知っている」ので、「わからない」ことはないのですが、「わからない」を選ばないと登録できませんでした。でも、もしかして、エラーが表示されなかっただけで、やっぱりInfoseekのデータベースには登録されないのかもとちょっと不安です。どうせ、アクセスのほとんどは経験上、GoogleかYahoo! Japanのロボット検索エンジン（YST）ぐらいからしかないから、まあいいかとも思いますけどって、Infoseekの人が聞いたら怒りますね。

心配になったので、Infoseek検索で「ココログ」を検索。ココログでないBLOGがかなり検索されますが、ココログ仲間もちゃんと検索されている模様。つまり、「UTF-8」でも登録は可能なようです。だったら、「UTF-8」というラジオボタンをつけてくださいよ、 Infoseekさん。（もしかしたら、UTF-8のサイトは、やっぱりこのフォームからの登録は不可であるけれども、どこかのサイトからリンクされていて、ロボットがリンクをたどって巡回した場合に限り登録されるという仕様なのかもしれませんが・・・。）

Infoseek検索では、「.comドメインなどjpドメイン（.co.jpや.jpなど）以外でEUC-JPのホームページ」を先述の登録フォームからは登録できないこと（参照： http://shikariki.com/3infoseek.html） は以前から知っていましたので、また同じような問題があるのかな？と焦った次第です。

<<これからはやっぱりUTF-8の時代でしょう!!>>
ところで、サーチエンジン（というかインターネット世界全体）がUTF-8に対応していくのは時代の流れだと思います。韓国語（ハングル）や中国語などの外国語を日本語と混ぜて使うにはUTF-8でないと何かと不便です。もちろん、数値文字参照（「천」を「&#52380;」のように表記する。）を使うことで、EUC-JPやShift_JISの文書の中でこれららの言語を混ぜることは不可能ではありませんが、何かと不具合が起りがちです。

「韓国の部屋」さんがご指摘のように、例えば、日本のサーチエンジンの代表的存在であるInfoseekやYahoo! Japan、そしてGooの文字コードはEUC-JPですが、これらのサイトで韓国語を入力し検索すると、さんざんな結果になります。「천」をGooで検索すると、まずInternet Explorerは「&#52380;」を検索するように伝え、Gooは的確に検索結果を表示します。検索結果は正しいのですが、その表示の段階においておかしくなります。セキュリティ上の理由から「<」「>」「&」はエスケープ（escape）しているのですが、この際に「&#52380;」という数値文字参照の中に含まれる「&」もエスケープされます。そうするとHTMLソース内では「&amp;#52380;」と表示され、ブラウザ上には「&#52380;」と表示されることになります。HTMLソース上で「&#52380;」となっているならば、「천」という韓国語がブラウザ上には表示されるはずですが、HTMLソース内で「&amp;52380;」（エスケープ処理の結果）となっているため、韓国語はブラウザに表示されません。その代わりに、ブラウザ上には、「&52380;」というように「&」「#」「数字」だけが表示されます。こうして、いわゆる”文字化け”が発生します。

同様な問題として、BLOGでも、ココログのようにUTF-8を採用せず、EUC-JPのところ（楽天広場など）では、韓国語の表示に問題が生じます（参照： 「Google検索日記『楽天広場における韓国語表示』」）。エキサイトブログの場合は、ココログ同様UTF-8なので韓国語も問題ないようです（参照： Googleで「韓国語」を含むエキサイトブログの検索結果）。

EUC-JPで作成されたWEBサービス（検索エンジンやBLOGなど）では、ハングルの表示を許すようにするためには、「&」の処理が複雑になりすぎるか、セキュリティ上好ましくないのかもしれません。国際化がさらに進んでいくと思われる時代、やっぱり今後はUTF-8の時代ですね。XMLやRSSの普及を考えてもUTF-8で書かれたホームページが増えることはあっても減ることはないように思います。

UTF-8は私がインターネットを始めた7年ぐらい前は、サポートしているブラウザ自体が少数であった記憶がありますが、今はほとんどのメジャーなブラウザ（Windows、Mac、Linuxを問わず。）でサポートされていますし・・・。（参照：　「ブラウザ別・メールソフト別UTF-8対応状況」。この参照記事ではLinuxブラウザのUTF-8サポート状況は検証されていませんが、私が試した限りでは、Firefox、Netscape、OperaなどメジャーなブラウザすべてでUTF-8はサポートされていました。）

Macでのパーティション分割

数日前、「MacでVineLinux」という記事の中でMacにおけるパーティション分割について書きました。あれからいろいろ調べて分かったことをまとめてみます。自分のための備忘録でもあります。

先日の記事の中で、VolumeWorksという製品について書きました。パーティションを分割・リサイズする際に、データを消さずにできるという製品です。その後、この製品は、アメリカのSubrosaSoft.comという会社の製品であることがわかりました。こちらに製品紹介ページ（英語）があるのですが、「この手のパーティション操作には常に危険が伴うので、バックアップは必ず行ってください。また、Apple DiskUtiltyなどを使ってハードディスクのチェックを行ってください。」というような文言が随所に繰り返されていて、幾分怖くなりました。

また、どんな製品でも、環境によって当たり外れがある場合がありますし、１ユーザーの意見が絶対とは思いませんが、こちらの記事（英文。MacFixIt - VolumeWorks: Partition corruption）を読んでいたら、余計に怖くなりました。

さらに、日本語の体験記も「えむろぐ - Echoo!-エコログ」さんで発見。起動できなくなるトラブルに見舞われた体験を読んでしまいました。むむむ・・・。

前傾の記事：「MacFixIt - VolumeWorks: Partition corruption」の下のほうに、サイト訪問者によるコメントが載っていたのですが、その中で、iPartitionという別のパーティション操作のためのMac用ソフトがあることを知りました。早速、iPartitionのサイト（英語）を訪問してみました。気が付いたこといくつか・・・。

• 少し安い。£24.95とありますので、約4,900円ほどのようです。volumeworksの英語版（本家）は59.95ドルですから約6,000円。日本で発売されているVolumeworksはダウンロード版で6,930円です。為替によって多少変わるでしょうが、iPartitionの方が総じて安いと言えます。
• iPartitionにはデモ版があります。VolumeWorksには、デモ版はありません。
• iPartionのサイトには、（本当かどうかは分かりませんが）「iPartition won't break bootable OS 9 partitions.」（iPartitionはOS9の起動可能なパーティションを破壊しません。）とあります。一方、VolumeWorksのほうには、OS9のデータは破損しないが、起動できなくなるので、再インストールが必要になる旨、明記されています（2005年1月1日現在）。

もちろん、これらの情報だけで製品のよしあしは決められないのですが、VolumeWorksにしてもiPartitionにしても、インストール前にバックアップは必要だろうし、またDiskエラーが発生しないかどうかあらかじめチェックする必要があったりと、結構面倒そうです。

であれば、（元のディスクをAとして）「Carbon Copy Cloner」を使って外付けハードディスクにバックアップBを取っておいて（万が一のための起動ディスクにもなります、Macの場合。）、バックアップした起動ディスクBの方から起動します。その上で、現在外付けハードディスクとして認識されているはずのディスクAのパーティションを再フォーマット・パーティション分割してしまいます。さらに、ディスクBの中身をCarbon Copy ClonerでディスクAに戻します（いきなりディスクAに戻すのが怖い場合は、もうひとつ外付けハードディスクCを準備しておいて、Cにバックアップを取り、安全性を確認してからディスクAに戻します）。こうして、ディスクAはデータは保全されたままで、パーティションを分割できます。手間はかかりますが、バックアップ＋VolumeWorks（or iPartition）とあまり変わらないようにも見えます。

専用ソフトを使わないで行う上記のやり方の問題点としては、A→B、B→Aと2回データの移動を行っているので、その間にデータの破損が起きないのか？ということがありますね。どちらが安全性が高いかの判断は、もちろん人それぞれだと思いますけど・・・。

もちろん、外付けハードディスクに「Carbon Copy Cloner」でバックアップを取った上で（起動ディスクとして作成）、iPartitionなりVolumeWorksを試せば一番良いのかもしれません。お金に余裕ができれば、私もその方法を試してみたいなと思っていますけど・・・。

※ パーティション操作は常に危険を伴います。必ず自己責任で行ってください。 ←やっぱり最後はこうなる。