ISO/IEC 2022

ISO 2022
言語様々な。
標準
分類ステートフルなエンコーディングシステム(ステートレスな事前設定されたサブセットを含む)
変換/エンコードUS-ASCIIおよび実装に応じて:
後継者ISO/IEC 10646 (ユニコード)
その他の関連エンコーディングステートフルサブセット:
事前構成バージョン:

ISO/IEC 2022 情報技術—文字コード構造及び拡張技術は、文字符号化分野におけるISO / IEC規格です。ECMA規格ECMA - 35 [1] [2] 、 ANSI規格ANSI X3.41 [3]、および日本工業規格JIS X 0202と同等です。1971年に制定され、1994年に改訂されました。[4]

ISO 2022は、文字エンコーディングが準拠できる一般的な構造を規定しており、特定のバイト範囲(0x00 ~1Fおよび0x7F~9F)を、グラフィカル文字ではなく、書式設定やインバンド命令(改行やテキスト端末の書式設定命令など)用の非印刷制御コード[5]専用にしています。また、 ESC制御コードで始まる複数バイトのシーケンスであるエスケープシーケンスの構文も規定しており、これも同様にインバンド命令に使用できます。[6] ISO 2022で使用するように設計された制御コードとエスケープシーケンスの特定のセットには、ISO/IEC 6429が含まれており、その一部はANSI.SYS端末エミュレータによって実装されています。

ISO 2022自体も、異なる符号化文字セット(例えば、ASCIIと日本語JIS X 0208 )間の切り替えに使用できる特定の制御コードとエスケープシーケンスを定義しており、単一の文書内で複数の文字セットを使用できるようにしています。[7]実質的には、それらを単一の状態のあるエンコーディングに組み合わせています(この機能はUnicodeの登場以降、それほど重要ではなくなりました)。これは、8ビット環境と7ビット環境( 8BITMIMEのない電子メールなど、1バイトで7ビットしか使用できない環境)の両方で使用できるように設計されています[8]

エンコーディングと適合性

ASCII 文字セットは、 ISO 基本ラテンアルファベット(英語のアルファベットに相当) をサポートしていますが、追加の文字を使用する言語や、まったく異なる表記体系を使用する言語については適切なサポートを提供していません。ギリシャ語キリル文字アラビア語ヘブライ語などの比較的文字数の少ない他の表記体系、およびISO 基本ラテンアルファベットにはない発音区別記号や文字を使用するラテン文字の形式は、歴史的に、最上位ビットが 0 の場合はASCIIに従い(つまり、16 進数で表現するとバイト 0x00–7F)、最上位ビットが 1 の場合は追加の文字 (つまり、バイト 0x80–FF) を含む、異なる8ビット、シングル バイト、拡張 ASCII エンコードでパーソナルコンピュータで表現されてきました。ISO 8859シリーズなど一部の規格はISO 2022に準拠していますが、[9] [10]、DOSコードページ437などは準拠していません。これは通常、制御コード用にバイト0x80~9Fを予約していないためです。

東アジア言語、特に中国語日本語韓国語(総称して「CJK」)は、1バイトで表現できる最大文字数256文字をはるかに超える文字数で表記され、コンピュータ上では当初、言語固有の2バイトエンコーディングまたは可変幅エンコーディングによって表現されていました。これらの言語の中には、簡体字中国語のGB 2312エンコーディングなどISO 2022に準拠しているものもあれば、繁体字中国語のBig5エンコーディングなど準拠していないものもあります。ISO 2022の制御コードは、グラフィカル文字に使用されるバイト数に関わらず、常に1バイトで表現されます。文字セットを切り替えるためにISO 2022メカニズムを使用する7ビット環境で使用されるCJKエンコーディングは、多くの場合「ISO-2022-」で始まる名前が付けられ、最も有名なのはISO-2022-JPですが、 EUC-JPなどの他のCJKエンコーディングもISO 2022メカニズムを使用しています。[11] [12]

Unicode最初の256個のコードポイントはISO 8859-1から取得されているため、UnicodeはISO 2022からC0およびC1制御コードの概念を継承していますが、 ISO 2022制御コードに加えて他の非印字文字も追加しています。ただし、 UTF-8などのUnicode変換形式は、一般的にISO 2022の構造から様々な点で逸脱しています。例えば、以下のような点が挙げられます。

  • 8ビットバイトを使用しますが、ISO 2022で規定されているシングルバイト形式のC1コードを表現していません(ほとんどのUTF、ただし廃止されたU​​TF-1は例外です)。
  • 制御コードを含むすべての文字を複数バイトで表現する(例:UTF-16UTF-32
  • 単一のコードポイント(例:UTF-1、 GB 18030のコード化表現内で、最上位ビットが設定されているバイトと設定されていないバイトを混在させる

しかし、ISO 2022エスケープシーケンスは、UTF-8を「ISO 2022とは異なるコーディングシステム」として切り替えるためのものであり、[13] xtermなどの特定の端末エミュレータでサポートされています[14]

概要

要素

ISO/IEC 2022 では、次のことが規定されています。

  • 複数のグラフィカル文字セットと、プライマリ(C0)とセカンダリ(C1)制御コードの複数のセットを含む、単一の文字符号化システムに含めることができる特定の構造を持つ複数の文字セットのインフラストラクチャ[15]
  • これらのセットをエンコードするためのフォーマットは、1バイトあたり8ビットが利用可能であると仮定し、[16]
  • 1バイトあたり7ビットしか利用できない場合に、これらのセットを同じ符号化システムで符号化するためのフォーマット[17]と、そのような7ビット環境を通過できるように任意の準拠文字データを変換する方法[8]
  • ANSIエスケープコード一般的な構造[6]および
  • 個々の文字セットを識別するための特定のエスケープコード形式[7] 、特定のエンコード機能またはサブセットの使用を通知するためのもの[18]、および他のエンコードシステムとの対話または切り替えのためのもの[18] 。

コードバージョン

特定の実装では、標準のすべてを実装する必要はありません。準拠レベルとサポートされる文字セットは、実装によって定義されます。 ISO/IEC 2022 標準で定義されているメカニズムの多くはあまり使用されませんが、いくつかの確立されたエンコーディングは、ISO/IEC 2022 システムのサブセットに基づいています。[19]特に、ISO/IEC 2022 メカニズムを使用する 7 ビット エンコーディング システムには、主に日本語の電子メールで使用されているISO-2022-JP (またはJIS エンコーディング) が含まれます。 ISO/IEC 2022 に準拠する 8 ビット エンコーディング システムには、 ISO/IEC 4873 (ECMA-43) があり、これはISO/IEC 8859によって準拠されています[9] [10]および東アジア言語で使用される拡張 Unix コード[11] ISO 2022 のより特殊なアプリケーションには、MARC 21ライブラリ レコードで使用されるMARC-8エンコーディング システムがあります[3]

指定エスケープシーケンス

特定の文字セットまたはエンコーディングに切り替えるためのエスケープシーケンスは、ISO-IRレジストリに登録されています(ベンダーまたはARIB STD-B24などのプロトコル仕様によって意味が定義されている、私的使用のために確保されているものを除く)。これらのエスケープシーケンスを使用する文字エンコーディングでは、データの正しい解釈は、以前に検出されたエスケープシーケンスに依存するため、データを順方向に順次処理する必要があります。

ISO-2022-JPなどの特定のプロファイルでは、行末の前に現在の文字セットをUS-ASCIIにリセットするなどの追加条件が課される場合があります。さらに、特定のISO-2022ベースのエンコーディングで許可または要求され、特定の国別文字セットの使用が指示されている場合、国別文字セットを宣言するエスケープシーケンスは省略されることがあります。例えば、ISO-8859-1では、定義用のエスケープシーケンスは不要と規定されています。

マルチバイト文字

大規模な文字セットを表現するために、ISO/IEC 2022 は、7ビットの文字表現では通常 94 個のグラフィック (印刷可能) 文字 (加えてスペースと 33 個の制御文字) を表現できるという ISO/IEC 646 の特性を基盤としている。C0 制御コード (狭義) のみを除外すれば、これは 96 文字まで拡張できる。したがって、2 バイトを使用すると最大 8,836 個 (94×94) の文字を表現でき、3 バイトを使用すると最大 830,584 個 (94×94×94) の文字を表現できる。標準規格では 3 バイトが定義されているが、登録されている文字セットで 3 バイトを使用するものはない (ただし、EUC-TWの未登録の G2 や、同様に未登録のCCCII は3 バイトを使用する)。

2バイト文字セットの場合、各文字のコードポイントは通常、行セルまたは区点[a]と呼ばれる形式で指定されます。これは1から94までの2つの数値で構成され、ゾーン内のその文字の行[b]とセル[c]を指定します。3バイトセットの場合は、先頭に追加のプレーン[d]番号が含まれます。 [20]エスケープシーケンスは、使用されている文字セットを宣言するだけでなく、セットがシングルバイトかマルチバイトか(マルチバイトの場合、使用するバイト数は指定しません)、および各バイトに94または96の許容値があるかどうかも宣言します。

コード構造

表記法と命名法

ISO/IEC 2022コーディングは、文字コードと表示文字との間の二層マッピングを規定しています。エスケープシーケンスは、膨大なグラフィック文字セットのレジストリのいずれかを、G0からG3までと名付けられた4つのワーキングセットのいずれかに「指定」[21]することを可能にし、より短い制御シーケンスは、ストリーム内のバイトを解釈するために「呼び出される」ワーキングセットを指定します[22] 。

エンコードされたバイト値(「ビットの組み合わせ」)は、多くの場合、列行表記法で表されます。列行表記法では、00~15の範囲の2つの10進数(それぞれ1つの16進数字に対応)がスラッシュで区切られます。[23]したがって、例えば、2/0(0x20)から2/15(0x2F)までのコードは「列02」と呼ばれることがあります。これは、ISO/IEC 2022 / ECMA-35規格自体で使用されている表記法です。[24]これらは、この記事でよく使用される16進数表記法、または対応するASCII文字を使用して記述される場合があります。 [25]ただし、エスケープシーケンスは実際にはバイト値で定義され、そのバイト値に割り当てられたグラフィックは、制御シーケンスに影響を与えずに変更できます。

文字コード表の左側にある7ビットASCIIグラフィック範囲(16進数0x20~0x7F)のバイト値は「GL」コード(「GL」は「グラフィックス左」の略)と呼ばれ、一方、「高ASCII」範囲(0xA0~0xFF)のバイトは、利用可能な場合(つまり8ビット環境の場合)は「GR」コード(「グラフィックス右」の略)と呼ばれます[5]制御範囲には「CL」(0x00~0x1F)と「CR」(0x80~0x9F)という用語が定義されていますが、CL範囲は常にプライマリ(C0)制御を呼び出しますが、CR範囲は常にセカンダリ(C1)制御を呼び出すか、使用されません。[5]

固定コード化文字

削除文字DEL(0x7F)、エスケープ文字ESC(0x1B)、およびスペース文字SP(0x20)は「固定」符号化文字として指定されており[26]、GL上でG0が呼び出された場合は、指定された文字セットに関係なく常に利用可能です。これらの文字はグラフィカル文字セットには含まれない場合があります。ただし、他のサイズや種類の空白文字は含まれる場合があります。[27]

エスケープシーケンスの一般的な構文

ESC(エスケープ)文字を使用したシーケンスは形式をとり、ESC文字の後に0x20~0x2Fの範囲の0個以上の中間バイト[28]I )と、0x30~0x7Eの範囲の1つの最終バイト[29]F)が続きます。[30]ESC [I...] F

最初のIバイトの有無によってエスケープシーケンスの種類が決まります。例えば、ワーキングセットを指定したり、単一の制御関数を表したりします。すべてのエスケープシーケンスにおいて、 0x30~0x3Fの範囲のFバイトは、当事者間の事前の合意によって定義された、登録されていない私的使用のために予約されています。[31]

