« SpaceTag: CGIを任意のディレクトリで実行するには | ホーム | スペースタグで Tomcat が Not installed »
2006年12月12日
文字コード"EUC-JP"と"UTF-8"の違い
[AD] 楽天市場 ジャンルごとのランキング一覧
■ EUC-JP(別名 : 日本語EUC)
日本語UNIXシステム諮問委員会の提案に基づいて1985年にAT&T社が定めた、複数バイトの文字を扱う文字コードの枠組み。日本語だけでなく複数バイト言語の各国の文字コードが規定されている。日本語のEUCコードを特に「EUC-JP」「日本語EUC」と呼ぶこともある。
■ UTF-8(8-bit UCS Transformation Format)
UCS-2やUCS-4(Unicode)で定義される文字集合を用いて記述された文字列をバイト列(数値の列)に変換する方式の一つ。UTF-8では1文字を1〜6バイトの可変長の数値(バイト列)に変換するようになっているが、現在定義されているUnicode文字をUTF-8で表現した場合、最長で4バイトのバイト列に変換される。
UTF-8では、Unicodeの最初の128文字(UCS-2でいうU+0000からU+007F)を変換した結果がASCIIとまったく同じになるため、従来の処理システムとの親和性が高いという特長がある。一方、日本語などの文字は元々2バイトだったものが3バイトや4バイトで表現されてしまうため、UTF-16と比べてデータサイズが大きくなってしまうという欠点がある。
ちなみに、UTF-16ではUCS-4を完全に表現することはできないが、理論上はUTF-8はUCS-4を完全に表現できる。
(以上、e-wordsより)
■ メリットとデメリットなどに関する書き込み
日本語UNIXシステム諮問委員会の提案に基づいて1985年にAT&T社が定めた、複数バイトの文字を扱う文字コードの枠組み。日本語だけでなく複数バイト言語の各国の文字コードが規定されている。日本語のEUCコードを特に「EUC-JP」「日本語EUC」と呼ぶこともある。
■ UTF-8(8-bit UCS Transformation Format)
UCS-2やUCS-4(Unicode)で定義される文字集合を用いて記述された文字列をバイト列(数値の列)に変換する方式の一つ。UTF-8では1文字を1〜6バイトの可変長の数値(バイト列)に変換するようになっているが、現在定義されているUnicode文字をUTF-8で表現した場合、最長で4バイトのバイト列に変換される。
UTF-8では、Unicodeの最初の128文字(UCS-2でいうU+0000からU+007F)を変換した結果がASCIIとまったく同じになるため、従来の処理システムとの親和性が高いという特長がある。一方、日本語などの文字は元々2バイトだったものが3バイトや4バイトで表現されてしまうため、UTF-16と比べてデータサイズが大きくなってしまうという欠点がある。
ちなみに、UTF-16ではUCS-4を完全に表現することはできないが、理論上はUTF-8はUCS-4を完全に表現できる。
(以上、e-wordsより)
■ メリットとデメリットなどに関する書き込み
UTF-8は最初から多言語での記述を前提とされているので、インターネットのように世界中からアクセスされるようなサイトの記述に適している。
EUC-JPはUnix系OSで扱われるだけでなく日本語を前提としているので、日本語版以外を扱うブラウザからアクセスした場合、文字化けする可能性がる。
EUC-JPに対するUTF-8のメリットとしては、
・HTMLやXHTML で使われる文字コードのデフォルトが UTF-8。
・UTF-8(というか Unicode)ならEUC-JPより表現できる文字の範囲が広い。
ツール側の都合で言えば、HTMLのデザイン(またはコーディング)ツールがXMLやXHTMLを扱う機能を必須としてきたため、必然的にUTF-8を扱えるようになった。さらに、UTF-8で書かれたソース側から言えば、多国籍企業の場合、各言語用のサイトで同じテンプレートを使いまわしすることができる。表示する文字の部分だけを、ターゲットとする言語圏の文字に置き換えれば済む。
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になる)。まあ、マシンパワーの向上が全て解決するといわれればそこまでだ。