ASCII

IIJ技術研究所 山本和彦

前回予告したように、今回から文字コードについてお話します。まず、ASCII とその仲間達から解説していきたいと思います。おそらく多くの人が ASCII のコード表を眺めたことがあるで、「ASCII ぐらい知っているよ」と思うに違いありません。

しかし、みなさんが曖昧に認識しているであろう 「ASCII」 は、実は奥が深いのです。一番使われている文字コードの割には、通信において問題をたくさん起こしてきました。 今回は ASCII の奥深さが分かって頂けると幸いです。

文字集合の枠組

まず、ASCII のコード表を眺めてみましょう。(Unix なら、man ascii で表示されます。)

ASCII

左の 2 列が「制御文字」、右6列の多くが「図形文字」になっています。右6列の中で特殊なのは、左上の SP (SPACE, 0x20) と右下の DEL (DELETE, 0x7F) です。SP は図形文字なのですが、図形が定義されていません。(つまり、空白です。)DEL は、もともと紙テープの打ち間違いを消去するために定義されており、どちらかというと制御文字です。(後程説明する ISO/IEC 646 では、DEL は DEL であり、制御文字だとも図形文字だとも定義されていません。後述の ANSI X3.4 では 制御文字に分類されています。)

文字の詳細に拘らずに、これらの関係を図示すると以下のようになります。

C0C1

この図はとっても大切です。ISO の文字集合は、この図に基づいて定義されます。基本的に文字集合では、図形文字を定義しますから、制御文字 32 個分は利用しません。また、図形文字を使うといっても、SP と DEL の領域は利用しない 94 文字集合と、6行全部を利用する 96 文字集合があります。たくさんの図形文字を定義したい文字集合では、94 × 94 か 96 × 96 の領域を使います。

まとめると、ISO が定める文字集合は以下の 4 つに分類できます。

これは来月学ぶ ISO 2022 の際に必要となりますから、ぜひ憶えて下さい。

ISO/IEC 646

ASCII を理解するには、まず ASCII の枠組を定めているISO/IEC 646 を学ぶ必要があります。まず、ISO/IEC 646 では、上記のように制御文字、SP、図形文字、DEL という領域を定義しています。そして、94 文字集合の意味を定めています。ISO/IEC 646 で定義されている図形文字を以下に図示します。

ISO/IEC 646

注意して頂きたいのは以下の項目です。

注：ASCII などでは NUMBER SIGN と DOLLAR SIGN を選択しています。ISO 8859 1(Latin1)(の右側)はISO/IEC 646 に則っている訳ではありませんが、それぞれの位置に POUND SIGN と CURRENCY SIGN を定義しています。

ASCII(IRV, ANSI X3.4)

ISO/IEC 646 に則って定義されている文字集合の 1 つが ASCII です。1991 年版の ISO/IEC 646 で定義されている IRV(International Reference Version) が ASCII です。これとは別に全く同じ ASCII の定義が ANSI から出されており、ANSI X3.4 1986 と呼ばれています。MIME では、ASCII という言葉が曖昧に使われていることを嫌い、ISO/IEC 646 IRV and/or ANSI X3.4 にわざわざ US-ASCII という名前を与えています。

ASCII のコード表を眺めれば明らかなことですが、老婆心ながら ASCII(ISO/IEC 646 IRV, ANSI 3.4) の定義を以下に示しておきます。

制御文字(ISO/IEC 6429)

ASCII のコード表を見るとなんだか制御文字も定義されているような気がします。ASCII が利用する制御文字は、ISO/IEC 6429 で定められています。しかし、定められているといっても、名前が決まっているという程度に考えた方がいいでしょう。

通信では、通信する者同士がなんらかの合意(プロトコル)を形成していなければなりません。文字コードに関しても合意が必要です。ASCII の制御文字に関しては、ほとんど合意がないといってもいいくらいなのです。

たとえば、DEL(ELETE, 0x7F) を受け取ったらどうすべきでしょう？似たような BS (BACKSPACE, 0x08) を受信したら、どう振舞うべきでしょうか？

インターネットでは電子メールを定めている RFC 822 が、他のプロトコルに対しかなりの影響力を持っています。ASCII の制御文字に対してもそうです。RFC 822 では、以下の 1 つが決まっています。

注：CR はタイプライター時代に印字位置を行頭に移すという意味を持っていました。LF はタイプライター時代に紙を送る(つまり印字位置を次の行に移す)ことを意味していました。

決まっている制御文字はたったこれだけなのです。さらに付け加えると、単独で現れる CR や LF の意味さえ決まっていません。RFC 822 を改訂している RFC2822 では、以下の規則も付け加えました。

MIME を定めている RFC の 1 つである RFC 2046 では、4.1.2 章において以下のような考察を加えています。

FF に関しては Control-L と表現した方が分かりやすいかもしれません。メールリーダの中には Control-L を処理して、本文をページに分割する機能を持っています。僕個人としては、ビープ音を鳴らす BEL(0x07, Control-G) も実質的な標準に入れてもいいのではないかなと思います。

このように制御文字に関しては何も決まっていないに等しいので、制御文字をやりとりするとしばしば問題が起こります。なお、ESC (ESCAPE, 0x1B)でさえ、ASCII の範疇では意味が決まっていないことは特筆すべきでしょう。

JIS X 0201

ISO/IEC 646 に則った文字集合の 1 つに、日本人が馴染みの深い JIS X 0201 1997 Latin set(JIS C 6220 1976, JIS X 0201 1976)があります。これは、ほとんど ASCII ですが、以下の 2 点が違います。

日本では ASCII と JIS X 0201 の両方が使われていますので、この 2 点の相違がしばしば問題になります。たとえば、「￥」マークのつもりで送ったのに、相手側では「＼」として表示されることがよくあります。これは、ASCII と JIS X 0201 とを厳密に区別していない、あるいは文字集合とフォントの対応が取れていないシステムがあるためです。

念ため JIS X 0201 1997 Latin set のコード表を以下に示します。

JIS X 0201

ISO/IEC 646 の仲間たち

ついでに ISO/IEC 646 の仲間たちを紹介しましょう。

韓国では、KS X 1003:1993(KS C 5636) があり、0x5C がウォンマーク、0x7E が OVERLINE になっています。

ヨーロッパ諸国では、0x23、0x24、0x40、0x5B、0x5C、0x5D、0x5E、0x60、0x7B、0x7C、0x7D、0x7E の 12 文字に対し、それぞれの国の事情に沿った文字を割り当てた文字コードが使われていました。このような状況が、文字コードの利用を不便にしていたのは想像に難くありません。0x80〜0xFF が利用可能になり、1986 年当時の EC 加盟国の文字をすべて網羅するよう設計された文字コードが ISO-8859-1 です。

ISO-8859-1 の不幸は、ヨーロッパで使われる文字の数を低く見積もってしまったことです。結局 128 文字ではヨーロッパの文字を網羅できないので、複数の ISO-8859 が生まれました。現在のヨーロッパでは、日本と比べ物にならないくらい、文字化けの問題は深刻です。

この状況を改善するために、Unicode に向かったわけですが、ここでも世界中で使われている文字の数を低く見積もるという失敗を犯してしまいました。