ISO/IEC 2022

ISO/IEC 2022 Informationstechnik – Zeichenkodierungsstruktur und Erweiterungstechniken ist ein ISO / IEC- Standard im Bereich der Zeichenkodierung . Er ist äquivalent zum ECMA- Standard ECMA - 35 ^{[ 1 ] [ 2 ]} , dem ANSI- Standard ANSI X3.41 ^{[ 3 ]} und dem japanischen Industriestandard JIS X 0202. Er entstand 1971 und wurde zuletzt 1994 überarbeitet. ^{[ 4 ]}

ISO 2022 definiert eine allgemeine Struktur, an die sich Zeichenkodierungen anpassen können. Bestimmte Bytebereiche (0x00–1F und 0x7F–9F) sind für nicht druckbare Steuercodes [ 5 ] reserviert, die für Formatierungs- und In-Band-Befehle (z. B. Zeilenumbrüche oder Formatierungsbefehle für Textterminals) anstelle von grafischen Zeichen verwendet werden . ^{ISO 2022 legt} außerdem eine Syntax für Escape - Sequenzen fest – mehrbyteige Sequenzen, die mit dem Steuercode ESC beginnen und ebenfalls für In-Band-Befehle verwendet werden können. ^{[ 6 ]} Spezielle Sätze von Steuercodes und Escape-Sequenzen, die für die Verwendung mit ISO 2022 vorgesehen sind, finden sich in ISO/IEC 6429. Teile davon sind in ANSI.SYS und Terminalemulatoren implementiert .

ISO 2022 definiert zudem spezielle Steuercodes und Escape-Sequenzen, mit denen zwischen verschiedenen Zeichensätzen (z. B. zwischen ASCII und dem japanischen JIS X 0208 ) umgeschaltet werden kann, um mehrere in einem Dokument zu verwenden ^{[ 7 ].} Dadurch werden sie effektiv zu einer einzigen zustandsbehafteten Kodierung kombiniert (ein Merkmal, das seit der Einführung von Unicode an Bedeutung verloren hat). ISO 2022 ist sowohl für 8-Bit- als auch für 7-Bit-Umgebungen (in denen nur sieben Bit pro Byte nutzbar sind, wie z. B. E-Mails ohne 8BITMIME ) geeignet ^{[ 8 ] .}

Der ASCII-Zeichensatz unterstützt das ISO-Basis-Lateinische Alphabet (entspricht dem englischen Alphabet ) und bietet keine gute Unterstützung für Sprachen mit zusätzlichen Buchstaben oder einem gänzlich anderen Schriftsystem . Andere Schriftsysteme mit relativ wenigen Zeichen, wie Griechisch , Kyrillisch , Arabisch oder Hebräisch , sowie Formen der lateinischen Schrift mit diakritischen Zeichen oder Buchstaben, die im ISO-Basis-Lateinischen Alphabet nicht vorkommen, wurden auf PCs traditionell mit verschiedenen 8- Bit - ASCII - Kodierungen ( Einzelbyte -Kodierungen) dargestellt . Diese entsprechen ASCII, wenn das höchstwertige Bit 0 ist (d. h. Bytes 0x00–7F in Hexadezimaldarstellung ), und enthalten zusätzliche Zeichen für ein höchstwertiges Bit von 1 (d. h. Bytes 0x80–FF). Einige davon, wie beispielsweise die ISO 8859- Serie, entsprechen ISO 2022, ^{[ 9 ] [ 10 ]} während andere, wie beispielsweise die DOS-Codepage 437, dies nicht tun, in der Regel weil sie die Bytes 0x80–9F nicht für Steuercodes reservieren.

Bestimmte ostasiatische Sprachen, insbesondere Chinesisch , Japanisch und Koreanisch (zusammen „ CJK “), verwenden deutlich mehr Zeichen als die maximal 256, die in einem einzelnen Byte dargestellt werden können. Sie wurden zunächst auf Computern mit sprachspezifischen Doppelbyte- oder variablen Bytebreitenkodierungen dargestellt . Einige dieser Kodierungen (wie die vereinfachte chinesische Kodierung GB 2312 ) entsprechen ISO 2022 , andere (wie die traditionelle chinesische Kodierung Big5 ) nicht. Steuerzeichen in ISO 2022 werden immer mit einem einzelnen Byte dargestellt, unabhängig von der Anzahl der Bytes für grafische Zeichen. CJK-Kodierungen, die in 7-Bit-Umgebungen mit ISO-2022- Mechanismen zum Umschalten zwischen Zeichensätzen verwendet werden, tragen oft Namen, die mit „ISO-2022-“ beginnen, insbesondere ISO-2022-JP . Auch einige andere CJK-Kodierungen wie EUC-JP nutzen ISO-2022-Mechanismen. ^{[ 11 ] [ 12 ]}

Da die ersten 256 Codepunkte von Unicode aus ISO 8859-1 stammen , übernimmt Unicode das Konzept der C0- und C1-Steuercodes von ISO 2022, fügt aber neben den ISO-2022-Steuercodes weitere nicht druckbare Zeichen hinzu. Unicode-Transformationsformate wie UTF-8 weichen jedoch in verschiedenen Punkten von der ISO-2022-Struktur ab, unter anderem:

• Verwendung von 8-Bit-Bytes, jedoch nicht Darstellung der C1-Codes in ihrer in ISO 2022 spezifizierten Einzelbyte-Form (die meisten UTFs, mit Ausnahme des veralteten UTF-1 ).
• Darstellung aller Zeichen, einschließlich Steuerzeichen, durch mehrere Bytes (z. B. UTF-16 , UTF-32 ).
• Mischen von Bytes, bei denen das höchstwertige Bit innerhalb der codierten Darstellung für einen einzelnen Codepunkt gesetzt und nicht gesetzt ist (z. B. UTF-1, GB 18030 ).

Es existieren jedoch ISO-2022-Escape-Sequenzen zum Umschalten zwischen UTF-8 als „einem von ISO 2022 abweichenden Codierungssystem “ ^{[ 13 ]} , die von bestimmten Terminalemulatoren wie xterm unterstützt werden . ^{[ 14 ]}

ISO/IEC 2022 legt Folgendes fest:

• Eine Infrastruktur aus mehreren Zeichensätzen mit bestimmten Strukturen, die in ein einziges Zeichenkodierungssystem integriert werden können , einschließlich mehrerer grafischer Zeichensätze und mehrerer Sätze von primären (C0) und sekundären (C1) Steuercodes , ^{[ 15 ].}
• Ein Format zur Kodierung dieser Mengen, unter der Annahme, dass 8 Bit pro Byte zur Verfügung stehen, ^{[ 16 ]}
• Ein Format zur Kodierung dieser Mengen im selben Kodierungssystem, wenn nur 7 Bit pro Byte zur Verfügung stehen, ^{[ 17 ]} und eine Methode zur Transformation beliebiger konformer Zeichendaten, um sie durch eine solche 7-Bit-Umgebung zu leiten, ^{[ 8 ].}
• Die allgemeine Struktur von ANSI-Escape-Codes , ^{[ 6 ]} und
• Spezifische Escape-Code-Formate zur Identifizierung einzelner Zeichensätze ^{[ 7 ]} , zur Ankündigung der Verwendung bestimmter Kodierungsmerkmale oder -teilmengen ^{[ 18 ]} und zur Interaktion mit oder zum Wechsel zu anderen Kodierungssystemen. ^{[ 18 ]}