一部の制御関数セットでは、エスケープシーケンス本体に続くバイトをさらに使用する場合があります。例えば、エスケープシーケンスを用いて表現できるISO 6429制御関数「制御シーケンスイントロデューサ」は、0x30~0x3Fの範囲の0個以上のバイト、0x20~0x2Fの範囲の0個以上のバイト、そして0x40~0x7Eの範囲の1バイトが続き、このシーケンス全体を「制御シーケンス」と呼びます。[32]

グラフィカル文字セット

4つのワーキングセットG0からG3はそれぞれ、94文字セットまたは94 n文字のマルチバイトセットです。また、G1からG3は96文字セットまたは96 n文字セットです

96文字セットまたは96n文字セットでは、GL呼び出し時には0x20から0x7Fまでのバイト、GR呼び出し時には0xA0から0xFFまでのバイトが割り当てられ、セットで使用できます。94文字セットまたは94n文字セットでは、0x20と0x7Fのバイトは使用されません。[33] 96文字セットまたは96n文字セットがGL領域で呼び出されると、スペース文字と削除文字(コード0x20と0x7F)は、94文字セットまたは94n文字セット(G0セットなど)がGLで呼び出されるまで使用できません。 [5] 96文字セットをG0に指定することはできません。

96文字セットとして登録されているからといって、0x20/A0バイトと0x7F/FFバイトが実際にそのセットに割り当てられているとは限りません。96セットとして登録されているが、これらのバイトを使用しないグラフィカル文字セットの例としては、IS 434のG1セット、[34] 、 ISO/IEC 10367のボックス描画セット[35] 、ISO-IR-164( CCITTで使用されるISO-8859-8のG1セットの文字のみのサブセット)などがあります。[36]

文字の組み合わせ

文字は、グラフィカルセットによって別途指定されていない限り、結合文字ではなく、スペーシング文字であることが期待されます。[37] ISO 2022 / ECMA-35では、バックスペースとキャリッジリターンの制御文字を、スペーシング文字を結合する手段として使用することも認識しています。また、CSIシーケンス「グラフィック文字結合」(GCC)[37]CSI 0x20 (SP) 0x5F (_))。[38]

このようなバックスペースとキャリッジリターンの使用はISO/IEC 646では許可されているが、ISO/IEC 4873 /ECMA-43 [39]およびISO/IEC 8859 [ 40] [41]では、グラフィカル文字のレパートリーが未定義になるという理由で禁止されている。ただし、ISO/IEC 4873/ECMA-43では、文字のシーケンスが同じままで、異なる意味を持つ文字を形成するためにオーバースタンプされるのではなく、単に1つのスペースに表示される限り、GCC機能の使用を許可している。[42]

制御文字セット

制御文字セットは「プライマリ」または「セカンダリ」制御コードセットに分類され、[43]それぞれ「C0」および「C1」制御コードセットとも呼ばれます。[44]

C0制御セットには、0x1BにESC(エスケープ)制御文字が含まれていなければなりません[45](ESCのみを含むC0セットはISO-IR-104として登録されています)[46]。一方、C1制御セットにはエスケープ制御文字が全く含まれていない可能性があります[33]。したがって、これらは完全に別々の登録であり、C0セットはC0セットのみであり、C1セットはC1セットのみである。[44]

ISO 6429 / ECMA-48のC0セットのコード、すなわちASCII制御コードがC0セットに現れる場合、それらはISO 6429 / ECMA-48の位置に現れる必要がある。[45] ISO 6429 / ECMA-48に含まれる10個の伝送制御文字(すなわちSOH、STX、ETX、EOT、ENQ、ACK、DLE、NAK、SYN、ETB)以外の伝送制御文字をC0セットに含めること、[47]またはC1セットにそれらの10個のいずれかを含めることは、ISO/IEC 2022 / ECMA-35規格によっても禁止されている。[45] [33]

C0制御セットはCL範囲0x00から0x1Fで呼び出されますが[48] 、 C1制御機能はCR範囲0x80から0x9F(8ビット環境)で呼び出されるか、エスケープシーケンスを使用して呼び出されます(7ビットまたは8ビット環境)[43]。ただし、両方を同時に呼び出すことはできません。どちらのC1呼び出しスタイルを使用するかは、コードバージョンの定義で指定する必要があります。[49]例えば、ISO/IEC 4873では、使用するC1制御(SS2およびSS3)のCRバイトを規定しています。[50]必要に応じて、どの呼び出しが使用されるかをアナウンサーシーケンスを使用して通知することができます。

後者の場合、C1制御コードセットからの単一の制御機能は、「タイプFe」エスケープシーケンスを使用して呼び出されます。[33]これは、ESC制御文字の後に列04または05(つまり、ESC 0x40 (@)からESC 0x5F (_))のバイトが続くことを意味します。[51]

その他の制御機能

