Information Processing―ISO 7‐bit and 8‐bit coded character sets―Code extension techniques

ISO/IEC 2022 符号拡張法 (文字コード)

[12] ISO/IEC 2022 Character Code Structure and Extension Techniques (文字符号の構造及び拡張法) (旧: Code Extension Techniques (情報交換用符号の拡張法) ) は、 符号拡張法、 すなわち ISO/IEC 646 で表現できない様々な符号化文字を使う手法を規定する ISO/IEC国際標準でした。

仕様書

[4] 最終改訂は。改訂を経るごとに複雑になってきている。

[44] 未だ現行規格ですが、 Unicode (ISO/IEC 的には ISO/IEC 10646) の普及によって実効性喪失しつつあります。

符号構造

[64] ISO/IEC 20227ビット符号または8ビット符号を想定しています。 つまり ISO/IEC 2022符号化文字データ要素の列とは、 7ビットまたは8ビットを1つの単位とするビット組合せの連続です。 1つの文字制御機能が、 1つ以上ビット組合せの列として表現されます。

[65] 現代においては、実際問題として、 すべて8ビットバイトとして表現されます。 7ビット符号最上位ビット08ビットバイトとして扱われます。
[46] ISO/IEC 2022符号の構造

[67] ISO文字コードの世界では7ビットで表現可能な [ 0/0, 7/15 ] (= [ 0x00, 0x7F ]) (left) 8ビットの増加部分 [ 8/0, 15/15 ] (= [ 0x80, 0xFF ]) (right) と呼んでいます。 左右それぞれが制御文字用の領域 CL ([ 0/0, 1/15 ] = [ 0x00, 0x1F ]), CR ([ 2/0, 7/15 ] = [ 0x20, 0x7F ])図形文字用の領域 GL ([ 8/0, 9/15 ] = [ 0x80, 0x9F ]), GR ([ 10/0, 15/15 ] = [ 0xA0, 0xFF ]) に分けられています。

[28] DOCS を使うと ISO/IEC 2022 の符号の構造の原則から外れる体系に移行できます。 移行先によっては ISO/IEC 2022 に復帰できます。

[66] ISO/IEC 10646 は、 ISO/IEC 10646規定する符号化文字データ要素の列として ISO/IEC 2022エスケープシーケンス (の一部) を利用する方法を定めています。 その場合には、 ISO/IEC 106462オクテット4オクテットの列や、 UTF-88ビットバイト列のような形で ISO/IEC 2022エスケープシーケンスが記述されます。 ISO/IEC 10646におけるエスケープシーケンス

ISO/IEC 2022 符号構造からの派生

[72] ISO/IEC 2022 系統の文字コードのように見えて微妙に違うものや、 ISO/IEC 2022 系統の文字コードとして出発し、その後の拡張で ISO/IEC 2022 に適合しなくなったものもいくつかあります。

符号化文字

[3] ISO/IEC 2022 の世界で扱う (指示する) ことのできる符号化文字集合は、その大きさと割当てる図形文字の種類で 6種類に分けられます。

[68] ISO/IEC 2022 でこれらの符号化文字集合に属する文字を使う場合、 まず当該符号化文字集合C0, C1, G0, G1, G2, G3 のいずれかに指示した上で、 GL, GR呼び出し(C0, C1, ESC F は常に呼び出された状態)文字符号を記述するという3段構成になります。

[69] 指示呼び出しISO/IEC 2022 のコアとなる概念ですが、 よく誤解される点でもあります。

[2] この他に ISO/IEC 2022 の世界で扱うことのできる符号化文字としては単独制御機能があります。

[28] DOCS を使うと ISO/IEC 2022 の外の世界の符号化文字を間接的に扱うことができます。

[19] 単一のビット組合せで表現可能な制御文字と、 エスケープシーケンスで表現可能なものを合わせて制御機能といいます.

[45] 文字集合に含まれるビット組合せエスケープシーケンスビット組合せの中には、 文字が割り当てられていないいわゆる空き領域ビット組合せもあります。

[47] DRCS のように事前に意味が定まっていない文字集合もあります。

