Unicode に関する誤解の誤解
初めにお断りしておくが、本項は、誰かを批判することが目的ではない。素人にありがちな誤解を正すことにある。
上記のサイトで、素人が間違いを犯しているからといって、素人を批判するつもりは毛頭ない。素人が専門知識をもたないのは当然だからだ。私としては、批判するためというよりは、読者が他山の石として眺めるために、上記のサイトを見ることをお勧めする。
Encode.pm の maintainer である dankogai 氏を素人呼ばわりするのもなかなか勇気があると思うが、じゃ、そういう本人の誤解を正しておこうか。
一方、 unicode には問題が山積みだ。だいたい、素人は unicode という言葉を使っているが、 unicode というものは一種類しかないわけではない。UTF-8，UTF-16BE，UTF-16LE，UTF-32 などが混在している。
極端に言えば、 unicode という文字コードはない、とすら言える。 unicode の文字セットは存在するが、 unicode という単一の文字エンコードはないわけだ。（ UTF-8，UTF-16BE，UTF-16LE，UTF-32 ならばある。）
極端もなにも、Unicode ってのはもともと文字集合と各文字に対応するコードポイントの話であって、エンコード方式の総称でもなんでもないし。てかなんで UTF-7 とか UTF-32{LE,BE} はないんだよ。
そして、これらの文字エンコードには互換性がない。（部分的な互換性はあるが、まともな互換性はない。）
その弊害は？
たとえば、検索しても、まともに検索できない、ということがある。GREP 検索するにしても、それぞれは異なる文字コードだから、別々に検索し直す必要がある。つまり、上記の４通りで、４回も検索する必要がある。検索時間が４倍になる。バカバカしいとしか言いようがない。
これはいわゆる、わら人形の論法だろうか？別に UTF-8 で統一すればいい話だし。ぶっちゃけテキスト を UTF-7/UTF-16/UTF-32 で保存している人は見たことない。よしんば複数のエンコーディングが存在してもワイド文字に変換しながら検索すればいい話だし*1、バカ正直に4回も検索したってまともな検索結果は得られない。あと、検索に関して言えば、Shift-JIS(MS932)/ISO-2022-JP/EUC-JP より UTF-8 の方が向いているだろう(8bit文字用の検索ロジックをそのまま使えることが少なくない)。
また、HTMLファイルを書くときは、ソースで文字コードの指定を正しく指定する必要が出てくる。間違った文字コードを指定すると、HTML文書全体が読み取れなくなる、ということがある。特に、UTF-8 しかサポートしていないソフトで、JIS第３水準・第４水準の難読文字を入力すると、まったく漢字を扱えなくなる、という問題が生じることもある。（アプリが UTF-8 には対応していても、UTF-16BE，UTF-16LE，UTF-32 には対応していない場合。）
要するに、現状のHTMLは、シフトJISと UTF-8 ぐらいが基本であって、UTF-16BE，UTF-16LE，UTF-32 には対応していないことが多い。にもかかわらず、単純に「 unicode （UTF-8）を使えばいい」という発想を取ると、UTF-16BE，UTF-16LE，UTF-32 の漢字がまぎれこんで、文書全体が読み取れなくなる、という問題が生じやすい。
は？現行の Unicode の規格では UTF-8, UTF-16, UTF-32 のいずれも扱える文字集合は同じだと思いましたけど。UTF-16, UTF-32 の漢字が紛れ込むというのも意味不明だ。あと、使っているアプリケーションの仕様を勝手に普遍的なものにするな。
また、そもそもの話、Windows は UTF-8 を採用していない。Windows がOSとして採用しているのは、UTF-16LE である。だからWindowsにおける「ユニコード・テキスト」とは UTF-16LE のことである。というわけで、「 UTF-8 への統一」なんて、ハナから無理だ。
Windows の内部コードが UTF-16LE だからなんなんだというのだ。つうか、プログラム内部で扱う形式と情報交換用の符号化形式を混同していないかい？
まぁ、なんというか、各言語ごとにコード体系を用意するのと、言語非依存のコード体系をみんなが使うのではどっちが幸せになれるかなんて考えるまでもないと思うわけですが。