Eine konkrete Implementierung muss nicht den gesamten Standard umsetzen; der Konformitätsgrad und die unterstützten Zeichensätze werden durch die Implementierung definiert. Obwohl viele der im ISO/IEC-2022-Standard definierten Mechanismen selten verwendet werden, basieren mehrere etablierte Kodierungen auf einer Teilmenge des ISO/IEC-2022-Systems. ^{[ 19 ]} Zu den 7-Bit-Kodierungssystemen, die ISO/IEC-2022-Mechanismen verwenden, gehört insbesondere ISO-2022-JP (oder JIS-Kodierung ), das hauptsächlich für japanische E-Mails verwendet wird . Zu den 8-Bit-Kodierungssystemen, die ISO/IEC 2022 entsprechen, gehören ISO/IEC 4873 (ECMA-43), das wiederum von ISO/IEC 8859 [ ^{9 ] [ 10 ]} und Extended Unix Code ( EUC ⁾ konformiert wird, welches für ostasiatische Sprachen verwendet wird . ^{[ 11 ]} Zu den spezialisierteren Anwendungen von ISO 2022 gehört das MARC-8- Kodierungssystem, das in MARC 21- Bibliotheksdatensätzen verwendet wird. ^{[ 3 ]}

Die Escape-Sequenzen zum Umschalten auf bestimmte Zeichensätze oder Kodierungen sind im ISO-IR- Register eingetragen (mit Ausnahme der für den privaten Gebrauch bestimmten Sequenzen, deren Bedeutung von Herstellern oder durch Protokollspezifikationen wie ARIB STD-B24 definiert wird ) und folgen den im Standard festgelegten Mustern. Zeichenkodierungen, die diese Escape-Sequenzen verwenden, erfordern eine sequentielle Datenverarbeitung in Vorwärtsrichtung, da die korrekte Interpretation der Daten von zuvor verwendeten Escape-Sequenzen abhängt.

Bestimmte Profile wie ISO-2022-JP können zusätzliche Bedingungen festlegen, beispielsweise dass der aktuelle Zeichensatz vor dem Zeilenende auf US-ASCII zurückgesetzt wird. Darüber hinaus können die Escape-Sequenzen zur Angabe der nationalen Zeichensätze fehlen, wenn eine spezifische ISO-2022-basierte Kodierung dies zulässt oder erfordert und die Verwendung bestimmter nationaler Zeichensätze vorschreibt. ISO-8859-1 beispielsweise legt fest, dass keine definierende Escape-Sequenz erforderlich ist.

Um große Zeichensätze darzustellen, baut ISO/IEC 2022 auf der Eigenschaft von ISO/IEC 646 auf , dass eine 7-Bit-Zeichendarstellung normalerweise 94 grafische (druckbare) Zeichen (zusätzlich zu Leerzeichen und 33 Steuerzeichen) darstellen kann. Werden lediglich die (eng definierten) C0-Steuercodes ausgeschlossen, lässt sich dies auf 96 Zeichen erweitern. Mit zwei Bytes können somit bis zu 8.836 (94×94) Zeichen und mit drei Bytes bis zu 830.584 (94×94×94) Zeichen dargestellt werden. Obwohl der Standard dies vorsieht, verwendet kein registrierter Zeichensatz drei Bytes (mit Ausnahme des nicht registrierten G2-Zeichensatzes von EUC-TW und des ebenfalls nicht registrierten CCCII ).

Bei Zwei-Byte-Zeichensätzen wird der Codepunkt jedes Zeichens üblicherweise in der sogenannten Zeilen-Zellen- oder Kuten- Form ^{[ a ] angegeben. Diese besteht aus zwei Zahlen zwischen 1 und 94 (einschließlich), die die Zeile [ b ]} und die Zelle ^{[ c ]} des jeweiligen Zeichens innerhalb der Zone festlegen. Bei Drei-Byte-Zeichensätzen wird zusätzlich eine Ebenennummer ^{[ d ]} am Anfang eingefügt. ^{[ 20 ]} Die Escape-Sequenzen deklarieren nicht nur den verwendeten Zeichensatz, sondern auch, ob es sich um einen Ein-Byte- oder Mehrbyte-Zeichensatz handelt (jedoch nicht, wie viele Bytes er im Falle eines Mehrbyte-Zeichensatzes verwendet) und ob jedes Byte 94 oder 96 zulässige Werte hat.

Die ISO/IEC-2022-Codierung spezifiziert eine zweischichtige Zuordnung zwischen Zeichencodes und angezeigten Zeichen. Escape-Sequenzen ermöglichen die Zuordnung eines beliebigen Zeichensatzes aus einem großen Register grafischer Zeichensätze zu einem der vier Arbeitssätze G0 bis G3 ^{[ 21 ]} . Kürzere Steuersequenzen legen den Arbeitssatz fest, der zur Interpretation der Bytes im Datenstrom aufgerufen wird ^{[ 22 ] .}

Die Kodierung von Byte-Werten („Bitkombinationen“) erfolgt häufig in Spalten-Zeilen-Notation , wobei zwei Dezimalzahlen im Bereich 00–15 (die jeweils einer einzelnen Hexadezimalziffer entsprechen) ^{[ 23 ]} durch einen Schrägstrich getrennt werden. ^{[ 24 ]} So können beispielsweise die Codes 2/0 (0x20) bis einschließlich 2/15 (0x2F) als „Spalte 02“ bezeichnet werden. Diese Notation wird auch im ISO/IEC 2022 / ECMA-35-Standard verwendet. ^{[ 25 ]} An anderer Stelle können sie , wie in diesem Artikel häufig üblich, hexadezimal oder mit den entsprechenden ASCII-Zeichen beschrieben werden. ^{[ 26 ]} Die Escape-Sequenzen sind jedoch tatsächlich über Byte-Werte definiert, und die diesem Byte-Wert zugeordnete Grafik kann geändert werden, ohne die Steuersequenz zu beeinflussen.

Bytewerte aus dem 7-Bit-ASCII-Grafikbereich (hexadezimal 0x20–0x7F), die sich auf der linken Seite einer Zeichentabelle befinden, werden als „GL“-Codes (GL steht für „graphics left“) bezeichnet. Bytes aus dem „High-ASCII“-Bereich (0xA0–0xFF) werden, sofern verfügbar (d. h. in einer 8-Bit-Umgebung), als „GR“-Codes („graphics right“) bezeichnet . ^{[ 5 ]} Die Begriffe „CL“ (0x00–0x1F) und „CR“ (0x80–0x9F) bezeichnen die Steuerbereiche. Der CL-Bereich ruft stets die primären Steuerelemente (C0) auf, während der CR-Bereich entweder die sekundären Steuerelemente (C1) aufruft oder ungenutzt bleibt. ^{[ 5 ]}

Das Löschzeichen DEL (0x7F), das Escape-Zeichen ESC (0x1B) und das Leerzeichen SP (0x20) sind als „fest codierte“ Zeichen ^{[ 27 ]} gekennzeichnet und stehen immer zur Verfügung, wenn G0 über GL aufgerufen wird, unabhängig vom verwendeten Zeichensatz. Sie sind möglicherweise nicht in grafischen Zeichensätzen enthalten, obwohl andere Größen oder Arten von Leerzeichen enthalten sein können. ^{[ 28 ]}

Sequenzen, die das ESC-Zeichen (Escape-Zeichen) verwenden, haben die Form , wobei auf das ESC-Zeichen null oder mehr Zwischenbytes ^{[ 29 ]} ( I ) aus dem Bereich 0x20–0x2F und ein letztes Byte ^{[ 30 ]} ( F ) aus dem Bereich 0x30–0x7E folgen. ^{[ 31 ]}ESC [I...] F

Das erste Byte (I) bzw. dessen Fehlen bestimmt den Typ der Escape-Sequenz; es kann beispielsweise einen Arbeitsbereich oder eine einzelne Steuerfunktion kennzeichnen. Bei allen Arten von Escape-Sequenzen sind F Bytes im Bereich 0x30–0x3F für nicht registrierte, private Zwecke reserviert, die durch vorherige Vereinbarung zwischen den Parteien festgelegt wurden. ^{[ 32 ]}

Steuerfunktionen einiger Sätze können nach der eigentlichen Escape-Sequenz weitere Bytes verwenden. Beispielsweise folgt auf die ISO-6429 -Steuerfunktion „ Control Sequence Introducer “, die mithilfe einer Escape-Sequenz dargestellt werden kann, null oder mehr Bytes im Bereich 0x30–0x3F, dann null oder mehr Bytes im Bereich 0x20–0x2F und schließlich ein einzelnes Byte im Bereich 0x40–0x7E. Die gesamte Sequenz wird als „Steuersequenz“ bezeichnet. ^{[ 33 ]}

Jeder der vier Arbeitssätze G0 bis G3 kann ein 94-Zeichen-Satz oder ein 94 ⁿ -Zeichen- Mehrbyte-Satz sein . Zusätzlich kann G1 bis G3 ein 96- oder 96 ⁿ -Zeichen-Satz sein.

In einem 96- oder 96^ⁿ-Zeichensatz werden die Bytes 0x20 bis 0x7F (bei Aufruf durch GL) bzw. 0xA0 bis 0xFF (bei Aufruf durch GR) reserviert und können vom Zeichensatz verwendet werden. In einem 94- oder 94^ⁿ-Zeichensatz werden die Bytes 0x20 und 0x7F nicht verwendet. ^{[ 34 ]} Wird ein 96- oder 96^ⁿ-Zeichensatz im GL-Bereich aufgerufen, stehen die Leerzeichen und Löschzeichen (Codes 0x20 und 0x7F) erst zur Verfügung, nachdem ein 94- oder 94^ⁿ-Zeichensatz (z. B. der G0-Zeichensatz) im GL-Bereich aufgerufen wurde. ^{[ 5 ]} 96-Zeichensätze können nicht dem G0-Bereich zugewiesen werden.

Die Registrierung eines Zeichensatzes als 96-Zeichen-Satz bedeutet nicht zwangsläufig, dass die Bytes 0x20/A0 und 0x7F/FF tatsächlich vom Satz belegt sind. Beispiele für grafische Zeichensätze, die als 96-Zeichen-Sätze registriert sind, diese Bytes aber nicht verwenden, sind der G1-Satz von IS 434 [ ^{35 ] ,} der Box-Zeichensatz von ISO/IEC 10367 [ ^{36 ] und} ISO-IR-164 (eine Teilmenge des G1-Satzes von ISO-8859-8 , die nur Buchstaben enthält und von CCITT verwendet wird ) ^{[ 37 ] .}

Es wird erwartet, dass Zeichen als Trennzeichen und nicht als Kombinationszeichen verwendet werden, sofern im jeweiligen Grafiksatz nichts anderes festgelegt ist. ^{[ 38 ]} ISO 2022 / ECMA-35 erkennt auch die Verwendung der Steuerzeichen Rücktaste und Wagenrücklauf als Mittel zur Kombination von ansonsten trennenden Zeichen sowie die CSI-Sequenz „Graphic Character Combination“ (GCC) ^{an [ 38 ]} ( CSI 0x20 (SP) 0x5F (_)). ^{[ 39 ]}

Die Verwendung der Rücktaste und des Wagenrücklaufs auf diese Weise ist gemäß ISO/IEC 646 zulässig , jedoch gemäß ISO/IEC 4873 / ECMA-43 ^{[ 40 ]} und ISO/IEC 8859 [ ^{41 ] [ 42 ] untersagt ,} da dadurch das grafische Zeichenrepertoire nicht definiert wird. ISO/IEC 4873 / ECMA-43 erlaubt jedoch die Verwendung der GCC-Funktion, sofern die Zeichenfolge unverändert bleibt und lediglich in einem einzigen Leerzeichen angezeigt wird, anstatt durch Überschreiben ein Zeichen mit anderer Bedeutung zu erzeugen. ^{[ 43 ]}

Steuerzeichensätze werden in „primäre“ und „sekundäre“ Steuerzeichensätze unterteilt, ^{[ 44 ]} die auch als „C0“- bzw. „C1“-Steuerzeichensätze bezeichnet werden. ^{[ 45 ]}

Ein C0-Steuersatz muss das ESC-Steuerzeichen (Escape-Zeichen) an Adresse 0x1B enthalten ^{[ 46 ]} (ein C0-Satz, der nur ESC enthält, ist als ISO-IR-104 registriert), ^{[ 47 ]} während ein C1-Steuersatz das Escape-Steuerzeichen überhaupt nicht enthalten darf. ^{[ 34 ]} Daher handelt es sich um völlig separate Registrierungen, wobei ein C0-Satz nur ein C0-Satz und ein C1-Satz nur ein C1-Satz ist. ^{[ 45 ]}

Wenn Codes aus dem C0-Zeichensatz von ISO 6429/ECMA-48, d. h. die ASCII-Steuercodes , im C0-Zeichensatz vorkommen, müssen sie an ihren entsprechenden Positionen gemäß ISO 6429/ECMA-48 erscheinen. ^{[ 46 ]} Die Aufnahme von Übertragungssteuerzeichen in den C0-Zeichensatz, zusätzlich zu den zehn in ISO 6429/ECMA-48 definierten Zeichen (nämlich SOH, STX, ETX, EOT, ENQ, ACK, DLE, NAK, SYN und ETB), ^{[ 48 ]} oder die Aufnahme eines dieser zehn Zeichen in den C1-Zeichensatz ist gemäß der Norm ISO/IEC 2022/ECMA-35 ebenfalls untersagt. ^{[ 46 ] [ 34 ]}

Ein C0-Steuersatz wird über den CL-Bereich 0x00 bis 0x1F aufgerufen ^{[ 49 ]} , während eine C1-Steuerfunktion über den CR-Bereich 0x80 bis 0x9F (in einer 8-Bit-Umgebung) oder mittels Escape-Sequenzen (in einer 7-Bit- oder 8-Bit-Umgebung) aufgerufen werden kann ^{[ 44 ]} , jedoch nicht beides gleichzeitig. Welche Art des C1-Aufrufs verwendet wird, muss in der Definition der Codeversion angegeben werden ^{[ 50 ]} . Beispielsweise spezifiziert ISO/IEC 4873 CR-Bytes für die verwendeten C1-Steuersätze (SS2 und SS3) ^{[ 51 ]} . Bei Bedarf kann die verwendete Aufrufart mithilfe von Ansagesequenzen kommuniziert werden .

Im letzteren Fall werden einzelne Steuerfunktionen aus dem Steuercodesatz C1 mithilfe von Escape-Sequenzen vom Typ Fe aufgerufen, ^{[ 34 ]} d. h. solchen, bei denen dem Steuerzeichen ESC ein Byte aus den Spalten 04 oder 05 folgt (d. h. bis ESC 0x40 (@)einschließlich ESC 0x5F (_)). ^{[ 52 ]}

Zusätzliche Steuerfunktionen werden Escape-Sequenzen vom Typ „Fs“ (im Bereich ESC 0x60 (`)von 1 bis 2 ESC 0x7E (~)) zugeordnet; diese haben eine fest zugewiesene Bedeutung und sind nicht von den Bezeichnungen C0 oder C1 abhängig. ^{[ 52 ] [ 53 ]} Die Registrierung von Steuerfunktionen für Sequenzen vom Typ „Fs“ muss von ISO/IEC JTC 1/SC 2 genehmigt werden . ^{[ 53 ]} Andere einzelne Steuerfunktionen können Escape-Sequenzen vom Typ „3Ft“ (im Bereich von 1 bis 2 ) zugeordnet werden, ^{[ 54 ]} obwohl derzeit (Stand 2019) keine „3Ft“-Sequenzen zugewiesen sind. ^{[ 55 ]} Einige davon sind in ECMA-35 (ISO 2022 / ANSI X3.41), andere in ECMA-48 (ISO 6429 / ANSI X3.64) spezifiziert. ^{[ 56 ]} ECMA-48 bezeichnet diese als „unabhängige Steuerfunktionen“. ^{[ 57 ]}ESC 0x23 (#) [I...] 0x40 (@)ESC 0x23 (#) [I...] 0x7E (~)

Escape-Sequenzen vom Typ „Fp“ ( ESC 0x30 (0)bis ESC 0x3F (?)) oder vom Typ „3Fp“ ( bis ) sind nach vorheriger Vereinbarung zwischen den Parteien für individuelle, private Steuercodes reserviert. ^{[ 59 ]} Mehrere solcher Sequenzen beider Typen werden von DEC- Terminals wie dem VT100 verwendet und werden daher von Terminalemulatoren unterstützt . ^{[ 14 ]}ESC 0x23 (#) [I...] 0x30 (0)ESC 0x23 (#) [I...] 0x3F (?)

Standardmäßig geben GL-Codes G0-Zeichen und GR-Codes (sofern verfügbar) G1-Zeichen an; dies kann nach vorheriger Vereinbarung abweichen. Der für jeden Bereich aufgerufene Satz kann auch mit Steuercodes, sogenannten Verschiebungen, modifiziert werden, wie in der folgenden Tabelle dargestellt. ^{[ 60 ]}

Ein 8-Bit-Code kann GR-Codes enthalten, die G1-Zeichen spezifizieren, wobei der zugehörige 7-Bit-Code Shift In und Shift Out verwendet , um zwischen den Zeichensätzen umzuschalten (z. B. JIS X 0201 ) ^{[ 61 ].} Einige Codes verwenden stattdessen GR-Codes, die G2-Zeichen spezifizieren, wobei der zugehörige 7-Bit-Code einen einfachen Shift-Code verwendet, um auf den zweiten Zeichensatz zuzugreifen (z. B. T.51 ) ^{[ 62 ] .}

Die in der folgenden Tabelle aufgeführten Codes sind die gebräuchlichsten Kodierungen dieser Steuercodes gemäß ISO/IEC 6429. Die Shift-Funktionen LS2, LS3, LS1R, LS2R und LS3R sind als einzelne Steuerfunktionen registriert und werden stets mit den unten aufgeführten Escape-Sequenzen kodiert ^{[ 55 ]} . Die übrigen Funktionen sind Teil eines C0- oder C1-Steuercodesatzes (wie unten dargestellt, sind SI (LS0) und SO (LS1) C0-Steuerfunktionen und SS2 und SS3 C1-Steuerfunktionen). Das bedeutet, dass ihre Kodierung und Verfügbarkeit je nach den verwendeten Steuercodesätzen variieren können: Sie müssen in den jeweiligen Steuercodesätzen vorhanden sein, wenn ihre Funktionalität genutzt wird. ^{[ 49 ] [ 50 ]} Die C1-Steuerfunktionen selbst können, wie bereits erwähnt, mit Escape-Sequenzen oder 8-Bit-Bytes dargestellt werden, jedoch nicht mit beidem.

Alternative Kodierungen der Einzelverschiebungen als C0-Steuercodes sind in bestimmten Steuercodesätzen verfügbar. Beispielsweise sind SS2 und SS3 in T.51 ^{[ 62 ]} und T.61 ^{[ 63 ]} üblicherweise unter 0x19 bzw. 0x1D verfügbar . Diese Kodierung wird derzeit von ISO/IEC 2022/ECMA-35 für Anwendungen empfohlen, die 7-Bit-Einzelbyte-Darstellungen von SS2 und SS3 benötigen ^{[ 64 ]} , und kann auch nur für SS2 verwendet werden ^{[ 65 ].} Es existieren jedoch auch ältere Codesätze mit SS2 unter 0x1C ^{[ 66 ] [ 67 ] [ 68 ]} , die in einer früheren Ausgabe des Standards als solche erwähnt wurden ^{[ 69 ]} . Die unten dargestellte Kodierung der Einzelverschiebungen unter 0x8E und 0x8F ist für ISO/IEC 4873 Level 2 und 3 obligatorisch ^{[ 70 ].}

Obwohl sie offiziell als Shift-Codes gelten und entsprechend benannt sind, werden Single-Shift-Codes nicht immer als Shifts betrachtet ^{[ 12 ]} , sondern können einfach als Präfixbytes (d. h. die ersten Bytes einer Mehrbytesequenz) angesehen werden ^{[ 11 ]} , da sie im Gegensatz zu Locking-Shift-Codes nicht erfordern, dass der Encoder den aktuell aktiven Satz als Zustand speichert . In 8-Bit-Umgebungen kann entweder GL oder GR, aber nicht beide, als Single-Shift-Bereich verwendet werden. Dies muss in der Definition der Codeversion angegeben werden ^{[ 73 ]} . Beispielsweise spezifiziert ISO/IEC 4873 GL, während Packed EUC GR spezifiziert. In 7-Bit-Umgebungen wird ausschließlich GL als Single-Shift-Bereich verwendet ^{[ 75 ] [ 76 ]} . Bei Bedarf kann der verwendete Single-Shift-Bereich mithilfe von Ansagesequenzen kommuniziert werden .

Die Bezeichnungen „Locking Shift Zero“ (LS0) und „Locking Shift One“ (LS1) beziehen sich auf dasselbe Paar von C0-Steuerzeichen (0x0F und 0x0E) wie die Bezeichnungen „Shift In“ (SI) und „Shift Out“ (SO). Im Standard werden sie jedoch als LS0 und LS1 bezeichnet, wenn sie in 8-Bit-Umgebungen verwendet werden, und als SI und SO, wenn sie in 7-Bit-Umgebungen verwendet werden. ^{[ 60 ]}

Der Standard ISO/IEC 2022 / ECMA-35 erlaubt zwar die gleichzeitige Verwendung von G1, G2 oder G3 in GL und GR, rät aber davon ab. ^{[ 77 ]}

Das internationale ISO-Register für codierte Zeichensätze zur Verwendung mit Escape-Sequenzen (ISO-IR) listet grafische Zeichensätze, Steuerzeichensätze, einzelne Steuerzeichen usw. auf, die für die Verwendung mit ISO/IEC 2022 registriert wurden. Das Verfahren zur Registrierung von Codes und Sätzen im ISO-IR-Register ist in ISO/IEC 2375 spezifiziert . Jede Registrierung erhält eine eindeutige Escape-Sequenz und eine eindeutige Registereintragsnummer zur Identifizierung. ^{[ 78 ] [ 79 ]} Beispielsweise ist der CCITT- Zeichensatz für vereinfachtes Chinesisch als ISO-IR-165 bekannt .

Die Registrierung codierter Zeichensätze im ISO-IR-Register kennzeichnet die Dokumente, die den Zeichensatz oder die Steuerfunktion einer ISO/IEC 2022-Escape-Sequenz für den nicht-privaten Gebrauch spezifizieren. Es kann sich dabei um ein Standarddokument handeln; die Registrierung führt jedoch nicht zur Schaffung eines neuen ISO-Standards, verpflichtet weder ISO noch IEC zur Übernahme als internationalen Standard und verpflichtet auch nicht ISO oder IEC zur Aufnahme ihrer Zeichen in den Universal Coded Character Set (UCS) . ^{[ 80 ]}

ISO-IR-registrierte Escape-Sequenzen werden auch in einem formalen öffentlichen Bezeichner (FPI) gekapselt, um Zeichensätze für numerische Zeichenreferenzen in SGML (ISO 8879) zu identifizieren. Beispielsweise ISO 646-1983//CHARSET International Reference Version (IRV)//ESC 2/5 4/0kann die Zeichenkette zur Identifizierung der Internationalen Referenzversion von ISO 646-1983 verwendet werden ^{[ 81 ]} , und die HTML- 4.01-Spezifikation verwendet sie zur Identifizierung von Unicode ^{[ 82 ]}ISO Registration Number 177//CHARSET ISO/IEC 10646-1:1993 UCS-4 with implementation level 3//ESC 2/5 2/15 4/6 . Die textuelle Darstellung der Escape-Sequenz, die im dritten Element des FPI enthalten ist, wird von SGML-Implementierungen für unterstützte Zeichensätze erkannt ^{[ 81 ] .}

Escape-Sequenzen zur Kennzeichnung von Zeichensätzen haben die Form <Zeichensatz> . Wie bereits erwähnt, liegen die Zwischenbytes ( I ) im Bereich von 0x20 bis 0x2F und das letzte Byte ( F ) im Bereich von 0x30 bis 0x7E. Das erste I- Byte (bzw. bei einem Mehrbyte-Zeichensatz die ersten beiden) identifiziert den Typ des Zeichensatzes und den zugehörigen Arbeitssatz, während das F- Byte (und alle weiteren I- Bytes) den Zeichensatz selbst identifiziert, wie er im ISO-IR-Register (oder bei Escape-Sequenzen für den privaten Gebrauch gemäß vorheriger Vereinbarung) festgelegt ist. ESC I [I...] F

Um den Bereich des F- Bytes zu erweitern, können zusätzliche I- Bytes vor dem F -Byte eingefügt werden . Dies wird derzeit nur bei 94-Zeichensätzen verwendet, denen Codes der Form ^{[ 83 ]} zugewiesen wurden. Im anderen Extremfall sind keine Multibyte-96-Zeichensätze registriert, daher sind die folgenden Sequenzen rein theoretischer Natur. ESC ( ! F

Wie bei anderen Escape-Sequenzen ist der Bereich 0x30–0x3F für private F- Bytes reserviert ^{[ 32 ]} , in diesem Fall für private Zeichensatzdefinitionen (einschließlich nicht registrierter Sätze, die durch Protokolle wie ^ARIB STD-B24 ^{[ 84 ]} oder MARC-8 [ ^{3 ]} oder herstellerspezifische Sätze wie DEC Special Graphics definiert sind ) ^{[ 85 ]} . Ist in einer grafischen Zeichensatzbezeichnungssequenz das zweite I- Byte (bei einem Ein-Byte-Satz) oder das dritte I- Byte (bei einem Doppel-Byte-Satz) jedoch 0x20 (Leerzeichen), handelt es sich bei dem bezeichneten Satz um einen „ dynamisch neu definierbaren Zeichensatz “ (DRCS), der durch vorherige Vereinbarung definiert wurde ^{[ 86 ]} und ebenfalls als privat gilt ^{[ 32 ]} . Ein grafischer Zeichensatz, der als DRCS gilt, repräsentiert eine Schriftart mit exakten Glyphen und nicht einen Satz abstrakter Zeichen. ^{[ 87 ]} Die Art und Weise, wie DRCS-Sätze und zugehörige Schriftarten übertragen, zugewiesen und verwaltet werden, ist in ISO/IEC 2022 / ECMA-35 selbst nicht festgelegt, obwohl empfohlen wird, sie sequenziell ab Byte 0x40 ( ) zuzuweisen ; [ @88 ^{] jedoch ist} in einigen Telekommunikationsprotokollen wie World System Teletext eine Methode zur Übertragung von DRCS-Schriftarten definiert . ^{[ 89 ]}

Es gibt außerdem drei Sonderfälle für Mehrbyte-Codes. Die Codesequenzen ESC $ @, ESC $ A, und ESC $ Bwurden alle registriert, als die damalige Version des Standards Mehrbyte-Sätze nur in G0 zuließ, daher müssen sie anstelle der Sequenzen ESC $ ( @bis akzeptiert werden ESC $ ( B, um den G0-Zeichensatz zu kennzeichnen. ^{[ 90 ]}

Es gibt zusätzliche (selten genutzte) Funktionen zum Umschalten von Steuerzeichensätzen. Dabei handelt es sich jedoch um eine einstufige Suche, da (wie bereits erwähnt) der C0-Satz immer über CL und der C1-Satz immer über CR oder mithilfe von Escape-Sequenzen aufgerufen wird. Wie bereits erwähnt, muss jeder C0-Zeichensatz das ESC-Zeichen an Position 0x1B enthalten, um weitere Änderungen zu ermöglichen. Die Bezeichnungssequenzen für Steuerzeichensätze (im Gegensatz zu den grafischen Sequenzen) können auch innerhalb von ISO/IEC 10646 (UCS/Unicode) verwendet werden, sofern die Verarbeitung von ANSI-Escape-Sequenzen sinnvoll ist und jedes Byte der Sequenz auf die Codeeinheitsgröße der Kodierung aufgefüllt wird. ^{[ 91 ]}

Nachfolgend ist eine Tabelle der Escape-Sequenz- I- Bytes und ihrer jeweiligen Bezeichnung oder Funktion aufgeführt. ^{[ 92 ]}

Beachten Sie, dass die Registrierung der F-ESC ( A Bytes für die verschiedenen Typen unabhängig ist. Der mit 94 bis 96 bezeichnete Grafikzeichensatz steht in keinerlei Beziehung zum mit 96 bis 96 ESC + Abezeichneten Zeichensatz . Und keiner dieser beiden steht in Beziehung zum mit 94 bis ⁿ bezeichneten Zeichensatz usw.; die letzten Bytes müssen im Kontext interpretiert werden. (Tatsächlich ist die Angabe des C1-Steuercodes 0x81 ohne Zwischenbytes möglich.)ESC - AESC / AESC $ ( AESC $ + AESC A

Beachten Sie außerdem, dass die Steuerzeichensätze C0 und C1 unabhängig sind; der durch bezeichnete Steuerzeichensatz C0 ESC ! A(der zufällig der NATS-Steuerzeichensatz für die Übertragung von Zeitungstexten ist) ist nicht derselbe wie der durch bezeichnete Steuerzeichensatz C1 ESC " A(der CCITT -Attributsteuerzeichensatz für Videotex ).

Der Standard definiert auch eine Möglichkeit, Codierungssysteme zu spezifizieren, die nicht seiner eigenen Struktur folgen.

Für die Rückkehr zu ISO/IEC 2022 ist eine Sequenz definiert; die Registrierungen, die diese Sequenz gemäß ISO/IEC 2022 unterstützen, umfassen (Stand 2019) verschiedene Videotex- Formate, UTF-8 und UTF-1 . ^{[ 100 ]} Ein zweites Byte vom Typ 0x2F /ist in den Bezeichnungssequenzen von Codes enthalten, die diese Byte-Sequenz nicht für die Rückkehr zu ISO 2022 verwenden; diese können eigene Mechanismen für die Rückkehr zu ISO 2022 (z. B. eine andere oder aufgefüllte Sequenz) oder gar keine verwenden. ^{[ 101 ]} Alle bestehenden Registrierungen des letztgenannten Typs (Stand 2019) sind entweder transparente Rohdaten, Unicode/UCS-Formate oder Teilmengen davon. ^{[ 102 ]}

Von besonderem Interesse sind die Sequenzen, die auf ISO/IEC 10646 ( Unicode )-Formate umstellen, welche nicht der ISO/IEC 2022-Struktur entsprechen. Dazu gehören UTF-8 (das den Bereich 0x80–0x9F nicht für Steuerzeichen reserviert), sein Vorgänger UTF-1 (das GR- und GL-Bytes in Mehrbytecodes mischt) sowie UTF-16 und UTF-32 (die breitere Codierungseinheiten verwenden). ^{[ 100 ] [ 102 ]}

Für Teilmengen (Level 1 und 2) von UTF-8, UTF-16 und UTF-32 sowie für drei Level von UCS-2 wurden mehrere Codes registriert . ^{[ 102 ]} Allerdings sind in ISO/IEC 10646 derzeit nur die Level-3-Codes für UTF-8, UTF-16 und UTF-32 sowie der nicht spezifizierte Level-Code für UTF-8 spezifiziert; alle anderen gelten als veraltet. ^{[ 104 ]} ISO/IEC 10646 legt fest, dass die Big-Endian- Formate von UTF-16 und UTF-32 durch ihre Escape-Sequenzen gekennzeichnet werden. ^{[ 105 ]}

Von den Sequenzen, die auf UTF-8 umstellen, ESC % Gist dies diejenige, die beispielsweise von xterm unterstützt wird . ^{[ 14 ]}

Obwohl die Verwendung einer Variante der Standardrückgabesequenz von UTF-16 und UTF-32 zulässig ist, müssen die Bytes der Escape-Sequenz auf die Größe der Codeeinheit der Kodierung (d. h. 001B 0025 0040für UTF-16) aufgefüllt werden, d. h. die Kodierung der Standardrückgabesequenz entspricht nicht exakt ISO/IEC 2022. Aus diesem Grund verwenden die Bezeichnungen für UTF-16 und UTF-32 eine Syntax ohne Standardrückgabe. ^{[ 108 ]}

Zur Spezifizierung von Kodierungen durch Labels definiert das Compound Text- Format des X-Konsortiums fünf DOCS-Sequenzen für den privaten Gebrauch. ^{[ 109 ]}

Die Sequenz „announce code structure“ ( ) dient zur Ankündigung einer spezifischen Codestruktur oder einer bestimmten Gruppe von ISO-2022-Einrichtungen, die in einer bestimmten Codeversion verwendet werden. Obwohl Ankündigungen kombiniert werden können, sind bestimmte widersprüchliche Kombinationen (insbesondere die Verwendung der Locking-Shift-Ankündigungen 16–23 mit den Ankündigungen 1, 3 und 4) gemäß der Norm verboten. Ebenso ist die Verwendung zusätzlicher Ankündigungen über die ISO/IEC-4873 -Ankündigungen 12–14 ^{[ 93 ]} hinaus untersagt (welche die zulässigen Strukturmerkmale vollständig spezifizieren). Die Ankündigungssequenzen lauten wie folgt: ESC SP (0x20) F

Sechs 7-Bit-ISO-2022-Codeversionen (ISO-2022-CN, ISO-2022-CN-EXT, ISO-2022-JP, ISO-2022-JP-1, ISO-2022-JP-2 und ISO-2022-KR) sind in den IETF RFCs definiert , von denen ISO-2022-JP und ISO-2022-KR in der Vergangenheit weit verbreitet waren. ^{[ 110 ]} Zahlreiche weitere Varianten werden von verschiedenen Herstellern, darunter IBM , definiert . ^{[ 111 ]} Obwohl UTF-8 die bevorzugte Kodierung in HTML5 ist , ist der ältere Inhalt in ISO-2022-JP noch so weit verbreitet, dass der WHATWG -Kodierungsstandard ihn weiterhin unterstützt. ^{[ 112 ]} Im Gegensatz dazu werden ISO-2022-KR, ISO-2022-CN und ISO-2022-CN-EXT ^{[ 113 ]} aufgrund von Bedenken hinsichtlich Code-Injection- Angriffen wie Cross-Site-Scripting ^vollständig auf das Ersatzzeichen abgebildet . [ ^{114 ] [ 112 ] [ 114 ]}

Zu den 8-Bit-Codeversionen gehört der erweiterte Unix-Code . ^{[ 11 ] [ 12 ]} Die ISO/IEC-8859 -Kodierungen folgen ebenfalls ISO 2022, und zwar in einer in ISO/IEC 4873 festgelegten Teilmenge. ^{[ 9 ] [ 10 ]}

ISO-2022-JP ist eine weit verbreitete Kodierung für Japanisch, insbesondere inE-Mails. Sie wurde für die Verwendung im JUNET-Netzwerk eingeführt und später inIETF RFC1468 von 1993 kodifiziert. ^{[ 115 ]} Sie hat gegenüber anderenKodierungen für Japanisch, dass sie keine8-Bit-Übertragung ohne Datenverlust erfordert. Microsoft bezeichnet sie alsCodepage 50220.[ ^{116 ] Sie} beginnt mit ASCII und enthält die folgenden Escape-Sequenzen:

• ESC ( Bauf ASCII umschalten (1 Byte pro Zeichen)
• ESC ( JUmstellung auf JIS X 0201-1976 (ISO/IEC 646:JP) Roman-Zeichensatz (1 Byte pro Zeichen)
• ESC $ @auf JIS X 0208-1978 (2 Bytes pro Zeichen) umstellen
• ESC $ Bauf JIS X 0208-1983 (2 Bytes pro Zeichen) umstellen

Die Verwendung der beiden in JIS X 0208-1990 hinzugefügten Zeichen ist zulässig, jedoch ohne Einbeziehung der IRR-Sequenz, d. h. unter Verwendung derselben Escape-Sequenz wie in JIS X 0208-1983. ^{[ 115 ]} Da die Registrierung vor der Möglichkeit erfolgte, Mehrbyte-Sets mit Ausnahme von G0 zu kennzeichnen, enthalten die Escape-Sequenzen für JIS X 0208 das zweite I -Byte nicht (. ^{[ 90 ]}

Der RFC merkt an, dass einige bestehende Systeme nicht ESC ( Bzwischen ESC ( J`\` und `\` unterschieden, legt aber fest, dass die Escape-Sequenzen von Systemen, die lediglich Nachrichten wie E-Mails weiterleiten, nicht geändert werden sollten. ESC $ @[ ^{115 ] Der} von HTML5 referenzierte WHATWG -Codierungsstandard behandelt `\` und `\` unterschiedlich, behandelt `\` beim Decodieren jedoch gleich wie `\` und verwendet `\` beim Codieren ausschließlich für JIS X 0208. ^{[ 117 ]} Der RFC merkt außerdem an, dass einige ältere Systeme die Sequenz fälschlicherweise verwendet haben, um von JIS X 0208 wegzuschalten, welches tatsächlich für ISO-IR-11 (eine schwedische Variante von ISO 646 und World System Teletext ) registriert ist. ^{[ 115 ] [ i ]}ESC $ BESC ( BESC ( JESC $ @ESC $ BESC $ BESC ( H

Die Verwendung von ESC ( I`to` zum Umschalten auf den Kana-Zeichensatz JIS X 0201-1976 (1 Byte pro Zeichen) ist nicht Teil des ISO-2022-JP-Profils ^{[ 115 ]} , wird aber dennoch gelegentlich verwendet. Python erlaubt dies in einer Variante namens ISO-2022-JP-EXT (die, wie unten beschrieben, auch JIS X 0212 enthält und somit EUC-JP vollständig abdeckt ) ^{[ 118 ] [ 119 ].} Diese ähnelt sowohl im Namen als auch in der Struktur einer von DEC als ISO-2022-JPext bezeichneten Kodierung, die zusätzlich einen benutzerdefinierten Zwei-Byte-Bereich hinzufügt, auf den mit `to` zugegriffen wird , um die Abdeckung von Super DEC Kanji zu vervollständigen ^{[ 120 ]} . Die WHATWG/HTML5-Variante erlaubt das Dekodieren von JIS X 0201 Katakana in ISO-2022-JP-Eingaben, konvertiert die Zeichen jedoch beim Kodieren in ihre JIS X 0208-Äquivalente. ^{[ 117 ]} Die Microsoft-Codepage für ISO-2022-JP mit zusätzlich zulässigen JIS X 0201 Kana ist die Codepage 50221. ^{[ 116 ]}ESC $ ( 0

Andere, ältere Varianten, bekannt als JIS7 ​​und JIS8, basieren direkt auf den 7-Bit- und 8-Bit-Kodierungen von JIS X 0201 und ermöglichen die Verwendung von JIS X 0201-Kana ab G1 ohne Escape-Sequenzen, indem sie Shift Out und Shift In bzw. das achte Bit (GR-aufgerufen) verwenden. ^{[ 121 ]} Sie sind nicht weit verbreitet; ^{[ 121 ]} Die Unterstützung von JIS X 0208 in erweitertem 8-Bit-JIS X 0201 wird üblicherweise über Shift JIS erreicht . Die Codepage von Microsoft für JIS X 0201-basiertes ISO 2022 mit Einzelbyte-Katakana über Shift Out und Shift In ist die Codepage 50222. ^{[ 116 ]}

ISO-2022-JP-2 ist eine mehrsprachige Erweiterung von ISO-2022-JP, definiert in RFC 1554 (von 1993), die zusätzlich zu den ISO-2022-JP-Sequenzen die folgenden Escape-Sequenzen zulässt. DieISO/IEC-8859-Teile sind 96-Zeichen-Sätze, die nicht G0 zugewiesen werden können und über G2 mit der 7-Bit-Escape-Sequenzform des Single-Shift-Codes SS2 aufgerufen werden: ^{[ 122 ]}

• ESC $ AUmstellung auf GB 2312-1980 (2 Bytes pro Zeichen)
• ESC $ ( CUmstellung auf KS X 1001-1992 (2 Bytes pro Zeichen)
• ESC $ ( DUmstellung auf JIS X 0212-1990 (2 Bytes pro Zeichen)
• ESC . AUmstellung auf ISO/IEC 8859-1 High Part, Extended Latin 1 Set (1 Byte pro Zeichen) [bezeichnet als G2]
• ESC . FUmstellung auf ISO/IEC 8859-7 High Part, Basic Greek Set (1 Byte pro Zeichen) [bezeichnet als G2]

ISO-2022-JP mit der ISO-2022-JP-2-Darstellung von JIS X 0212, jedoch ohne die anderen Erweiterungen, wurde anschließend durch RFC 2237 aus dem Jahr 1997 als ISO-2022-JP-1 bezeichnet. ^{[ 123 ]}

IBM implementiert neun 7-Bit-Kodierungen auf Basis von ISO 2022 für Japanisch, die jeweils unterschiedliche Escape-Sequenzen verwenden: IBM-956, IBM-957, IBM-958, IBM-959, IBM-5052, IBM-5053, IBM-5054, IBM-5055 und ISO-2022-JP. Diese werden zusammenfassend als „TCP/IP-Zeichensätze für Japanisch“ bezeichnet. ^{[ 124 ]} Die Standardkodierung ISO-2022-JP ist gemäß RFC 1468 unter der CCSID 9148 definiert. ^{[ 125 ]}

Der erstmals im Jahr 2000 veröffentlichte Standard JIS X 0213 definiert eine aktualisierte Version von ISO-2022-JP ohne die Erweiterungen ISO-2022-JP-2, genannt ISO-2022-JP-3 . Die Ergänzungen von JIS X 0213 gegenüber dem Basisstandard JIS X 0208 führten zu einer neuen Registrierung für die erweiterte JIS-Ebene 1, während die neue Ebene 2 eine eigene Registrierung erhielt. Die weiteren Ergänzungen der Ebene 1 in der Ausgabe von 2004 führten zu einer zusätzlichen Registrierung für eine weitere Überarbeitung des Profils, genannt ISO-2022-JP-2004 . Neben den grundlegenden ISO-2022-JP-Bezeichnungscodes werden die folgenden Bezeichnungen anerkannt:

• ESC ( IUmstellung auf JIS X 0201-1976 Kana-Satz (1 Byte pro Zeichen)
• ESC $ ( OUmstellung auf JIS X 0213-2000 Ebene 1 (2 Bytes pro Zeichen)
• ESC $ ( PUmstellung auf JIS X 0213-2000 Ebene 2 (2 Bytes pro Zeichen)
• ESC $ ( QUmstellung auf JIS X 0213-2004 Ebene 1 (2 Bytes pro Zeichen, nur ISO-2022-JP-2004)

ISO-2022-KR ist in RFC 1557 von 1993 definiert. ^{[ 134 ]} Es kodiert ASCII und das koreanische DoppelbyteKS X 1001-1992[ ^{135 ] [ 136 ] ,} das früher KS C 5601-1987 hieß. Im Gegensatz zu ISO-2022-JP-2 verwendet es dieZeichen Shift Out und Shift Inzum Umschalten zwischen den Zeichensätzen, nachdem esESC $ ) Ceinmalig am Zeilenanfang eingefügt wurde, um KS X 1001 bis G1 zu kennzeichnen. ^{[ 134 ]}

ISO-2022-CN undISO-2022-CN-EXT sind in RFC 1922 von 1996 definiert. Es handelt sich um 7-Bit-Kodierungen, die sowohl die Shift-Out- als auch die Shift-In-Funktionen (zum Verschieben zwischen G0 und G1) sowie die 7-Bit-Escape-Codes der Einzelverschiebungsfunktionen SS2 und SS3 (zum Zugriff auf G2 und G3) verwenden. ^{[ 137 ]} Sie unterstützen die ZeichensätzeGB 2312(fürvereinfachtes Chinesisch) undCNS 11643(fürtraditionelles Chinesisch).

Das Basisprofil ISO-2022-CN verwendet ASCII als G0-Zeichensatz (Shift-In) und enthält außerdem GB 2312 und die ersten beiden Ebenen von CNS 11643 (da diese beiden Ebenen ausreichen, um alle traditionellen chinesischen Zeichen aus dem gemeinsamen Big5 darzustellen , zu dem der RFC in einem Anhang eine Entsprechung bereitstellt): ^{[ 137 ]}

• ESC $ ) AUmstellung auf GB 2312-1980 (2 Bytes pro Zeichen) [bezeichnet als G1]
• ESC $ ) GUmschaltung auf CNS 11643-1992 Ebene 1 (2 Bytes pro Zeichen) [bezeichnet als G1]
• ESC $ * HUmschaltung auf CNS 11643-1992 Ebene 2 (2 Bytes pro Zeichen) [bezeichnet als G2]

Das ISO-2022-CN-EXT-Profil erlaubt die folgenden zusätzlichen Sätze und Ebenen. ^{[ 137 ]}

• ESC $ ) EUmstellung auf ISO-IR-165 (2 Bytes pro Zeichen) [G1 zugeordnet]
• ESC $ + IUmschaltung auf CNS 11643-1992 Ebene 3 (2 Bytes pro Zeichen) [bezeichnet als G3]
• ESC $ + JUmschaltung auf CNS 11643-1992 Ebene 4 (2 Bytes pro Zeichen) [bezeichnet als G3]
• ESC $ + KUmschaltung auf CNS 11643-1992 Ebene 5 (2 Bytes pro Zeichen) [bezeichnet als G3]
• ESC $ + LUmschaltung auf CNS 11643-1992 Ebene 6 (2 Bytes pro Zeichen) [bezeichnet als G3]
• ESC $ + MUmschaltung auf CNS 11643-1992 Ebene 7 (2 Bytes pro Zeichen) [bezeichnet für G3]

Das ISO-2022-CN-EXT-Profil listet darüber hinaus weitere grafische Zeichensätze nach Guobiao-Standard auf , die zulässig sind, jedoch nur unter der Bedingung, dass ihnen registrierte ISO 2022-Escape-Sequenzen zugewiesen werden: ^{[ 137 ]}

• GB 12345 in G1
• GB 7589 oder GB 13131 in G2
• GB 7590 oder GB 13132 in G3

Das Zeichen nach dem Komma ESC(bei Einbyte-Zeichensätzen) bzw. dem Komma ESC $(bei Mehrbyte-Zeichensätzen) gibt den Typ des Zeichensatzes und des zugehörigen Arbeitssatzes an. In den obigen Beispielen (kennzeichnet das Zeichen (0x28) einen 94-Zeichen-Zeichensatz für den G0-Zeichensatz, während )das *Komma +(0x29–0x2B) die Zeichensätze G1–G3 kennzeichnet.

ISO-2022-KR und ISO-2022-CN werden seltener verwendet als ISO-2022-JP und werden aufgrund von Sicherheitsbedenken teilweise bewusst nicht unterstützt. Der von HTML5 verwendete WHATWG- Codierungsstandard ordnet ISO-2022-KR, ISO-2022-CN und ISO-2022-CN-EXT (sowie HZ-GB-2312 ) dem „Ersetzungs“-Decoder zu ^{[ 113 ]} , der alle Eingaben auf das Ersetzungszeichen (�) umwandelt. Dies dient der Verhinderung bestimmter Cross-Site-Scripting- Angriffe und ähnlicher Angriffe, die Unterschiede in der Codierungsunterstützung zwischen Client und Server ausnutzen. ^{[ 114 ]} Obwohl die gleiche Sicherheitsbedenken (unterschiedliche Interpretation von ASCII-Byte-Sequenzen) auch für ISO-2022-JP und UTF-16 gelten , konnten diese aufgrund ihrer deutlich häufigeren Verwendung in bereitgestellten Inhalten nicht so behandelt werden. ^{[ 112 ]}

Im April 2024 wurde eine Sicherheitslücke ^{[ 138 ]} in der Implementierung von ISO-2022-CN-EXT in glibc entdeckt , was zu Empfehlungen führte, die Kodierung auf Linux-Systemen vollständig zu deaktivieren. ^{[ 139 ]}

Eine Teilmenge von ISO 2022, angewendet auf 8-Bit-Einzelbyte-Codierungen, ist in ISO/IEC 4873 definiert , das auch von Ecma International als ECMA-43 veröffentlicht wurde. ISO/IEC 8859 definiert 8-Bit-Codes für ISO/IEC 4873 (oder ECMA-43) Level 1. ^{[ 9 ] [ 10 ]}

ISO/IEC 4873 / ECMA-43 definiert drei Kodierungsebenen: ^{[ 140 ]}

• Ebene 1 umfasst den Zeichensatz C0, den ASCII-Zeichensatz G0, einen optionalen Zeichensatz C1 und einen optionalen Einzelbyte-Zeichensatz G1 (94 oder 96 Zeichen). G0 wird über GL und G1 über GR aufgerufen. Die Verwendung von Schiebefunktionen ist nicht zulässig.
• Level 2 umfasst neben einem obligatorischen G1-Satz einen (94 oder 96 Zeichen langen) Einzelbyte-G2- und/oder G3-Satz. Zulässig sind ausschließlich die Einzelverschiebungsfunktionen SS2 und SS3 (d. h. Sperrverschiebungen sind verboten). Sie greifen auf den GL-Bereich zu (einschließlich 0x20 und 0x7F im Fall eines 96-Zeichen-Satzes). SS2 und SS3 müssen in C1 an den Adressen 0x8E bzw. 0x8F verfügbar sein. Dieser minimale, für ISO 4873 erforderliche C1-Satz ist als ISO-IR-105 registriert. ^{[ 70 ]}
• Stufe 3, die neben den Einzelschaltungen auch die GR-Sperrschaltfunktionen LS1R, LS2R und LS3R ermöglicht, ansonsten aber die gleichen Einschränkungen wie Stufe 2 aufweist.

Frühere Versionen des Standards erlaubten die Verwendung von Nicht-ASCII-Zeichen im G0-Zeichensatz, sofern die in ISO/IEC 646 festgelegten invarianten Positionen erhalten blieben, die übrigen Positionen Leerzeichen (nicht Kombinationszeichen) zugeordnet wurden, 0x23 entweder £ oder # und 0x24 entweder $ oder ¤ zugeordnet wurde . ^{[ 141 ]} Beispielsweise ist die 8-Bit-Kodierung von JIS X 0201 mit früheren Versionen kompatibel. Dies wurde später geändert, um den Zeichensatz ISO/IEC 646:1991 IRV / ISO-IR Nr. 6 (ASCII) vollständig zu spezifizieren. ^{[ 142 ] [ 143 ] [ 144 ]}

Die Verwendung des ISO/IEC 646 IRV (seit 1991 mit ASCII synchronisiert) auf ISO/IEC 4873 Level 1 ohne gesetztes C1 oder G1, d. h. die Verwendung des IRV in einer 8-Bit-Umgebung, in der keine Schiebecodes verwendet werden und das höchste Bit immer Null ist, wird als ISO 4873 DV bezeichnet , wobei DV für „Standardversion“ steht. ^{[ 145 ]}

Wenn Zeichen in verschiedenen Zeichensätzen vorhanden sind, erlaubt die aktuelle Ausgabe von ISO/IEC 4873 / ECMA-43 nur die Verwendung dieser Zeichen im niedrigsten Zeichensatz, in dem sie vorkommen. ^{[ 146 ]} Wenn beispielsweise ein Zeichen sowohl im G1- als auch im G3-Zeichensatz vorkommt, muss es aus dem G1-Zeichensatz verwendet werden. Die Verwendung aus anderen Zeichensätzen war in früheren Ausgaben jedoch zulässig. ^{[ 144 ]}

ISO/IEC 8859 definiert vollständige Kodierungen auf Ebene 1 von ISO/IEC 4873 und erlaubt nicht die gleichzeitige Verwendung mehrerer Teile von ISO/IEC 8859. Stattdessen ist für die Ebenen 2 und 3 von ISO/IEC 4873 ISO/IEC 10367 zu verwenden. ^{[ 9 ] [ 10 ]} ISO/IEC 10367:1991 enthält die G0- und G1-Sätze, die denen der ersten neun Teile von ISO/IEC 8859 entsprechen (d. h. jene, die zum Zeitpunkt der Veröffentlichung 1991 existierten), sowie einige ergänzende Sätze. ^{[ 147 ]}

Escape-Sequenzen zur Zeichensatzbezeichnung werden zur Identifizierung oder zum Umschalten zwischen Versionen beim Informationsaustausch nur dann verwendet, wenn dies von einem weiteren Protokoll gefordert wird. In diesem Fall verlangt der Standard eine ISO/IEC-2022-Ankündigungssequenz, die die ISO/IEC-4873-Ebene angibt, gefolgt von einem vollständigen Satz von Escape-Sequenzen, die die Zeichensatzbezeichnungen für C0, C1, G0, G1, G2 und G3 spezifizieren (wobei die Bezeichnungen G2 und G3 für Ebene 1 weggelassen werden). Ein F -Byte von 0x7E kennzeichnet eine leere Zeichensatzmenge. Jede ISO/IEC-4873-Ebene hat ihre eigene ISO/IEC-2022-Ankündigungssequenz, die wie folgt lautet: ^{[ 148 ]}

Extended Unix Code (EUC) ist ein 8-Bit- Zeichenkodierungssystem mit variabler Breite, das hauptsächlich für Japanisch , Koreanisch und vereinfachtes Chinesisch verwendet wird . Es basiert auf ISO 2022, und nur Zeichensätze, die der ISO-2022-Struktur entsprechen, können in EUC dargestellt werden. Bis zu vier kodierte Zeichensätze können dargestellt werden (in G0, G1, G2 und G3). Der G0-Satz wird über GL, der G1-Satz über GR und die Sätze G2 und G3 (falls vorhanden) über die einfachen Verschiebungen SS2 und SS3 aufgerufen, die als CR-Bytes (d. h. 0x8E bzw. 0x8F) verwendet werden und über GR (nicht GL) aufgerufen werden. ^{[ 11 ]} Sperrverschiebungscodes werden nicht verwendet. ^{[ 12 ]}

Der dem G0-Zeichensatz zugewiesene Code ist ASCII oder der nationale ISO-646 -Zeichensatz des jeweiligen Landes, wie z. B. KS-Roman (KS X 1003) oder JIS-Roman (die untere Hälfte von JIS X 0201 ). ^{[ 11 ]} Daher wird 0x5C ( Backslash in US-ASCII) in einigen Versionen von EUC-JP für das Yen-Zeichen und in einigen Versionen von EUC-KR für das Won-Zeichen verwendet.

G1 wird für einen 94x94-Zeichensatz verwendet, der in zwei Bytes dargestellt wird. Die EUC-CN- Form von GB 2312 und EUC-KR sind Beispiele für solche Zwei-Byte-EUC-Codes. EUC-JP umfasst Zeichen, die durch bis zu drei Bytes dargestellt werden (d. h. SS3 plus zwei Bytes), während ein einzelnes Zeichen in EUC-TW bis zu vier Bytes belegen kann (d. h. SS2 plus drei Bytes).

Der EUC-Code selbst verwendet nicht die Ansager- oder Bezeichnungssequenzen aus ISO 2022; er entspricht jedoch der folgenden Sequenz von vier Ansagersequenzen, deren Bedeutungen sich wie folgt aufschlüsseln. ^{[ 149 ]}

Das X-Konsortium definierte 1989 ein ISO-2022-Profil namens Compound Text als Austauschformat. [ 150 ] Dieses verwendet nur vier Steuercodes: HT ( ), NL (Zeilenumbruch, kodiert als LF ) ^{, ESC (} ) und CSI ( in seiner 8 - Bit - Darstellung ) , [ 151 ^{] wobei die} SDS - CSI -Sequenz für die bidirektionale Textsteuerung verwendet wird. ^{[ 152 ]} Es handelt sich um einen 8-Bit-Code, der G0 und G1 für GL und GR verwendet und in seinem Ausgangszustand ISO-8859-1 entspricht. ^{[ 153 ]} Die folgenden F-Bytes werden verwendet: 0x090x0A0x1B0x9BCSI … ]

Zur Angabe von Kodierungen mittels Labels definiert X11 Compound Text fünf DOCS-Sequenzen für den privaten Gebrauch: ESC % / 0( 1B 25 2F 30) für Kodierungen variabler Länge und ESC % / 1bis ESC % / 4für Kodierungen fester Länge mit jeweils ein bis vier Bytes. Anstatt eine weitere Escape-Sequenz zu verwenden, um zu ISO 2022 zurückzukehren , geben die beiden Bytes nach der ersten Escape-Sequenz die verbleibende Länge in Bytes an, kodiert in Basis-128 mit Bytes 0x80–FF. Das Kodierungslabel wird gemäß ISO 8859-1 vor dem kodierten Text eingefügt und mit STX ( ) abgeschlossen. ^{[ 109 ]}0x02

• Da der gesamte Zeichensatz von ISO/IEC 2022 über GL aufgerufen werden kann, ist die Auswahl an Glyphen nicht wesentlich eingeschränkt, beispielsweise durch die fehlende Darstellung von GR und C1 in Systemen mit 7-Bit-Kodierung. Dadurch lässt sich auch in solchen Systemen ein großer Zeichensatz darstellen. Im Allgemeinen bietet diese 7-Bit-Kompatibilität keinen wirklichen Vorteil, außer der Abwärtskompatibilität mit älteren Systemen. Die überwiegende Mehrheit moderner Computer verwendet 8 Bit pro Byte.
• Im Vergleich zu Unicode umgeht ISO/IEC 2022 die Vereinheitlichung der chinesischen Schriftzeichen , indem es Sequenzcodes verwendet, um zwischen diskreten Kodierungen für verschiedene ostasiatische Sprachen umzuschalten. Dadurch werden die mit der Vereinheitlichung verbundenen Probleme vermieden, wie beispielsweise die Schwierigkeit, mehrere CJK -Sprachen mit ihren jeweiligen Zeichenvarianten in einem einzigen Dokument und einer einzigen Schriftart zu unterstützen.

• Da ISO/IEC 2022 eine zustandsbehaftete Kodierung ist, kann ein Programm nicht mitten in einen Textblock springen, um Zeichen zu suchen, einzufügen oder zu löschen. Dies macht die Textmanipulation im Vergleich zu nicht zustandsbehafteten Kodierungen sehr umständlich und langsam. Jeder Sprung mitten im Text kann ein Zurückspringen zur vorherigen Escape-Sequenz erfordern, bevor die nachfolgenden Bytes interpretiert werden können.
• Aufgrund der zustandsbehafteten Natur von ISO/IEC 2022 kann ein identisches und äquivalentes Zeichen in verschiedenen Zeichensätzen kodiert sein. Diese Zeichensätze können den Bereichen G0 bis G3 zugeordnet werden, die entweder durch einfache Verschiebungen oder durch Sperrverschiebungen auf GL oder GR aktiviert werden. Folglich können Zeichen auf verschiedene Weisen dargestellt werden, was bedeutet, dass zwei visuell identische und äquivalente Zeichenketten nicht zuverlässig auf Gleichheit verglichen werden können.
• Einige Systeme, wie DICOM und diverse E-Mail-Clients, verwenden neben der Unterstützung weiterer Kodierungen eine Variante von ISO-2022 (z. B. „ISO 2022 IR 100“ ^{[ 155 ] ). [ 156 ]} Diese Variabilität erschwert den portablen Datenaustausch zwischen Computersystemen.
• UTF-1 , das Multibyte -Unicode- Transformationsformat, das mit der Darstellung von 8-Bit-Steuerzeichen gemäß ISO/IEC 2022 kompatibel ist, weist im Vergleich zu UTF-8 verschiedene Nachteile auf , und der Wechsel von oder zu anderen Zeichensätzen, wie sie von ISO/IEC 2022 unterstützt werden, ist in Unicode-Dokumenten in der Regel unnötig.
• Aufgrund seiner Escape-Sequenzen ist es möglich, Angriffsbytefolgen zu erstellen, in denen eine schädliche Zeichenkette (z. B. Cross-Site-Scripting ) maskiert wird, bis sie in Unicode dekodiert wird. Dadurch kann sie die Bereinigung umgehen. ^{[ 157 ]} Die Verwendung dieser Kodierung wird daher von Malware-Schutzsystemen als verdächtig eingestuft. ^{[ 158 ]} 7-Bit-ISO-2022-Daten (mit Ausnahme von ISO-2022-JP) werden vollständig auf das entsprechende Ersatzzeichen in HTML5 abgebildet , um Angriffe zu verhindern. ^{[ 113 ] [ 114 ]} Eingeschränkte 8-Bit-Versionen des ISO-2022-Codes, die keine Escape-Sequenzen oder Sperr-Shift-Codes verwenden, wie z. B. Extended Unix Code , weisen dieses Problem nicht auf.
• Die Verkettung von Datenströmen kann Probleme verursachen. Profile wie ISO-2022-JP legen fest, dass der Datenstrom im ASCII-Zustand beginnt und endet. ^{[ 115 ]} Dies ist notwendig, um sicherzustellen, dass Zeichen in verketteten ISO-2022-JP- und/oder ASCII-Datenströmen korrekt interpretiert werden. Daraus folgt, dass beim Verketten eines Datenstroms, der mit einem Mehrbytezeichen endet, mit einem Datenstrom, der mit einem Mehrbytezeichen beginnt, ein Paar Escape-Sequenzen generiert wird, die kurz in den ASCII-Zustand wechseln und diesen sofort wieder verlassen. Gemäß Unicode Technical Report #36 („Unicode Security Considerations“) sollten jedoch Paare von ISO-2022-Escape-Sequenzen ohne dazwischenliegende Zeichen ein Ersatzzeichen („�“) generieren, um zu verhindern, dass sie zur Maskierung schädlicher Sequenzen wie Cross-Site-Scripting missbraucht werden . ^{[ 159 ]} Die Implementierung dieser Maßnahme, z. B. in Mozilla Thunderbird , hat zu Interoperabilitätsproblemen geführt, da unerwartete "�"-Zeichen erzeugt wurden, wenn zwei ISO-2022-JP-Streams verkettet wurden. ^{[ 157 ]}

• ISO 2709
• ISO/IEC 646
• ISO-IR-102
• Steuercodes C0 und C1
• CJK-Zeichen
• MARC-Standards
• Mojibake
• luit
• ISO/IEC JTC 1/SC 2

• ARIB (2008). ARIB STD-B24: Datenkodierungs- und Übertragungsspezifikation für digitales Fernsehen (PDF) (ARIB-Standard). 5.2-E1. Band 1. Archiviert (PDF) vom Original am 10.07.2017 . Abgerufen am 10.07.2017 .
• ECMA (1980). ECMA-35: Erweiterung des 7-Bit-codierten Zeichensatzes (PDF) (ECMA-Standard) (2. Aufl.).
• ECMA (1994). ECMA-35: Zeichencodestruktur und Erweiterungstechniken (PDF) (ECMA-Standard) (6. Aufl.).
• ECMA (1985). ECMA-43: 8-Bit Coded Character Set Structure and Rules (PDF) (ECMA Standard) (2nd ed.).
• ECMA (1991). ECMA-43: 8-Bit Coded Character Set Structure and Rules (PDF) (ECMA Standard) (3rd ed.).
• ECMA (1991). ECMA-48: Steuerfunktionen für codierte Zeichensätze (PDF) (ECMA-Standard) (5. Aufl.).
• ECMA (2000). ECMA-144: 8-Bit Single-Byte Coded Graphic Character sets: Latin Alphabet No. 6 (PDF) (ECMA Standard) (3rd ed.).
• Europäische Rundfunkunion (1997). ETS 300 706: Erweiterte Teletext-Spezifikation (PDF) (Europäische Telekommunikationsstandards). ETSI .
• ISO/IEC JTC 1/SC 2 (2003). ISO/IEC 2375:2003: Informationstechnik – Verfahren zur Registrierung von Escape-Sequenzen und codierten Zeichensätzen . ISO .{{cite book}}: CS1 Wartung: numerische Namen: Autorenliste ( Link )
• ISO/IEC JTC 1/SC 2 (1998-02-12). ISO/IEC FDIS 8859-10: Informationstechnik — 8-Bit-Einzelbyte-codierte grafische Zeichensätze — Teil 10: Lateinisches Alphabet Nr. 6 (PDF) (Final Draft International Standard).{{cite book}}: CS1 Wartung: numerische Namen: Autorenliste ( Link )
• ISO/IEC JTC 1/SC 2 (2017). ISO/IEC 10646: Informationstechnik – Universeller codierter Zeichensatz (UCS) (ISO-Standard) (5. Ausgabe). ISO .{{cite book}}: CS1 Wartung: numerische Namen: Autorenliste ( Link )
• ISO-IR: Internationales ISO/IEC-Register codierter Zeichensätze zur Verwendung mit Escape-Sequenzen (PDF) (Registerindex). ITSCJ/ IPSJ . Archiviert vom Original (PDF) am 12.05.2023 . Abgerufen am 12.05.2023 .
• Scheifler, Robert W. (1989). Zusammengesetzte Textkodierung (X-Konsortium-Standard). X-Konsortium .
• van Kesteren, Anne . WHATWG-Kodierungsstandard (WHATWG Living Standard). WASWG .

• ISO/TC 97/SC 2 (1975-12-01). ISO-IR-1: Der Satz von Steuerzeichen der ISO 646 (PDF) . ITSCJ/ IPSJ .{{citation}}: CS1 Wartung: numerische Namen: Autorenliste ( Link )
• Schwedische Standardisierungskommission (01.12.1975). ISO-IR-7: NATS-Steuersatz für Zeitungstextübertragung (PDF) . ITSCJ/ IPSJ .
• Japanisches Komitee für Industrienormen (1975-12-01). ISO-IR-14: Der japanische lateinische Zeichensatz (PDF) . ITSCJ/ IPSJ .
• IPTC (25.03.1976). ISO-IR-26: Steuersatz für Zeitungstextübertragung (PDF) . ITSCJ/ IPSJ .
• ISO/TC 97/SC 2 (15.10.1977). ISO-IR-36: Der Satz von Steuerzeichen der ISO 646, wobei IS4 durch Single Shift für G2 (SS2) ersetzt wird (PDF) . ITSCJ/ IPSJ .{{citation}}: CS1 Wartung: numerische Namen: Autorenliste ( Link )
• ISO/TC97/SC2/WG-7 ; ECMA (01.08.1985). ISO-IR-104: Mindest-C0-Satz für ISO 4873 (PDF) . ITSCJ/ IPSJ .{{citation}}: CS1 Wartung: numerische Namen: Autorenliste ( Link )
• ISO/TC97/SC2/WG-7 ; ECMA (01.08.1985). ISO-IR-105: Mindest-C1-Set für ISO 4873 (PDF) . ITSCJ/ IPSJ .{{citation}}: CS1 Wartung: numerische Namen: Autorenliste ( Link )
• ITU (1985-08-01). ISO-IR-106: Teletex Primärer Satz von Steuerfunktionen (PDF) . ITSCJ/ IPSJ .
• Úřad pro normalizaci a měřeni (1987-07-31). ISO-IR-140: Der C0-Steuerzeichensatz von ISO 646, wobei EM durch SS2 ersetzt wird (PDF) . ITSCJ/ IPSJ .
• Koreanisches Normungsinstitut (1988-10-01). ISO-IR-149: Koreanischer Zeichensatz für den Informationsaustausch (KS C 5601:1987) (PDF) . ITSCJ/ IPSJ .
• ISO/IEC/JTC1/SC2/WG3 (1990-04-16). ISO-IR-155: Basic Box-Drawings Set (PDF) . ITSCJ/ IPSJ .{{citation}}: CS1 Wartung: numerische Namen: Autorenliste ( Link )
• CCITT (13.07.1992). ISO-IR-164: Hebräischer Ergänzungssatz grafischer Zeichen (PDF) . ITSCJ/ IPSJ .
• ECMA (22.04.1996). ISO-IR-192: UCS Transformation Format (UTF-8), Implementierungsstufe 3, ohne Standardrückgabe (PDF) . ITSCJ/ IPSJ .
• ECMA (22.04.1996). ISO-IR-195: UCS Transformation Format (UTF-16), Implementierungsstufe 3, ohne Standardrückgabe (PDF) . ITSCJ/ IPSJ .
• ECMA (22.04.1996). ISO-IR-196: UCS Transformation Format (UTF-8), mit Standardrückgabe (PDF) . ITSCJ/ IPSJ .
• National Standards Authority of Ireland (07.12.1999). ISO-IR-208: Ogham-kodierter Zeichensatz für den Informationsaustausch (PDF) . ITSCJ/ IPSJ .

• Murai, J.; Crispin, M.; van der Poel, E. (1993). „RFC 1468: Japanische Zeichenkodierung für Internetnachrichten“ . Requests for Comments . IETF . doi : 10.17487/rfc1468 .
• Ohta, M.; Handa, K. (1993). „RFC 1554: ISO-2022-JP-2: Mehrsprachige Erweiterung von ISO-2022-JP“ . Requests for Comments . IETF . doi : 10.17487/rfc1554 .
• Choi, U.; Chon, K.; Park, H. (1993). „RFC 1557: Koreanische Zeichenkodierung für Internetnachrichten“ . Requests for Comments . IETF . doi : 10.17487/rfc1557 .
• Zhu, HF.; Hu, DY.; Wang, ZG.; Kao, TC.; Chang, WCH.; Crispin, M. (1996). „RFC 1922: Chinesische Zeichenkodierung für Internetnachrichten“ . Requests for Comments . IETF . doi : 10.17487/rfc1922 .
• Tamaru, K. (1997). „RFC 2237: Japanische Zeichenkodierung für Internetnachrichten“ . Requests for Comments . IETF . doi : 10.17487/rfc2237 .

• Lunde, Ken (2008). CJKV-Informationsverarbeitung (2. Aufl.). O'Reilly Media . ISBN 9780596514471Die

• Lunde, Ken (1998). CJKV Informationsverarbeitung . Cambridge, Massachusetts: O'Reilly & Associates . ISBN 1-56592-224-7Die

• ISO/IEC 2022:1994
• ISO/IEC 2022:1994/Cor 1:1999
• ECMA-35 , entspricht ISO/IEC 2022 und ist frei herunterladbar.
• Internationales Register codierter Zeichensätze zur Verwendung mit Escape-Sequenzen , eine vollständige Liste der zugewiesenen Zeichensätze und ihrer Escape-Sequenzen
• Geschichte der Zeichencodes in Nordamerika, Europa und Ostasien ab 1999, überarbeitet 2004
• Ken Lundes CJK.INF , archiviert am 15.05.2021 in der Wayback Machine : ein Dokument über die Kodierung der chinesischen, japanischen und koreanischen (CJK) Sprachen, einschließlich einer Diskussion der verschiedenen Varianten von ISO/IEC 2022.