プロファイル

[18] ISO/IEC 2022情報交換の当事者間の合意によって決定されるべきオプションを大量に含む (むしろ規定のほとんどがそうなのではないかと思われる) 「曖昧」な仕様でした。 完全な実装が存在したのか不明で、存在し得るのかも不明です。

[17] 元々完全実装を想定したものではなくて、 環境によって必要なだけ部分実装して使われるもので、実際に ISO/IEC 2022 の仕組みの一部を取り出した符号化方式がいろいろある。

[88] ISO/IEC 2022 を用いた符号

[29] RFC 1502 - X.400 Use of Extended Character Sets, , https://tools.ietf.org/html/rfc1502#section-3.3

エラー処理

[61] ISO/IEC 2022 が作られた時代の情報交換情報処理規格にはよくあることですが、 エラー処理はほとんど規定されていません。 すなわち、 適合する符号化文字データ要素適合する装置受信したときにどう動作するべきかは規定されているものの、 そうでない符号化文字データ要素受信したときどう動作するべきかは定かでないのです。

[62] 規格とはそうあるべきという当時の考え方なのでしょうが (未だにそういう考え方をする人や業界もあるようです)、 現実問題として規格適合しないデータはよく流通していて相互運用性に支障をきたしていますし、 ときにはセキュリティーの問題を引き起こすリスクすらあります。

[63] 故に実装 (受信する装置) は既存の実装の挙動や既存のデータを調査しつつ、 セキュリティーにも配慮して当たり障りのない実装方法を探る必要があるのです。

[71] ctext は要件に沿わない場合に文字列全体を非妥当と扱うべきだと規定しています。 ctext 実装がそれに従っているのかは謎です。 (長い文字列の最後の方が壊れている場合に一々検査しているのかなど。)

[122] Encoding Standardiso-2022-jpeuc-jp などの元来 ISO/IEC 2022 だった文字符号化復号の処理を厳密に規定していますが、 その結果本来の ISO/IEC 2022 に基づく実装の (正常な符号化文字データ要素列の) 処理から逸脱している部分があります。

エスケープシーケンス, 中間バイト, CMD, 空集合, PCD, 告知 (ISO/IEC 2022), IRR, 単独シフト, 制御文字, T.101

ASN.1

[80] ISO/IEC 2022 附属書A (規定) は ASN.1 における ISO/IEC 2022 の利用方法を規定しています。

[81] さすがは ISO ですね。規格制定時に ASN.1 を使う義務とかあるんでしょうか?

[82] character abstract syntaxオブジェクト識別子では、 ISO-IR の登録番号を何個か列挙することで、 符号化文字集合を指定できます。 改訂番号を添えることもできます。 character abstract syntax, ISO-IR, IRR

[86] なぜか文字集合本体は登録番号、改訂は登録番号でなく改訂番号が使われます。 文字集合本体として改訂の登録番号を指定してもいいのでしょうか?

[83] character transfer syntaxオブジェクト識別子では、

character transfer syntax, ISO-IR

[85] こちらでは改訂番号を書けないようです。 改訂の登録番号を指定してもいいのでしょうか?

[84] ISO/IEC 2022 character transfer syntax では、 ACS, CMD, DOCS を使ってはなりません。 また、 水準 4, 4C 以外では 指示および IRR が使えません。 A.3.2

[110] 登録番号は枝番が使えなそう?

改訂によるおもな変更点

[102] IPSJ-MGN140110.pdf, https://ipsj.ixsq.nii.ac.jp/ej/index.php?action=pages_view_main&active_action=repository_action_common_download&item_id=8100&item_no=1&attribute_id=1&file_no=1&page_id=13&block_id=8

ISO 2022‐1973 (JIS C 6228‐1975)

  • [6] 最初の版

ISO 2022‐1982 (JIS C 6228‐1984 → JIS X 0202‐1984)

ISO 2022-1986 (JIS X 0202‐1991)

  • [10] G4MDZ が ESC 02/04 F から ESC 02/04 02/08 F に変更
  • [9] 96集合が導入される
  • [11] ESC 2/4 2/12 Fが削除される

