ISO/IEC 2022

今日は、今まで丁寧に説明していなかったところを、つらつらと書きたいと思います。

ISO/IEC 2022の基本


ISO/IEC 2022は、日本では電子メール等で「ISO-2022-JP」などとして知られます。
実際には、もっと複雑怪奇な符号なのですが、ASCIIを拡張して、次のような符号を扱えるようになっています。

■94図形文字集合
■96図形文字集合
■94n図形文字集合
■96n図形文字集合
■その他の文字集合

これらを、適切に切り替えるために、様々な仕様が定義されている。それがISO/IEC 2022というわけです。

文字集合


文字集合とは、その名の通り文字の集まりです。
ABCD…といった文字を集めた「ASCII」も、それは文字集合というわけです。
日本語の場合、漢字などを収めた「JIS X 0208」が有名です。

これを、制御文字の列(エスケープシーケンスといいます)で選んで使うわけです。



図形文字表


一般に、文字コードと言うときは、0x20 とか 0x5d とか番号で言うわけです。
この番号は表に表わされた文字の番号をいうわけですが、この表を「図形文字表」といいます。
ASCIIの上位互換にするために、様々な工夫があります。

0x00‐0x1f CL
0x20‐0x7f GL
0x80‐0x9f CR
0xa0‐0xff GR

CLはCRLFや、エスケープなど、いわゆる制御文字が入る場所です。32個あります。
GLは、空白文字からDEL文字までの文字が入る場所です。96個あります。

元々7ビットが想定された符号系ですが、普通、1バイトは8ビットですから、「更に倍!」ということで、CRとGRがあります。

下4ビットを縦、上4ビットを横にした二次元の文字コード表を作った時、ASCIIは左側に収まります。
拡張された部分は、右側になります。
CL/GLのLは左を意味し、CR/GRのRは右を意味するわけです。

シフトJISとかを使っている日本人には馴染みが薄いですが、0x80‐0x9fはCRという、制御文字の領域なのです。
ISO/IEC 2022で最も有名なのは、EUCで使うSS2やSS3でしょうか。
EUC-JPで半角カナを表わすのに、0x8e 0x?? としますね。0x8eがSS2で、これはCR領域にある制御文字なわけです。


バッファ


ASCIIと、それ以外の文字集合を切り替えて使いたいわけです。
文字集合は、無数にありますが、それを同時にまとめて使うこともないので、数個を覚えておければ充分です。これがバッファです。
最初の仕様では、G0とG1という二個のバッファが用意されました。
足りないので、後に拡張されG2とG3が追加されました。

様々な文字集合は、一旦このバッファに「指示」します。
例えば、EUC-JPを想定すると、次のように指示されます。

G0 ASCII
G1 JIS X 0208
G2 JIS X 0201右側 (いわゆる半角カナ)
G3 JIS X 0201 (いわゆる補助漢字)

バッファはあくまでバッファで、覚えておくだけです。
G0からG3は、GLまたはGRのどちらかに、「呼出」をします。そうすると、図形文字表として、その文字が見えるようになるのです。

上の例では、GLにG0のASCIIが、GRにG1のJIS X 0208が、見えるように「呼出」されます。


シフト


G2やG3にあるものを使うには、どうするか。
最初の仕様にはなかったG2とG3、これは後の拡張により、扱えるようになりました。
その方法は「シフト」です。シフトして使うことになります。

シフトには、シフトキーのように1文字だけシフトする「シングルシフト」と、CapsLockキーのようにずっとシフトする「ロッキングシフト」があります。

どちらを使っても良いのですが、ロッキングシフトを使う場合、今の状態を保持する、つまり「モード」を持つ必要があるため、簡素な実装をしたい需要には人気がないようです。
「EUC」として使われるものは、例外なくシングルシフトを使っており、ロッキングシフトは使われていません。
「ISO-2022-なにがし」等として規定されるものは、エスケープシーケンスの処理もあるので、素直にSI/SOというロッキングシフトが使われているようです。


シングルシフトは、元々EUC用に作られたものとも言え、このためSS2とSS3しかありません。SS1などは無いのです。
ロッキングシフトはG0からG3まで全部用があります。
LS0とLS1は特殊で、ASCIIの頃からの互換性が重視されており、LS0はSI(0x0f)、LS1はSO(0x0e)を使います。SI/SOは、聞いたことがある人も居るかと思います。


文字


こうして、様々な制御をして、目的の文字集合を図形文字表に表わします。
そして0x20‐0x7f、0xa0‐0xffの範囲、つまりGL/GRを直接表わすと、それが文字になるわけです。

GRにG1が呼出され、G1にはJIS X 0208が指示されていたとすると

0xa1 0xa1

という2バイトの符号が、JIS X 0208の全角空白(区点位置 1区1点)を表わすことになります。

このような符号を認識しないような、古いASCII対応の機械でこの符号を読み取った場合、当然日本語などは認識しないでしょうが、同時に、誤動作もしないわけです。
0xa1は最上位ビットが消されて0x21になるかもしれませんが、それは感嘆符! なわけで、前後に変なもの(エスケープシーケンス)があるけれども、それ以外は!!でしかない。

従って、この機械を「経由」していく電文があったとしても、内容が消えることなく通信できることになります。
8ビットを通さない機械のために、全てを7ビットで行なう「安全な」方法もあります。
日本語の電子メールで使うISO-2022-JPが、まさにそうですね。

