ISO-2022-JP
僕自身も最初混同していたのですがISO-2022-JPはあくまでもISO 2022に準拠した日本語エンコーディングスキームのことでISOが制定した規格ではありません。もともとはJUNETでJIS X 0201/JIS X 0208を実装する方法として考案されたました。特徴としては、
- ISO 2022 7ビット構成を使用する（領域をGL領域に固定する）
- GLには常にG0を指示するものとする
- 改行で自動的にG0へASCIIを呼び出す
で、使用する文字集合とエスケープシーケンスは下記のようになります。GLは常にG0と同一のため、G0への指示はそのままGLへの呼び出しとなります。
| 文字集合 | エスケープシーケンス |
|---|---|
| ASCII | ESC(B |
| JISローマ字 | ESC(J |
| JIS C 6226-1978（78JIS） | ESC$@ |
| JIS X 0208-1983（83JIS） | ESC$B |
半角カナ
表のとおり、JIS X 0201（カナ）は文字コードに含まれていませんのでいわゆる「半角カナ」は使用できません。電子メールでは多くの場合エンコーディングスキームとしてこのISO-2022-JPを使用しますので必然的に電子メールでは半角カナは使えないことになります。
しかしながら、メールソフトの中にはこの「半角カナ」を使用できるよう独自の拡張を行っているソフトも多く、現実には「半角カナ」を含むメールが存在することもあるようです。こういうことは、便利なようでいて最終的には混乱の元なので規格があるのであればそれに従うべきだと個人的には思います。
改行でASCIIに
特徴の三番目で「改行ごとにASCIIを呼び出す」というのがあります。これは、"モーダルコード"の弱点を補おうとする工夫で、エスケープシーケンスを送り損なったとき文字集合がわからなくなることに対する備えです。
万が一エスケープシーケンスを送り損なった場合、文字集合の判定ができなくなるため以降の文章がすべて文字化けしてしまいますが、改行でいったんASCIIに戻し必要なら再度エスケープすることにより、最悪でも改行までの文字化けで救われることになります。
ISO-2022-JP-1/2/3
ISO-2022-JP-1
ISO-2022-JPにJIS X 0212-1990の補助漢字を使えるように拡張したものです。
| 文字集合 | エスケープシーケンス |
|---|---|
| JIS X 0212-1990 | ESC$D |
ISO-2022-JP-2
下記の表のとおりの文字集合とエスケープシーケンスをとります。
| 文字集合 | エスケープシーケンス |
|---|---|
| GB2312-80（中国） | ESC$A |
| JIS X 0212-1990 | ESC$D |
| KS X 1001:1992（韓国） | ESC$C |
| ISO 8859-1:1998（右） | ESC.A |
| ISO 8859-7:1998（右） | ESC.F |
注目すべきはISO-8859-1/7の２つ（ラテン・ギリシャ文字）。これらは９６文字集合のため、ISO-2022-JPのGLには常にG0を指示するという規定が拡張され、G2領域を使用するよう拡張されこれらの文字を使用する際にはESC+SS2（0x1b 0x4e）のシングルシフトを使用することになります。
ISO-2022-JP-3
JIS X 0213を使用します。JIS X 0213はJIS X 0208の拡張版ともいえますので第一水準から第四水準までの漢字を使うことができます。
| 文字集合 | エスケープシーケンス |
|---|---|
| JIS X 0213 １面 | ESC(O |
| JIS X 0213 ２面 | ESC(P |
| JIS X 0208-1983 | ESC$B |
