ISO/IEC 2022
↑ 第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 (調和) と呼ばれた。
Extended Unix Code (EUC) は、ISO/IEC 2022の機構に準じた8ビット符号の文字コードである。これには以下のものが含まれる。次のような特徴を持つ。
アナウンス機能のエスケープシーケンスは省略する。
8ビット符号なので、GR領域も使う。エスケープシーケンスは使わない。
G0にASCIIを、G1にマルチバイト文字集合を、G2やG3に補助的な文字集合を (あれば) 指示し、G0をGL領域に、G1をGR領域に呼び出した状態で始まる (このための制御機能は省略する)。つまり、最初は7ビット符号がASCII、8ビット符号がマルチバイト文字集合で始まる。
指示の状態は固定的に決まっており、変更は行わない。
呼び出しはシングルシフトのみで、G2かG3 (あれば) からGR領域へのみ。
実際にIRRを使用するかどうかは情報交換の仕様の中で定められる。RFC 1468 では、1990年版を使う場合も IRR の付加をしないことを提案している。
JIS X 0208:1997では、附属書2「RFC1468符号化表現」として ISO-2022-JP をJISの規定としたが、この符号化表現が「ISO/IEC 2022に適合するものではない」と付記している。
ISO-2022-JP は、マルチバイト文字集合を扱うものとしては初のMIME用キャラクタセットであった。これ以降、中国語、朝鮮語、あるいは多言語での利用を想定したマルチバイトのキャラクタセットが、ISO-2022-○○という名称でいくつか提案され、一部はRFC にもなった。これらは、ISO-2022-JP で採用された ISO/IEC 2022 の7ビット符号による符号化方式を踏襲していた。しかしその後、日本語以外の言語では、電子メールなどのキャラクタセットはEUC符号化によるものなどが事実上の標準となっていった。今日、マルチバイトで7ビットのキャラクタセットとして一般的に使われているものは、事実上、日本語用の ISO-2022-JP のみである。
ISO/IEC 2022のDOCS (#表2参照) と私用終端バイトにより、利用者独自の文字集合や、UTF-8 のようにISO/IEC 2022に準拠した構造の符号表を持たない符号化システムを指示する (#表5参照)。
ISO/IEC 6429のSDSにより書字方向を指定する (#表5参照)。
また、つぎの点で ISO/IEC 2022 に対する拡張となっている。
指示のエスケープシーケンスでは、中間バイト02/08の省略 (#表2 注参照) をしない。
この結果、複数の符号化システムや文字集合が混在する場合でも、文字コード変換による情報の劣化を起こさず、またクライアントが対応していない符号化システムや文字集合の情報も伝達することが可能になっている。なお、これは異なるアプリケーションの間でのテキスト情報の交換のための符号化方式を定めたものであり、個々のアプリケーション内部でのテキスト処理の際は、適当な内部形式に変換してから処理することが想定されている。