[12] [DFN[[[ISO/IEC 2022]]]] [CITE[[RUBYB[[DFN[Character Code Structure and Extension Techniques]]][[DFN[文字符号の構造及び拡張法]]]]]] (旧: [CITE[[RUBYB[[DFN[Code Extension Techniques]]][[DFN[情報交換用符号の拡張法]]]]]]) は、 [DFN[符号拡張法]]、 すなわち [[ISO/IEC 646]] で表現できない様々な[[符号化文字]]を使う手法を規定する [[ISO/IEC]] の[[国際標準]]でした。 * 仕様書 [REFS[ - [13] [DFN[[[ISO 2022]]:1986]] [DFN[[CITE[Information ProcessingーISO 7‐bit and 8‐bit coded character sets―Code extension techniques]]]] - [43] [DFN[ISO/IEC 2022:1994]] ]REFS] [4] 最終改訂は[TIME[西暦1994年][1994]]。改訂を経るごとに複雑になってきている。 [44] 未だ現行[[規格]]ですが、 [[Unicode]] ([[ISO/IEC]] 的には [[ISO/IEC 10646]]) の普及によって[[実効性喪失]]しつつあります。 * 符号構造 [64] [[ISO/IEC 2022]] は[[7ビット符号]]または[[8ビット符号]]を想定しています。 つまり [[ISO/IEC 2022]] の[[符号化文字データ要素]]の列とは、 [[7ビット]]または[[8ビット]]を1つの[[単位]]とする[[ビット組合せ]]の連続です。 1つの[[文字]]や[[制御機能]]が、 1つ[[以上]]の[[ビット組合せ]]の列として表現されます。 ;; [65] [[現代]]においては、実際問題として、 すべて[[8ビット]]の[[バイト]]の[[列][バイト列]]として表現されます。 [[7ビット符号]]は[[最上位ビット]]が [N[0]] の[[8ビット]]の[[バイト]]の[[列][バイト列]]として扱われます。 [FIG(short list)[ [46] [[ISO/IEC 2022]] の[[符号]]の構造 - [[固定符号化文字]] - [[CL]] - [[GL]] - [[CR]] - [[GR]] - [[エスケープシーケンス][ISO/IEC 2022 escape sequence]] - [[制御シーケンス]] - [[制御ストリング]] ]FIG] [67] [[ISO文字コード]]の世界では[[7ビット]]で表現可能な [ [[0/0]], [[7/15]] ] [WEAK[(= [ [N[0x00]], [N[0x7F]] ])]] を[RUBYB[[[左][左半面]]][left]]、 [[8ビット]]の増加部分 [ [[8/0]], [[15/15]] ] [WEAK[(= [ [N[0x80]], [N[0xFF]] ])]] を[RUBYB[[[右][右半面]]][right]]と呼んでいます。 左右それぞれが[[制御文字]]用の領域 [[CL]] [WEAK[([ [[0/0]], [[1/15]] ] = [ [N[0x00]], [N[0x1F]] ])]], [[CR]] [WEAK[([ [[2/0]], [[7/15]] ] = [ [N[0x20]], [N[0x7F]] ])]] と[[図形文字]]用の領域 [[GL]] [WEAK[([ [[8/0]], [[9/15]] ] = [ [N[0x80]], [N[0x9F]] ])]], [[GR]] [WEAK[([ [[10/0]], [[15/15]] ] = [ [N[0xA0]], [N[0xFF]] ])]] に分けられています。 [28] [CODE(charname)[[[DOCS]]]] を使うと [[ISO/IEC 2022]] の符号の構造の原則から外れる体系に移行できます。 移行先によっては [[ISO/IEC 2022]] に復帰できます。 [66] [[ISO/IEC 10646]] は、 [[ISO/IEC 10646]] の[[規定]]する[[符号化文字データ要素]]の列として [[ISO/IEC 2022]] の[[エスケープシーケンス]] (の一部) を利用する方法を定めています。 その場合には、 [[ISO/IEC 10646]] の[[2オクテット][UCS-2]]や[[4オクテット][UCS-4]]の列や、 [[UTF-8]] の[[8ビット]]の[[バイト列]]のような形で [[ISO/IEC 2022]] の[[エスケープシーケンス]]が記述されます。 [SEE[ [[ISO/IEC 10646におけるエスケープシーケンス]] ]] ** ISO/IEC 2022 符号構造からの派生 [72] [[ISO/IEC 2022]] 系統の[[文字コード]]のように見えて微妙に違うものや、 [[ISO/IEC 2022]] 系統の[[文字コード]]として出発し、その後の拡張で [[ISO/IEC 2022]] に適合しなくなったものもいくつかあります。 - [73] [[GB 8045]] は [CODE(charname)@en[SP]] のかわりに [CODE(charname)@en[MSP]] を割り当てています。 - [109] [[NATS]] は[[94集合]]で [N[2/0]] の[[空白]]の意味も定めています。 [SEE[ [[空白文字]] ]] - [99] [[ISIRI 2900]], [[ISIRI 3342]] は[[右側]]に諸々を[[呼び出し]]ます。 - [98] [[ISO/IEC 8859]] や [[GB 12050-89]] [[8ビット符号]]には [CODE[DEL]] がありません。 [SEE[ [[DELETE]] ]] - [95] [[Mule]] は[[96集合]]を [[G0]] に[[指示]]できます。 - [93] [[CEA-708]] は [[GL]] = [[G0]] に[[96集合]]を使っています。 - [94] [[CEA-708]] は [[C2]], [[C3]] を追加しています。 - [113] [[CR]] に [[C0]] を[[呼び出し]]できる実装があります。 [SEE[ [[符号構造機能の告知]] ]] - [90] [[Videotex]] には C、G の他に L-set があります。 - [74] [[DECの文字コード]]のいくつかや [[EUC-HJ]] や [[JAPAN/MARC]] は [[GR]] + [[GL]] の2バイトコードを使っています。 -- [111] [[固定長EUC]]や [[DIS 10646]] や [[TRONコード]]はこの方向に更に展開したものといえます。 - [75] [[DEC Hanyu]] は [[GR]] + [[GR]] + [[GR]] + ([[GL]] / [[GR]]) の4バイトコードを使っています。 - [77] [[GBK]], [[UHC]] は [[GR]] を逸脱した2バイトコードを使っています。 -- [78] [[GB 18030]] は更に4バイトに拡張しています。 - [79] [[日本語EUC]]の拡張の1種で[[シフトJIS]]風3バイトコードが一部使えるものがありました。 - [92] [[ISO-2022-JP]] の拡張で [[ISO 2022]] から逸脱したものがありました。 [SEE[ [[ISO-2022-JP]] ]] - [91] [[Videotex]] には [[ISO 2022]] から逸脱した[[指示シーケンス]]があります。 - [76] [[VT][VT100]] の[[エスケープシーケンス]]のいくつかは [[ISO/IEC 2022]] の構造から逸脱しています。 [SEE[ [[VT][VT100]], [[SGR]] ]] - [125] [[[CODE(charname)@en[ESC]] [CODE[eKanji]]]] - [114] [[ISO/IEC 2022]] 以外の方法の[[指示]]や[[呼び出し]]ができることがあります。 [SEE[ [[DOCS]], [[SGR]], [[DECSPPCS]], [[DECPCTERM]], [[VT][VT100]] ]] - [112] [[符号構造機能の告知]]の副作用 - [CITE[Encoding Standard]] [SEE[ >>122 ]] * 符号化文字 [3] ISO/IEC 2022 の世界で扱う (指示する) ことのできる符号化文字集合は、その大きさと割当てる図形文字の種類で 6種類に分けられます。 [FIG(list middle)[ -[[制御文字集合]] --[[C0文字集合]] --[[C1文字集合]] -[[図形文字集合]] --[[94文字集合]] --[[96文字集合]] --[[94[SUP[[VAR[n]]]]文字集合]] --[[96[SUP[[VAR[n]]]]文字集合]] ]FIG] [68] [[ISO/IEC 2022]] でこれらの[[符号化文字集合]]に属する[[文字]]を使う場合、 まず当該[[符号化文字集合]]を [[C0]], [[C1]], [[G0]], [[G1]], [[G2]], [[G3]] のいずれかに[[指示]]した上で、 [[GL]], [[GR]] に[[呼び出し]]し [WEAK[([[C0]], [[C1]], [CODE(charname)@en[ESC]] [VAR[F]] は常に[[呼び出さ][呼び出し]]れた状態)]]、 [[文字]]の[[符号]]を記述するという3段構成になります。 ;; [69] [[指示]]と[[呼び出し]]は [[ISO/IEC 2022]] のコアとなる概念ですが、 よく誤解される点でもあります。 [2] この他に ISO/IEC 2022 の世界で扱うことのできる符号化文字としては[[単独制御機能]]があります。 [28] [CODE(charname)[[[DOCS]]]] を使うと ISO/IEC 2022 の外の世界の符号化文字を間接的に扱うことができます。 [19] 単一の[[ビット組合せ]]で表現可能な[[制御文字]]と、 [[エスケープシーケンス]]で表現可能なものを合わせて[[制御機能]]といいます. [45] [[文字集合]]に含まれる[[ビット組合せ]]や[[エスケープシーケンス]]の[[ビット組合せ]]の中には、 [[文字]]が割り当てられていないいわゆる[[空き領域]]の[[ビット組合せ]]もあります。 [47] [[DRCS]] のように事前に意味が定まっていない[[文字集合]]もあります。 * プロファイル [18] [[ISO/IEC 2022]] は[[情報交換の当事者間の合意]]によって決定されるべきオプションを大量に含む (むしろ規定のほとんどがそうなのではないかと思われる) 「曖昧」な仕様でした。 完全な実装が存在したのか不明で、存在し得るのかも不明です。 [17] 元々完全実装を想定したものではなくて、 環境によって[[必要なだけ部分実装][プロファイル]]して使われるもので、実際に ISO/IEC 2022 の仕組みの一部を取り出した[[符号化方式]]がいろいろある。 [FIG(short list)[ [88] [[ISO/IEC 2022]] を用いた[[符号]] - [[ISO/IEC 2022 character abstract syntax]] - [[ISO/IEC 2022 character transfer syntax]] - [[ISO/IEC 646]] - [[ISO/IEC 8859]] 系列 - [[EUC]] ([[拡張 Un*x 符号]]) 各種 - [[JIS X 0201]] の各符号 - [[JIS X 0208:1997]] 本体の各符号 - [[JIS X 0213]] 本体の各符号 - [[ISO/IEC 2022エスケープシーケンスを用いた符号]] - [[iso-2022-7bit]] - [[junetコード]]と [[ISO-2022-JP]] の系譜 - [[ISO-2022-CN]] と [[ISO-2022-CN-EXT]] - [[ISO-2022-KR]] - [[Compound Text]] - [[ISO/IEC 4873]] - [[VT][VT100]] 系統の実装 - [[DECの文字コード]]のうちいくつか - [[T51String]] - [[GB 8565]] - [[KS X 1001]] 附属書4 - [[KS X 1003]] - [[OCR][OCR書体]]用符号各種 - [[I.S. 434]] ]FIG] [29] [CITE@en[RFC 1502 - X.400 Use of Extended Character Sets]], [TIME[2021-01-24T15:50:13.000Z]], [TIME[2021-03-22T09:31:08.531Z]] * エラー処理 [61] [[ISO/IEC 2022]] が作られた時代の[[情報交換]]や[[情報処理]]の[[規格]]にはよくあることですが、 [[エラー処理]]はほとんど規定されていません。 すなわち、 [[適合]]する[[符号化文字データ要素]]を[[適合]]する[[装置]]が[[受信]]したときにどう動作するべきかは[[規定]]されているものの、 そうでない[[符号化文字データ要素]]を[[受信]]したときどう動作するべきかは定かでないのです。 [62] [[規格]]とはそうあるべきという当時の考え方なのでしょうが (未だにそういう考え方をする人や業界もあるようです)、 現実問題として[[規格]]に[[適合]]しないデータはよく流通していて[[相互運用性]]に支障をきたしていますし、 ときには[[セキュリティー][文字のセキュリティー]]の問題を引き起こすリスクすらあります。 [63] 故に実装 ([[受信]]する[[装置]]) は既存の実装の挙動や既存のデータを調査しつつ、 [[セキュリティー][文字のセキュリティー]]にも配慮して当たり障りのない実装方法を探る必要があるのです。 [71] [[ctext]] は要件に沿わない場合に[[文字列]]全体を非妥当と扱うべきだと規定しています。 [SEE[ [[ctext]] ]] 実装がそれに従っているのかは謎です。 (長い文字列の最後の方が壊れている場合に一々検査しているのかなど。) [122] [CITE[Encoding Standard]] は [[iso-2022-jp]] や [[euc-jp]] などの元来 [[ISO/IEC 2022]] だった[[文字符号化]]の[[復号]]の処理を厳密に規定していますが、 その結果本来の [[ISO/IEC 2022]] に基づく実装の (正常な[[符号化文字データ要素]]列の) 処理から逸脱している部分があります。 [SEE[ [[エスケープシーケンス]], [[中間バイト]], [[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] [DFN[character abstract syntax][ISO/IEC 2022 character abstract syntax]] の[[オブジェクト識別子]]では、 [[ISO-IR]] の登録番号を何個か列挙することで、 [[符号化文字集合]]を指定できます。 改訂番号を添えることもできます。 [SEE[ [[character abstract syntax]], [[ISO-IR]], [[IRR]] ]] ;; [86] なぜか[[文字集合]]本体は登録番号、改訂は登録番号でなく改訂番号が使われます。 [[文字集合]]本体として改訂の登録番号を指定してもいいのでしょうか? [83] [DFN[character transfer syntax][ISO/IEC 2022 character transfer syntax]] の[[オブジェクト識別子]]では、 - [[7ビット符号]] 実装水準 1 - 4, [[8ビット符号]] 実装水準 1 - 4, 1C - 4C, 2A - 4A, 2AC - 4AC のいずれか - [[GL]] が [[G0]] (既定値), [[G1]], [[G2]], [[G3]] のいずれか - [[GR]] が [[G1]] (既定値), [[G2]], [[G3]] のいずれか - [[C0]], [[C1]], [[G0]], [[G1]], [[G2]], [[G3]] が [[ISO-IR]] 登録番号いずれか [SEE[ [[character transfer syntax]], [[ISO-IR]] ]] ;; [85] こちらでは改訂番号を書けないようです。 改訂の登録番号を指定してもいいのでしょうか? [84] [[ISO/IEC 2022 character transfer syntax]] では、 [CODE(charname)@en[ACS]], [CODE(charname)@en[CMD]], [CODE(charname)@en[DOCS]] を使ってはなりません。 また、 水準 4, 4C 以外では [[指示]]および [CODE(charname)@en[IRR]] が使えません。 [SRC[A.3.2]] [110] 登録番号は枝番が使えなそう? *改訂によるおもな変更点 [102] [CITE[IPSJ-MGN140110.pdf]], [TIME[2022-05-20T01:16:26.000Z]] **ISO 2022‐1973 (JIS C 6228‐1975) -[6] 最初の版 **ISO 2022‐1982 (JIS C 6228‐1984 → JIS X 0202‐1984) -[1] 複数バイト図形文字集合が [[GR]] に呼び出せるようになる -[7] [[G2]], [[G3]]が導入される -[8] [[単独シフト]]が導入される **ISO 2022-1986 (JIS X 0202‐1991) -[10] G4MDZ が ESC 02/04 F から ESC 02/04 02/08 F に変更 -[9] [[96集合]]が導入される -[11] [CODE(char)@en[[CODE(charname)[[[ESC]]]] 2/4 2/12 [VAR[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]] 版は高価ですが、同等のものが [[FIPS]] や [[ECMA]] の[[Webサイト]]で無償で閲覧できます。 [37] [[FIPS]] 版 ([[米国]]): - [35] [CITE[Federal Information Processing Standards Publication: code extension techniques for use with the 7-bit coded character set of American national standard code for information interchange - fipspub1-2-1974.pdf]], [TIME[2017-11-30T17:34:19.000Z]], [TIME[2022-03-23T03:45:49.202Z]] - [36] [CITE[Federal Information Processing Standards Publication: code extension techniques for use with the 7-bit coded character set of American national standard code for information interchange - fipspub35.pdf]], [TIME[2017-12-01T13:03:50.000Z]], [TIME[2022-03-23T03:48:37.397Z]] [14] [[ECMA]] 版は [[ECMA 35]]。 - [20] [CITE[Standard ECMA-35]], [TIME[2020-01-24T08:38:33.000Z]], [TIME[2020-10-07T08:06:01.504Z]] -- 移転確認 [TIME[2022-04-29T01:20:19.900Z]] -- [51] [CITE@en-US[ECMA-35 - Ecma International]], [TIME[2022-04-29T01:20:07.000Z]] -- [52] 第1版 [TIME[西暦1971年12月][1971-12]] --- [21] [CITE[ECMA-35, 1st Edition, December 1971.pdf]], [TIME[2014-10-28T05:27:37.000Z]], [TIME[2020-10-07T08:06:51.692Z]] ---- 移転確認 [TIME[2022-04-29T01:21:44.700Z]] --- [57] [CITE[ECMA-35_1st_edition_december_1971.pdf]], [TIME[2021-01-16T09:57:02.000Z]], [TIME[2022-04-29T01:21:51.253Z]] -- [53] 第2版 [TIME[西暦1980年1月][1980-01]] --- [22] [CITE[ECMA-35, 2nd Edition, January 1980.pdf]], [TIME[2014-10-28T05:28:01.000Z]], [TIME[2020-10-07T08:07:03.514Z]] ---- 移転確認 [TIME[2022-04-29T01:22:30.300Z]] --- [58] [CITE[ECMA-35_2nd_edition_january_1980.pdf]], [TIME[2021-01-16T09:57:02.000Z]], [TIME[2022-04-29T01:22:00.179Z]] -- [54] 第3版 [TIME[西暦1982年1月][1982-01]] --- [23] [CITE[ECMA-35, 3rd Edition, January 1982.pdf]], [TIME[2014-10-28T05:28:31.000Z]], [TIME[2020-10-07T08:07:13.275Z]] ---- 移転確認 [TIME[2022-04-29T01:23:05.600Z]] --- [59] [CITE[ECMA-35_3rd_edition_january_1982.pdf]], [TIME[2021-01-16T09:57:02.000Z]], [TIME[2022-04-29T01:22:21.576Z]] -- [55] 第4版 [TIME[西暦1985年3月][1985-03]] --- [24] [CITE[ECMA-35, 4th Edition, March 1985.pdf]], [TIME[2014-10-28T05:29:09.000Z]], [TIME[2020-10-07T08:07:28.676Z]] ---- 移転確認 [TIME[2022-04-29T01:23:42.600Z]] --- [60] [CITE[ECMA-35_4th_edition_march_1985.pdf]], [TIME[2021-01-16T09:57:03.000Z]], [TIME[2022-04-29T01:23:27.325Z]] -- [25] 第5版 なし -- [56] 第6版 [TIME[西暦1994年12月][1994-12]] --- [26] [CITE[Ecma-035.pdf]], [TIME[2014-10-28T04:43:07.000Z]], [TIME[2020-10-07T08:06:35.169Z]] ---- 移転確認 [TIME[2022-04-29T01:19:43.400Z]] --- [50] [CITE[ECMA-35_6th_edition_december_1994.pdf]], [TIME[2021-01-16T09:57:02.000Z]], [TIME[2022-04-29T01:19:03.500Z]] [13] [[JIS]] 版 ([[日本]]) は [[JIS X 0202]] (旧 [[JIS C 6228]])。 [[IDT]]。 [FIG(list)[ ,*[[JIS]] ,* [[ISO/IEC]] ,*[[JIS]] 規格名称 ,* [[JIS]] 発行 ,JIS C 6228-1975 ,ISO 2022:(初版) ,情報交換用符号の拡張法 ,1975-03 ,JIS C 6228-1984 (JIS X 0202-1984) , ,情報交換用符号の拡張法 ,1984-11 ,JIS X 0202-1991 ,ISO 2022:1986 ,情報交換用符号の拡張法 ,JIS X 0202:1998 ,ISO/IEC 2022:1994 ,情報技術—文字符号の構造及び拡張法 ]FIG] [5] [[CNS]] 版 ([[中華民国]]) は - [38] [[CNS 7654]] (C 5123, X 5006) ‐1989 [CITE[資訊處理 —— 七位元及八位元碼字元集 —— 延碼技術]] [TIME[1989年 (中華民国 78 年) 7月15日][1989-07-15]]制定。 - [39] [[CNS 7654]] (X 5006) [CITE[資訊技術 —— 字元碼結構及延伸技術]] ([CITE[Information technology —— Character code structure and extension techniques]]) [TIME[1998年 (中華民国 86 年) 11月29日][1998-11-29]]改訂。 [27] [[GB]] 版 ([[中華人民共和国]]) は [DFN[GB 2311]] - [40] [DFN[GB 2311‐80]] は[TIME[1980-03-29]]に[[発布]]されました。 - [41] [DFN[GB 2311‐90]] [CITE[信息処理 七位和八位編碼字符集 代碼拡充技朮]] は、 [[ISO 2022:1986]] に対応しています ([[IDT]])。 - [42] [DFN[GB/T 2311‐2000]] [CITE[信息技朮 字符代碼結[木匂]与拡充技朮]] ([CITE[Information technology--Character code structure and extension techniques]]) は [[ISO/IEC 2022]]:1994 に[[対応]]しています ([[IDT]])。 [TIME[2000-07-14]]に修訂、 [TIME[2001-03-01]]に[[実施]]されています。 [100] [DFN[KS X 1004:2007]]。 * 文脈 [31] [[SGML]] [SEE[ [[SGMLにおける文字コード]] ]] [32] [[DICOM]] [SRC[>>33]] [87] [[ISO/IEC 2022]] 以外の[[文字コード]]体系でも[[エスケープシーケンス]]が使われることがあります。 [SEE[ [[ISO/IEC 2022エスケープシーケンス]] ]] [101] [[KS X 2502:2003]] ([[CGM]]): p.63 あたりから [REFS[ - [33] [CITE[19_87.pdf]], [TIME[2021-10-12T08:53:33.000Z]] ]REFS] - [118] [CITE[null]], [[Jonathan Dale]], [TIME[2022-12-13T08:34:22.000Z]] -- [119] [CITE@EN-US[FIPA Agent Message Transport Specification]], [TIME[2022-12-13T08:35:04.000Z]] - [115] [CITE[null]], [[Jonathan Dale]], [TIME[2022-12-13T08:13:03.000Z]] -- [116] [CITE@EN-US[FIPA ACL Message Representation in String Specification]], [TIME[2022-12-13T08:14:59.000Z]] [117] >>119, >>116 [[ISO 2022]] を使える (どの程度? [CODE(charname)@en[ESC]], [CODE(charname)@en[SI]], [CODE(charname)@en[SO]] とは書いてある) が、複雑なので [[EBNF]] 構文では省略している、と書かれています。 [123] [[Web]] でもいろいろな [[ISO/IEC 2022]] の[[プロファイル]]が使われてきました。 しかし現在の[[Webブラウザー]]はそのうちのごく一部にしか対応していません。 [SEE[ [[Webにおける文字コード]], [[ISO-2022-JP]] ]] * 処理 [97] [[ISO/IEC 2022エスケープシーケンス]], [[固定シフト]], [[単独シフト]], [[制御機能]]などを参照。 [96] [[ISO/IEC 2022 decoder]] * 実装 [104] [[ISO/IEC 2022]] の一部分の実装はたくさんあります。各項参照。 [105] 完全または大部分の機能の実装がどれだけあったのかは不明。 -*-*- -[106] [CITE@en[GitHub - harjitmoe/[DFN[ecma35lib]]: Aspiring to implement ECMA-35, in its fullness, for a Unicode era. This repo may occasionally lag behind the one on Gitlab.]], [TIME[2022-10-27T04:27:12.000Z]] -[107] [CITE@en[HarJIT / ecma35lib · [[GitLab]]]], [TIME[2022-10-27T04:28:09.000Z]] [108] 関連記事: [[DOCS]], [[IRR]], [[DECSPPCS]], [[CCCII]], [[Fp]], [[コードページ]], [[CSI )p]] -*-*- [126] [CITE@ja[[DFN[skf]] - simple kanji filter の使い方 - skf - simple kanji filter - OSDN]], [TIME[2024-07-05T14:45:08.000Z]] [127] 関連記事: [[Fp]], [[内部コード]], [[skf言語]] -*-*- -[128] [CITE[luit(1)]], [TIME[2024-01-03T08:50:00.000Z]], [TIME[2025-11-02T05:58:21.768Z]] * 関連 [89] [[Teletext]] の符号構造は [[ISO/IEC 2022]] に似ていますが、 [[エスケープシーケンス]]のかわりに独自の[[プロトコル]]を使っています。 * メモ [70] [CITE@ja-jp[ISO/IEC 2022 ‐ 通信用語の基礎知識]], [TIME[2022-04-30T06:39:45.000Z]] [15] [CITE@en-us[UTS #22: CharMapML]] ([TIME[2017-06-01 07:35:01 +09:00]]) [30] [TIME[西暦2022年][2022]]は [[ISO/IEC 2022]] の[[年]]!!!! [34] [TIME[2022-02-02]]の [[JIS X 0202]] 記念日(?)をスルーしちゃった笑 [103] [[GB 18030-2022]] が[[実質]] [[ISO 2022]] だな(錯乱) [120] [TIME[2022-12-14T13:30:53.900Z]] [121] あー ISO 2022 の時代が終わるんじゃーーー[TIME[2022-12-31T05:49:25.500Z]] [124] [CITE@ja[もねさん@まったいら / C102 日曜西え11abさんはTwitterを使っています: 「プログラムコード内にベタ書きされている西暦年「2022」を一括で「2023」に置き換えようとするときには、「ISO-2022-JP」を誤って置換しないように注意しなければなりません。」 / Twitter]], [TIME[午後4:30 · 2023年7月22日][2023-07-22T07:30:17.000Z]], [TIME[2023-07-23T02:57:49.000Z]]