ISO/IEC 2022
出典: フリー百科事典『ウィキペディア（Wikipedia）』
 |
このページの図表を置いたサブページが削除依頼で審議中です。Wikipedia:削除依頼/文字/表 主な漢字辞典の収録文字数 |
ISO/IEC 2022(旧称はISO 2022)は
を規定するISO規格である。JISの対応規格はJIS X 0202 「情報技術-文字符号の構造及び拡張法」[1]。Ecma Internationalの対応規格はECMA-35。
ISO/IEC 2022 の符号化方式は、一般に、1文字に1バイトか2バイト以上を使う可変長の文字符号化方式である。いくつかの符号化表現がISO/IEC 2022の機構を使っている。たとえば、ISO-2022-JPは日本語で広く使われている符号化表現であり、いわゆる「JISコード」というのもこれを指すことが一般的である。
目次 |
[編集] 歴史
コンピュータによる文字情報処理が可能になって以来、さまざまな言語のために、コンピュータ上で文字データを表現したいという要求を満たすため、多くの符号化文字集合が作られてきた。複数の文字集合の存在は、文字集合があらかじめ当事者間で合意されていなければ情報交換に支障をきたす。また、情報交換中に複数の文字集合を利用することも困難である。ISO/IEC 2022は、複数の文字集合を単一の文字符号化方式の下で利用できるようにするための技術として開発された。
ASCIIは7ビットのラテンアルファベット文字集合であり、最大94文字の図形文字 (空白文字を除く) しか収容できない。ISO/IEC 646 (1967年初版)[2]では、図形文字の収容領域を ASCII に倣いつつ、12個の符号位置を各国の国内使用目的のために置き換えてよいこととし、さらにレパートリとして国別の文字集合を定義するという方法をとった。
ISO/IEC 2022 (1973年初版)[3] は、ISO/IEC 646 に準拠した複数の符号表を切り替えて多言語の処理を実現することを目的に制定された。
しかし、ISO/IEC 646 の方式では、ラテンアルファベットの範囲に限ってさえも、多数のダイアクリティカルマーク付き文字や、言語ごとに必要とされる記号類などを十分に収容することができなかった。このため、ISO/IEC 646 と互換性を保ちつつ8ビット符号 を採用した ISO/IEC 4873 (1979年初版)[4] が制定された。特にヨーロッパでは1980年代に入って多言語のテキストデータを共通の仕様の下に処理できるようにしたいという要求が高まっており[5]、1987年からは ISO/IEC 4873 に対応した ISO/IEC 8859シリーズが制定されはじめた。ISO/IEC 8859シリーズでは、新たに96文字の図形文字を収容可能にし、さらにレパートリとして言語別の文字集合を定義するという方法をとった。
また、ギリシア語、ロシア語、アラビア語、もしくはヘブライ語のような、ラテンアルファベットに基づかない多くの言語の文字も、歴史的に ISO/IEC 4873 に準拠した俗に言う「拡張ASCII」を用いてコンピュータ上で表現されてきたものが多い (一部は後に ISO/IEC 8859 シリーズにも規定されたほか、多くの国・地域の符号化文字集合の規格が ISO/IEC 4873 に準拠している)。
さらに、東アジア言語、とくに中国語、日本語、および韓国語の表記は、8ビットの1バイトで表現可能な範囲をはるかに超えた数の文字を使い、言語別の2バイト文字集合によって初めてコンピュータ上で表現された。
ISO/IEC 2022 は、これら複数の文字集合を単一の符号化方式の下に扱うことを可能にしている。
ISO/IEC 2022に基づく符号化表現は現在も広く使われている。たとえば日本語電子メール用のISO-2022-JPがそうである。しかし近年、電子メールアプリケーションは、多言語に対応して状態遷移のないUTF-8のようなUnicodeの文字符号化方式に徐々に移行しつつある。
[編集] 第2次規格以降の主な改正点
第2次規格以降の主な改正点には次のようなものがある。なお、用語については当項目でこの後解説する。
第2次規格
- 8ビット符号に対応した。
- バッファG2およびG3を新設した。
- マルチバイト文字集合に対応した。
第3次規格
- 96文字集合および96n文字集合に対応した。
- （JISのみ）この版からJIS X 0201を拡張する規格からISO/IEC 646を拡張する規格になったため、国際一致規格になった。
第4次規格
- 7ビット符号中心の記述から8ビット符号中心の記述に改められた。
#表1に、各版ごとの規格番号、制定日などを示す。
| 版 | ISO規格番号 | ISO制定・改正日 | JIS規格番号 | JIS制定・改正日 |
|---|---|---|---|---|
| 第1次規格 | ISO 2022:1973 | 1973年5月制定 | JIS C 6228:1975 | 1975年3月1日制定 |
| 第2次規格 | ISO 2022:1982 | 1982年12月改正 | JIS C 6228:1984※ | 1984年11月1日改正 |
| 第3次規格 | ISO 2022:1986 | 1986年5月改正 | JIS X 0202:1991 | 1991年1月1日改正 |
| 第4次規格 | ISO/IEC 2022:1994 | 1994年12月改正 | JIS X 0202:1998 | 1998年1月20日改正 |
- ※ 1987年3月1日部門X（情報処理）の新設に伴いJIS X 0202:1984 と改称された。
[編集] 詳細
[編集] 符号表の構造
ISO/IEC 2022は当初ISO/IEC 646に基づいた7ビット符号であったので、多くのISO/IEC 646の特性を持ち合わせている。7ビット符号では、各バイトの最上位桁ビットは使われない。これにより、7ビットの伝送路を通してISO/IEC 2022を伝送することは(ISO/IEC 646と同様)容易である。8ビット符号では、最上位桁ビットを GL領域とGR領域 (後述) の区別に用いるが、文字集合中の文字を区別するのには用いない。この特性はEUC符号化の基本原理にも利用されている。
ISO/IEC 2022の符号表は、表示や印字される文字 (図形文字) の領域と、制御機能に使う文字 (制御文字) の領域に分けられている。7ビット符号は、32個の制御文字基本集合の領域 (C0) と、94個または96個の図形文字集合の領域 (GL領域) を持つ。8ビット符号は、これに加えて32個の制御文字補助集合の領域 (C1) と、94個または96個の図形文字集合の領域 (GR領域) を持つ。#図1に、7ビットと8ビットの符号表の構造を示す。符号表上の文字の位置は、表の行および列で表す。たとえばASCIIの「Z」という文字は行列で 05/10 にあたり、符号のバイトの値としては16進数で 5A (10進数で 90) となる。
複数バイトの文字集合では、複数のバイトで1文字を符号化する。たとえば94n文字集合では、2バイトを使って8836個(94×94)までの文字を表現できる。そして、3バイトを使って830584個(94×94×94)までの文字を表現できる。2バイト文字集合では、各文字の符号位置は区点 (3バイト文字集合の場合は面区点) で(面および)区および区内の位置を指定する。つまり、94×94文字集合の場合、区および点のそれぞれが 1 から 94 の範囲をとるので、それぞれを1バイトずつGL領域の 02/01 から 07/14 (GR領域ならば 10/01 から 15/14) に対応させて2バイトとする。たとえば、JIS X 0208 の「字」は 17区7点 (17-07) なので、GL領域では 03/01 02/07、GR領域では 11/01 10/07 と表現される。
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
[編集] 制御機能
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
JIS X 0202:1998 および JIS X 0211-1994 を元に作成。 符号表上の文字の位置を行と列で示す。たとえば 01/11 (ESCAPE) は16進数値では 1B にあたる。また、Ft または I Ft は、ISOの文字集合国際登録簿への登録によって割り当てられたエスケープシーケンスの終端バイト (および第2中間バイト) を表す。 a ただし、Ftバイト が 04/00、04/01、04/02 の場合は 02/08 を省略する。これは具体的には、JISC C 6226-1978 (JIS X 0208 の第一次規格)、GB 2312-80、JIS C 6226-1983 (同第二次規格) の文字集合を指示する場合である。 b Fバイトで、直後の指示機能で指示される文字集合の改訂番号を識別する。 c 7ビット符号でのみ用いる。 d 8ビット符号でのみ用いる。 e 7ビット符号ではエスケープシーケンスを使う。8ビット符号ではC1制御文字を使うこともできる。 f Fバイトによって、利用する機能を指定する。 |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
複数の文字集合を表現するために、ISO/IEC 2022の文字符号化方式は、符号の性質や扱う文字集合を指定するための制御機能を含んでいる。制御機能の表現には、7ビット符号ではC0制御文字のほか、ESCAPE制御文字(01/11。十六進数の1B、十進数の27)で始まる2バイトないし4バイトからなるエスケープシーケンスを用いる[6]。8ビット符号ではさらに、C1 制御文字も用いる。この文字符号化方式では、データの正しい解釈が最後に出現した制御機能に依存するため、データを先頭から順番に処理する必要がある。#表2に、ISO/IEC 2022 の制御機能の一部を示す。
[編集] 文字集合の選択
ある文字集合を符号表上で使うには、一般に指示 (英: designate) と呼び出し (英: invoke) という2段階の手続きを必要とする。
ISO/IEC 2022 は、符号表上の4つの領域C0、GL、C1、GRとは別に、仮想的なバッファをもっている。G0、G1、G2、G3という4つのバッファがある。
まず、指示のエスケープシーケンスによって、使おうとしている文字集合を、4つのバッファのいずれかに対応付ける。
指示のエスケープシーケンスは、どの文字集合を使おうとしているか宣言するのみならず、これらの文字集合の特性をも知らせる。扱おうとしている文字集合が94文字、96文字、8836(94×94)文字、830584(94×94×94)文字、もしくは他のサイズのいずれであるかを伝える。指示していない文字集合を使うことはできない。また、5つ以上の文字集合を一度に指示しておくこともできない。
つぎに、呼び出し (シフト) の制御機能によって、G0、G1、G2、G3のいずれかを、符号表上のGL領域かGR領域に対応付ける。指示した文字集合を呼び出ししてはじめて、その文字集合を符号として使うことができるようになる。7ビット符号では2つ以上、8ビット符号では3つ以上のバッファを一度に呼び出しておくことはできない。
呼び出しには、ロッキングシフトとシングルシフトがある。ロッキングシフトでは、いったん呼び出しされたものは、別の呼び出しがあるまで使いつづけることができる[7]。シングルシフトでは、呼び出しされたものは直後の1文字 (シングルバイトの文字集合であれば1バイト、マルチバイトの文字集合であればそれぞれのバイト数分) だけ使え、そのあとは呼び出し前の状態に戻る[8]。
実際には、文脈や規約が特定の文字集合を使うよう指定していれば、符号化の仕様を指定する制御機能 (アナウンス機能) や初期の文字集合を指示する制御機能は省略することができる。ISO-2022-CNを定義しているRFC 1922を例に取ると、呼び出しにSIとSOの制御文字を使用するが、この仕様を宣言するアナウンス機能のエスケープシーケンスを省略している。また、初期状態ではG0にUS-ASCII、G1にGB2312-80を指示し、G0をGL領域に呼び出しているが、指示のエスケープシーケンスも省略している。
[編集] ISO国際登録簿
ISO/IEC 2022は具体的な符号化文字集合とは切り離して規定されているため、実際にこの規格を適用するにあたってはエスケープシーケンスの終端文字と符号化文字集合などとの具体的な対応関係を定める必要があり、そのために符号化文字集合のISO国際登録簿が存在する。これはエスケープシーケンスの終端文字についてそれぞれどの文字がどの符号化文字集合などに対応しているのかを定めたものである。符号化文字集合のISO国際登録簿と登録方法はISO/IEC 2375 Data Processing - Procedure for Registration of Escape Sequences (情報技術－エスケープシーケンス及び符号化文字集合の登録手順) に規定されている。
ISO国際登録簿への登録申請を行うことが出来るのは次の者に限定される。
- ISO/IECの技術委員会または小委員会
- 符号拡張またはエスケープシーケンスの使用法を検討するISO/IEC JTC/SC2内のグループ
- ISO/IECの会員団体（各国で1団体ずつと決められており、日本では日本工業標準調査会）
- ISO/IECの技術委員会または小委員会と関連のある国際機関（ITU-T（旧CCITT）など）
登録の手続きと国際登録簿の維持管理は登録事務局（Registration Authority）がおこなうことになっている。現在、その事務局は日本の情報処理学会情報規格調査会 (IPSJ/ITSCJ) が引き受けている（符号化文字集合の国際登録簿）。かつてはECMA（欧州計算機製造業者協会）が登録事務局を引き受けていた[9]。
[編集] 応用例
[編集] 7ビット符号によるマルチバイト用のキャラクタセット
ISO/IEC 2022の機構を使う7ビット符号のキャラクタセットには以下のものが含まれる。次のような特徴を持つ。
- アナウンス機能のエスケープシーケンスは省略する。
- 7ビット符号なので、GR領域は使わず、C1制御文字はエスケープシーケンスで表す。
- 最初は、G0にASCIIを指示し、G0をGL領域に呼び出した状態で始まる (このための制御機能は省略する)。つまり、最初はUS-ASCIIで始まる。
- 行の終わりではASCIIに戻さなければならない[10]。
#表3に、これらのキャラクタセットで用いる符号化文字集合と、その選択のための制御機能を示す。
ISO-2022-JPでの「日本語版Wikipedia」という文字列の符号化を例に説明する (#表3も参照)。
| 文字 | 日 | 本 | 語 | 版 | W | i | k | i | p | e | d | i | a | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 機能 区点 行列 |
JIS X 0208 を指示 |
38-92 | 43-60 | 24-76 | 40-39 | ASCII を指示 |
05/07 | 06/09 | 06/11 | 06/09 | 07/00 | 06/05 | 06/04 | 06/09 | 06/01 | ||||||||
| 符号 | 01/11 | 02/04 | 04/02 | 04/06 | 07/12 | 04/11 | 05/12 | 03/08 | 06/12 | 04/08 | 04/07 | 01/11 | 02/08 | 04/02 | 05/07 | 06/09 | 06/11 | 06/09 | 07/00 | 06/05 | 06/04 | 06/09 | 06/01 |
| ESC | $ | B | F | | | K | \ | 8 | l | H | G | ESC | ( | B | W | i | k | i | p | e | d | i | a | |
上図で、上段が符号化したい文字列である。「日本語版」は JIS X 0208 に含まれる文字の列、「Wikipedia」はASCIIに含まれる文字の列である。また、最初はASCIIで始まる。したがって、「日本語版」の直前と「Wikipedia」の直前に文字集合を指示するエスケープシーケンスが必要になる (ISO-2022-JP では指示が呼び出しを兼ねるので、呼び出しの制御機能は必要ない)。マルチバイト文字は区点で、シングルバイト文字は行列で表すと、中段のようになる。区点を2バイトずつで表し、全体を7ビット符号で表すと、下段のように符号化される。
| キャラクタセット | 対象言語 | 文字集合 | 文字集合選択のための制御機能 | ||
|---|---|---|---|---|---|
| 指示 | 呼び出し | ||||
| ISO-2022-JP | 日本語 | ASCII | G0 | 01/11 02/08 04/02 ESC ( B |
指示が兼ねる (ロッキングシフト) |
| JIS X 0201-1976のラテン文字集合 (ISO/IEC 646の日本版) | 01/11 02/08 04/10 ESC ( J |
||||
| JIS C 6226-1978 | 01/11 02/04 04/00 ESC $ @ |
||||
| JIS X 0208-1983 または JIS X 0208:1990 |
01/11 02/04 04/02 ESC $ B |
||||
| ISO-2022-JP-1 | 日本語 | ISO-2022-JP に以下を追加 | |||
| JIS X 0212-1990 | G0 | 01/11 02/04 02/08 04/04 ESC $ ( D |
指示が兼ねる (ロッキングシフト) |
||
| ISO-2022-JP-2 | 多言語 | ISO-2022-JP-1 に以下を追加 | |||
| GB 2312-80 | G0 | 01/11 02/04 04/01 ESC $ A |
指示が兼ねる (ロッキングシフト) |
||
| KS X 1001-1992 | 01/11 02/04 02/08 04/03 ESC $ ( C |
||||
| ISO/IEC 8859-1 の右半分 | G2 | 01/11 02/14 04/01 ESC . A |
01/11 04/14 ESC N (シングルシフト) |
||
| ISO/IEC 8859-7 の右半分 | 01/11 02/14 04/06 ESC . F |
||||
| ISO-2022-JP-3 | 日本語 | ISO-2022-JP に以下を追加 | |||
| JIS X 0213:2000の1面 | G0 | 01/11 02/04 02/08 04/15 ESC $ ( O |
指示が兼ねる (ロッキングシフト) |
||
| JIS X 0213:2000の2面 | 01/11 02/04 02/08 04/16 ESC $ ( P |
||||
| ISO-2022-JP-2004 | 日本語 | ISO-2022-JP-3 に以下を追加 | |||
| JIS X 0213:2004の1面 | G0 | 01/11 02/04 02/08 04/17 ESC $ ( Q |
指示が兼ねる (ロッキングシフト) |
||
| ISO-2022-KR | 韓国語 | ASCII | G0 | 初めから指示したまま | 00/15 SI (ロッキングシフト) |
| KS X 1001-1992 | G1 | 01/11 02/04 02/09 04/03 ESC $ ) C ただし、行の初めに置く |
00/14 SO (ロッキングシフト) |
||
| ISO-2022-CN | 中国語 | ASCII | G0 | 初めから指示したまま | 00/15 SI (ロッキングシフト) |
| GB 2312-80 | G1 | 01/11 02/04 02/09 04/01 ESC $ ) A |
00/14 SO (ロッキングシフト) |
||
| CNS 11643-1992の1面 | 01/11 02/04 02/09 04/07 ESC $ ) G |
||||
| CNS 11643-1992の2面 | G2 | 01/11 02/04 02/10 04/08 ESC $ * H |
01/11 04/14 ESC N (シングルシフト) |
||
| ISO-2022-CN-EXT | 中国語 | ISO-2022-CN に以下を追加 | |||
| ISO-IR-165 | G1 | 01/11 02/04 02/09 04/05 ESC $ ) E |
00/14 SO (ロッキングシフト) |
||
| GB 12345-90 | 未定 | ||||
| GB 7589-87 | G2 | 未定 | 01/11 04/14 ESC N (シングルシフト) |
||
| GB 13131-91 | 未定 | ||||
| GB 7590-87 | G3 | 未定 | 01/11 04/15 ESC O (シングルシフト) |
||
| GB 13132-91 | 未定 | ||||
| CNS 11643-1992の3面 | 01/11 02/04 02/11 04/09 ESC $ + I |
||||
| CNS 11643-1992の4面 | 01/11 02/04 02/11 04/10 ESC $ + J |
||||
| CNS 11643-1992の5面 | 01/11 02/04 02/11 04/11 ESC $ + K |
||||
| CNS 11643-1992の6面 | 01/11 02/04 02/11 04/12 ESC $ + L |
||||
| CNS 11643-1992の7面 | 01/11 02/04 02/11 04/13 ESC $ + M |
||||
[編集] ISO-2022-JP
ISO-2022-JPは、日本語の電子メールなどのための符号化表現として広く使われている。このキャラクタセットは、1986年後半ころに、当時のJUNETで、ネットニューズや電子メールで日本語を利用するための符号化の共通仕様として成立した。当初はJUNETコード (junet-code) と呼ばれたが、最終的には現在の名称でMIMEのためのキャラクタセットとして登録された[11]。その仕様は RFC 1468 で定義されている。
ISO/IEC 2022 に準拠した7ビットの符号化表現だが、次のような特徴を持つ。
- 漢字の文字集合が指示、呼び出しされている状態では、SPACE (空白文字) や制御文字を使ってはならない。
- 行末では指示、呼び出しをASCIIにもどさなければならない。つまり、改行の前に漢字の文字集合が指示されていたら、ASCIIを指示してから改行しなければならない[10]。
- JIS X 0208を指示するとき、改訂番号識別の制御機能を用いずに1983年版と1990年版のどちらを使ってもよい。
JUNETコードの成立当時、端末エミュレータなどの機器には「漢字イン/漢字アウト」理解[7]に基づく動作をするものが複数存在し、漢字の符号化文字要素中に空白文字や制御文字が現れると正しく処理できなかった。改行の処理についても、行が変わると表示などの処理がASCIIにもどってしまうものがあった。こういった機器は、ハードウェアや組込みソフトウェアによって実現されている例も多く、その挙動を修正することはしばしば困難だった。そのため、符号化のしかたにこのような条件を課したのだと考えられる。
また、ISO/IEC 2022 では、改訂があった文字集合を指示する場合には、指示のエスケープシーケンスの前に改訂番号を識別するエスケープシーケンス (IRR。#表2参照) を置くことができると定めている。たとえば、JIS X 0208:1990 (JIS X 0208 の1990年版) は JIS C 6226-1983 (同じく1983年版。後に JIS X 0208-1983に改称) の改訂である (漢字2文字が追加されている) ため、1990年版を指示する場合は、指示のエスケープシーケンスの直前に 01/11 02/06 04/00 (ESC & @) を付加する。実際にIRRを使用するかどうかは情報交換の仕様の中で定められる。RFC 1468 では、1990年版を使う場合も IRR の付加をしないことを提案している。
JIS X 0208:1997では、附属書2「RFC1468符号化表現」として ISO-2022-JP をJISの規定としたが、この符号化表現が「ISO/IEC 2022に適合するものではない」[12]と付記している。
ISO-2022-JP は、マルチバイト文字集合を扱うものとしては初のMIME用キャラクタセットであった。これ以後、中国語、朝鮮語、あるいは多言語での利用を想定したISO-2022-〜の名称のキャラクタセットがいくつか提案され、RFC にもなった。これらの仕様には ISO-2022-JP の影響が見られる。しかし、日本語以外の言語では、現在、電子メールなどのキャラクタセットはEUC符号化によるものなどが事実上の標準となっており、マルチバイトで7ビットのキャラクタセットとして一般的に使われているものは、事実上、日本語用の ISO-2022-JP のみである。
[編集] Extended Unix Code (EUC)
Extended Unix Code (EUC) は、ISO/IEC 2022の機構に準じた8ビット符号の文字コード[13]である。これには以下のものが含まれる。次のような特徴を持つ。
- アナウンス機能のエスケープシーケンスは省略する。
- 8ビット符号なので、GR領域も使う。エスケープシーケンスは使わない。
- G0にASCIIを、G1にマルチバイト文字集合を、G2やG3に補助的な文字集合を (あれば) 指示し、G0をGL領域に、G1をGR領域に呼び出した状態で始まる (このための制御機能は省略する)。つまり、最初は7ビット符号がASCII、8ビット符号がマルチバイト文字集合で始まる。
- 指示の状態は固定的に決まっており、変更は行わない。
- 呼び出しはシングルシフトのみで、G2かG3 (あれば) からGR領域へのみ。
この結果、ASCIIの文字は常に7ビット、それ以外の文字集合の文字は常に8ビットで符号化され、しかも、同じ文字集合の文字は常に同じバイト数で表現されることになる。
#表4に、これらの文字コードで用いる符号化文字集合と、その選択のための制御機能を示す。
EUC-JPでの「日本語版Wikipedia」という文字列の符号化を例に説明する (#表4も参照)。
| 文字 | 日 | 本 | 語 | 版 | W | i | k | i | p | e | d | i | a | ||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 区点 行列 |
38-92 | 43-60 | 24-76 | 40-39 | 05/07 | 06/09 | 06/11 | 06/09 | 07/00 | 06/05 | 06/04 | 06/09 | 06/01 | ||||
| 符号 | 12/06 | 15/12 | 12/11 | 13/12 | 11/08 | 14/12 | 12/08 | 12/07 | 05/07 | 06/09 | 06/11 | 06/09 | 07/00 | 06/05 | 06/04 | 06/09 | 06/01 |
| C6 | FC | CB | DC | B8 | EC | C8 | C7 | 57 | 69 | 6B | 69 | 70 | 65 | 64 | 69 | 61 | |
上図で、上段が符号化したい文字列である。「日本語版」は JIS X 0208 に含まれる文字の列、「Wikipedia」はASCIIに含まれる文字の列である。ASCIIはGL領域に、JIS X 0208はGR領域に呼び出されている。したがって、「日本語版」を8ビットで、「Wikipedia」を7ビットで符号化すればよい。マルチバイト文字は区点で、シングルバイト文字は行列で表すと、中段のようになる。区点を2バイトずつで表し、全体を8ビット符号か7ビット符号で表すと、下段のように符号化される。
| 文字コード[13] | 対象言語 | 文字集合 | 文字集合選択のための制御機能 | ||
|---|---|---|---|---|---|
| 指示 | 呼び出し | ||||
| EUC-CN (GB2312) |
中国語 簡体字 |
ASCII | G0 | 指示したまま | GLのまま |
| GB 2312-80 | G1 | GRのまま | |||
| EUC-JP (AJEC) |
日本語 | ASCII | G0 | 指示したまま | GLのまま |
| JIS X 0208のいずれかの版 | G1 | GRのまま | |||
| JIS X 0201-1976の仮名文字集合 (実装しなくてもよい) | G2 | 08/14 SS2 (シングルシフトGR) |
|||
| JIS X 0212-1990 (実装しなくてもよい) | G3 | 08/15 SS3 (シングルシフトGR) |
|||
| EUC-JISX0213 | 日本語 | ASCII | G0 | 指示したまま | GLのまま |
| JIS X 0213:2000の1面 | G1 | GRのまま | |||
| JIS X 0201-1976の仮名文字集合 (原則として用いない) | G2 | 08/14 SS2 (シングルシフトGR) |
|||
| JIS X 0213:2000の2面 | G3 | 08/15 SS3 (シングルシフトGR) |
|||
| EUC-JIS-2004 | 日本語 | EUC-JISX0213 のG1とG3に、それぞれJIS X 0213:2004の1面と2面を指示したもの | |||
| EUC-KR | 韓国語 | ASCII | G0 | 指示したまま | GLのまま |
| KS X 1001 | G1 | GRのまま | |||
| EUC-TW | 中国語 伝統字 |
ASCII | G0 | 指示したまま | GLのまま |
| CNS 11643の1面 | G1 | GRのまま | |||
| CNS 11643の2面以降 (面1バイトと区点2バイト) |
G2 | 08/14 SS2 (シングルシフトGR) |
|||
[編集] 変異
EUCは業界標準であるため、ベンダごとの独自の実装も包含するものとなっている。そのため、厳密に言えばISO/IEC 2022に準拠しているとは言えないものもある。
EUC-JP では、G1に指示する文字集合に JIS X 0208 のさまざまな版を使うものがある。1978年版 (JIS C 6226-1978)、1983年版 (JIS X 0208-1983)、1990年版 (JIS X 0208:1990) は、ISO/IEC 2022に基づく符号化文字集合としてはそれぞれ異なるものだが、いずれの文字集合を使っているかはベンダによって異なる。また、G2 のJIS X 0201片仮名文字集合や、G3 のJIS X 0212については、ベンダによっては実装していないことがある。
EUC-TW では、CNS 11643の2面以降の文字を、シングルシフト (SS2) の後に面1バイト(10/02 A2 から11/00 B0 で2面から16面を表す)と区点2バイトの合計4バイトで呼び出す。つまり、CNS 11643の2面以降をまとめてひとつの文字集合として扱っていることになる。ISO/IEC 2022に基づく符号化文字集合としては、各面はそれぞれ異なる文字集合である。
[編集] 拡張ASCII
「拡張ASCII」は俗称である。8ビット符号を使うシングルバイト文字集合で、ASCIIに対して上位互換となっているものを指す。#歴史で見たように、ISO/IEC 4873 に準拠した符号表を持てばその文字集合は ISO/IEC 2022 に準拠していると言える。しかしここでは、ISO/IEC 2022 の側から見て解説する。
一般に、拡張ASCIIとはISO/IEC 2022準拠の符号表を使う文字集合の、つぎのような符号化表現であると考えることができる。
- アナウンス機能のエスケープシーケンスは省略する。
- G0に ISO/IEC 646 の各国版またはASCIIを、G1にその他のシングルバイト文字集合を指示し、G0をGL領域に、G1をGR領域に呼び出した状態で始まる (このための制御機能は省略する)。
- 指示の状態も呼び出しの状態も固定的に決まっており、変更は行わない。
この結果、8ビット符号で最大188個ないし190個の図形文字を利用することができ、しかもすべての文字が1バイトの固定長で表現されることになる。なお、これらの多くは、IANAがキャラクタセットとして登録している。
拡張ASCIIの例としては次のようなものがある。詳細は各項目の解説を参照。
- ARMSCII(en)
- アルメニア文字。
- ASMO 449(en)
- アラビア語用のアラビア文字。ISO/IEC 8859シリーズにもアラビア文字集合が含まれるが、互換性はない。
- ISCII(en)
- インドの諸言語の文字。用字系の切り替えや、結合文字の表現のための特殊な図形文字を持つ。
- ISO/IEC 8859 シリーズ(en)
- ヨーロッパの諸言語 (トルコ語およびエスペラントを含む) のラテン文字集合を含み、さらにアラビア文字、ギリシア文字、キリル文字、タイ文字、ヘブライ文字の文字集合をも含む。
- JIS X 0201
- 日本語用の片仮名。
- TIS 620(en)
- タイ文字。ISO/IEC 8859-11と互換性がある。
- TSCII(en)
- タミル文字。ISCIIのタミル文字とは互換性がない。
[編集] はみ出し
拡張ASCIIの方法では、ラテン文字以外の文字は最大96文字までしか収録できない。またたとえラテン文字であっても、極めて多数のダイアクリティカルマーク付き文字を使う言語では、ISO/IEC 2022の8ビット符号でも文字数が不足する。かといって、マルチバイト文字集合を採用するほど多いわけでもない、という場合、図形文字をGR領域やGL領域の外にまで配置することもある。
- VISCII
- ベトナム語用電子メールなどで広く使われているキャラクタセットである。GL領域はASCIIであるが、ダイアクリティカルマーク付き文字のうち96文字をGR領域に収容し、残りを、C1の32文字すべて、さらにはC0のうち6文字にまで割り当てている。
- KOI8 系文字集合(en)
- キリル文字。ロシア語用およびブルガリア語用に使われるKOI8-R、ウクライナ語用に使われるKOI8-U、ウクライナ語、ベラルーシ語、ロシア語共通のKOI8-RUが代表的である。ほかにも、キリル文字を使う多くの言語用にKOI8の変種が用いられており、タジク語用 (KOI8-T)、チェコ語およびスロバキア語用 (KOI8-CS)、モンゴル語用などがある。C1領域にも記号や罫線素などを収容している。
[編集] Compound Text Encoding (CTEXT)
|
||||||||||||||||||||||
Compound Text Encoding (CTEXT) は、ISO/IEC 2022およびISO/IEC 6429の機構に準じつつそれを拡張した8ビット符号の符号化方式である。X Window Systemにおいて、クライアント間のテキスト情報の伝達や、リソース中のテキスト情報の表現に用いる。次のような特徴を持つ。
- アナウンス機能のエスケープシーケンスは省略する。
- 8ビット符号なので、GR領域も使う。
- G0にASCIIを、G1にISO/IEC 8859-1の右半分を指示し、G0をGL領域に、G1をGR領域に呼び出した状態で始まる (このための制御機能は省略する)。つまり、最初はISO/IEC 8859-1で始まる。
- G0およびG1への指示がGL領域およびGR領域への呼び出しを兼ねる。呼び出しの制御機能は使わない。つまり、文字集合の選択は指示のエスケープシーケンスだけで行う。
- ISO/IEC 2022のDOCS (#表2参照) と私用終端バイトにより、利用者独自の文字集合や、UTF-8 のようにISO/IEC 2022に準拠した構造の符号表を持たない符号化システムを指示する (#表5参照)。
- ISO/IEC 6429のSDSにより書字方向を指定する (#表5参照)。
また、つぎの点で ISO/IEC 2022 に対する拡張となっている。
- 指示のエスケープシーケンスでは、中間バイト02/08の省略 (#表2 注参照) をしない。
この結果、複数の符号化システムや文字集合が混在する場合でも、文字コード変換による情報の劣化を起こさず、またクライアントが対応していない符号化システムや文字集合の情報も伝達することが可能になっている。なお、これは異なるアプリケーションの間でのテキスト情報の交換のための符号化方式を定めたものであり、個々のアプリケーション内部でのテキスト処理の際は、適当な内部形式に変換してから処理することが想定されている。
[編集] 注
- ^ 第3次規格までの標題は「情報交換用符号の拡張法」であった。
- ^ 初版制定当時の名称は ISO/R 646。その後 ISO 646、さらに ISO/IEC 646 と改称された。しかし、本項では原則として ISO/IEC 646 と表記する。
- ^ 初版制定当時の名称は ISO 2022:1973。その後1994年の第4版で ISO/IEC 2022 と改称。初版に対するJISの対応規格は JIS C 6228:1975。1982年第2版の JIS C 6228:1982 はその後 JIS X 0202:1982 と改称された。しかし、本項では原則として ISO/IEC 2022 および JIS X 0202 と表記する。
- ^ 初版制定当時の名称は ISO 4873。後に ISO/IEC 4873 と改称された。しかし、本項では原則として ISO/IEC 4873 と表記する。
- ^ これは今日では internationalization (i18n。国際化) あるいは multilingualization (m17n。多言語化) と呼ばれる考えかたであるが、当時はヨーロッパの諸言語にまたがるという意味で harmonization (調和) と呼ばれた。後に ISO/IEC 8859 はヨーロッパ諸語以外も包含するものになる。
- ^ 論理的には5バイト以上のエスケープシーケンスも用いられ得るが、現時点では ISO/IEC 2022 で規定されているものはない。
- ^ a b ISO/IEC 2022が定められた当初は、呼び出しの制御機能には SI (G1からGL領域への呼び出し) と SO (G0からGL領域への呼び出し) しかなかった。そのため、SIを「漢字イン」(制御文字やローマ字の符号表から漢字の符号表にシフトする)、SOを「漢字アウト」(漢字の符号表へのシフトから復する) とする理解が生まれ、ほかの呼び出し制御機能が定められた際には混乱を招いた。実際にはロッキングシフトでは、前の呼び出しを記憶しているわけではない。ちなみに、当時開発されたプリンタ記述言語 (プリンタを制御するための通信手順) には、この漢字イン/漢字アウトの発想が残っているものがある。
- ^ シングルシフトには、G2かG3から呼び出しするものしかない。また、8ビット符号の場合、GL領域に呼び出すかGR領域に呼び出すかは最初にアナウンス機能によって決定することになっている。
- ^ JIS X 0202:1991 解説「登録」による
- ^ a b ISO-2022-JPの場合は、JIS X 0201-1976のラテン文字集合でもよい。
- ^ 日本の国コード JP が含まれる名称である。文字集合として使う JIS X 0208 が日本工業規格であるためと考えられる。なお、JIS X 0208 は、漢字や仮名といった日本語の主要な文字体系のほかに、一部のラテン文字、ギリシア文字、キリル文字をも含んでいる。そのため、日本語以外の言語を部分的に表記できる場合がある。しかし、RFC 1468 の表題は Japanese Character Encoding for Internet Messages (インターネットメッセージのための日本語文字符号化) であることから、特に日本国内にかぎった利用を想定していたわけでもなく、かといって多言語での利用を想定していたわけでもなく、一般的に日本語のコミュニティでの利用を想定していたと考えられる。
- ^ JIS X 0208:1997 附属書2より引用。また、同解説 3.11 も参照。
- ^ EUCでは文字コード (英: codeset)、JISでは符号化表現と呼ぶ。また、一部はキャラクタセットとしてIANAが登録している。
[編集] 参考文献
全般的な記述には以下の文献を参照した。
- ISO/IEC 2375:2003 Data Processing - Procedure for Registration of Escape Sequences
- JIS X 0202:1998 情報技術 - 文字符号の構造及び拡張法 (ISO/IEC 2022:1994 Information technology - Character code structure and extension techniques 第4版の国際一致規格), 日本規格協会, 1998.
- Lunde, Ken. CJKV日中韓越情報処理. オライリー・ジャパン, 2002. ISBN 4-87311-108-0. (原著 Lunde, Ken. CJKV Information Processing. Cambridge, Massachusetts: O'Reilly & Associates, 1998. ISBN 1-56592-224-7.)
- 三上喜貴, 文字符号の歴史 - アジア編 -. 共立出版, 2002年3月. ISBN 4-320-12040-X.
さらに、#応用例の記述には以下の文献も参照した。
- RFC 1468 Japanese Character Encoding for Internet Messages (『インターネットメッセージのための日本語文字符号化』), J. Murai 他著, 1993年6月.
- RFC 1554 ISO-2022-JP-2: Multilingual Extension of ISO-2022-JP (『ISO-2022-JP-2: ISO-2022-JPの多言語拡張』), M. Ohta 他著, 1993年12月.
- RFC 1557 Korean Character Encoding for Internet Messages (『インターネットメッセージのための朝鮮語文字符号化』), U. Choi 他著, 1993年12月.
- RFC 1922 Chinese Character Encoding for Internet Messages (『インターネットメッセージのための中文文字符号化』), HF. Zhu 他著, 1996年3月.
- RFC 2237 Japanese Character Encoding for Internet Messages (『インターネットメッセージのための日本語文字符号化』), K. Tamaru 他著, 1997年11月.
- JIS X 0208:1997 『7ビット及び8ビットの2バイト情報交換用符号化漢字集合』 (7-bit and 8-bit double byte coded Kanji sets for information interchange) 附属書2「RFC1468符号化表現」, 日本規格協会, 1997年.
- JIS X 0213:2000 『7ビット及び8ビットの2バイト情報交換用符号化拡張漢字集合』 (7-bit and 8-bit double byte coded extended Kanji sets for information interchange) 附属書2「ISO-2022-JP-3符号化表現」, 日本規格協会, 2000年.
- JIS X 0213:2000/AMENDMENT 1:2004 『7ビット及び8ビットの2バイト情報交換用符号化拡張漢字集合 (追補1)』 (7-bit and 8-bit double byte coded extended Kanji sets for information interchange (Amendment 1)) 附属書2「ISO-2022-JP-2004符号化表現」, 日本規格協会, 2004年.
- 『UI-OSF-USLP 共同技術資料 日本語EUCの定義と解説』(Unapproved Draft 1.7), 1991年12月.
- X Consortium Standard, Compound Text Encoding Version 1.1, Robert W. Scheifler 著, 1989年.
- Very old fj.kanji discussion - JUNETコード成立のころの議論
- Роман Чибора, The Cyrillic Charset Soup, 1998. - キリル文字用文字コードの変遷
