ASCIIと半角カナ一覧

ASCII (American Standard Code for Infomation Interchange)は 最上位ビットを使用せず、7ビットの範囲(0x00-0x7F)で表現していました。 日本ではこれに最上位ビットも使用し8ビットの範囲(0x00-0xFF)とし、 独自にカタカナを押し込めました。

これは慣例的に使われていたに過ぎなかったのですが、やがて「ANKコード」 (Alphabet, Numerical digit, Katakana) と呼ばれ広く使われるようになり、1969年に 「JIS X 0201」 として正式に定義されました。

Shift_JIS系では1バイト文字に関しては「ANKコード」の文字コード値をそのまま使用しています。 そして「ANKコード」の1バイトの「カタカナ」を、Shift_JIS系では「半角カナ」とし、別途2バイトの「(全角)カタカナ」を追加しました (EUC-JPやUTF-8でも「半角カナ」は定義されましたが、文字コード値は異なります)。

一方で全ての文字を7ビットで扱うことを前提としている 「ISO-2022-JP」では 「半角カナ」は定義されていません。しかし独自にサポートしているアプリケーションも多数存在します。

メールのプロトコルSMTPはRFC 5322で、 メッセージで使える文字列はUS-ASCII文字(7bit文字)のみと定められています。 そのため、日本語を含むメールでは7ビットで表現することを前提にしている「ISO-2022-JP」が多用されました。 また「ISO-2022-JP」を独自に拡張し、最上位ビットも使用して、半角カナをサポートするメーラーもありました。

しかし、最上位ビットの扱いは任意となっており、 送信時に8ビット目をクリアしてしまうメーラーや、 中継サーバーで8ビット目をクリアしてしまうことがあったり、 受け取っても半角カナは表示しないメーラーもあり、 とにかく半角カナを使用したメールは文字化けをすることがありました。 そのため「メールを送信する際は半角カナは禁止」とされていたのです。

「半角カナ」を「機種依存文字」としている説明をたまに見かけます。 これはメールや「ISO-2022-JP」に限定して言えば正しいです。 しかし半角カナがWebでも化けるとか、半角カナが全般的に 機種依存文字であるかの様な説明は明らかに間違いです。

ちなみにMSXでは、さらに「0x80-0x9F」と「0xE0-0xFF」に、ひらがなと トランプマークなどの記号を押し込め、右画像のような文字セットにしていました (画像はMSXのエミュレーターで作成しました)。

「ANKコードのMSX独自拡張」とも言えるでしょう。 ひらがなの位置に注目すると、残り少ない空き領域に詰め込んだ様子が伺えます。

私は小学生の頃にMSXを使っていてその頃は全く気にしていませんでしたが、 今思うとカタカナとひらがなも1バイトで表現できるよう工夫されていたのは印象的です。

MSXはさらに、0x00～0x1Fの制御文字の範囲を、「グラフィック文字」として使い 簡単な漢字や罫線などを割り当てました。少々やりすぎにも感じますが、 少ないリソースでより多くの表現を行おうと工夫していた様子がうかがえます。

ASCIIは記号が4ヶ所に別れて配置されています。一見分かりにくいのですが、 「0x20-0x3F」「0x40-0x5F」「0x60-0x7F」の大きく3つのエリアに分けると、意図を感じることが出来ます。

「0x20-0x3F」は数字と記号の一部で、記号も算術記号や数字に関連するものが多いです。 「0xA0-0xBF」は半角カナの前半です。

左右の表に対応する文字のビットの違いは最上位ビットだけです。よって、メールで半角カナを使用し、 最上位ビットがクリアされることにより文字化けが発生したのなら、 隣の表の対応する文字に化けている可能性が高いです。

「0x40-0x5F」はアルファベット大文字と記号の一部です。 「0xC0-0xDF」は半角カナの後半です。

「0x60-0x7F」はアルファベット小文字と記号の一部です。「0xE0-0xFF」は使われていません。

「0x40-0x5F」と「0x60-0x7F」のグループはそれぞれ、日本語キーボード上は 同じキーに割り当てられており、Shiftキーを押すか押さないかの関係にあります。

最後に。0x20-0xBFの範囲を32文字ずつ並べておきます。