ISO/IEC 2022:1994 (JIS X 0202:1998)

  • 規格本文が全面的に書き直された。 (C.1)
  • 符号識別機能名前と略号が与えられた。 (C.2)
  • 一意な符号化のための仕様が追加された。 (C.4)
  • 単独シフトの後のビット組合せ (単独シフト領域のビット組合せ) が GL でも GR でもいいことが明記された。 (C.5)
  • ISO/IEC4873 を基にした実装水準が規定された。 (C.6)
  • ASN.1 構文による表現が規定された。 (C.8)

(JIS X 0202:1998 附属書C)

標準化団体

[16] 標準化ISO/IEC JTC1/SC2/WG3 が担当していました。

対応国内規格

[49] 他の工業標準と同じように各国の標準化団体標準規格にもなっています。

[48] オリジナルの ISO/IEC 版は高価ですが、同等のものが FIPSECMAWebサイトで無償で閲覧できます。

[37] FIPS 版 (米国):

[14] ECMA 版は ECMA 35

[13] JIS 版 (日本) は JIS X 0202 (旧 JIS C 6228)。 IDT

JIS ISO/IECJIS 規格名称 JIS 発行
JIS C 6228-1975ISO 2022:(初版)情報交換用符号の拡張法1975-03
JIS C 6228-1984 (JIS X 0202-1984)情報交換用符号の拡張法1984-11
JIS X 0202-1991ISO 2022:1986情報交換用符号の拡張法
JIS X 0202:1998ISO/IEC 2022:1994情報技術—文字符号の構造及び拡張法

[5] CNS 版 (中華民国) は

[27] GB 版 (中華人民共和国) は GB 2311

[100] KS X 1004:2007

文脈

[31] SGML SGMLにおける文字コード

[32] DICOM >>33

[87] ISO/IEC 2022 以外の文字コード体系でもエスケープシーケンスが使われることがあります。 ISO/IEC 2022エスケープシーケンス

[101] KS X 2502:2003 (CGM): p.63 あたりから

[117] >>119, >>116 ISO 2022 を使える (どの程度? ESC, SI, SO とは書いてある) が、複雑なので EBNF 構文では省略している、と書かれています。

[123] Web でもいろいろな ISO/IEC 2022プロファイルが使われてきました。 しかし現在のWebブラウザーはそのうちのごく一部にしか対応していません。 Webにおける文字コード, ISO-2022-JP

処理

[97] ISO/IEC 2022エスケープシーケンス, 固定シフト, 単独シフト, 制御機能などを参照。

[96] ISO/IEC 2022 decoder

実装

[104] ISO/IEC 2022 の一部分の実装はたくさんあります。各項参照。

[105] 完全または大部分の機能の実装がどれだけあったのかは不明。


[108] 関連記事: DOCS, IRR, DECSPPCS, CCCII, Fp, コードページ, CSI )p

関連

[89] Teletext の符号構造は ISO/IEC 2022 に似ていますが、 エスケープシーケンスのかわりに独自のプロトコルを使っています。

メモ

[70] ISO/IEC 2022 ‐ 通信用語の基礎知識, https://www.wdic.org/w/WDIC/ISO/IEC%202022

[15] UTS #22: CharMapML () http://www.unicode.org/reports/tr22/tr22-8.html#ISO_2022

[30] ISO/IEC 2022!!!!

[34] JIS X 0202 記念日(?)をスルーしちゃった笑

[103] GB 18030-2022実質 ISO 2022 だな(錯乱)

[120] https://ipsj.ixsq.nii.ac.jp/ej/?action=repository_action_common_download&item_id=6544&item_no=1&attribute_id=1&file_no=1

[121] あー ISO 2022 の時代が終わるんじゃーーー

[124] もねさん@まったいら / C102 日曜西え11abさんはTwitterを使っています: 「プログラムコード内にベタ書きされている西暦年「2022」を一括で「2023」に置き換えようとするときには、「ISO-2022-JP」を誤って置換しないように注意しなければなりません。」 / Twitter, , https://twitter.com/Moneto_Tk/status/1682654280258404352