ISO/IEC 2022 （旧称 ISO 2022 ）は、
文字集合 を7ビット符号または8ビット符号で表現するための技術、および複数の文字集合を単一の文字符号化方式 に含める技術 を規定する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] レパートリ として国別の文字集合を定義するという方法をとった。
ISO/IEC 2022 (1973年初版)[ 3] ダイアクリティカルマーク 付き文字や、言語ごとに必要とされる記号類などを十分に収容することができなかった。このため、ISO/IEC 646 と互換性を保ちつつ8ビット符号 を採用した ISO/IEC 4873 (1979年初版)[ 4] ヨーロッパ では1980年代 に入って多言語のテキストデータを共通の仕様の下に処理できるようにしたいという要求が高まっており[ 5] 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 や、UNIX 環境で使われるEUC-JP 、中国のGB 2312 ことEUC-CN、韓国のEUC-KR などがそうである。ISO/IEC 8859シリーズもISO/IEC 2022の構造にしたがっている。一方で、この規格に則らない符号化方式、たとえばShift_JIS や台湾のBig5 などもまた広く使われている。
第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日改正
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の符号表は、表示や印字される文字 (図形文字 ) の領域と、制御機能に使う文字 (制御文字 #図1 行 および列 で表す。たとえば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 の「字」は 27区90点 (27-90) なので、GL領域では 03/11 07/10、GR領域では 11/11 15/10 と表現される。
(a) 7ビット符号
行
00
01
02
03
04
05
06
07
08
09
00
[b]
01
02
03
04
05
06
07
C0
GL
C1[d]
08
09
10
11
[a]
12
13
14
15
[c]
(b) 8ビット符号
行
00
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
00
[b]
[e]
01
02
03
04
05
06
07
C0
GL
C1
GR
08
09
10
11
[a]
12
13
14
15
[c]
[e]
JIS X 0202:1998 を元に作成。
符号表上の文字の位置を行と列で示す。たとえば 01/11 (ESCAPE) は16進数値では 1B にあたる。
a
b
c
d
e
制御文字またはエスケープシーケンス
説明
略号
指示
01/11 02/01 I Ft
C0への制御機能集合の指示 (呼び出しを含む)
CZD
01/11 02/02 I Ft
C1への制御機能集合の指示 (呼び出しを含む)
C1D
01/11 02/08 I Ft
G0への94文字集合の指示
GZD4
01/11 02/09 I Ft
G1への94文字集合の指示
G1D4
01/11 02/10 I Ft
G2への94文字集合の指示
G2D4
01/11 02/11 I Ft
G3への94文字集合の指示
G3D4
01/11 02/13 I Ft
G1への96文字集合の指示
G1D6
01/11 02/14 I Ft
G2への96文字集合の指示
G2D6
01/11 02/15 I Ft
G3への96文字集合の指示
G3D6
01/11 02/04 02/08 Ft [a]
G0への94n 文字集合の指示
GZDM4
01/11 02/04 02/09 Ft
G1への94n 文字集合の指示
G1DM4
01/11 02/04 02/10 Ft
G2への94n 文字集合の指示
G2DM4
01/11 02/04 02/11 Ft
G3への94n 文字集合の指示
G3DM4
01/11 02/04 02/13 Ft
G1への96n 文字集合の指示
G1DM6
01/11 02/04 02/14 Ft
G2への96n 文字集合の指示
G2DM6
01/11 02/04 02/15 Ft
G3への96n 文字集合の指示
G3DM6
01/11 02/05 I Ft
他の符号化システムの指示
DOCS
01/11 02/06 F [b]
文字集合の改訂番号の識別
IRR
呼び出し (シフト)
00/15
GL領域へのG0の呼び出し[c]
SI
00/15
GL領域へのG0の呼び出し[d]
LS0
00/14
GL領域へのG1の呼び出し[c]
SO
00/14
GL領域へのG1の呼び出し[d]
LS1
01/11 06/14
GL領域へのG2の呼び出し
LS2
01/11 06/15
GL領域へのG3の呼び出し
LS3
01/11 07/14
GR領域へのG1の呼び出し[d]
LS1R
01/11 07/13
GR領域へのG2の呼び出し[d]
LS2R
01/11 07/12
GR領域へのG3の呼び出し[d]
LS3R
01/11 04/14
GL領域またはGR領域へのG2の1文字限りの呼び出し[e]
SS2
01/11 04/15
GL領域またはGR領域へのG3の1文字限りの呼び出し[e]
SS3
アナウンス
01/11 02/00 F [f]
アナウンス機能
ACS
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
d
e
f F バイトによって、利用する機能を指定する。
複数の文字集合を表現するために、ISO/IEC 2022の文字符号化方式は、符号の性質や扱う文字集合を指定するための制御機能 を含んでいる。制御機能の表現には、7ビット符号ではC0制御文字のほか、ESCAPE制御文字(01/11。十六進数の1B、十進数の27)で始まる2バイトないし4バイトからなるエスケープシーケンス を用いる[ 6] #表2
ある文字集合を符号表上で使うには、一般に指示 (英: 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] [ 8]
実際には、文脈や規約が特定の文字集合を使うよう指定していれば、符号化の仕様を指定する制御機能 (アナウンス機能) や初期の文字集合を指示する制御機能は省略することができる。ISO-2022-CNを定義しているRFC 1922 を例に取ると、呼び出しにSIとSOの制御文字を使用するが、この仕様を宣言するアナウンス機能のエスケープシーケンスを省略している。また、初期状態ではG0にUS-ASCII 、G1にGB2312-80 を指示し、G0をGL領域に呼び出しているが、指示のエスケープシーケンスも省略している。
ISO/IEC 2022は具体的な符号化文字集合とは切り離して規定されているため、実際にこの規格を適用するにあたってはエスケープシーケンスの終端文字と符号化文字集合などとの具体的な対応関係を定める必要があり、そのために符号化文字集合のISO国際登録簿が存在する。これはエスケープシーケンスの終端文字についてそれぞれどの文字がどの符号化文字集合などに対応しているのかを定めたものである。符号化文字集合のISO国際登録簿と登録方法はISO/IEC 2375 Data Processing - Procedure for Registration of Escape Sequences (情報技術－エスケープシーケンス及び符号化文字集合の登録手順) に規定されている。
ISO国際登録簿への登録申請を行うことが出来るのは次の者に限定される。
ISO/IEC（ISO/IEC JTC 1結成以前はISO）の技術委員会（TC）または小委員会（SC）
ISO TC 46/SC 4、ISO TC 97/SC 2、ISO TC 97/SC 21など
符号拡張またはエスケープシーケンスの使用法を検討するISO/IEC JTC/SC2（ISO/IEC JTC 1結成以前はISO TC 97/SC 2）内の作業グループ（WG）
ISO/IEC JTC 1/SC 2/WG 2、ISO/IEC JTC 1/SC 2/WG 3、ISO TC 97/SC 2/WG 4、ISO TC 97/SC 2/WG 7など。
ISO/IEC（ISO/IEC JTC 1結成以前はISO）の会員団体（各国で1団体ずつと決められている。）
米国規格協会（ANSI ）、日本工業標準調査会 （JISC）、英国規格協会 （BSI）、ドイツ規格協会（DIN ）など。
ISO/IECの技術委員会または小委員会と関連のある国際機関
ヨーロッパ電子計算機工業会（ECMA ）、国際電気通信連合 電気通信標準化部門（ITU-T ：旧CCITT）など。 登録の手続きと国際登録簿の維持管理は登録事務局（Registration Authority）がおこなうことになっている。現在、その事務局は日本の情報処理学会 情報規格調査会 (IPSJ/ITSCJ) が引き受けている（符号化文字集合の国際登録簿 ）。かつてはECMA（欧州計算機製造業者協会、現Ecma International ）が登録事務局を引き受けていた[ 9]
終端文字は登録順に16進数の「4/0」から順に割り振っていくことになっている。終端文字の割り振りは区分ごとに行われることになっている。（そのため同じ終端文字でも、どの区分の終端文字であるのかによって指し示す符号系は異なり、そのエスケープシーケンスがどの区分の符号系を指し示すのかは中間文字が何であるのかによって識別できる。）
登録数の最も多い94文字集合については、当初の規格で用意されていた利用可能な終端文字を使い切ってしまったため、第三次規格において94文字集合を指し示す新たな中間文字を設けてより多くの94文字集合が登録出来るように規定が改正された。
なお、一つの規格で定められた符号系であっても、文字の追加変更を含む改正が行われたときには異なる符号系として扱われることになっており、そのために改めて登録が行われ、新たな登録番号と終端符号が付与されることになる。例えばJIS X 0208は1978年 版、1983年 版、1990年 版のそれぞれが、JIS X 0213 は2000年 版と2004年 版がそれぞれ異なる符号系として登録されている。
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 C 6220 -1976のラテン文字集合 (ISO/IEC 646の日本版)01/11 02/08 04/10 ESC ( J
JIS C 6226 -197801/11 02/04 04/00 ESC $ @
JIS X 0208 -198301/11 02/04 04/02 ESC $ B
ISO-2022-JP-1
日本語
ISO-2022-JP に以下を追加
JIS X 0212 -1990G0
01/11 02/04 02/08 04/04 ESC $ ( D 指示が兼ねる
ISO-2022-JP-2
多言語
ISO-2022-JP-1 に以下を追加
GB 2312 -80G0
01/11 02/04 04/01 ESC $ A 指示が兼ねる
KS X 1001 -199201/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 -1992G1
01/11 02/04 02/09 04/03 ESC $ ) C 00/14 SO
ISO-2022-CN
中国語
ASCII
G0
初めから指示したまま
00/15 SI
GB 2312 -80G1
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 -87G2
未定 01/11 04/14 ESC N
GB 13131 -91未定
GB 7590 -87G3
未定 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 で、ネットニューズや電子メールで日本語を利用するための符号化の共通仕様として成立し、のちにその仕様は RFC 1468 でInformational として発行された。当初は「JISコード」、「JUNETコード」(junet-code ) などと呼ばれたが、最終的には同RFCにおいて、MIME のためのキャラクタセット名としてISO-2022-JPの名称が規定され[ 11] IANA Character Sets にも収録されている。
ISO/IEC 2022 に準拠した7ビットの符号化表現だが、次のような特徴を持つ。
JIS X 0208 が指示(かつ呼び出し)されている状態では、SPACE (空白) や制御文字を使ってはならない。行末では指示(かつ呼び出し)をASCIIにもどさなければならない。つまり、行末の前に漢字の文字集合が指示されていたら、ASCIIを指示してから改行しなければならない[ 10]
JIS X 0208を指示するとき、改訂番号識別のエスケープシーケンスを用いずに1983年版と1990年版のどちらを使ってもよい。 JUNETコードの成立当時、日本語対応端末などの機器には「漢字イン/漢字アウト」理解[ 7] 02/00 ) や制御文字が現れると正しく処理できなかった。改行の処理についても、行末の制御文字の処理でASCIIにもどってしまうものがあった。こういった機器は、ハードウェアの組込みソフトウェアによって実現されている例も多く、その挙動を修正することはしばしば困難だった。そのため、情報交換当事者間の合意として上記の条件のもと符号化する。
また、ISO/IEC 2022 では、改訂後の文字集合を指示する場合には、指示のエスケープシーケンスの前に改訂番号を識別するエスケープシーケンス (IRR。#表2 01/11 02/06 04/00 (ESC & @ 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 で採用された ISO/IEC 2022 の7ビット符号による符号化方式を踏襲していた。しかしその後、日本語以外の言語では、電子メールなどのキャラクタセットはEUC 符号化によるものなどが事実上の標準となっていった。今日、マルチバイトで7ビットのキャラクタセットとして一般的に使われているものは、事実上、日本語用の ISO-2022-JP のみである。
Extended Unix Code [ 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ビット符号で表すと、下段のように符号化される。
EUCは業界標準であるため、ベンダごとの独自の実装も包含するものとなっている。そのため、厳密に言えばISO/IEC 2022に準拠しているとは言えないものもある。
EUC-JP 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 」は俗称である。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 アルメニア文字 。ASMO 449+ アラビア語 用のアラビア文字 。ISO/IEC 8859-6 と互換性がある。ISCII インド の諸言語の文字。用字系 の切り替えや、結合文字 の表現のための特殊な図形文字を持つ。ISO/IEC 8859 シリーズヨーロッパ の諸言語 (トルコ語 およびエスペラント を含む) のラテン文字集合を含み、さらにアラビア文字 、ギリシア文字 、キリル文字 、タイ文字 、ヘブライ文字 の文字集合をも含む。JIS X 0201 日本語 用の片仮名 。PASCII アラビア文字 (ウルドゥ語 、シンド語 、カシミール語 、アラビア語 )。ISO/IEC 8859-6 とは互換性がない。TIS 620 タイ文字 。ISO/IEC 8859-11 と互換性がある。TSCII タミル文字 。ISCIIのタミル文字とは互換性がない。
拡張ASCIIの方法では、ラテン文字 以外の文字は最大96文字までしか収録できない。またたとえラテン文字であっても、極めて多数のダイアクリティカルマーク 付き文字を使う言語では、ISO/IEC 2022の8ビット符号でも文字数が不足する。かといって、マルチバイト文字集合を採用するほど多いわけでもない、という場合、図形文字をGR領域やGL領域の外にまで配置することもある。
VISCII ベトナム語 用電子メール などで広く使われているキャラクタセットである。GL領域はASCIIであるが、ダイアクリティカルマーク付き文字のうち96文字をGR領域に収容し、残りを、C1の32文字すべて、さらにはC0のうち6文字にまで割り当てている。KOI8 系文字集合キリル文字 。ロシア語 用およびブルガリア語 用に使われるKOI8-R 、ウクライナ語 用に使われるKOI8-U 、ウクライナ語、ベラルーシ語 、ロシア語共通のKOI8-RU が代表的である。ほかにも、キリル文字を使う多くの言語用にKOI8の変種が用いられており、タジク語 用 (KOI8-T )、チェコ語 およびスロバキア語 用 (KOI8-CS )、モンゴル語 用などがある。C1領域にも記号や罫線素などを収容している。MS-DOS 、Windows 、その他パソコン に組み込みのコードページ これらのうち、シングルバイトのものの多く。C1領域にも記号や罫線素などを収容している。
制御機能
説明
01/11 02/05 02/15 03/00 M L [a]
可変長の符号化システムの指示
01/11 02/05 02/15 03/01 M L [a]
1文字1バイトの符号化システムの指示
01/11 02/05 02/15 03/02 M L [a]
1文字2バイトの符号化システムの指示
01/11 02/05 02/15 03/03 M L [a]
1文字3バイトの符号化システムの指示
01/11 02/05 02/15 03/04 M L [a]
1文字4バイトの符号化システムの指示
01/11 02/05 04/07[b]
UTF-8に切り替える
01/11 02/05 04/00[b]
UTF-8から戻る
09/11 03/01 05/13[c]
書字方向を左から右とする
09/11 03/02 05/13[c]
書字方向を右から左とする
09/11 05/13[c]
直近に行った書字方向の指定から戻る
a M L で指示の後につづく要素のバイト数を示す。M と L の最上位桁ビット (常に1) を除く合計14ビットが表す値がバイト数となる。要素内は、符号化システムの名前ではじまり、00/02 (STX ) で区切ってその後に実際の符号化文字要素が続く。
b XFree86 による拡張。本来の Compound Text Encoding では ISO に登録された「他の符号化システム」は使わないことになっている。
c ISO/IEC 6429 の機能。
Compound Text Encoding 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 が含まれる名称であるのは、ネットニューズのfj.*グループの利用者およびホストコンピュータのjpドメイン名を電子メールアドレスに含む利用者らの議論による。なお文字集合として使う JIS X 0208 は日本工業規格であり、漢字 や仮名 といった日本語に必須の文字体系 のほかに、アラビア数字や種々の記号とともに頭字語用途を主として[要出典 一部のラテン文字 、ギリシア文字 、キリル文字 も含んでいる。そのため、日本語以外の言語を部分的に表現できる。RFC 1468 の表題は Japanese Character Encoding for Internet Messages (インターネットメッセージのための日本語文字符号化) であることから、特に日本国内にかぎった利用を想定していたわけでもなく、日本語コミュニティでの利用を想定していた。
^ JIS X 0208:1997 附属書2より引用。また、同解説 3.11 も参照。
^ EUC では文字コード (英: codeset )、JIS では符号化表現 と呼ぶ。また、一部はキャラクタセット としてIANAが登録している。
全般的な記述には以下の文献を参照した。
JIS X 0202:1998 『情報技術 - 文字符号の構造及び拡張法』 日本規格協会、1998年。(ISO/IEC 2022:1994 Information technology - Character code structure and extension techniques 第4版の国際一致規格)
Lunde, Ken 『CJKV日中韓越情報処理』オライリー・ジャパン、2002年。ISBN 4-87311-108-0 。 Lunde, Ken (1998). CJKV Information Processing . Cambridge, Massachusetts: O'Reilly & Associates. ISBN 1-56592-224-7
さらに、節ごとの記述で以下の文献を参照した。
#歴史 (#第2次規格以降の主な改正点 以外)
#ISO国際登録簿
ISO/IEC 2375:2003 Data Processing - Procedure for Registration of Escape Sequences #応用例
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コード成立のころの議論Роман Чибора (1998年). “The Cyrillic Charset Soup ”. 2007年2月11日 閲覧。 - キリル文字用文字コードの変遷
日本語 用の
日本語を含む
日本語以外用の
ソフトウェア 区分け 概念 関連トピック
カテゴリ