追加の制御機能は「タイプFs」エスケープシーケンス(範囲: からESC 0x60 (`))に割り当てられますESC 0x7E (~)。これらはC0またはC1指定に依存せず、永続的に割り当てられた意味を持ちます。[51] [52]制御機能をタイプ「Fs」シーケンスに登録するには、ISO/IEC JTC 1/SC 2の承認が必要です[52]その他の単独制御機能はタイプ「3Ft」エスケープシーケンス(範囲: から)に登録できますが[53]現在(2019年現在)「3Ft」シーケンスは割り当てられていません。[54]これらの一部はECMA-35(ISO 2022 / ANSI X3.41)で規定されており、その他はECMA-48(ISO 6429 / ANSI X3.64)で規定されています。[55] ECMA-48では、これらを「独立制御機能」と呼んでいます。[56]ESC 0x23 (#) [I...] 0x40 (@)ESC 0x23 (#) [I...] 0x7E (~)

コードヘックス略語名前効果[54]
ESC `1B 60DMI手動入力を無効にするデバイスの手動入力機能の一部またはすべてを無効にします。
ESC a1B 61INT割り込み現在のプロセスを中断します。
ESC b1B 62EMI手動入力を有効にするデバイスの手動入力機能を有効にします。
ESC c1B 63リス初期状態にリセットデバイスのディスプレイと入力サブシステムは、電源を入れたときと同じ状態に戻ります。[57]クライアントへの接続は影響を受けません。
ESC d1B 64司令官コーディング方法の区切り文字外部コーディング/表現システムと対話するときに使用されます。以下を参照してください。
ESC n1B 6ELS2シフト2をロックするシフト機能については下記を参照してください。
ESC o1B 6FLS3シフト3をロックするシフト機能については下記を参照してください。
ESC |1B 7CLS3Rロックシフト3右シフト機能については下記を参照してください。
ESC }1B 7DLS2Rシフト2を右にロックシフト機能については下記を参照してください。
ESC ~1B 7ELS1R右シフトをロックシフト機能については下記を参照してください。

ESC 0x30 (0)「Fp」( ~ESC 0x3F (?))または「3Fp」(~ )のエスケープシーケンスは、当事者間の事前の合意により、単一の私的使用制御コード用に予約されています。[58]両方のタイプのいくつかのシーケンスは、 VT100などのDEC端末で使用されており、端末エミュレータによってサポートされています。[14]ESC 0x23 (#) [I...] 0x30 (0)ESC 0x23 (#) [I...] 0x3F (?)

シフト機能

デフォルトでは、GLコードはG0文字を指定し、GRコード(利用可能な場合)はG1文字を指定します。これは事前の合意により変更される場合があります。各領域で呼び出されるセットは、以下の表に示すように、シフトと呼ばれる制御コードによって変更されることもあります。[59]

8ビットコードにはG1文字を指定するGRコードがあり、対応する7ビットコードではシフトインシフトアウトを使用してセット間を切り替えることができます(例:JIS X 0201[60]。ただし、GRコードでG2文字を指定するものもあり、対応する7ビットコードではシングルシフトコードを使用して2番目のセットにアクセスします(例:T.51)。[61]

下の表に示すコードは、これらの制御コードの最も一般的なエンコードであり、ISO/IEC 6429に準拠しています。 LS2、LS3、LS1R、LS2R、および LS3R シフトは、単一の制御機能として登録され、常に以下にリストするエスケープシーケンスとしてエンコードされます。[54]一方、その他のシフトは C0 または C1 制御コードセットの一部です (以下に示すように、SI (LS0) と SO (LS1) は C0 制御であり、SS2 と SS3 は C1 制御です)。つまり、どの制御セットが指定されているかによって、そのエンコードと可用性が異なる場合があります。つまり、その機能が使用されるには、指定された制御セットに存在している必要があります。[48] [49]前述のように、C1 制御自体は、エスケープシーケンスまたは 8 ビットバイトを使用して表すことができますが、両方を使用することはできません。

特定の制御コードセットでは、シングルシフトをC0制御コードとして代替エンコードすることが可能です。例えば、SS2とSS3は通常、T.51 [61]T.61でそれぞれ0x19と0x1Dで利用可能です。[62]このエンコードは現在、SS2とSS3の7ビットシングルバイト表現を必要とするアプリケーション向けにISO/IEC 2022/ECMA-35で推奨されています。[63]また、SS2のみに使用することもできます。[64]ただし、SS2が0x1Cである古いコードセットも存在し、[65] [66] [67]以前の規格でもそのように言及されていました。[68]以下に示すシングルシフトの0x8Eと0x8Fエンコードは、ISO/IEC 4873レベル2と3で必須です。 [69]

コードヘックス略語名前効果
SI0FSI
LS0
シフトイン
ロックシフトゼロ
GLは今後G0をエンコードする[70] [71]
SO0ESO
LS1
シフトアウト
シフト1をロック
GLは今後G1をエンコードする[70] [71]
ESC n1B 6ELS2シフト2をロックするGLは今後G2をエンコードする[70] [71]
ESC o1B 6FLS3シフト3をロックするGLは今後G3をエンコードする[70] [71]
CR領域: SS2
エスケープコード: ESC N
CR領域: 8E
エスケープコード: 1B 4E
SS2シングルシフト2GLまたはGR(下記参照)は直後の文字のみG2をエンコードする[72]
CR領域: SS3
エスケープコード: ESC O
CR領域: 8F
エスケープコード: 1B 4F
SS3シングルシフト3GLまたはGR(下記参照)は直後の文字のみG3をエンコードする[72]
ESC ~1B 7ELS1R右シフトをロックGRは今後G1をエンコードする[73]
ESC }1B 7DLS2Rシフト2を右にロックGRは今後G2をエンコードする[73]
ESC |1B 7CLS3Rロックシフト3右GRは今後G3をエンコードする[73]

シングルシフトコードは正式にはシフトコードとみなされ、それに応じて命名されているが、常にシフトと見なされるわけではなく、[12]単にプレフィックスバイト(つまり、マルチバイトシーケンスの最初のバイト)と見なされることもある。 [11]これは、ロックシフトコードとは異なり、エンコーダが現在アクティブなセットを状態として保持する必要がないためである。8ビット環境では、GLまたはGRのいずれか一方がシングルシフト領域として使用され得るが、両方は使用されない。これは、コードバージョンの定義で指定されなければならない。[72]たとえば、ISO/IEC 4873ではGLが指定されているが、パックEUCではGRが指定されている。7ビット環境では、GLのみがシングルシフト領域として使用される。[74] [75]必要に応じて、どのシングルシフト領域が使用されているかをアナウンサーシーケンスを使用して通信することができる。

「ロッキングシフトゼロ」(LS0)と「ロッキングシフトワン」(LS1)という名称は、「シフトイン」(SI)と「シフトアウト」(SO)という名称と同じC0制御文字のペア(0x0Fと0x0E)を指します。ただし、規格では、8ビット環境で使用される場合はLS0とLS1、7ビット環境で使用される場合はSIとSOと表記されます。[59]

ISO/IEC 2022 / ECMA-35規格では、GLとGRの両方でG1、G2、またはG3を同時に呼び出すことは許可されているが、推奨されていない。[76]

グラフィカルおよび制御コードセットの登録

ISO国際エスケープシーケンス用コード化文字セット登録簿(ISO-IR)には、ISO/IEC 2022で使用するために登録されているグラフィカル文字セット、制御コードセット、単一制御コードなどが列挙されている。コードとセットをISO-IR登録簿に登録する手順は、ISO/IEC 2375で規定されている。登録ごとに固有のエスケープシーケンスと、それを識別するための固有の登録エントリ番号が付与される。[77] [78]例えば、簡体字中国語のCCITT文字セットはISO-IR-165として知られている

ISO-IRレジストリへの符号化文字セットの登録は、ISO/IEC 2022非私用エスケープシーケンスに関連付けられた文字セットまたは制御機能を規定する文書を特定するものである。これは標準文書となる場合もあるが、登録によって新たなISO規格が作成されるわけではなく、ISOまたはIECがそれを国際標準として採用することを約束するものではなく、ISOまたはIECがその文字をユニバーサル符号化文字セットに追加することを約束するものでもない。[79]

ISO-IRに登録されたエスケープシーケンスは、SGML (ISO 8879)における数値文字参照に使用される文字セットを識別するために、公式公開識別子( FPI)にカプセル化されて使用される。例えば、この文字列はISO 646-1983の国際参照版を識別するために使用でき[80] HTML 4.01仕様ではUnicodeを識別するために使用されている [ 81] FPIの3番目の要素に含まれるエスケープシーケンスのテキスト表現は、サポートされている文字セットのSGML実装によって認識される。[80]ISO 646-1983//CHARSET International Reference Version (IRV)//ESC 2/5 4/0ISO Registration Number 177//CHARSET ISO/IEC 10646-1:1993 UCS-4 with implementation level 3//ESC 2/5 2/15 4/6

文字セットの指定

文字セットを指定するためのエスケープシーケンスは、 という形式をとります。前述のように、中間バイト(I)は0x20~0x2Fの範囲、最終バイト(F)は0x30~0x7Eの範囲です。最初のIバイト(マルチバイトセットの場合は最初の2バイト)は、文字セットの種類と、その文字セットが指定するワーキングセットを識別します。一方、Fバイト(および追加のIバイト)は、ISO-IRレジスタ(または、私的使用エスケープシーケンスの場合は事前の合意)で割り当てられた文字セット自体を識別します。ESC I [I...] F

Fバイトの範囲を拡張するために、Fバイトの前にIバイトを追加することができます。これは現在、94文字セットでのみ使用されており、その場合は形式のコードが割り当てられています。[82]一方、マルチバイトの96文字セットは登録されていないため、以下のシーケンスはあくまで理論上のものです。ESC ( ! F

他のエスケープシーケンスタイプと同様に、0x30~0x3Fの範囲は私的使用のFバイトのために予約されており、[31]この場合は私的使用の文字セット定義(ARIB STD-B24 [83]MARC-8 [ 3]などのプロトコルで定義されている未登録のセット、またはDEC Special Graphics [84]などのベンダー固有のセットが含まれる場合があります)用です。ただし、グラフィカルセット指定シーケンスでは、2番目のIバイト(シングルバイトセットの場合)または3番目のIバイト(ダブルバイトセットの場合)が0x20(スペース)の場合、示されているセットは事前の合意によって定義された「動的に再定義可能な文字セット」(DRCS)であり、[85]これも私的使用と見なされます。[31]グラフィカルセットがDRCSと見なされるということは、抽象的な文字のセットではなく、正確なグリフのフォントを表すことを意味します。[86] DRCSセットと関連フォントの伝送、割り当て、管理方法はISO/IEC 2022/ECMA-35自体では規定されていないが、Fバイト0x40(@)から順番に割り当てることを推奨している。[87]ただし、DRCSフォントの伝送方法は、ワールドシステムテレテキストなどの一部の通信プロトコルで定義されている。[88]

マルチバイトコードには3つの特殊なケースがあります。、、のコードシーケンスはESC $ @当時の標準規格がマルチバイトセットをG0でのみ許可していた時代に登録されたため、G0文字セットを指定するには、シーケンスからの代わりに受け入れる必要があります[89]ESC $ AESC $ BESC $ ( @ESC $ ( B

制御文字セットを切り替えるための追加機能(まれにしか使用されない)もありますが、これは単一レベルのルックアップであり、(前述のように)C0セットは常にCLを介して呼び出され、C1セットは常にCRを介して、またはエスケープコードを使用して呼び出されます。前述のように、C0文字セットには位置0x1BにESC文字が含まれている必要があり、これによりさらなる変更が可能になります。制御セット指定シーケンス(グラフィカルセットのシーケンスとは対照的に)は、 ANSIエスケープコードの処理が適切なコンテキストにおいて、 ISO/IEC 10646 (UCS/Unicode)内から使用することもできます。ただし、シーケンス内の各バイトはエンコードのコード単位サイズに合わせてパディングされます。[90]

エスケープシーケンスIバイトとそれが実行する指定またはその他の機能の表を以下に示します。 [91]

コードヘックス略語名前効果
ESC SP F1B 20 FACSコード構造を発表する使用されるコード機能を指定します(例:ワーキングセット(下記参照)。[92]ESC SP L
ISO 4873レベル1)
ESC ! F1B 21 FCZDC0指定Fは使用するC0制御文字セットを選択します。[93]ESC ! @
ASCII C0コード
ESC " F1B 22 FC1DC1指定Fは使用するC1制御文字セットを選択します。[94]ESC " C
ISO 6429 C1 コード
ESC # F1B 23 F-(単一制御機能)(制御機能のシーケンス用に予約されています。上記を参照してください。)ESC # 6
(私的使用:DECダブル幅線)[95]
  • ESC $ F[e]
  • ESC $ ( F
  • 1B 24 F[e]
  • 1B 24 28 F
GZDM4G0指定マルチバイト94セットFはG0に使用する94個のn文字セットを選択する。 [89]ESC $ ( C
G0のKS X 1001 )
ESC $ ) F1B 24 29 FG1DM4G1指定マルチバイト94セットFはG1に使用する94個のn文字セットを選択する。 [89]ESC $ ) A
G1のGB 2312 )
ESC $ * F1B 24 2A FG2DM4G2指定マルチバイト94セットFはG2に使用する94個のn文字セットを選択する。 [89]ESC $ * B
JIS X 0208 G2)
ESC $ + F1B 24 2B FG3DM4G3指定マルチバイト94セットFはG3に使用する94個のn文字セットを選択する。 [89]ESC $ + D
JIS X 0212 G3)
ESC $ , F1B 24 2C F-(未使用)(未使用)[f]-
ESC $ - F1B 24 2D FG1DM6G1指定マルチバイト96セットFはG1に使用する96個のn文字セットを選択する。 [89]ESC $ - 1
(私的使用)
ESC $ . F1B 24 2E FG2DM6G2指定マルチバイト96セットFはG2に使用する96個のn文字セットを選択する。 [89]ESC $ . 2
(私的使用)
ESC $ / F1B 24 2F FG3DM6G3指定マルチバイト96セットFはG3に使用する96個のn文字セットを選択する。 [89]ESC $ / 3
(私的使用)
ESC % F1B 25 Fドキュメント他のコーディングシステムを指定するコーディング システムを切り替えます。以下を参照してください。ESC % G
UTF-8
ESC & F1B 26 F内部収益改訂登録の特定リビジョンを示すために指定エスケープをプレフィックスとして付けます。[g]ESC & @ ESC $ B
JIS X 0208:1990 G0)
ESC ' F1B 27 F-(未使用)(未使用)-
ESC ( F1B 28 FGZD4G0指定94セットFはG0に使用する94文字セットを選択します。[89]ESC ( B
G0のASCII )
ESC ) F1B 29 FG1D4G1指定94セットFはG1に使用する94文字セットを選択します。[89]ESC ) I
JIS X 0201かなG1)
ESC * F1B 2A FG2D4G2指定94セットFはG2に使用する94文字セットを選択します。[89]ESC * v
ITU T.61 G2のRHS)
ESC + F1B 2B FG3D4G3指定94セットFはG3に使用する94文字セットを選択します。[89]ESC + D
G3のNATS-SEFI-ADD )
ESC , F1B 2C F-(未使用)(未使用)[h]-
ESC - F1B 2D FG1D6G1指定96セットFはG1に使用する96文字セットを選択します。[89]ESC - A
ISO 8859-1 G1のRHS)
ESC . F1B 2E FG2D6G2指定96セットFはG2に使用する96文字セットを選択します。[89]ESC . B
ISO 8859-2 G2のRHS)
ESC / F1B 2F FG3D6G3指定96セットFはG3に使用する96文字セットを選択します。[89]ESC / b
ISO 8859-15 G3のRHS)