例に出したEUC-JPはPCで使うには都合がいいですが、このような古くさい機械では情報が欠落する恐れはあります。


94と96文字集合


文字集合には、2種類あります。
0x21‐0x7eまでを使い、0x20は空白、0x7fはDELで固定化した「94図形文字集合」と、0x20‐0x7fまでを全部使う「96図形文字集合」です。
選ぶ方法(エスケープシーケンス)や、与えられた文字集合の番号(終端文字)はそれぞれ別になっています。

一般に、右側に呼び出す場合、0x80や0xffを空白やDELにする必要はほぼ無く、無駄に余らせるよりは文字を入れた方が効率的です。
従って、欧米圏で使われているISO-8859シリーズは、全てが96文字集合です。

一方、シフトJISの0x20‐0x7fで使われているJIS X 0201左側、いわゆるISO-646-JPは、94文字集合なわけです。

96文字集合は、G1からG3までにしか指示できません。G0は、94文字集合専用なのです。
そしてGLは通常の使用方法ではG0が呼出されますから、GLの0x20と0x7fが空白またはDELであることは維持される。この2文字は、神域で侵してはいけない扱いのようです。

尤も、上に書いたようにシングルシフトやロッキングシフトを使ってしまうと、GLにもG1からG3までが呼出できてしまうので、結局0x20と0x7fは文字で潰されてしまいます。
それでも、今でもISO/IEC 2022はG0に96図形文字集合を指示することができません。とにかく意地っ張りのようです。


エスケープシーケンス


エスケープシーケンスは、次の書式と決まっています。

<ESC> <中間文字(1個以上)> <終端文字>

94にするか96にするか、G0からG3のどこにするか、は、全て「中間文字」で選択します。
図形文字表は終端文字で選びます。94と96で、終端文字に対応する図形文字表は別になります。

■94図形文字集合 G0=2/8 G1=2/9 G2=2/10 G3=2/11
■96図形文字集合 G0=なし G1=2/13 G2=2/14 G3=2/15

例えば2/11は0x2bを表わすと考えて下さい。
「0x1b 0x28 ※」とすれば、※で指定された94図形文字集合がG0に指示されます。

94図形文字集合は増えすぎて終端文字が足りなくなったので、第二中間文字2/1というものもあり、これを使うとまた終端文字に対応する図形文字表が変わります。
「0x1b 0x28 0x21 ※」とすれば、新しい図形文字表を使うことができるわけです。

さて、良く見ると、96で無いはずのG0のところ、微妙に番号が飛んでますね。
2/12とか見えるような気がしますが、これは見なかったことにしましょう。
とはいえ実際、2/12でG0に指示できる実装はあるようです。今のところ、開発中のgTefも、G0に指示できます。当然、規格外の動作になりますが。


多バイト文字集合のエスケープシーケンス


日本語のように1バイトでは済まないものは、2から4バイト系の符号として利用できます。
94と96でそれぞれあるので、これは「94n図形文字集合」「96n図形文字集合」と呼ぶことにしましょう。

96n図形文字集合は、規格上は利用可能ですが、今のところ一つも定義されていません。
94n図形文字集合の代表はJIS X 0208ですが、他にも色々あります。

これは、G0からG3に指示する中間文字の前に、多バイト文字集合を表わす中間文字「2/4」を挟むことで表現します。
例えば、「0x1b 0x24 0x28 ※」とすれば、※で指定された94n図形文字集合がG0に指示されます。


またこれらは2バイトですが、終端文字により、その長さが決まることになっています。
JIS X 0208の場合、終端文字は4/2ですが、次のように長さが決められています。

終端文字が
4/0‐5/15 2バイト
6/0‐6/15 3バイト
7/0‐7/13 4バイト

但し、3バイトと4バイトの文字集合もまた、一つも定義されていません。
ISO/IEC 2022は拡張性が極めて高く、無限の可能性を秘めているのですが、まだまだ使われていない部分が多く存在するのです。

今日はここまで。

2008/12/29(月)23:59 |Comments(0) |Trackback(0)

製造開発 | プログラミング | コンピュータ | [編集]

▲ページトップ

コメント

コメントの投稿

年末のご挨拶 ホーム Unicodeのバージョン
トラックバック

この記事にトラックバックする(FC2ブログユーザー)
▲ページトップ

カレンダー

09 | 2017/10 | 11
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30 31 - - - -

プロフィール

miraicorp

Author:miraicorp
未来情報産業(株) 社長

主として「ICカードこれひとつ」や「文字、文字コード」処理、時々C++などについて記述しています。

twitterツイッター

管理用

検索フォーム

お知らせ

コメント等お気軽にどうぞ。

気に入ったら拍手して頂けると、今後の記事を書く際の参考や励みになります。

■お仕事を募集しております
ソフトウェア製造の仕事や、原稿執筆の仕事などを随時受け付けております。
お気軽にご相談下さい

■初めての方へ
こまごまと更新しているため、他にも関連する記事があるかもしれません。
「月別アーカイブ」「検索フォーム」「カテゴリ」などをお試し下さい。
トップページはこちら

最新記事

最新コメント

最新トラックバック

月別アーカイブ

カテゴリ

広告枠

メール

メールはこちら

リンク

このブログをリンクに追加する

RSSリンクの表示

QRコード

QR