この質問は「島国根性プログラマー」への煽りです。
ファイル名が外国文字の圧縮ファイルを解凍できず、同じく画像ファイルを閲覧できず、日本語化CGIは外国語を扱えず……。いつまで島国根性を続けるんでしょうか?
Windowsも2000からUnicodeベースになっている現在、もし日本語を扱うのにUnicodeではまずい合理的な理由があれば滔々と述べていただければ幸いです。
ちなみに、はてなはグループでUTF-8化してくださったので非常に感謝してます。
http://euc.jp/i18n/ucsnote.ja.html
従来の文字コードとUnicodeの対応に関する諸問題
その1、既存のシステムとの整合性の問題
全てのシステムをUnicodeで書き直すのは現実的ではない。
特にメールシステムは現在でもJISが標準だが、これはどうするのだろう?
http://www.linux.or.jp/JM/html/LDP_man-pages/man7/unicode.7.html
Manpage of UNICODE
その2、Unicodeと一口に言っても実装方式には
UCS-2、UCS-4、UTF-8、UTF-16などがあり、
現在はUTF-8が主流だが、将来どうなるか不明。今は様子見の段階である。
(最初にUCS-2を考えた奴はアホだと言っておこう)
その3、EUCやShift-JISはバイト数/2で文字数を算出できるがUTF-8は先頭からスキャンしないと文字数を算出できない。
JISコードとかと同じでUTF-8はバイト数=文字数ではない。
最後にMSもShift-JISと微妙に異なるCP932という規格を勝手につくってさらに文字コードを混乱させている。
個人的にはUnicodeは嫌いだ。
どうせ統一的に扱えないのならJISみたいにシフトコードを定義し、あとはコードのマッピングはそれぞれに任せた方がよいと私は考える。
この際全員英語を使えば…
あっしまった、私英語駄目だ(汗
>この際全員英語を使えば…
>あっしまった、私英語駄目だ(汗
ウケタ(笑
Unicode対応CGIの一例です。終了した質問ですが、参考までに。
http://homepage3.nifty.com/marbacka/msearch/
5.6未満のPerlが入っているサーバーで使ってますが、問題なくUTF-8を検索できています。
http://homepage3.nifty.com/marbacka/msearch/
もう回答は締め切ってしまっているようなので、こちらに書きます。
> もし日本語を扱うのにUnicodeではまずい合理的な理由があれば滔々と述べていただければ幸いです。
に関して、1の回答の[その3]のCP932問題 は大きいと思います。
> その3、これは外国語を切り捨てる理由としては弱いかと。
> 最後、MSの新規格は論外。
とおっしゃってますが、本当にそうでしょうか?
よく考えてみてください。
windowsにおいて、JIS系コード(ShiftJIS,EUC-JP,ISO-2022-JP)とUnicodeとの変換が、一般規定と異なる為、“〜”を初めとするいくつかの文字はUnicode表記をするとWindowsと他OSとで表示が異なってしまいます。つまり文字化けが起こる。
JIS系コードならばこの心配はありません。
なので、日本語の表示をさせるには、エンコードはJIS系コードを用いるのが安全なのです。Webに関しては、Unicodeでしか表示できない文字も&#で始めるUTF-8のコード表記で書けますから。
“〜”を初めとする問題のある文字を一切使わないなら別ですが、そうでないなら。
windowsが他の一般規定を無視した為、Unicodeで書いた場合に上記文字化けを防ぐ方法はありません。(windowsのみで動作するソフトで他OSでは使わない物、またはその逆ならUnicodeを使用しても良いのですが、CGI等はそうではないですよね。)
それでいて、JIS系コードを用いた場合に、Unicodeの文字を表記する手法はあります。
これを、理由として小さいとは私は思いません。
外国語を切り捨てる理由、という点について誤解があるようですが、わたしは常に日本語と他の言語の文字を同じHTMLファイルの中で扱う必要性があります。それに目をつぶって、どうしても日本文字だけにこだわり、たとえば(検索の利便も捨てて)外国文字を画像ファイル化して埋め込むことを考えなければならないほどの重大な理由があるのだろうか、あるいは(面倒だから、ではなく)積極的に日本文字以外を切り捨てなければならないと考えているような人がいるのだろうか、という趣旨の質問でありました。
「〜」問題については、すでにMovableType携帯対応CGIのMT4iでは解決されていますので、理由にはならないと思います。
また、JIS系コード上(たとえばはてなダイアリー)で実体参照を使えば他の言語の文字が表示されるのも知っていますが、例えば半分が中国語のとき、そのまま貼りつけられないでいちいち変換しなければならないのは致命的です。ですから、中国語の話題については、UTF-8のはてなグループに移行せざるを得ませんでした。
やっぱり今のところ、「面倒くさい」「日本語以外の言語のことは念頭に置いていない」以外に日本語文字コードでなければならない理由はないように感じます。
単純なCGI程度のプログラムなら良いのですが、非常に大きなデータベースを扱うかうようなプログラムを書かれているかたは、このような問題には非常にデリケートになるのではないでしょうか?
個人的に大きいと思うのは、既存のスクリプトがそのまま流用出来なくなるって事でしょうか。というか、文字コード依存のスクリプトをたらたら書き出すプログラマの腕もどうかな、と(ごく一部、どうしても依存のコードを書かないと目的を達成できないとかはさておき。)。Shift_JIS の利点は、現状ほとんど無いと思います。制御コードが含まれる2バイト文字とか。散々言われていることですけど。EUC-JP も以下同文。ISO-2022-JP は複雑だからヤダ。
Perl 上の Unicode のサポートの問題は、UTF8 フラグとか直感的にわかりにくい構造を持っていることでしょうかね。少々マニュアルを読めば理解できるのですけど、それを怠っている人が多いこと。ただ、perl 5.8 over の嬉しいところは、encoding.pm が入出力にフィルタとなって、入出力の文字コードを変えてくれるので、既存のシステムとの整合性を取りつつ切り替えることが出来ると思いますがね。
あ、Unicode でただ気になるのが \ <- これが ¥ にならないことです。ちょっと気になる。いやあ、慣れの問題ですが。
処理能力がないシステムでは Shift_JIS とか EUC-JP を使用するしか無いんでしょう。そんなにマッピングが多いと、メモリなどの資源の問題もありますし。
# そんな古いシステムなんか捨てちまえ! という意見はなしで(ぉ。