Fバイトのレジストリは、異なるタイプに対して独立していることに注意してください。 から で指定される94文字のグラフィックセットは、ESC ( AからESC + A指定される96文字セットとは全く関連がありません。また、これらの文字セットは、からで指定される94個のn文字セットとは関連がありません。以下同様です。最終バイトは文脈に応じて解釈する必要があります。(実際、中間バイトなしで は、C1制御コード0x81を指定する方法です。)ESC - AESC / AESC $ ( AESC $ + AESC A

また、C0 制御文字セットと C1 制御文字セットは独立していることにも注意してください。 で指定される C0 制御文字セット (新聞のテキスト送信用の NATS 制御セット) は、 で指定される C1 制御文字セット( Videotex用のCCITT属性制御セット)ESC ! Aと同じではありません。ESC " A

他のコーディングシステムとの相互作用

この標準では、独自の構造に従わないコーディング システムを指定する方法も定義されています。

ISO/IEC 2022に戻すためのシーケンスも定義されています。ISO/IEC 2022でエンコードされたこのシーケンスをサポートする登録には、(2019年現在)さまざまなビデオテックス形式、UTF-8UTF-1が含まれます。[99] 0x2F()の2番目のI/バイトは、そのバイトシーケンスを使用してISO 2022に戻らないコードの指定シーケンスに含まれます。これらのコードには、ISO 2022に戻すための独自の手段(異なるシーケンスやパディングされたシーケンスなど)がある場合もあれば、まったくない場合もあります。[100]後者のタイプの既存の登録はすべて(2019年現在)、透過的な生データ、Unicode/UCS形式、またはそれらのサブセットのいずれかです。[101]

コードヘックス略語名前効果
ESC % @1B 25 40ドキュメント他のコーディングシステムを指定する(「標準リターン」)別のエンコーディングからISO/IEC 2022に戻る。[100]
ESC % F1B 25 F他のコード体系を指定する(「標準リターン付き」)[99]Fは8ビットコードを選択します。ESC % @戻るにはFを使用します。[100]
ESC % / F1B 25 2F F他のコード体系を指定する(「標準リターンなし」)[101]Fは8ビットコードを選択します。返す標準的な方法はありません。[100]
ESC d1B 64司令官コーディング方法の区切り文字ISO/IEC 2022コード化シーケンスの終了を示す。[102]

特に興味深いのは、ISO/IEC 2022の構造に従わないISO/IEC 10646Unicode )形式への切り替えシーケンスです。これには、UTF-8(制御文字用に0x80~0x9Fの範囲を予約していない)、その前身であるUTF-1(マルチバイトコードでGRバイトとGLバイトを混在させる)、そしてUTF-16とUTF-32(より広い符号化単位を使用する)が含まれます。[99] [101]

UTF-8、UTF-16、UTF-32のサブセット(レベル1と2)や、UCS-2の3つのレベルにも、いくつかのコードが登録されている。[101]しかし、現在ISO/IEC 10646で規定されているコードは、UTF-8、UTF-16、UTF-32のレベル3コードと、UTF-8の未指定レベルコードのみであり、残りは非推奨となっている。[103] ISO/IEC 10646では、 UTF-16とUTF-32のビッグエンディアン形式はエスケープシーケンスで指定すると規定されている。[104]

Unicode形式コードヘックス[103]非推奨のコード非推奨の16進数[99] [101] [103]
UTF-1(UTF-1 は現在の ISO/IEC 10646 には含まれていません。)ESC % B1B 25 42
UTF-8ESC % G
ESC % / I
1B 25 47, [13]
1B 25 2F 49[105]
ESC % / G
ESC % / H
1B 25 2F 47
1B 25 2F 48
UTF-16ESC % / L1B 25 2F 4C[106]ESC % / @、、、、、
ESC % / C
ESC % / E
ESC % / J
ESC % / K
1B 25 2F 40、、、、、
1B 25 2F 43
1B 25 2F 45
1B 25 2F 4A
1B 25 2F 4B
UTF-32ESC % / F1B 25 2F 46ESC % / A
ESC % / D
1B 25 2F 41
1B 25 2F 44

UTF-8への切り替えシーケンスのうち、ESC % G例えばxtermでサポートされているものはこれです。[14]

UTF-16およびUTF-32の標準リターンシーケンスのバリエーションの使用は許可されていますが、エスケープシーケンスのバイトはエンコードのコード単位のサイズ(つまり001B 0025 0040UTF-16の場合)に合わせてパディングする必要があります。つまり、標準リターンシーケンスのコーディングはISO/IEC 2022に厳密に準拠していません。このため、UTF-16およびUTF-32の指定では、標準リターンを使用しない構文が使用されます。[107]

ラベルによるエンコーディングを指定するために、Xコンソーシアム複合テキスト形式では5つの私的使用DOCSシーケンスが定義されている。[108]

コード構造のアナウンス

シーケンス「コード構造アナウンス」()は、特定のコード構造、または特定のコードバージョンで使用されるISO 2022機能の特定のグループをアナウンスするために使用されます。アナウンスは組み合わせることができますが、特定の矛盾する組み合わせ(具体的には、ロッキングシフトアナウンスメント16~23をアナウンスメント1、3、および4と併用すること)は規格で禁止されています。また、ISO/IEC 4873レベルのアナウンスメント12 ~14 [92](許容される構造的特徴を完全に規定)に加えて追加のアナウンスを使用することも禁止されています。アナウンスシーケンスは以下のとおりです。ESC SP (0x20) F

番号コードヘックスコードバージョン機能が発表されました[92]
1ESC SP A1B 20 41GL に G0、GR が存在しないまたは未使用、ロック シフトなし。
2ESC SP B1B 20 42G0 および G1 はシフトをロックすることによって GL に呼び出され、GR は存在しないか未使用です。
3ESC SP C1B 20 43GL では G0、GR では G1、ロック シフトなし、8 ビット環境が必要です。
4ESC SP D1B 20 448 ビットの場合は GL で G0、GR で G1、7 ビット環境でない限りロック シフトはありません。
5ESC SP E1B 20 457 ビット/8 ビット変換中にシフト関数が保持されます。
6ESC SP F1B 20 46C1 はエスケープ シーケンスを使用して制御します。
7ESC SP G1B 20 47C1 は、8 ビット環境では CR 領域を制御し、それ以外の場合はエスケープ シーケンスとして機能します。
8ESC SP H1B 20 4894 文字のグラフィック セットのみ。
9ESC SP I1B 20 4994 文字および/または 96 文字のグラフィカル セット。
10ESC SP J1B 20 4A8 番目のビットが使用可能な場合でも、7 ビット コードを使用します。
11ESC SP K1B 20 4B8 ビットのコードが必要です。
12ESC SP L1B 20 4CISO/IEC 4873 (ECMA-43) レベル 1に準拠しています。
13ESC SP M1B 20 4DISO/IEC 4873 (ECMA-43) レベル 2に準拠しています。
14ESC SP N1B 20 4EISO/IEC 4873 (ECMA-43) レベル 3に準拠しています。
16ESC SP P1B 20 50SI/LS0 使用。
18ESC SP R1B 20 52SO/LS1使用。
19ESC SP S1B 20 53LS1R は 8 ビット環境で使用され、SO は 7 ビット環境で使用されます。
20ESC SP T1B 20 54LS2使用。
21ESC SP U1B 20 55LS2R は 8 ビット環境で使用され、LS2 は 7 ビット環境で使用されます。
22ESC SP V1B 20 56LS3使用。
23ESC SP W1B 20 57LS3R は 8 ビット環境で使用され、LS3 は 7 ビット環境で使用されます。
26ESC SP Z1B 20 5ASS2使用。
27ESC SP [1B 20 5BSS3使用。
28ESC SP \1B 20 5Cシングルシフトは GR を呼び出します。

ISO/IEC 2022 コードバージョン

(古いバージョンの Firefox のスクリーンショット。CJK サブメニューで利用可能なエンコードとして、Big5、GB 2312、GBK、GB 18030、HZ、ISO-2022-CN、Big5-HKSCS、EUC-TW、EUC-JP、ISO-2022-JP、Shift_JIS、EUC-KR、UHC、Johab、および ISO-2022-KR が表示されています。)
2004 年現在、Mozilla Firefoxではさまざまな ISO 2022 およびその他のCJKエンコーディングがサポートされています(このサポートは、特定のクロスサイト スクリプティング攻撃を回避するために、それ以降のバージョンでは縮小されています)。

IETF RFCでは、6つの7ビットISO 2022コードバージョン(ISO-2022-CN、ISO-2022-CN-EXT、ISO-2022-JP、ISO-2022-JP-1、ISO-2022-JP-2、ISO-2022-KR)が定義されており、このうちISO-2022-JPとISO-2022-KRは過去に広く使用されてきた。[109] IBMなどのベンダーによって、他の多くのバリアントが定義されている[110] HTML5ではUTF-8が推奨されるエンコーディングであるが、ISO-2022-JPのレガシーコンテンツは依然として広く普及しているため、WHATWGエンコーディング標準ではサポートが維持されている。[111] ISO-2022-KR、ISO-2022-CN、ISO-2022-CN-EXT [112]を完全に置換文字にマッピングするのではなく[113]クロスサイトスクリプティングなどのコードインジェクション攻撃への懸念からである[111] [113]

8ビットコード版には拡張Unixコードが含まれる。[11] [12] ISO /IEC 8859エンコーディングもISO/IEC 4873で規定されたサブセットのISO 2022に準拠している。[9] [10]

日本語版メール

ISO-2022-JP

ISO-2022-JPは、特に電子メール。JUNETネットワークでの使用のために導入され、後に1993年のIETF RFC[114]日本語の他のエンコード方式8ビットのクリーンなを必要としないという利点があります。マイクロソフトはこれをコードページ50220[115]ASCIIで始まり、以下のエスケープシーケンスを含みます。

  • ESC ( BASCII(1文字あたり1バイト)に切り替える
  • ESC ( JJIS X 0201-1976 (ISO/IEC 646:JP) ローマ字セット (1文字あたり1バイト)に切り替える
  • ESC $ @JIS X 0208-1978(1文字あたり2バイト)に切り替える
  • ESC $ BJIS X 0208-1983(1文字あたり2バイト)に切り替える

JIS X 0208-1990で追加された2つの文字の使用は許可されていますが、IRRシーケンスを含めず、つまりJIS X 0208-1983と同じエスケープシーケンスを使用します。[114]また、G0以外のマルチバイトセットの指定が可能になる前に登録されたため、JIS X 0208のエスケープには2番目のIバイトは含まれません([89]

RFCでは、既存のシステムのESC ( B中には と を区別しなかったものESC ( Jや とESC $ @を区別しなかったものがあると指摘しているが、電子ESC $ Bメールなどのメッセージを単に中継するシステムではエスケープシーケンスを変更してはならないと規定している。[114] HTML5が参照するWHATWGエンコード標準では、区別して扱うが、デコード時には を と同じように扱いエンコード時には を のみ とする。[116] RFCではまた、過去のシステムの中には、 シーケンスを誤って使用して、実際にはISO-IR-11 ( ISO 646およびWorld System Teletextのスウェーデン版)に登録されているJIS X 0208から切り替えていたものもあったと指摘している。[114] [i]ESC ( BESC ( JESC $ @ESC $ BESC $ BESC ( H

半角カタカナ版

を使ってJIS X 0201-1976ESC ( Iかなセット(1 文字につき 1 バイト)に切り替えることは、ISO-2022-JP プロファイルの一部ではないが、[114]時々使用される。Pythonでは、 ISO-2022-JP-EXTというラベルの付いた変種でこれを許可している(これは、後述するように JIS X 0212 も組み込んでおり、EUC-JPの適用範囲を完了する)。[117] [118]これは、名前と構造の両方でDECISO-2022-JPextというエンコーディングに近い。これは、さらに、でアクセスされる 2 バイトのユーザー定義領域を追加して、Super DEC Kanjiの適用範囲を完了する[119] WHATWG/HTML5 の変種では、ISO-2022-JP 入力で JIS X 0201 カタカナのデコードを許可しているが、エンコード時に文字を JIS X 0208 の同等の文字に変換している。[116] JIS X 0201かなも追加で許可されたISO-2022-JPのMicrosoftコードページはコードページ50221である。[115]ESC $ ( 0

JIS7およびJIS8として知られる他の古い変種は、JIS X 0201で定義された7ビットおよび8ビットのエンコーディングを直接構築し、それぞれシフトアウトとシフトインを使用するか、8番目のビットを設定する(GR呼び出し)ことで、エスケープシーケンスなしでG1からJIS X 0201かなを使用できる。 [120]これらは広く使用されていない。[120]拡張8ビットJIS X 0201でのJIS X 0208のサポートは、シフトJISを介してより一般的に実現される。シフトアウトとシフトインを介してシングルバイトカタカナを含むJIS X 0201ベースのISO 2022のMicrosoftのコードページは、コードページ50222である。[115]

ISO-2022-JP-2

ISO-2022-JP-2は、RFC 1554(1993年)で定義されたISO-2022-JPの多言語拡張であり、ISO-2022-JPのエスケープシーケンスに加えて、以下のエスケープシーケンスが許容されています。ISO/IEC 8859部分は96文字セットで、G0には指定できません。G2からは、シングルシフトコードSS2の7ビットエスケープシーケンス形式を使用してアクセスします。[121]

  • ESC $ AGB 2312-1980(1文字あたり2バイト)に切り替える
  • ESC $ ( CKS X 1001-1992(1文字あたり2バイト)に切り替える
  • ESC $ ( DJIS X 0212-1990(1文字あたり2バイト)に切り替える
  • ESC . AISO/IEC 8859-1上位部、拡張ラテン 1 セット(1 文字あたり 1 バイト)に切り替える[G2 に指定]
  • ESC . FISO/IEC 8859-7上位部分、基本ギリシャ語セット(1文字あたり1バイト)に切り替える[G2 に指定]

JIS X 0212のISO-2022-JP-2表現を含むISO-2022-JPは、他の拡張は含まず、1997年のRFC 2237でISO-2022-JP-1と改名された。[122]

IBM 日本語 TCP

IBMは、日本語向けに9つの7ビットISO 2022ベースのエンコードを実装しており、それぞれ異なるエスケープシーケンスセットを使用しています。IBM-956、IBM-957、IBM-958、IBM-959、IBM-5052、IBM-5053、IBM-5054、IBM-5055、ISO-2022-JPです。これらは総称して「TCP/IP日本語コード化文字セット」と呼ばれています。[123] CCSID 9148は標準(RFC 1468)ISO-2022-JPです。[124]

ISO-2022-JPのIBMバリアント
コードページ / CCSIDACRI定義番号ACRIのエスケープシーケンス[110]
956 [125]TCP-01
  • ESC ( J(JIS X 0201 ローマ字)
  • ESC $ ( B(JIS X 0208、1983+、長いエスケープシーケンス)
  • ESC $ I(JIS X 0201 カタカナ)
  • ESC $ ( D
957 [126]TCP-02
  • ESC ( J(JIS X 0201 ローマ字)
  • ESC $ ( @(JIS X 0208、1978、長いエスケープシーケンス)
  • ESC $ I(JIS X 0201 カタカナ)
  • ESC $ ( D(JIS X 0212)
958 [127]TCP-03
  • ESC ( A(アスキー)
  • ESC $ ( B(JIS X 0208、1983+、長いエスケープシーケンス)
  • ESC $ I(JIS X 0201 カタカナ)
  • ESC $ ( D(JIS X 0212)
959 [128]TCP-04
  • ESC ( A(アスキー)
  • ESC $ ( @(JIS X 0208、1978、長いエスケープシーケンス)
  • ESC $ I(JIS X 0201 カタカナ)
  • ESC $ ( D(JIS X 0212)
5052 [129]TCP-05
  • ESC ( J(JIS X 0201 ローマ字)
  • ESC $ B(JIS X 0208、1983+)
  • ESC $ I(JIS X 0201 カタカナ)
  • ESC $ ( D(JIS X 0212)
5053 [130]TCP-06
  • ESC ( J(JIS X 0201 ローマ字)
  • ESC $ @(JIS X 0208、1978)
  • ESC $ I(JIS X 0201 カタカナ)
  • ESC $ ( D(JIS X 0212)
5054 [131]TCP-07
  • ESC ( A(アスキー)
  • ESC $ B(JIS X 0208、1983+)
  • ESC $ I(JIS X 0201 カタカナ)
  • ESC $ ( D(JIS X 0212)
5055 [132]TCP-08
  • ESC ( A(アスキー)
  • ESC $ @(JIS X 0208、1978)
  • ESC $ I(JIS X 0201 カタカナ)
  • ESC $ ( D(JIS X 0212)
9148 [124]TCP-16
  • ESC ( A(アスキー)
  • ESC ( J(JIS X 0201 ローマ字)
  • ESC $ @(JIS X 0208、1978)
  • ESC $ B(JIS X 0208、1983+)

JIS X 0213

2000年に初めて発行されたJIS X 0213規格は、ISO-2022-JP-2拡張機能を除いたISO-2022-JPの更新バージョンであるISO-2022-JP-3を定義しています。ベースのJIS X 0208規格と比較してJIS X 0213で行われた追加により、拡張されたJISプレーン1が新しく登録され、新しいプレーン2は独自の登録を受けました。規格の2004年版でプレーン1にさらに追加されたため、プロファイルのさらなる改訂版であるISO-2022-JP-2004に追加登録されました。基本的なISO-2022-JP指定コードに加えて、次の指定が認識されます。

  • ESC ( IJIS X 0201-1976かなセット(1文字あたり1バイト)に切り替える
  • ESC $ ( OJIS X 0213-2000プレーン1(1文字あたり2バイト)に切り替える
  • ESC $ ( PJIS X 0213-2000プレーン2(1文字あたり2バイト)に切り替える
  • ESC $ ( QJIS X 0213-2004プレーン 1 (1 文字あたり 2 バイト、ISO-2022-JP-2004 のみ)に切り替える

その他の7ビットバージョン

ISO-2022-KRは、1993年のRFC 1557で定義されています。[133]これは、ASCIIと韓国語の2バイト文字KS X 1001-1992[134][135]KS X 1001からG1を指定するために行頭に一度挿入した後、Shift Out文字とShift In文字を使用し[133]ESC $ ) C

ISO-2022-CNおよびISO-2022-CN-EXTは、1996年のRFC 1922で定義されています。これらは7ビットのエンコードで、Shift Out機能とShift In機能(G0とG1間のシフト)と、単一シフト機能SS2とSS3(G2とG3へのアクセス)の7ビットエスケープコード形式の両方を利用しています。[136]これらは、文字セットGB 2312簡体字中国語)とCNS 11643繁体字中国語)をサポートしています。

基本的なISO-2022-CNプロファイルは、G0(シフトイン)セットとしてASCIIを使用し、GB 2312とCNS 11643の最初の2つのプレーンも含んでいます(これらの2つのプレーンは、一般的なBig5のすべての繁体字中国語文字を表すのに十分であるため、RFCは付録で対応を示しています)。[136]

  • ESC $ ) AGB 2312-1980(1文字あたり2バイト)に切り替える[G1に指定]
  • ESC $ ) GCNS 11643-1992プレーン 1 (1 文字あたり 2 バイト) [G1 に指定]に切り替える
  • ESC $ * HCNS 11643-1992 プレーン 2 (1 文字あたり 2 バイト) [G2 に指定]に切り替える

ISO-2022-CN-EXTプロファイルでは、以下の追加のセットとプレーンが許可されます。[136]

  • ESC $ ) EISO-IR-165(1文字あたり2バイト)に切り替える[G1に指定]
  • ESC $ + ICNS 11643-1992 プレーン 3 (1 文字あたり 2 バイト) [G3 に指定]に切り替える
  • ESC $ + JCNS 11643-1992 プレーン4(1文字あたり2バイト)に切り替える[G3に指定]
  • ESC $ + KCNS 11643-1992 Plane 5(1文字あたり2バイト) [G3に指定]に切り替える
  • ESC $ + LCNS 11643-1992 Plane 6(1文字あたり2バイト) [G3に指定]に切り替える
  • ESC $ + MCNS 11643-1992 Plane 7(1文字あたり2バイト) [G3に指定]に切り替える

ISO-2022-CN-EXTプロファイルでは、追加のGuobiao標準グラフィックセットが許可されていると記載されていますが、登録されたISO 2022エスケープシーケンスが割り当てられていることが条件となっています。[136]

  • G1のGB 12345
  • G2のGB 7589またはGB 13131
  • G3のGB 7590またはGB 13132

ESC(シングルバイト文字セットの場合)または(マルチバイト文字セットの場合)の後の文字は、ESC $指定する文字セットとワーキングセットの種類を指定します。上記の例では、文字((0x28)は94文字セットをG0文字セットに指定し、)*または+(0x29~0x2B)はG1~G3文字セットに指定します。

ISO-2022-KRとISO-2022-CNはISO-2022-JPよりも使用頻度が低く、セキュリティ上の懸念から意図的にサポートされない場合もあります。特に、HTML5で使用されるWHATWGエンコーディング標準は、ISO-2022-KR、ISO-2022-CN、ISO-2022-CN-EXT(およびHZ-GB-2312)を「置換」デコーダーにマッピングします。[112]このデコーダーは、すべての入力を置換文字(�)にマッピングすることで、クライアントとサーバーのエンコーディングサポートの違いを利用したクロスサイトスクリプティングなどの攻撃を防止します。[113]同じセキュリティ上の懸念(ASCIIバイトのシーケンスが異なる解釈を許す)はISO-2022-JPとUTF-16にも当てはまりますが、展開されたコンテンツでの使用頻度がはるかに高いため、この処理は適用されませんでした。[111]

2024年4月、 glibcのISO-2022-CN-EXTの実装にセキュリティ上の欠陥[137]が発見され、Linuxシステムでエンコーディングを完全に無効にすることが推奨されました。[138]

ISO/IEC 4873

ECMA-43 (ISO/IEC 4873) のエディションおよびレベルと EUC の関係。

ISO 2022の8ビットシングルバイトエンコーディングに適用されるサブセットは、ISO/IEC 4873で定義されています。これは、 ECMA InternationalによってECMA-43として発行されています。ISO /IEC 8859は、 ISO/IEC 4873(またはECMA-43)レベル1の8ビットコードを定義しています。[9] [10]

ISO/IEC 4873 / ECMA-43は3つのレベルのエンコードを定義している: [139]

  • レベル1には、C0セット、ASCII G0セット、オプションのC1セット、およびオプションのシングルバイト(94文字または96文字)G1セットが含まれます。G0はGLを介して呼び出され、G1はGRを介して呼び出されます。シフト機能の使用は許可されていません。
  • レベル2は、必須のG1セットに加えて、(94文字または96文字)1バイトのG2セットおよび/またはG3セットを含む。シングルシフト機能SS2およびSS3のみが許可され(つまり、ロックシフトは禁止)、これらはGL領域(96セットの場合は0x20と0x7Fを含む)を呼び出します。SS2とSS3は、それぞれC1の0x8Eと0x8Fで利用可能でなければなりません。ISO 4873に最低限必要なC1セットは、ISO-IR-105として登録されています。[69]
  • レベル 3 では、シングル シフトに加えて GR ロック シフト機能 LS1R、LS2R、および LS3R が許可されますが、それ以外はレベル 2 と同じ制限があります。

以前の版では、ISO/IEC 646の不変位置が保持され、他の位置がスペース文字(結合文字ではない)に割り当てられ、0x23が£または#に割り当てられ、0x24が$または¤に割り当てられることを条件として、G0セットに非ASCII文字の割り当てが許可されていました。[140]例えば、JIS X 0201の8ビットエンコーディングは以前の版に準拠しています。これはその後、ISO/IEC 646:1991 IRV / ISO-IR No. 6セット(ASCII)を完全に規定するように変更されました。[141] [142] [143]

ISO/IEC 646 IRV(1991年以降ASCIIと同期)をISO/IEC 4873レベル1でC1またはG1を設定せずに使用すること、つまりシフトコードを使用せず上位ビットが常にゼロである8ビット環境でIRVを使用することは、ISO 4873 DVと呼ばれ、DVは「デフォルトバージョン」の略です。[144]

異なるセットに重複する文字が存在する場合、ISO/IEC 4873 / ECMA-43の現行版では、これらの文字は、その文字が含まれるワーキングセットの中で最も番号の小さいセットでのみ使用が許可されています。[145]例えば、ある文字がG1セットとG3セットの両方に含まれる場合、その文字はG1セットから使用する必要があります。ただし、以前の版では他のセットからの使用が許可されていたことが明記されています。[143]

ISO/IEC 8859はISO/IEC 4873のレベル1における完全な符号化を定義しており、複数のISO/IEC 8859パートを併用することは許可されていません。ISO /IEC 4873のレベル2および3には、ISO/IEC 10367を使用する必要があると規定されています。[9] [10] ISO/IEC 10367:1991には、ISO/IEC 8859の最初の9つのパート(つまり、1991年の発行時点で存在していたもの)で使用されるG0およびG1セットと、いくつかの補足セットが含まれています。[146]

文字セット指定エスケープシーケンスは、情報交換中にバージョンを識別または切り替えるために使用されるが、これは他のプロトコルによって要求される場合のみである。その場合、規格ではISO/IEC 4873レベルを指定するISO/IEC 2022アナウンサーシーケンスが要求され、その後にC0、C1、G0、G1、G2、G3の文字セット指定を指定するエスケープシーケンスの完全なセットが続く(ただし、レベル1のG2とG3の指定は省略される)。Fバイト0x7Eは空セットを示す。ISO/IEC 4873の各レベルには、それぞれ独自のISO/IEC 2022アナウンサーシーケンスが1つずつあり、以下の通りである。[ 147]

コードヘックス発表
ESC SP L1B 20 4CISO 4873 レベル1
ESC SP M1B 20 4DISO 4873 レベル2
ESC SP N1B 20 4EISO 4873 レベル3

拡張Unixコード

拡張Unixコード(EUC)は、主に日本語韓国語中国語(簡体字)で使用される8ビット可変幅文字符号化システムです。ISO 2022に基づいており、ISO 2022構造に準拠する文字セットのみがEUC形式を持つことができます。最大4つの符号化文字セット(G0、G1、G2、G3)を表現できます。G0セットはGLを介して呼び出され、G1セットはGRを介して呼び出され、G2セットとG3セット(存在する場合)は、CRバイト(それぞれ0x8Eと0x8F)として使用される単一のシフトSS2とSS3を使用して呼び出され、GR(GLではない)を介して呼び出されます。[11]ロックシフトコードは使用されません。[12]

G0セットに割り当てられたコードはASCII、またはKS-Roman(KS X 1003)やJIS-Roman ( JIS X 0201の下半分)などの各国のISO 646文字セットです。 [11]そのため、0x5C( US-ASCIIではバックスラッシュ)は、 EUC-JPの一部のバージョンでは円記号を表すために、EUC-KRの一部のバージョンではウォン記号を表すために使用されます

G1は、2バイトで表現される94x94の符号化文字セットに使用されます。GB 2312EUC-CN形式やEUC-KRは、このような2バイトEUCコードの例です。EUC -JPは最大3バイト(つまりSS3と2バイト)で表現される文字を含みますが、EUC-TWでは1文字あたり最大4バイト(つまりSS2と3バイト)になります。

EUCコード自体はISO 2022のアナウンサーシーケンスや指定シーケンスを使用していませんが、次の4つのアナウンサーシーケンスのシーケンスに対応しており、意味は次のように分類されます。[148]

個別のシーケンス16進数EUCの特徴
ESC SP C1B 20 43ISO-8 (8 ビット、GL では G0、GR では G1)
ESC SP Z1B 20 5ASS2を使用してアクセスされたG2
ESC SP [1B 20 5BSS3を使用してアクセスされたG3
ESC SP \1B 20 5CシングルシフトはGRを呼び出す

複合テキスト(X11)

Xコンソーシアムは1989年に、Compound TextというISO 2022プロファイルを交換フォーマットとして定義した。[149]これは、HT)、 NL(改行、LFとしてコード化) 、ESC CSI(8ビット表現)の4つの制御コードのみを使用し、[150] SDS CSIシーケンスは双方向テキスト制御に使用されている。[151]これは、GLとGRにG0とG1を使用する8ビットコードであり、初期状態ではISO-8859-1に準拠している。 [152]次のFバイトが使用される。0x090x0A 0x1B0x9BCSI … ]

X11複合テキストで使用されるISO 2022指定シーケンス[153]
エスケープシーケンスの種類最終バイトグラフィカルセット
GZD4、G1D4(94文字セットの場合)B0x42アスキー
I0x49JIS X 0201カタカナ
J0x4AJIS X 0201 ローマ字
G1D6(96文字セット用)A0x41ISO-8859-1高部
B0x42ISO-8859-2上位部分
C0x43ISO-8859-3高部
D0x44ISO-8859-4上位部分
F0x46ISO-8859-7高部
G0x47ISO-8859-6高部
H0x48ISO-8859-8高部
L0x4CISO-8859-5高部
M0x4DISO-8859-9上位部分
GZDM4、G1DM4(2バイトセットの場合)A0x41GB 2312
B0x42JIS X 0208
C0x43KS C 5601

X11 Compound Textでは、ラベルによるエンコード指定のために、5つの私的使用DOCSシーケンスを定義しています。可変長エンコードの場合はESC % / 0( )、固定長エンコードの場合は( )から( )で、それぞれ1バイトから4バイトを使用します。ISO 2022に戻るために別のエスケープシーケンスを使用するのではなく、最初のエスケープシーケンスに続く2バイトで、残りの長さをバイト単位で指定します。これは、128進数でエンコードされ、バイト数で表されます。エンコードラベルはISO 8859-1にエンコードされたテキストの前に含まれ、STX ( )で終了します。[108]1B 25 2F 30ESC % / 1ESC % / 40x80–FF0x02

他のエンコーディングとの比較

利点

  • ISO/IEC 2022の全グラフィカル文字エンコーディングはGL上で呼び出せるため、GRとC1を表現できないことで利用可能なグリフが大幅に制限されることはなく、例えば7ビットエンコーディングに制限されているシステムでは、この制限はありません。したがって、このようなシステムでも、膨大な文字セットを表現できます。一般的に、この7ビット互換性は、古いシステムとの後方互換性を除けば、それほど大きな利点にはなりません。現代のコンピュータの大部分は、1バイトあたり8ビットを使用しています。
  • ISO/IEC 2022は、Unicodeと比較して、東アジアの異なる言語の個別のエンコーディングを切り替えるシーケンスコードを使用することで、漢字統合を回避しています。これにより、単一の文書とフォントで複数のCJK言語とその関連する文字異体をサポートすることが困難になるなど、漢字統合に伴う問題[要出典]回避しています。

デメリット

  • ISO/IEC 2022は状態を持つエンコーディングであるため、プログラムはテキストブロックの途中にジャンプして文字を検索、挿入、または削除することはできません。そのため、状態を持たないエンコーディングと比較して、テキスト操作は非常に煩雑で遅くなります。テキストの途中でジャンプした場合、エスケープシーケンスに続くバイトを解釈する前に、前のエスケープシーケンスに戻る必要がある場合があります。
  • ISO/IEC 2022 の状態依存の性質により、同一かつ等価な文字が異なる文字セットで符号化される可能性があり、これらの文字セットは G0 から G3 のいずれかに指定され、単一のシフト、または GL または GR へのロックシフトによって呼び出される可能性があります。その結果、文字は複数の方法で表現される可能性があり、視覚的に同一かつ等価な 2 つの文字列の等価性を確実に比較することはできません。
  • DICOMやいくつかの電子メールクライアントなどのシステムでは、他のいくつかのエンコードをサポートすることに加えて、 ISO-2022のバリエーション(例えば「ISO 2022 IR 100」 [154] )を使用しています。 [155]このようなバリエーションがあるため、コンピュータシステム間でテキストを移植可能に転送することが困難です。
  • ISO/IEC 2022 の 8 ビット制御文字の表現と互換性のあるマルチバイトUnicode変換形式であるUTF-1は、 UTF-8と比較してさまざまな欠点があり、ISO/IEC 2022 でサポートされている他の文字セットとの間で切り替えることは、通常、Unicode ドキュメントでは不要です。
  • エスケープシーケンスのため、悪意のある文字列(クロスサイトスクリプティングなど)がUnicodeにデコードされるまでマスクされ、サニタイズを回避できる攻撃バイトシーケンスを作成することが可能です。[156]そのため、このエンコードの使用はマルウェア対策スイートによって疑わしいものとして扱われ、[157] [より適切な出典が必要]また、7ビットのISO 2022データ(ISO-2022-JPを除く)は攻撃を防ぐためにHTML5置換文字に完全にマッピングされます。[112] [113]指定エスケープやロックシフトコードを使用しない制限されたISO 2022 8ビットコードバージョン(拡張Unixコードなど)ではこの問題は発生しません。
  • 連結は問題を引き起こす可能性があります。ISO-2022-JPなどのプロファイルでは、ストリームはASCII状態で始まり、ASCII状態で終わる必要があると規定されています。[114]これは、連結されたISO-2022-JPおよび/またはASCIIストリーム内の文字が正しいセットで解釈されることを保証するために必要です。その結果、マルチバイト文字で終わるストリームがマルチバイト文字で始まるストリームと連結されると、ASCIIに切り替えてすぐにASCIIから離れるエスケープコードのペアが生成されます。ただし、Unicode技術レポート#36(「Unicodeセキュリティに関する考慮事項」)に規定されているように、間に文字がないISO 2022エスケープシーケンスのペアは、クロスサイトスクリプティングなどの悪意のあるシーケンスを隠すために使用されるのを防ぐために、置換文字(「�」)を生成する必要があります[158]この対策をMozilla Thunderbirdなどで実装したところ、相互運用性の問題が発生し、2つのISO-2022-JPストリームが連結された箇所に予期しない「�」文字が生成されました。[156]

参照

脚注

  1. ^ 日本語:区点ローマ字kuten ;簡体字中国語:区位;繁体字中国語:區位;ピンイン: qōwèi ;韓国語 행렬 ;漢字行列; RRヘンニョル
  2. ^ 繁体字中国語:;簡体字中国語:;ピンイン: ;日本語の発音;点灯した。 'ゾーン';韓国語 ;漢字; RRヘン
  3. ^ 日本語:ローマ字ten lit。 'ポイント';中国語:;ピンイン:ウェイ;点灯した。 '位置';韓国語 ;漢字; RR: ヨル
  4. ^ 日本語ローマ字:  men文字通り「顔」
  5. ^ ab 歴史的な理由により、Fバイト0x40()、0x41()、0x42( )のみに指定されています。 [89]ソフトバンク2Gの絵文字エンコーディングなど、一部の実装では、ISO-2022に準拠していない目的でこの形式の追加のエスケープを使用しています。[96]@AB
  6. ^ MARC-8に掲載[3]背景については下記脚注を参照ESC , F
  7. ^ Fは1~63の範囲に調整され、直後の登録のどの(上位互換性のある)リビジョンが必要であるかを示し、古いシステムが古いことを認識できるようにします。[97]
  8. ^ 以前の版では96文字セットは存在せず、現在96文字セットに使用されているエスケープコードは、追加の94文字セットのためのスペースとして予約されていました。したがって、このESC 0x1B 0x2Cシーケンスは、標準の初期版では、追加の94文字セットをG0に指定するように定義されていました。[98] 96文字セットをG0に指定することはできないため、この最初のIバイトは現在の版の標準では使用されていません。ただし、 MARC-8には依然としてリストされています[3]
  9. ^ また、例えば、Printronix (2012)、OKI® Programmer's Reference Manual (PDF) 、p. 26も参照。 2019年9月25日にオリジナル(PDF)からアーカイブ。 2019年9月25日取得。ESC ( HDBCS から ASCII に切り替えるために使用する最近のシステムの場合。

参考文献

  1. ^ ECMA-35 (1994)、概要
  2. ^ ECMA-35 (1994)、p.51、付録D
  3. ^ abcde 「テクニック2:標準的な代替グラフィック文字セットの使用」。MARC 21 レコード構造、文字セット、および交換メディア仕様米国議会図書館。2007年12月5日。2020年7月22日時点のオリジナルからアーカイブ。 2020年7月19日閲覧
  4. ^ 「ECMA-35: 文字コード構造と拡張技術(ウェブページ)」. Ecma International . 2022年4月25日時点のオリジナルよりアーカイブ。 2022年4月27日閲覧
  5. ^ abcd ECMA-35 (1994)、15~16ページ、第8.1章
  6. ^ ab ECMA-35 (1994)、第13章
  7. ^ ab ECMA-35 (1994)、第12章、第14章
  8. ^ ab ECMA-35 (1994)、第11章
  9. ^ abcde ISO/IEC FDIS 8859-10 (1998)、p. 1、第1章(「適用範囲」)
  10. ^ abcde ECMA-144 (2000)、p. 1、第1章(「適用範囲」)
  11. ^ abcdef Lunde (2008)、pp. 242–245、第4章(「エンコード方式」)、セクション「EUCエンコード」
  12. ^ abcd Lunde (2008)、253–255ページ、第4章(「エンコード方式」)、「EUCとISO-2022エンコードの比較」セクション。
  13. ^ ISO-IR-196 (1996) より
  14. ^ abc Moy, Edward; Gildea, Stephen; Dickey, Thomas. 「ESCで始まるコントロール」. XTerm Control Sequences . 2019年10月10日時点のオリジナルよりアーカイブ2019年10月4日閲覧。
  15. ^ ECMA-35(1994)、第6章、第7章
  16. ^ ECMA-35(1994)、第8章
  17. ^ ECMA-35(1994)、第9章
  18. ^ ab ECMA-35 (1994)、第15章
  19. ^ Lunde (2008)、pp. 228–234、第4章(「エンコード方式」)、セクション「ISO-2022エンコード」
  20. ^ Lunde (2008)、pp. 19–20、第1章(「CJKV情報処理の概要」)、「行セルと平面行セルとは何か?」のセクション。
  21. ^ ECMA-35 (1994)、p.4、定義4.11
  22. ^ ECMA-35 (1994)、p.5、定義4.18
  23. ^ たとえば、ISO-IR-14 (1975)では、JIS X 0201ローマ字セットのG0指定をと定義していますESC 2/8 4/10
  24. ^ ECMA-35 (1994)、5ページ、5.1章
  25. ^ たとえば、RFC 1468 (1993)では、JIS X 0201 RomanセットのG0指定をと定義していますESC ( J
  26. ^ ECMA-35 (1994)、7ページ、6.2章
  27. ^ ECMA-35 (1994)、10ページ、6.3.2章
  28. ^ ECMA-35 (1994)、p.4、定義4.17
  29. ^ ECMA-35 (1994)、p.4、定義4.14
  30. ^ ECMA-35 (1994)、28ページ、第13.1章
  31. ^ abc ECMA-35 (1994)、33ページ、13.3.3章
  32. ^ ECMA-48 (1991)、24~26ページ、第5.4章
  33. ^ abcd ECMA-35 (1994)、p. 11、章6.4.3
  34. ^ ISO-IR-208 (1999)
  35. ^ ISO-IR-155 (1990)
  36. ^ ISO-IR-164 (1992)
  37. ^ ab ECMA-35 (1994)、10ページ、6.3.3章
  38. ^ Google Inc. (2014). 「ansi.go, 134行目」。Go用のANSIエスケープシーケンスライブラリ。2022年4月30日時点のオリジナルよりアーカイブ。 2019年9月14日閲覧
  39. ^ ECMA-43 (1991)、p. 5、第7章(「8ビットコードの文字の仕様」)
  40. ^ ISO/IEC FDIS 8859-10 (1998)、p. 3、第6章(「符号化文字セットの仕様」)
  41. ^ ECMA-144 (2000)、p. 3、第6章(「符号化文字セットの仕様」)
  42. ^ ECMA-43 (1991)、p. 19、付録C(「複合グラフィック文字」)
  43. ^ ab ECMA-35 (1994)、p. 10、章6.4.1
  44. ^ ab ECMA-35 (1994)、p. 11、章6.4.4
  45. ^ abc ECMA-35 (1994)、p. 11、章6.4.2
  46. ^ ISO-IR-104 (1985)
  47. ^ ISO-IR-1 (1975)
  48. ^ ab ECMA-35 (1994)、19ページ、第8.5.1章
  49. ^ ab ECMA-35 (1994)、p. 19、章8.5.2
  50. ^ ECMA-43 (1991)、p. 8、第7.6章 (「C1セット」)
  51. ^ ab ECMA-35 (1994)、p. 29、章 13.2.1
  52. ^ ab ECMA-35 (1994)、p. 12、章6.5.1
  53. ^ ECMA-35 (1994)、12ページ、6.5.2章
  54. ^ abc ISO-IR、p. 19、第2.7章(「単一制御機能」)
  55. ^ ECMA-35 (1994)、12ページ、6.5.4章
  56. ^ ECMA-48(1991)、第5.5章
  57. ^ ISO/TC 97/SC 2 (1976-12-30). 初期状態へのリセット (RIS) (PDF) . ITSCJ/ IPSJ . ISO-IR -35.{{citation}}: CS1 maint: 数値名: 著者リスト (リンク)
  58. ^ ECMA-35 (1994)、12ページ、6.5.3章
  59. ^ ab ECMA-35 (1994)、p. 14、第7.3章、表2
  60. ^ ISO-IR-14 (1975)
  61. ^ ab ITU-T (1995-08-11). 勧告T.51 (1992) 修正1. 2020年8月2日時点のオリジナルよりアーカイブ。 2019年12月25日閲覧
  62. ^ ISO-IR-106 (1985)
  63. ^ ECMA-35 (1994)、p. 15、第7.3章、注23
  64. ^ ISO-IR-140 (1987)
  65. ^ ISO-IR-7 (1975)
  66. ^ ISO-IR-26 (1976)
  67. ^ ISO-IR-36 (1977)
  68. ^ ECMA-35 (1980)、p.8、章5.1.7
  69. ^ ISO-IR-105 (1985) より
  70. ^ abcd ECMA-35 (1994)、17ページ、第8.3.1章
  71. ^ abcd ECMA-35 (1994)、p. 23、第9.3.1章
  72. ^ abc ECMA-35 (1994)、19ページ、第8.4章
  73. ^ abc ECMA-35 (1994)、17ページ、第8.3.2章
  74. ^ ECMA-35 (1994)、23~24ページ、第9.4章
  75. ^ ECMA-35 (1994)、27ページ、第11.1章
  76. ^ ECMA-35 (1994)、17ページ、第8.3.3章
  77. ^ ECMA-35 (1994)、p.47、付録B
  78. ^ ISO-IR、p. 2、第1章(「はじめに」)
  79. ^ ISO/IEC 2375 (2003)
  80. ^ ab 「SPにおけるSGML宣言の取り扱い」。SP : 国際標準ISO 8879に準拠したSGMLシステム
  81. ^ 「20: HTML 4のSGML 宣言」。HTML 4.01仕様。W3C
  82. ^ ISO-IR、p. 10、第2.2章(「第2中間バイトを持つ94文字のグラフィック文字セット」)
  83. ^ ARIB STD-B24 (2008)、p.39、パート2、表7-3
  84. ^ Mascheck, Sven; Le Breton, Stefan; Hamilton, Richard L. 「『代替線描画文字セット』について」~sven_mascheck/。2019年12月29日時点のオリジナルよりアーカイブ。 2020年1月8日閲覧
  85. ^ ECMA-35 (1994)、36ページ、第14.4章
  86. ^ ECMA-35 (1994)、36ページ、14.4.2章、注48
  87. ^ ECMA-35 (1994)、36ページ、14.4.2章、注47
  88. ^ ETS 300 706 (1997)、p. 103、第14章(「動的に再定義可能な文字」)
  89. ^ abcdefghijklmnopq ECMA-35 (1994)、35~36ページ、14.3.2章
  90. ^ ISO/IEC 10646 (2017)、19~20頁、12.4章(「制御機能セットの識別」)
  91. ^ ECMA-35 (1994)、32ページ、表5
  92. ^ abc ECMA-35 (1994)、37–41ページ、第15.2章
  93. ^ ECMA-35 (1994)、34ページ、14.2.2章
  94. ^ ECMA-35 (1994)、34ページ、14.2.3章
  95. ^ Digital . 「DECDWL—ダブル幅、シングルハイトライン」. VT510 ビデオ端末プログラマ情報. 2020年8月2日時点のオリジナルよりアーカイブ。 2020年1月17日閲覧
  96. ^ 川崎裕介 (2010). "Encode::JP::Emoji::Encoding". Encode-JP-Emoji . 268行目. 2022年4月30日時点のオリジナルよりアーカイブ。 2020年5月28日閲覧
  97. ^ ECMA-35 (1994)、36~37ページ、第14.5章
  98. ^ ECMA-35 (1980)、14~15ページ、5.3.7章
  99. ^ abcd ISO-IR、p. 20、章2.8.1(「標準戻り値によるコーディングシステム」)
  100. ^ abcd ECMA-35 (1994)、41~42ページ、第15.4章
  101. ^ abcde ISO-IR、p. 21、章2.8.2(「標準戻り値のないコーディングシステム」)
  102. ^ ECMA-35 (1994)、41ページ、第15.3章
  103. ^ abc ISO/IEC 10646 (2017)、p. 19、第12.2章(「UCSエンコーディングスキームの識別」)
  104. ^ ISO/IEC 10646 (2017)、18~19ページ、12.1章(「識別の目的とコンテキスト」)
  105. ^ ISO-IR-192 (1996)
  106. ^ ISO-IR-195 (1996)
  107. ^ ISO/IEC 10646 (2017)、p. 20、第12.5章(「ISO/IEC 2022のコーディングシステムの識別」)
  108. ^ ab Scheifler (1989)、§ 非標準文字セット エンコーディング
  109. ^ Lunde (2008)、229~230ページ、第4章(「エンコード方式」)、「ISO-2022エンコード」セクション「過去に広く使用されてきたエンコード、または現在も何らかの目的で使用され続けているエンコードが強調表示されています。」
  110. ^ ab 「コーディング関連の必須追加情報」。IBMグローバリゼーション - コード化文字セット識別子。IBM2015年1月7日時点のオリジナルよりアーカイブ。
  111. ^ abc WHATWG エンコーディング標準、セクション 2 (「セキュリティの背景」)
  112. ^ abc WHATWG エンコーディング標準、第4.2章(「名前とラベル」)、アンカー「置換」
  113. ^ abcd WHATWGエンコーディング標準、セクション14.1(「置換」)
  114. ^ abcdef RFC 1468 (1993)
  115. ^ abc 「コードページ識別子」。Windows Dev Center。Microsoft。2019年6月16日時点のオリジナルよりアーカイブ。 2019年9月16日閲覧
  116. ^ ab WHATWGエンコーディング規格、セクション12.2(「ISO-2022-JP」)
  117. ^ Chang, Hye-Shik. 「Modules/cjkcodecs/_codecs_iso2022.c、行番号1122」。cPythonソースツリー。Python Software Foundation。2022年4月30日時点のオリジナルよりアーカイブ。 2019年9月15日閲覧
  118. ^ "codecs — コーデックレジストリと基本クラス § 標準エンコーディング". Python 3.7.4 ドキュメント. Python Software Foundation. 2019年7月28日時点のオリジナルよりアーカイブ。 2019年9月16日閲覧
  119. ^ 「2: コードセットとコードセット変換」。DIGITAL UNIX 日本語機能使用のためのテクニカルリファレンス。Digital Equipment CorporationCompaq[リンク切れ]
  120. ^ ab Lunde (2008)、pp. 236–238、第4章(「エンコード方式」)、「ISO-2022-JPエンコードの前身であるJISエンコード」セクション
  121. ^ RFC 1554 (1993)
  122. ^ RFC 2237 (1997)
  123. ^ “PQ02042: 日本語ISO-2022-JP向けC/370 iconv()サポートを提供する新機能”. IBM . 2021年1月19日. 2022年1月4日時点のオリジナルよりアーカイブ。 2022年1月4日閲覧
  124. ^ ab "CCSID 9148". IBM Globalization - Coded Character Set Identifiers . IBM . 2014年11月29日時点のオリジナルよりアーカイブ。
  125. ^ 「CCSID 956」。IBMグローバリゼーション - コード化文字セット識別子。IBM 2014年12月2日時点のオリジナルよりアーカイブ。
  126. ^ 「CCSID 957」。IBMグローバリゼーション - コード化文字セット識別子。IBM 2014年11月30日時点のオリジナルよりアーカイブ。
  127. ^ 「CCSID 958」。IBMグローバリゼーション - コード化文字セット識別子。IBM 2014年12月1日時点のオリジナルよりアーカイブ。
  128. ^ 「CCSID 959」。IBMグローバリゼーション - コード化文字セット識別子。IBM 2014年12月2日時点のオリジナルよりアーカイブ。
  129. ^ 「CCSID 5052」。IBMグローバリゼーション - コード化文字セット識別子。IBM 2014年11月29日時点のオリジナルよりアーカイブ。
  130. ^ 「CCSID 5053」。IBMグローバリゼーション - コード化文字セット識別子。IBM 2014年11月29日時点のオリジナルよりアーカイブ。
  131. ^ 「CCSID 5054」。IBMグローバリゼーション - コード化文字セット識別子。IBM 2014年11月29日時点のオリジナルよりアーカイブ。
  132. ^ 「CCSID 5055」。IBMグローバリゼーション - コード化文字セット識別子。IBM 2014年11月29日時点のオリジナルよりアーカイブ。
  133. ^ RFC 1557 (1993) より
  134. ^ 「KS X 1001:1992」(PDF) 。 2007年9月26日時点のオリジナルよりアーカイブ(PDF) 。 2007年7月12日閲覧
  135. ^ ISO-IR-149 (1988)
  136. ^ abcd RFC 1922 (1996)
  137. ^ 「CVE-2024-2961」。
  138. ^ 「PHP を提供するサーバー上の GLIBC の脆弱性」。
  139. ^ ECMA-43 (1991)、9~10ページ、第8章(「レベル」)
  140. ^ ECMA-43 (1985)、7–11ページ、7.3章(「G0集合」)
  141. ^ ECMA-43 (1991)、6~8ページ、7.4章(「G0セット」)
  142. ^ ECMA-43 (1991)、p. 11、第10.3章(「バージョンの識別」)
  143. ^ ab ECMA-43 (1991)、p. 23、付録E(「このECMA規格の第2版(1985年)と現在の第3版の主な相違点」)
  144. ^ IPTC (1995). IPTC推奨メッセージフォーマット(PDF) (第5版). IPTC TEC 7901. 2022年1月25日時点のオリジナルよりアーカイブ(PDF) 。 2020年1月14日閲覧
  145. ^ ECMA-43 (1991)、10ページ、9.2章(「文字の一意の符号化」)
  146. ^ van Wingen, Johan W (1999). 「8. Code Extension, ISO 2022 and 2375, ISO 4873 and 10367」.文字セット. 文字、トークン、コード. Terena. 2020年8月1日時点のオリジナルよりアーカイブ。 2019年10月2日閲覧
  147. ^ ECMA-43 (1991)、pp. 10–11、第10章(「バージョンとレベルの識別」)
  148. ^ IBM . 「Character Data Representation Architecture (CDRA)」. IBM . pp.  157– 162. 2019年6月23日時点のオリジナルよりアーカイブ。 2020年6月18日閲覧
  149. ^ シェイフラー(1989)
  150. ^ シャイフラー (1989)、§ 制御文字
  151. ^ シャイフラー (1989)、§ 方向性
  152. ^ Scheifler (1989)、§ 標準文字セット エンコーディング
  153. ^ Scheifler (1989)、§ 承認された標準エンコーディング
  154. ^ 「DICOM PS3.2 2016d - 適合性; D.6.2 文字セット; D.6 文字セットのサポート」。2020年2月16日時点のオリジナルよりアーカイブ。 2020年5月21日閲覧
  155. ^ “DICOM ISO 2022 variation”. 2013年4月30日時点のオリジナルよりアーカイブ2009年7月25日閲覧。
  156. ^ ab Sivonen, Henri (2018-12-17). 「(未提出ドラフト) ISO-2022-JPエスケープシーケンス間のゼロ長ASCII状態コンテンツに対するU+FFFD生成なし」(PDF) 。 2019年2月21日時点のオリジナルよりアーカイブ(PDF) 。 2019年2月21日閲覧
  157. ^ “935453 - HZおよび削除を検討しているその他のエンコードに関するテレメトリを収集する”. 2017年5月19日時点のオリジナルよりアーカイブ2018年6月18日閲覧。
  158. ^ Davis, Mark; Suignard, Michel (2014年9月19日). 「3.6.2 すべての入力に対する一部の出力」. Unicode技術レポート #36: Unicodeセキュリティに関する考慮事項(改訂第15版) . Unicodeコンソーシアム. 2019年2月22日時点のオリジナルよりアーカイブ。 2019年2月21日閲覧


引用された標準およびレジストリインデックス

  • ARIB (2008). ARIB STD-B24: デジタル放送におけるデータ符号化及び伝送方式(PDF) (ARIB標準規格). 5.2-E1. 第1巻. 2017年7月10日時点のオリジナルよりアーカイブ(PDF) . 2017年7月10日閲覧
  • ECMA (1980). ECMA-35: 7ビット符号化文字セットの拡張(PDF) (ECMA規格) (第2版).
  • ECMA (1994). ECMA-35: 文字コードの構造と拡張テクニック(PDF) (ECMA 標準) (第 6 版).
  • ECMA (1985). ECMA-43: 8ビット符号化文字セットの構造と規則(PDF) (ECMA規格) (第2版).
  • ECMA (1991). ECMA-43: 8ビット符号化文字セットの構造と規則(PDF) (ECMA規格) (第3版).
  • ECMA (1991). ECMA-48: 符号化文字セットの制御関数(PDF) (ECMA 標準) (第 5 版).
  • ECMA (2000). ECMA-144: 8ビットシングルバイトコード化グラフィック文字セット: ラテンアルファベットNo.6 (PDF) (ECMA規格) (第3版).
  • 欧州放送連合(1997). ETS 300 706: 拡張テレテキスト仕様(PDF) (欧州電気通信規格). ETSI .
  • ISO/IEC JTC 1/SC 2 (2003). ISO/IEC 2375:2003: 情報技術 — エスケープシーケンスおよびコード化文字セットの登録手順. ISO .{{cite book}}: CS1 maint: 数値名: 著者リスト (リンク)
  • ISO/IEC JTC 1/SC 2 (1998-02-12). ISO/IEC FDIS 8859-10: 情報技術 — 8ビットシングルバイトコード化グラフィック文字セット — パート10: ラテンアルファベット No. 6 (PDF) (最終国際規格草案).{{cite book}}: CS1 maint: 数値名: 著者リスト (リンク)
  • ISO/IEC JTC 1/SC 2 (2017). ISO/IEC 10646: 情報技術 — 汎用コード化文字セット (UCS) (ISO 規格) (第 5 版). ISO .{{cite book}}: CS1 maint: 数値名: 著者リスト (リンク)
  • ISO-IR: ISO/IEC エスケープシーケンスで使用されるコード化文字セットの国際登録簿(PDF) (レジストリインデックス). ITSCJ/ IPSJ . 2023年5月12日時点のオリジナル(PDF)からアーカイブ。 2023年5月12日閲覧
  • シャイフラー、ロバート W. (1989)。複合テキストエンコーディング (X コンソーシアム標準)。Xコンソーシアム
  • ファン・ケステレン、アン。 WHATWG エンコーディング標準 (WHATWG Living Standard)。なんてことだ

登録コードセットの引用

  • ISO/TC 97/SC 2 (1975-12-01). ISO-IR-1: ISO 646の制御文字セット(PDF) . ITSCJ/ IPSJ .{{citation}}: CS1 maint: 数値名: 著者リスト (リンク)
  • スウェーデン標準化委員会 (1975-12-01)。 ISO-IR-7: 新聞テキスト送信用の NATS 制御セット(PDF)。 ITSC​​J/情報処理学会
  • 日本工業標準調査会(1975-12-01). ISO-IR-14: 日本語ローマ字グラフィック文字セット(PDF) . ITSCJ/ IPSJ .
  • IPTC (1976-03-25)。 ISO-IR-26: 新聞テキスト送信用のコントロール セット(PDF)。 ITSC​​J/情報処理学会
  • ISO/TC 97/SC 2 (1977-10-15). ISO-IR-36: ISO 646の制御文字セット。IS4をG2のシングルシフト(SS2)に置き換えたもの(PDF) . ITSCJ/ IPSJ .{{citation}}: CS1 maint: 数値名: 著者リスト (リンク)
  • ISO/TC97/SC2/WG-7 ; ECMA (1985-08-01)。 ISO-IR-104: ISO 4873 に設定された最小 C0 (PDF)。 ITSC​​J/情報処理学会{{citation}}: CS1 maint: 数値名: 著者リスト (リンク)
  • ISO/TC97/SC2/WG-7 ; ECMA (1985-08-01)。 ISO-IR-105: ISO 4873 の最小 C1 セット(PDF)。 ITSC​​J/情報処理学会{{citation}}: CS1 maint: 数値名: 著者リスト (リンク)
  • ITU (1985-08-01). ISO-IR-106: テレテックス制御機能の基本セット(PDF) . ITSCJ/ IPSJ .
  • Úřad pronormalizaci a měřeni (1987-07-31)。 ISO-IR-140: ISO 646 の制御文字の C0 セット。EM は SS2 に置き換えられています(PDF)。 ITSC​​J/情報処理学会
  • 韓国規格協会 (1988年10月1日). ISO-IR-149: 情報交換のための韓国語グラフィック文字集合 (KS C 5601:1987) (PDF) . ITSCJ/ IPSJ .
  • ISO/IEC/JTC1/SC2/WG3 (1990-04-16). ISO-IR-155: 基本ボックス図面セット(PDF) . ITSCJ/ IPSJ .{{citation}}: CS1 maint: 数値名: 著者リスト (リンク)
  • CCITT (1992-07-13). ISO-IR-164: ヘブライ語補助図形文字セット(PDF) . ITSCJ/ IPSJ .
  • ECMA (1996-04-22). ISO-IR-192: UCS変換フォーマット(UTF-8)、実装レベル3、標準リターンなし(PDF) . ITSCJ/ IPSJ .
  • ECMA (1996-04-22). ISO-IR-195: UCS変換フォーマット(UTF-16)、実装レベル3、標準リターンなし(PDF) . ITSCJ/ IPSJ .
  • ECMA (1996-04-22). ISO-IR-196: UCS変換フォーマット (UTF-8), 標準リターン付き(PDF) . ITSCJ/ IPSJ .
  • アイルランド国家規格協会(1999年12月7日). ISO-IR-208: 情報交換のためのオガム符号化文字セット(PDF) . ITSCJ/ IPSJ .

インターネットコメント要請を引用

  • Murai, J.; Crispin, M.; van der Poel, E. (1993). 「RFC 1468: インターネットメッセージにおける日本語文字エンコーディング」 . Requests for Comments . IETF . doi : 10.17487/rfc1468 .
  • 太田正之; 半田健一 (1993). 「RFC 1554: ISO-2022-JP-2: ISO-2022-JPの多言語拡張」.コメント要求. IETF . doi : 10.17487/rfc1554 .
  • Choi, U.; Chon, K.; Park, H. (1993). 「RFC 1557: インターネットメッセージにおける韓国語文字エンコーディング」 . Requests for Comments . IETF . doi : 10.17487/rfc1557 .
  • Zhu, HF.; Hu, DY.; Wang, ZG.; Kao, TC.; Chang, WCH.; Crispin, M. (1996). 「RFC 1922: インターネットメッセージのための中国語文字エンコーディング」 . Requests for Comments . IETF . doi : 10.17487/rfc1922 .
  • 田丸 憲一 (1997). 「RFC 2237: インターネットメッセージにおける日本語文字エンコーディング」. Requests for Comments . IETF . doi : 10.17487/rfc2237 .

その他の引用文献

さらに読む

  • ISO/IEC 2022:1994
  • ISO/IEC 2022:1994/Cor 1:1999
  • ECMA-35 は ISO/IEC 2022 と同等であり、無料でダウンロードできます。
  • エスケープシーケンスで使用されるコード化文字セットの国際登録、割り当てられた文字セットとそのエスケープシーケンスの完全なリスト
  • 北米、ヨーロッパ、東アジアの文字コードの歴史(1999年以降、2004年改訂)
  • Ken Lundeの CJK.INF: 中国語、日本語、韓国語 (CJK) 言語のエンコードに関するドキュメント。ISO/IEC 2022 のさまざまなバリエーションに関する説明も含まれています。
「https://en.wikipedia.org/w/index.php?title=ISO/IEC_2022&oldid=1305169067#IBM_Japanese_TCP」から取得