EUCボクメツ委員会

37 名前：login:Penguin [01/10/16 12:50 ID:uARHilua.net] >>35 なんか違うぞ ISO-2022-JP はそれまで慣習として通信で使われてた7bitJISコード (ISO-2022にそこそこ準拠)を、fj.* と Internet Mail で使うものとして、 制限つけてRFCとして書き起こしたものだ。名前に反して実は ISO-2022 に 正確には準拠してないのは有名だ。7bit JIS としてなら歴史はあるが、 まとまったのは一番新しい。 まあ、たぶん言いたいことは「ISO-2022 が先にある」ってことなのだろう。 それなら正しい。 ShiftJIS は、Microsoft社が MS-DOSに日本語を導入するにあたって、 半角カナを残しつつ漢字コードをわりこませるためにASCII社に作らせた もんだ。変態的な変換で気持ち悪いことと、当時既にあった国際規格の ISO-2022を全部無視したこと以外はそんなに悪いコードじゃない。 いってる通り、不幸の文字があるので、ASCII処理前提でかかれていた コードは全部書き直しの憂き目にあったのはそのとおり。 んで、EUC-JP は別にそのあたりを教訓にしたのではなくて、 UNIX の国際化を行うにあたって、普通に 8bit 版 ISO-2022 の使い方を日本語用に確定しただけのものだ。これは当時国内でUNIXを 作ってたメーカが、既に同等の手法で自社UNIXを国際化してたのが 細部が異なってたのを統一する形でつくられた。 ISO-2022 のままだと、ステートが爆発するので扱いにくいのは事実。 でも、SJIS と EUC-JP では、正しくまじめに国際化するのなら、質的 には有利/不利の差は存在しない。 ただ、世の中には、「ascii依存」なソースがあまりに多い。で、EUC-JP の 場合、コードが重ならない関係で、8bitスルーにさえなれば、日本語が 壊れず通ってしまう。こういった「手抜き国際化」は EUC-JP のが やりやすいのは確か。 ちなみにこの条件は UTF-8 も同じだ。だから、最近のあちらさんの アプリケーションはこれで処理したがってる。ソースをあんまり 修正しなくて良いってことね。 UTF-8 は、互換性は目をつぶるとしても、日本語だけを扱うとしたら パフォーマンスが悪くなるのと、通信量が膨れ上がるのが欠陥 (漢字は6byteになる)。まあ、マシンパワーの向上が全て解決すると いわれればそこまでやね。

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef