ISO/IEC 2022

ISO/IEC 2022（旧称 ISO 2022）は、
 文字集合を7ビット符号または8ビット符号で表現するための技術、および
 複数の文字集合を単一の文字符号化方式に含める技術
を規定するISO規格である。JISの対応規格はJIS X 0202 「情報技術-文字符号の構造及び拡張法」第3次規格までの標題は「情報交換用符号の拡張法」であった。。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年初版)初版制定当時の名称は ISO/R 646。その後 ISO 646、さらに ISO/IEC 646 と改称された。しかし、本項では原則として ISO/IEC 646 と表記する。では、図形文字の収容領域を ASCII に倣いつつ、12個の符号位置を各国の国内使用目的のために置き換えてよいこととし、さらにレパートリとして国別の文字集合を定義するという方法をとった。

ISO/IEC 2022 (1973年初版)初版制定当時の名称は 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/IEC 646 に準拠した複数の符号表を切り替えて多言語の処理を実現することを目的に制定された。しかし、ISO/IEC 646 の方式では、ラテンアルファベットの範囲に限ってさえも、多数のダイアクリティカルマーク付き文字や、言語ごとに必要とされる記号類などを十分に収容することができなかった。このため、ISO/IEC 646 と互換性を保ちつつ8ビット符号 を採用した ISO/IEC 4873 (1979年初版)初版制定当時の名称は ISO 4873。後に ISO/IEC 4873 と改称された。しかし、本項では原則として ISO/IEC 4873 と表記する。 が制定された。特にヨーロッパでは1980年代に入って多言語のテキストデータを共通の仕様の下に処理できるようにしたいという要求が高まっておりこれは今日では internationalization (i18n。国際化) あるいは multilingualization (m17n。多言語化) と呼ばれる考えかたであるが、当時はヨーロッパの諸言語にまたがるという意味で harmonization (調和) と呼ばれた。後に ISO/IEC 8859 はヨーロッパ諸語以外も包含するものになる。、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文字集合および96n文字集合に対応した。
（JISのみ）この版からJIS X 0201を拡張する規格からISO/IEC 646を拡張する規格になったため、国際一致規格になった。
第4次規格
7ビット符号中心の記述から8ビット符号中心の記述に改められた。

#表1に、各版ごとの規格番号、制定日などを示す。
+  ISO/IEC 2022 の各版ごとの規格番号・制定日等版ISO規格番号ISO制定・改正日JIS番号JIS制定・改正日第1次規格ISO 2022:19731973年5月制定JIS C 6228:19751975年3月1日制定第2次規格ISO 2022:19821982年12月改正JIS C 6228:1984※1984年11月1日改正第3次規格ISO 2022:19861986年5月改正JIS X 0202:19911991年1月1日改正第4次規格ISO/IEC 2022:19941994年12月改正JIS X 0202:19981998年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 の「字」は 27区90点 (27-90) なので、GL領域では 03/11 07/10、GR領域では 11/11 15/10 と表現される。

 制御機能 

複数の文字集合を表現するために、ISO/IEC 2022の文字符号化方式は、符号の性質や扱う文字集合を指定するための制御機能を含んでいる。制御機能の表現には、7ビット符号ではC0制御文字のほか、ESCAPE制御文字(01/11。十六進数の1B、十進数の27)で始まる2バイトないし4バイトからなるエスケープシーケンスを用いる論理的には5バイト以上のエスケープシーケンスも用いられ得るが、現時点では ISO/IEC 2022 で規定されているものはない。。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つ以上のバッファを一度に呼び出しておくことはできない。

呼び出しには、ロッキングシフトとシングルシフトがある。ロッキングシフトでは、いったん呼び出しされたものは、別の呼び出しがあるまで使いつづけることができるISO/IEC 2022が定められた当初は、呼び出しの制御機能には SI (G1からGL領域への呼び出し) と SO (G0からGL領域への呼び出し) しかなかった。そのため、SIを「漢字イン」(制御文字やローマ字の符号表から漢字の符号表にシフトする)、SOを「漢字アウト」(漢字の符号表へのシフトから復する) とする理解が生まれ、ほかの呼び出し制御機能が定められた際には混乱を招いた。実際にはロッキングシフトでは、前の呼び出しを記憶しているわけではない。ちなみに、当時開発されたプリンタ記述言語 (プリンタを制御するための通信手順) には、この漢字イン/漢字アウトの発想が残っているものがある。。シングルシフトでは、呼び出しされたものは直後の1文字 (シングルバイトの文字集合であれば1バイト、マルチバイトの文字集合であればそれぞれのバイト数分) だけ使え、そのあとは呼び出し前の状態に戻るシングルシフトには、G2かG3から呼び出しするものしかない。また、8ビット符号の場合、GL領域に呼び出すかGR領域に呼び出すかは最初にアナウンス機能によって決定することになっている。。

実際には、文脈や規約が特定の文字集合を使うよう指定していれば、符号化の仕様を指定する制御機能 (アナウンス機能) や初期の文字集合を指示する制御機能は省略することができる。ISO-2022-CNを定義しているを例に取ると、呼び出しに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）がおこなうことになっている。2024年に登録手続きが廃止されるまでISO/IEC TR 2375:2024 Information technology – Registered escape sequences and coded character sets、その事務局は日本の情報処理学会情報規格調査会 (IPSJ/ITSCJ) が引き受けていた（符号化文字集合の国際登録簿）。ITSCJ以前はECMA（欧州計算機製造業者協会、現Ecma International）が登録事務局を引き受けていたJIS X 0202:1991 解説「登録」による。

終端文字は登録順に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に戻さなければならないISO-2022-JPの場合は、JIS X 0201-1976のラテン文字集合でもよい。。

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

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

上図で、上段が符号化したい文字列である。「日本語版」は JIS X 0208 に含まれる文字の列、「Wikipedia」はASCIIに含まれる文字の列である。また、最初はASCIIで始まる。したがって、「日本語版」の直前と「Wikipedia」の直前に文字集合を指示するエスケープシーケンスが必要になる (ISO-2022-JP では指示が呼び出しを兼ねるので、呼び出しの制御機能は必要ない)。マルチバイト文字は区点で、シングルバイト文字は行列で表すと、中段のようになる。区点を2バイトずつで表し、全体を7ビット符号で表すと、下段のように符号化される。

 ISO-2022-JP 

ISO-2022-JPは、日本語の電子メールなどのための符号化表現として広く使われている。このキャラクタセットは、1986年後半ころに、当時のJUNETで、ネットニューズや電子メールで日本語を利用するための符号化の共通仕様として成立し、のちにその仕様は  でInformationalとして発行された。当初は「JISコード」、「JUNETコード」(junet-code) などと呼ばれたが、最終的には同RFCにおいて、MIMEのためのキャラクタセット名としてISO-2022-JPの名称が規定され日本の国コード JP が含まれる名称であるのは、ネットニューズのfj.*グループの利用者およびホストコンピュータのjpドメイン名を電子メールアドレスに含む利用者らの議論による。なお文字集合として使う JIS X 0208 は日本産業規格であり、漢字や仮名といった日本語に必須の文字体系のほかに、アラビア数字や種々の記号とともに頭字語用途を主として一部のラテン文字、ギリシア文字、キリル文字も含んでいる。そのため、日本語以外の言語を部分的に表現できる。 の表題は Japanese Character Encoding for Internet Messages (インターネットメッセージのための日本語文字符号化) であることから、特に日本国内にかぎった利用を想定していたわけでもなく、日本語コミュニティでの利用を想定していた。、後のIANA Character Setsにも収録されている。

ISO/IEC 2022 に準拠した7ビットの符号化表現だが、次のような特徴を持つ。

 JIS X 0208が指示(かつ呼び出し)されている状態では、SPACE (空白) や制御文字を使ってはならない。
 行末では指示(かつ呼び出し)をASCIIにもどさなければならない。つまり、行末の前に漢字の文字集合が指示されていたら、ASCIIを指示してから改行しなければならない。
 JIS X 0208を指示するとき、改訂番号識別のエスケープシーケンスを用いずに1983年版と1990年版のどちらを使ってもよい。

