[Edit][Create New]
[ IndexPage / ネットとプログラミング / web296 / No88.txt ]

No88.txt

文字コードについて(文字コードの選択)

現在Web上(HTMLドキュメント上)で日本語を扱う際、一般的にISO-2022-JP、
EUC-JP、Shift_JISの3つの文字コードが使われているのは皆さんもご存知だと思
います。今回はこれらの文字コードの特徴と、長所短所について解説していきま
す。

まず、3つの文字コードについて(今回はUTF-7などのUnicodeは除きます)、簡単に
その成り立ちを見ていきましょう。

まず最初にISO-2022-JP。この文字コードと日本のInternetの歴史とは深い関わり
があります。1984年、首都圏の3大学間をUUCP接続で結ぶJUNET(ジュネット)が組
織されました。その後もJUNETは多くの大学間を結び、国内のInternet整備の一端
を担うわけですが(JUNET自身は1994年にその役割を終えて解散)、当時主に使われ
ていたプロトコル、NNTP(ネットニュース)とSMTP(いわゆる電子メール)は、7ビッ
トコードしか通すことができませんでした。

当時UNIXで主に使われていたEUCは、8ビットコードであるため使えません。そこ
でISO-2022規格の日本版であるISO-2022-JPがInternet上での標準的な文字コード
として使われてきた経緯があります。最近ではあまり聞きませんが、当時は
ISO-2022-JPは、別名Junetコードなどとも呼ばれていました。

次にEUC-JP。EUCとは「Extended UNIX Code」の略であり、「拡張UNIXコード」と
略されます。ISO-2022を扱いやすくするために生まれたもので、その名の通り
UNIX上で非英語圏言語(特にアジア言語)を扱うために設計されたコードです。設
計の中心にはAT&T社が関わっていたといわれています。EUC-JPはその日本語版で
あり、現在でもUNIXの内部文字コードとして広く使われています。

最後にShift_JIS。このコードは他のコードに比べてちょっと変わった生い立ちを
持っています。この文字コードは当初「シフトJIS(別名MS漢字)」としてMS-DOS向
けにMicrosoftが設計したもので、JIS X 0201の右半面(お馴染み、いわゆる半角
カナ)とJIS X 0208を共存させるために、JIS X 0201の領域を避けるようにJIS X
0208の方の領域をずらせて(シフトさせて)定義したため、この名前がついていま
す。日本語のみを対象としている点でも特殊と言えます。

当時はMicrosoft社のOS(やウインドウマネージャ)に付随しているコードである、
というだけで厳密な規格書は存在しなかったのですが(実装ごとの規格は存在する
場合がある)、その後JIS X 0208の方が、1997年版の附則としてシフトJISのエン
コード方法を紹介し、これを根拠にShift_JISがIANAに登録されて、晴れて一般的
なInternet上のコードとして使われるようになりました。なお、皮肉なことに
JIS X 0208その後の版ではシフトJISに関する附則は削除されています。

なお、シフトJISとShift_JISは、後者がNECやIBMが独自に拡張した文字(いわゆる
丸囲み数字などの機種依存文字)を含んでいないという点などで相違があり、同じ
文字コードではありません。

それではそれぞれの長所と短所を見ていきましょう。

ISO-2022-JPは前述したとおり、3つの文字コードの中では唯一7ビットで表現でき
る文字コードで、電子メールなどでは今でもこの文字コードが主に使われていま
す。また、Shift_JISとEUC-JPが混同されやすにのに比べ、ISO-2022-JPは独特の
エスケープシーケンスを含んでいるため、もっとも判別が容易です。

短所としては、エスケープシーケンスを含むため、文字数とバイト数が比例せず、
文章の途中から文字列を抜き出すのが困難だという事があげられます。極端な話、
ファイルの途中で無作為に文字列を取り出した場合、それが日本語部分なのか
ASCII部分なのか、全く区別がつかないということです。ですからプログラムで複
雑な文字列操作をする場合かなり面倒な処理が必要で、一旦EUCなどに変換してか
ら処理するということも多く行われています。

EUC-JPの場合、逆に全て8ビットコードですから、ASCII部分と日本語部分との判
別が容易ですし、文字数とバイト数も完全に比例の関係にあるため、計算機での
処理にもっとも向いています。CGIスクリプトなどがEUC-JPで書かれることが多い
のもそのためです。また、ISO-2022-JPとの相互変換も比較的容易です。

短所としては、元々UNIX用として開発されたため、他で使われることが少なく、
おそらく3つのコードのうちもっとも普及率が低い点。筆者個人としては、いわゆ
る半角カナをサポートしている割に1文字あたり2バイト喰ってしまうのが納得い
かないです。

最後にShift_JISの場合。長所は、なんと言ってもパソコンの内部コードとして
(Shift_JISの類似コードが)広く使われているので、パソコン用のアプリケーショ
ンの開発や、パソコン上でドキュメントを作成する際に便利な点でしょう。

短所は、何といっても正式な規格書を持っていない点(JIS X 0208のある特定の版
のオマケに含まれているに過ぎない)。また、MS漢字など規格の定まっていない類
似コードが多く、混乱や誤解を招きやすい点。半角カナを使うとEUCと混同されて
しまう点(これはEUCの短所にも含まれますが)。更に7ビットコード混在なので、
プログラムなどを書く際、7ビットの特殊文字が知らずに紛れ込んでいてエラーを
起こすことが多くあります(これはISO-2022-JPにも共通する欠点です)。

以上ざっと挙げてみましたが、本当にどのコードも一長一短で、どれか一番良い
ものを選べと言われても筆者にはとうてい不可能に思えます。

ただ重要なのは、これらの長所と短所をきちんと踏まえ、要所に適した文字コー
ドを選択していくという、ごく当たり前のことだということです。

別にアナウンスがあったように、今回でひとまず最終回となります。長い間ご愛
読いただき本当にありがとうございました。