ISO/IEC 2022

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]では、図形文字の収容領域を 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や、UNIX環境で使われるEUC-JP、中国のGB 2312ことEUC-CN、韓国のEUC-KRなどがそうである。ISO/IEC 8859シリーズもISO/IEC 2022の構造にしたがっている。一方で、この規格に則らない符号化方式、たとえばShift_JISや台湾のBig5などもまた広く使われている。

第2次規格以降の主な改正点

第2次規格以降の主な改正点には次のようなものがある。なお、用語については当項目でこの後解説する。

第2次規格

8ビット符号に対応した。
バッファG2およびG3を新設した。
マルチバイト文字集合に対応した。

第3次規格

96文字集合および96ⁿ文字集合に対応した。
（JISのみ）この版からJIS X 0201を拡張する規格からISO/IEC 646を拡張する規格になったため、国際一致規格になった。

第4次規格

7ビット符号中心の記述から8ビット符号中心の記述に改められた。

#表1に、各版ごとの規格番号、制定日などを示す。

**表1 ISO/IEC 2022 の各版ごとの規格番号・制定日等**
版	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文字を符号化する。たとえば94ⁿ文字集合では、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 と表現される。

図1 ISO/IEC 2022の符号表の構造

**(a) 7ビット符号**
行＼列	00	01	02	04	07	08
00			^[b]
01
02
03
04
05
06
07	C0			GL		C1^[d]
08	C0			GL		C1^[d]
09
10
11		^[a]
12
13
14
15					^[c]

**(b) 8ビット符号**
行＼列	00	01	02	04	07	08	10	12	15
00			^[b]				^[e]
01
02
03
04
05
06
07	C0			GL		C1		GR
08	C0			GL		C1		GR
09
10
11		^[a]
12
13
14
15					^[c]				^[e]

JIS X 0202:1998 を元に作成。

符号表上の文字の位置を行と列で示す。たとえば 01/11 (ESCAPE) は16進数値では 1B にあたる。

^a 常に ESCAPE 制御文字。

^b GL領域に94文字集合が呼び出されているときは SPACE (空白文字) となる。

^c GL領域に94文字集合が呼び出されているときは DELETE 制御文字となる。

^d 7ビット符号では、C1制御文字は実際には使用しない。代替のエスケープシーケンスで表す。

^e GR領域に94文字集合が呼び出されているときは、この2つの行列は使用しない。

制御機能

**表2 ISO/IEC 2022 の制御機能 (抜粋)**
制御文字またはエスケープシーケンス	説明	略号

指示
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への94ⁿ文字集合の指示	GZDM4
01/11 02/04 02/09 Ft	G1への94ⁿ文字集合の指示	G1DM4
01/11 02/04 02/10 Ft	G2への94ⁿ文字集合の指示	G2DM4
01/11 02/04 02/11 Ft	G3への94ⁿ文字集合の指示	G3DM4
01/11 02/04 02/13 Ft	G1への96ⁿ文字集合の指示	G1DM6
01/11 02/04 02/14 Ft	G2への96ⁿ文字集合の指示	G2DM6
01/11 02/04 02/15 Ft	G3への96ⁿ文字集合の指示	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 または 08/14	GL領域またはGR領域へのG2の1文字限りの呼び出し^[e] (シングルシフト)	SS2
01/11 04/15 または 08/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 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 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年版がそれぞれ異なる符号系として登録されている。

応用例

7ビット符号によるマルチバイト用のキャラクタセット

ISO/IEC 2022の機構を使う7ビット符号のキャラクタセットには以下のものが含まれる。次のような特徴を持つ。

アナウンス機能のエスケープシーケンスは省略する。
7ビット符号なので、GR領域は使わず、C1制御文字はエスケープシーケンスで表す。
最初は、G0にASCIIを指示し、G0をGL領域に呼び出した状態で始まる (このための制御機能は省略する)。つまり、最初はUS-ASCIIで始まる。
行の終わりではASCIIに戻さなければならない^[10]。

#表3に、これらのキャラクタセットで用いる符号化文字集合と、その選択のための制御機能を示す。

ISO-2022-JPでの「日本語版Wikipedia」という文字列の符号化を例に説明する (#表3も参照)。

**図2 ISO-2022-JPによる「日本語版Wikipedia」の符号化**
文字				日		本		語		版					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ビット符号で表すと、下段のように符号化される。

**表3 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-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 に以下を追加
ISO-2022-JP-1	日本語	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	G0	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 の右半分	G2	01/11 02/14 04/06 ESC . F	01/11 04/14 ESC N (シングルシフト)

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面	G0	01/11 02/04 02/08 04/16 ESC $ ( P	指示が兼ねる (ロッキングシフト)

ISO-2022-JP-2004	日本語	ISO-2022-JP-3 に以下を追加
ISO-2022-JP-2004	日本語	JIS X 0213:2004の1面	G0	01/11 02/04 02/08 04/17 ESC $ ( Q	指示が兼ねる (ロッキングシフト)

ISO-2022-KR	韓国語	ASCII	G0	初めから指示したまま	00/15 SI (ロッキングシフト)
ISO-2022-KR	韓国語	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面	G1	01/11 02/04 02/09 04/07 ESC $ ) G	00/14 SO (ロッキングシフト)
		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	G1	未定	00/14 SO (ロッキングシフト)
		GB 7589-87	G2	未定	01/11 04/14 ESC N (シングルシフト)
		GB 13131-91	G2	未定	01/11 04/14 ESC N (シングルシフト)
		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」も参照

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]に基づく動作をするものが複数存在し、JIS X 0208の文字要素並びの途中にSPACE (空白 02/00) や制御文字が現れると正しく処理できなかった。改行の処理についても、行末の制御文字の処理で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 で採用された ISO/IEC 2022 の7ビット符号による符号化方式を踏襲していた。しかしその後、日本語以外の言語では、電子メールなどのキャラクタセットは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も参照)。

**図3 EUC-JPによる「日本語版Wikipedia」の符号化**
文字	日		本		語		版		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ビット符号で表すと、下段のように符号化される。

**表4 EUCでの文字集合の選択**
文字コード	対象言語	文字集合	文字集合選択のための制御機能
文字コード	対象言語	文字集合	指示		呼び出し

EUC-CN (GB2312)	中国語簡体字	ASCII	G0	指示したまま	GLのまま
EUC-CN (GB2312)	中国語簡体字	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のまま
EUC-KR	韓国語	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: アルメニア文字。
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領域にも記号や罫線素などを収容している。

Compound Text Encoding (CTEXT)

**表5 Compound Text Encoding で拡張された制御機能**
制御機能	説明
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 (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 が含まれる名称であるのは、ネットニューズの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次規格以降の主な改正点以外)

三上喜貴『文字符号の歴史 - アジア編 -』共立出版、2002年3月。ISBN 4-320-12040-X。特に第3章「ASCIIとその拡張」を参照。

#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日閲覧。 - キリル文字用文字コードの変遷