JUNETコードの成立当時、日本語対応端末などの機器には「漢字イン/漢字アウト」理解に基づく動作をするものが複数存在し、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を使用するかどうかは情報交換の仕様の中で定められる。 では、1990年版を使う場合も IRR の付加をしないことを提案している。

JIS X 0208:1997では、附属書2「RFC1468符号化表現」として ISO-2022-JP をJISの規定としたが、この符号化表現が「ISO/IEC 2022に適合するものではない」JIS X 0208:1997 附属書2より引用。また、同解説 3.11 も参照。と付記している。

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ビット符号の文字コードEUCでは文字コード (英: codeset)、JISでは符号化表現と呼ぶ。また、一部はキャラクタセットとしてIANAが登録している。である。これには以下のものが含まれる。次のような特徴を持つ。

 アナウンス機能のエスケープシーケンスは省略する。
 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も参照)。

上図で、上段が符号化したい文字列である。「日本語版」は JIS X 0208 に含まれる文字の列、「Wikipedia」はASCIIに含まれる文字の列である。ASCIIはGL領域に、JIS X 0208はGR領域に呼び出されている。したがって、「日本語版」を8ビットで、「Wikipedia」を7ビットで符号化すればよい。マルチバイト文字は区点で、シングルバイト文字は行列で表すと、中段のようになる。区点を2バイトずつで表し、全体を8ビット符号か7ビット符号で表すと、下段のように符号化される。

 変異 
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領域にも記号や罫線素などを収容している。

DOS、Windows、その他パソコンに組み込みのコードページ  これらのうち、シングルバイトのものの多く。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 注参照) をしない。

この結果、複数の符号化システムや文字集合が混在する場合でも、文字コード変換による情報の劣化を起こさず、またクライアントが対応していない符号化システムや文字集合の情報も伝達することが可能になっている。なお、これは異なるアプリケーションの間でのテキスト情報の交換のための符号化方式を定めたものであり、個々のアプリケーション内部でのテキスト処理の際は、適当な内部形式に変換してから処理することが想定されている。

 注 

 参考文献 

全般的な記述には以下の文献を参照した。

 JIS X 0202:1998　『情報技術 - 文字符号の構造及び拡張法』　日本規格協会、1998年。(ISO/IEC 2022:1994 Information technology - Character code structure and extension techniques 第4版の国際一致規格)
 (原著 )

さらに、節ごとの記述で以下の文献を参照した。

#歴史 (#第2次規格以降の主な改正点以外)

 特に第3章「ASCIIとその拡張」を参照。

#ISO国際登録簿
 ISO/IEC 2375:2003 Data Processing - Procedure for Registration of Escape Sequences

#応用例
  Japanese Character Encoding for Internet Messages (『インターネットメッセージのための日本語文字符号化』), J. Murai 他著, 1993年6月.
   ISO-2022-JP-2: Multilingual Extension of ISO-2022-JP (『ISO-2022-JP-2: ISO-2022-JPの多言語拡張』), M. Ohta 他著, 1993年12月.
  Korean Character Encoding for Internet Messages (『インターネットメッセージのための朝鮮語文字符号化』), U. Choi 他著, 1993年12月.
  Chinese Character Encoding for Internet Messages (『インターネットメッセージのための中文文字符号化』), HF. Zhu 他著, 1996年3月.
  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コード成立のころの議論
  - キリル文字用文字コードの変遷

 関連項目 
ISO/IEC 646
Extended Unix Code
CJKV
文字化け
国際化と地域化

 外部リンク 
 国際標準化機構（英語）
 ECMA-35
 符号化文字集合の国際登録簿（英語）
 北米、ヨーロッパー、およびアジアにおける文字コードの歴史（英語）
 CJK.INF（英語）: 日中韓(CJK)の言語の符号化方式に関する文書。ISO/IEC 2022の各変種の議論を含む。HTTPでも入手可能。

02022
ISO IEC 02022