ИСО/МЭК 2022

Не путать с ISO 20022 .

ИСО 2022

Язык(и)	Различный.
Стандартный	ИСО/МЭК 2022 ЭКМА -35 АНСИ Х3.41 ДЖИС Х 0202 ГБ/Т 2311
Классификация	с сохранением состояния Система кодировок (с предварительно настроенными подмножествами без сохранения состояния)
Преобразует/кодирует	US-ASCII и, в зависимости от реализации: ГБ 2312 ДЖИС Х 0201 ДЖИС Х 0208 ДЖИС Х 0212 ДЖИС Х 0213 КС Х 1001 ЦНС 11643 ИСО/МЭК 646 ИСО/ 8859/10367 МЭК различные другие
Преемник	ISO/IEC 10646 ( Юникод )
Другая связанная кодировка(и)	Stateful subsets: ISO-2022-JP ISO-2022-CN ISO-2022-KR Compound Text Pre-configured versions: ISO/IEC 4873 EUC

ISO/IEC 2022 Информационные технологии. Структура кода символов и методы расширения — это стандарт ISO / IEC в области кодирования символов . Он эквивалентен ECMA стандарту ECMA-35 . ANSI стандарт ANSI X3.41 и японский промышленный стандарт JIS X 0202 . Созданный в 1971 году, последний раз он был пересмотрен в 1994 году.

ISO 2022 определяет общую структуру, которой могут соответствовать кодировки символов, выделяя определенные диапазоны байтов ( 0x 00–1F и 0x7F–9F), которые будут использоваться для непечатаемых управляющих кодов. для форматирования и внутриполосных инструкций (таких как разрывы строк или инструкции форматирования для текстовых терминалов ), а не для графических символов . Он также определяет синтаксис escape-последовательностей, многобайтовых последовательностей, начинающихся с Код управления ESC , который также можно использовать для внутриполосных инструкций. Конкретные наборы управляющих кодов и escape-последовательностей, разработанные для использования с ISO 2022, включают ISO/IEC 6429 , части которого реализованы с помощью ANSI.SYS и эмуляторов терминала .

ISO 2022 itself also defines particular control codes and escape sequences which can be used for switching between different coded character sets (for example, between ASCII and the Japanese JIS X 0208) so as to use multiple in a single document, effectively combining them into a single stateful encoding (a feature less important since the advent of Unicode). It is designed to be usable in both 8-bit environments and 7-bit environments (those where only seven bits are usable in a byte, such as e-mail without 8BITMIME).

Encodings and conformance

The ASCII character set supports the ISO Basic Latin alphabet (equivalent to the English alphabet), and does not provide good support for languages which use additional letters, or which use a different writing system altogether. Other writing systems with relatively few characters, such as Greek, Cyrillic, Arabic or Hebrew, as well as forms of the Latin script using diacritics or letters absent from the ISO Basic Latin alphabet, have historically been represented on personal computers with different 8-bit, single byte, extended ASCII encodings, which follow ASCII when the most significant bit is 0 (i.e. bytes 0x00–7F, when represented in hexadecimal), and include additional characters for a most significant bit of 1 (i.e. bytes 0x80–FF). Some of these, such as the ISO 8859 series, conform to ISO 2022, while others such as DOS code page 437 do not, usually due to not reserving the bytes 0x80–9F for control codes.

Certain East Asian languages, specifically Chinese, Japanese, and Korean (collectively "CJK"), are written using far more characters than the maximum of 256 which can be represented in a single byte, and were first represented on computers with language-specific double-byte encodings or variable-width encodings; some of these (such as the Simplified Chinese encoding GB 2312) conform to ISO 2022, while others (such as the Traditional Chinese encoding Big5) do not. Control codes in ISO 2022 are always represented with a single byte, regardless of the number of bytes used for graphical characters. CJK encodings used in 7-bit environments which use ISO 2022 mechanisms to switch between character sets are often given names starting with "ISO-2022-", most notably ISO-2022-JP, although some other CJK encodings such as EUC-JP also make use of ISO 2022 mechanisms.

Since the first 256 code points of Unicode were taken from ISO 8859-1, Unicode inherits the concept of C0 and C1 control codes from ISO 2022, although it adds other non-printing characters besides the ISO 2022 control codes. However, Unicode transformation formats such as UTF-8 generally deviate from the ISO 2022 structure in various ways, including:

• Using 8-bit bytes, but not representing the C1 codes in their single-byte forms specified in ISO 2022 (most UTFs, one exception being the obsolete UTF-1)
• Representing all characters, including control codes, with multiple bytes (e.g. UTF-16, UTF-32)
• Mixing bytes with the most significant bit set and unset within the coded representation for a single code point (e.g. UTF-1, GB 18030)

ISO 2022 escape sequences do, however, exist for switching to and from UTF-8 as a "coding system different from that of ISO 2022", which are supported by certain terminal emulators such as xterm.

Overview

Elements

ISO/IEC 2022 specifies the following:

• An infrastructure of multiple character sets with particular structures which may be included in a single character encoding system, including multiple graphical character sets and multiple sets of both primary (C0) and secondary (C1) control codes,
• A format for encoding these sets, assuming that 8 bits are available per byte,
• A format for encoding these sets in the same encoding system when only 7 bits are available per byte, and a method for transforming any conformant character data to pass through such a 7-bit environment,
• The general structure of ANSI escape codes, and
• Specific escape code formats for identifying individual character sets, for announcing the use of particular encoding features or subsets, and for interacting with or switching to other encoding systems.

Code versions

Further information: § ISO/IEC 2022 code versions

A specific implementation does not have to implement all of the standard; the conformance level and the supported character sets are defined by the implementation. Although many of the mechanisms defined by the ISO/IEC 2022 standard are infrequently used, several established encodings are based on a subset of the ISO/IEC 2022 system. In particular, 7-bit encoding systems using ISO/IEC 2022 mechanisms include ISO-2022-JP (or JIS encoding), which has primarily been used in Japanese-language e-mail. 8-bit encoding systems conforming to ISO/IEC 2022 include ISO/IEC 4873 (ECMA-43), which is in turn conformed to by ISO/IEC 8859, and Extended Unix Code, which is used for East Asian languages. More specialised applications of ISO 2022 include the MARC-8 encoding system used in MARC 21 library records.

Designation escape sequences

Further information: § Registration of graphical and control code sets, and § Character set designations

The escape sequences for switching to particular character sets or encodings are registered with the ISO-IR registry (except for those set apart for private use, the meanings of which are defined by vendors, or by protocol specifications such as ARIB STD-B24) and follow the patterns defined within the standard. Character encodings making use of these escape sequences require data to be processed sequentially in a forward direction, since the correct interpretation of the data depends on previously encountered escape sequences.

Specific profiles such as ISO-2022-JP may impose extra conditions, such as that the current character set is reset to US-ASCII before the end of a line. Furthermore, the escape sequences declaring the national character sets may be absent if a specific ISO-2022-based encoding permits or requires this, and dictates that particular national character sets are to be used. For example, ISO-8859-1 states that no defining escape sequence is needed.

Multi-byte characters

Further information: JIS X 0208 § Code points and code numbers

To represent large character sets, ISO/IEC 2022 builds on ISO/IEC 646's property that a seven-bit character representation will normally be able to represent 94 graphic (printable) characters (in addition to space and 33 control characters); if only the C0 control codes (narrowly defined) are excluded, this can be expanded to 96 characters. Using two bytes, it is thus possible to represent up to 8,836 (94×94) characters; and, using three bytes, up to 830,584 (94×94×94) characters. Though the standard defines it, no registered character set uses three bytes (although EUC-TW's unregistered G2 does, as does the similarly unregistered CCCII).

For the two-byte character sets, the code point of each character is normally specified in so-called row-cell or kuten form, which comprises two numbers between 1 and 94 inclusive, specifying a row and cell of that character within the zone. For a three-byte set, an additional plane number is included at the beginning. The escape sequences do not only declare which character set is being used, but also whether the set is single-byte or multi-byte (although not how many bytes it uses if it is multi-byte), and also whether each byte has 94 or 96 permitted values.

Code structure

Notation and nomenclature

ISO/IEC 2022 coding specifies a two-layer mapping between character codes and displayed characters. Escape sequences allow any of a large registry of graphic character sets to be "designated" into one of four working sets, named G0 through G3, and shorter control sequences specify the working set that is "invoked" to interpret bytes in the stream.

Encoding byte values ("bit combinations") are often given in column-line notation, where two decimal numbers in the range 00–15 (each corresponding to a single hexadecimal digit) are separated by a slash. Hence, for instance, codes 2/0 (0x20) through 2/15 (0x2F) inclusive may be referred to as "column 02". This is the notation used in the ISO/IEC 2022 / ECMA-35 standard itself. They may be described elsewhere using hexadecimal, as is often used in this article, or using the corresponding ASCII characters, although the escape sequences are actually defined in terms of byte values, and the graphic assigned to that byte value may be altered without affecting the control sequence.

Byte values from the 7-bit ASCII graphic range (hexadecimal 0x20–0x7F), being on the left side of a character code table, are referred to as "GL" codes (with "GL" standing for "graphics left") while bytes from the "high ASCII" range (0xA0–0xFF), if available (i.e. in an 8-bit environment), are referred to as the "GR" codes ("graphics right"). The terms "CL" (0x00–0x1F) and "CR" (0x80–0x9F) are defined for the control ranges, but the CL range always invokes the primary (C0) controls, whereas the CR range always either invokes the secondary (C1) controls or is unused.

Fixed coded characters

The delete character DEL (0x7F), the escape character ESC (0x1B) and the space character SP (0x20) are designated "fixed" coded characters and are always available when G0 is invoked over GL, irrespective of what character sets are designated. They may not be included in graphical character sets, although other sizes or types of whitespace character may be.

General syntax of escape sequences

Sequences using the ESC (escape) character take the form ESC [I...] F, where the ESC character is followed by zero or more intermediate bytes (I) from the range 0x20–0x2F, and one final byte (F) from the range 0x30–0x7E.

The first I byte, or absence thereof, determines the type of escape sequence; it might, for instance, designate a working set, or denote a single control function. In all types of escape sequences, F bytes in the range 0x30–0x3F are reserved for unregistered private uses defined by prior agreement between parties.

Control functions from some sets may make use of further bytes following the escape sequence proper. For example, the ISO 6429 control function "Control Sequence Introducer", which can be represented using an escape sequence, is followed by zero or more bytes in the range 0x30–0x3F, then zero or more bytes in the range 0x20–0x2F, then by a single byte in the range 0x40–0x7E, the entire sequence being called a "control sequence".

Graphical character sets

Each of the four working sets G0 through G3 may be a 94-character set or a 94ⁿ-character multi-byte set. Additionally, G1 through G3 may be a 96- or 96ⁿ-character set.

In a 96- or 96ⁿ-character set, the bytes 0x20 through 0x7F when GL-invoked, or 0xA0 through 0xFF when GR-invoked, are allocated to and may be used by the set. In a 94- or 94ⁿ-character set, the bytes 0x20 and 0x7F are not used. When a 96- or 96ⁿ-character set is invoked in the GL region, the space and delete characters (codes 0x20 and 0x7F) are not available until a 94- or 94ⁿ-character set (such as the G0 set) is invoked in GL. 96-character sets cannot be designated to G0.

Registration of a set as a 96-character set does not necessarily mean that the 0x20/A0 and 0x7F/FF bytes are actually assigned by the set; some examples of graphical character sets which are registered as 96-sets but do not use those bytes include the G1 set of I.S. 434, the box drawing set from ISO/IEC 10367, and ISO-IR-164 (a subset of the G1 set of ISO-8859-8 with only the letters, used by CCITT).

Combining characters

Characters are expected to be spacing characters, not combining characters, unless specified otherwise by the graphical set in question. ISO 2022 / ECMA-35 also recognizes the use of the backspace and carriage return control characters as means of combining otherwise spacing characters, as well as the CSI sequence "Graphic Character Combination" (GCC) (CSI 0x20 (SP) 0x5F (_)).

Use of the backspace and carriage return in this manner is permitted by ISO/IEC 646 but prohibited by ISO/IEC 4873 / ECMA-43 and by ISO/IEC 8859, on the basis that it leaves the graphical character repertoire undefined. ISO/IEC 4873 / ECMA-43 does, however, permit the use of the GCC function provided that the sequence of characters is kept the same and merely displayed in one space, rather than being over-stamped to form a character with a different meaning.

Control character sets

Control character sets are classified as "primary" or "secondary" control code sets, respectively also called "C0" and "C1" control code sets.

A C0 control set must contain the ESC (escape) control character at 0x1B (a C0 set containing only ESC is registered as ISO-IR-104), whereas a C1 control set may not contain the escape control whatsoever. Hence, they are entirely separate registrations, with a C0 set being only a C0 set and a C1 set being only a C1 set.

If codes from the C0 set of ISO 6429 / ECMA-48, i.e. the ASCII control codes, appear in the C0 set, they are required to appear at their ISO 6429 / ECMA-48 locations. Inclusion of transmission control characters in the C0 set, besides the ten included by ISO 6429 / ECMA-48 (namely SOH, STX, ETX, EOT, ENQ, ACK, DLE, NAK, SYN and ETB), or inclusion of any of those ten in the C1 set, is also prohibited by the ISO/IEC 2022 / ECMA-35 standard.

A C0 control set is invoked over the CL range 0x00 through 0x1F, whereas a C1 control function may be invoked over the CR range 0x80 through 0x9F (in an 8-bit environment) or by using escape sequences (in a 7-bit or 8-bit environment), but not both. Which style of C1 invocation is used must be specified in the definition of the code version. For example, ISO/IEC 4873 specifies CR bytes for the C1 controls which it uses (SS2 and SS3). If necessary, which invocation is used may be communicated using announcer sequences.

In the latter case, single control functions from the C1 control code set are invoked using "type Fe" escape sequences, meaning those where the ESC control character is followed by a byte from columns 04 or 05 (that is to say, ESC 0x40 (@) through ESC 0x5F (_)).

Other control functions

Additional control functions are assigned to "type Fs" escape sequences (in the range ESC 0x60 (`) through ESC 0x7E (~)); these have permanently assigned meanings rather than depending on the C0 or C1 designations. Registration of control functions to type "Fs" sequences must be approved by ISO/IEC JTC 1/SC 2. Other single control functions may be registered to type "3Ft" escape sequences (in the range ESC 0x23 (#) [I...] 0x40 (@) through ESC 0x23 (#) [I...] 0x7E (~)), although no "3Ft" sequences are currently assigned (as of 2019). Some of these are specified in ECMA-35 (ISO 2022 / ANSI X3.41), others in ECMA-48 (ISO 6429 / ANSI X3.64). ECMA-48 refers to these as "independent control functions".

Code	Hex	Abbr.	Name	Effect
ESC `	1B 60	DMI	Disable manual input	Disables some or all of the manual input facilities of the device.
ESC a	1B 61	INT	Interrupt	Interrupts the current process.
ESC b	1B 62	EMI	Enable manual input	Enables the manual input facilities of the device.
ESC c	1B 63	RIS	Reset to initial state	Resets the device to its state after being powered on.
ESC d	1B 64	CMD	Coding method delimiter	Used when interacting with an outer coding / representation system, see below.
ESC n	1B 6E	LS2	Locking shift two	Shift function, see below.
ESC o	1B 6F	LS3	Locking shift three	Shift function, see below.
ESC |	1B 7C	LS3R	Locking shift three right	Shift function, see below.
ESC }	1B 7D	LS2R	Locking shift two right	Shift function, see below.
ESC ~	1B 7E	LS1R	Locking shift one right	Shift function, see below.

Escape sequences of type "Fp" (ESC 0x30 (0) through ESC 0x3F (?)) or of type "3Fp" (ESC 0x23 (#) [I...] 0x30 (0) through ESC 0x23 (#) [I...] 0x3F (?)) are reserved for single private use control codes, by prior agreement between parties. Several such sequences of both types are used by DEC terminals such as the VT100, and are thus supported by terminal emulators.

Shift functions

By default, GL codes specify G0 characters and GR codes (where available) specify G1 characters; this may be otherwise specified by prior agreement. The set invoked over each area may also be modified with control codes referred to as shifts, as shown in the table below.

An 8-bit code may have GR codes specifying G1 characters, i.e. with its corresponding 7-bit code using Shift In and Shift Out to switch between the sets (e.g. JIS X 0201), although some instead have GR codes specifying G2 characters, with the corresponding 7-bit code using a single-shift code to access the second set (e.g. T.51).

The codes shown in the table below are the most common encodings of these control codes, conforming to ISO/IEC 6429. The LS2, LS3, LS1R, LS2R and LS3R shifts are registered as single control functions and are always encoded as the escape sequences listed below, whereas the others are part of a C0 or C1 control code set (as shown below, SI (LS0) and SO (LS1) are C0 controls and SS2 and SS3 are C1 controls), meaning that their coding and availability may vary depending on which control sets are designated: they must be present in the designated control sets if their functionality is used. The C1 controls themselves, as mentioned above, may be represented using escape sequences or 8-bit bytes, but not both.

Alternative encodings of the single-shifts as C0 control codes are available in certain control code sets. For example, SS2 and SS3 are usually available at 0x19 and 0x1D respectively in T.51 and T.61. This coding is currently recommended by ISO/IEC 2022 / ECMA-35 for applications requiring 7-bit single-byte representations of SS2 and SS3, and may also be used for SS2 only, although older code sets with SS2 at 0x1C also exist, and were mentioned as such in an earlier edition of the standard. The 0x8E and 0x8F coding of the single shifts as shown below is mandatory for ISO/IEC 4873 levels 2 and 3.

Code	Hex	Abbr.	Name	Effect
SI	0F	SI LS0	Shift In Locking shift zero	GL encodes G0 from now on
SO	0E	SO LS1	Shift Out Locking shift one	GL encodes G1 from now on
ESC n	1B 6E	LS2	Locking shift two	GL encodes G2 from now on
ESC o	1B 6F	LS3	Locking shift three	GL encodes G3 from now on
CR area: SS2 Escape code: ESC N	CR area: 8E Escape code: 1B 4E	SS2	Single shift two	GL or GR (see below) encodes G2 for the immediately following character only
CR area: SS3 Escape code: ESC O	CR area: 8F Escape code: 1B 4F	SS3	Single shift three	GL or GR (see below) encodes G3 for the immediately following character only
ESC ~	1B 7E	LS1R	Locking shift one right	GR encodes G1 from now on
ESC }	1B 7D	LS2R	Locking shift two right	GR encodes G2 from now on
ESC |	1B 7C	LS3R	Locking shift three right	GR encodes G3 from now on

Although officially considered shift codes and named accordingly, single-shift codes are not always viewed as shifts, and they may simply be viewed as prefix bytes (i.e. the first bytes in a multi-byte sequence), since they do not require the encoder to keep the currently active set as state, unlike locking shift codes. In 8-bit environments, either GL or GR, but not both, may be used as the single-shift area. This must be specified in the definition of the code version. For instance, ISO/IEC 4873 specifies GL, whereas packed EUC specifies GR. In 7-bit environments, only GL is used as the single-shift area. If necessary, which single-shift area is used may be communicated using announcer sequences.

The names "locking shift zero" (LS0) and "locking shift one" (LS1) refer to the same pair of C0 control characters (0x0F and 0x0E) as the names "shift in" (SI) and "shift out" (SO). However, the standard refers to them as LS0 and LS1 when they are used in 8-bit environments and as SI and SO when they are used in 7-bit environments.

The ISO/IEC 2022 / ECMA-35 standard permits, but discourages, invoking G1, G2 or G3 in both GL and GR simultaneously.

Registration of graphical and control code sets

The ISO International register of coded character sets to be used with escape sequences (ISO-IR) lists graphical character sets, control code sets, single control codes and so forth which have been registered for use with ISO/IEC 2022. The procedure for registering codes and sets with the ISO-IR registry is specified by ISO/IEC 2375. Each registration receives a unique escape sequence, and a unique registry entry number to identify it. For example, the CCITT character set for Simplified Chinese is known as ISO-IR-165.

Registration of coded character sets with the ISO-IR registry identifies the documents specifying the character set or control function associated with an ISO/IEC 2022 non‑private-use escape sequence. This may be a standard document; however, registration does not create a new ISO standard, does not commit the ISO or IEC to adopt it as an international standard, and does not commit the ISO or IEC to add any of its characters to the Universal Coded Character Set.

ISO-IR registered escape sequences are also used encapsulated in a Formal Public Identifier to identify character sets used for numeric character references in SGML (ISO 8879). For example, the string ISO 646-1983//CHARSET International Reference Version (IRV)//ESC 2/5 4/0 can be used to identify the International Reference Version of ISO 646-1983, and the HTML 4.01 specification uses ISO Registration Number 177//CHARSET ISO/IEC 10646-1:1993 UCS-4 with implementation level 3//ESC 2/5 2/15 4/6 to identify Unicode. The textual representation of the escape sequence, included in the third element of the FPI, will be recognised by SGML implementations for supported character sets.

Character set designations

Escape sequences to designate character sets take the form ESC I [I...] F. As mentioned above, the intermediate (I) bytes are from the range 0x20–0x2F, and the final (F) byte is from the range 0x30–0x7E. The first I byte (or, for a multi-byte set, the first two) identifies the type of character set and the working set it is to be designated to, whereas the F byte (and any additional I bytes) identify the character set itself, as assigned in the ISO-IR register (or, for the private-use escape sequences, by prior agreement).

Additional I bytes may be added before the F byte to extend the F byte range. This is currently only used with 94-character sets, where codes of the form ESC ( ! F have been assigned. At the other extreme, no multibyte 96-sets have been registered, so the sequences below are strictly theoretical.

As with other escape sequence types, the range 0x30–0x3F is reserved for private-use F bytes, in this case for private-use character set definitions (which might include unregistered sets defined by protocols such as ARIB STD-B24 or MARC-8, or vendor-specific sets such as DEC Special Graphics). However, in a graphical set designation sequence, if the second I byte (for a single-byte set) or the third I byte (for a double-byte set) is 0x20 (space), the set denoted is a "dynamically redefinable character set" (DRCS) defined by prior agreement, which is also considered private use. A graphical set being considered a DRCS implies that it represents a font of exact glyphs, rather than a set of abstract characters. The manner in which DRCS sets and associated fonts are transmitted, allocated and managed is not stipulated by ISO/IEC 2022 / ECMA-35 itself, although it recommends allocating them sequentially starting with F byte 0x40 (@); however, a manner for transmitting DRCS fonts is defined within some telecommunication protocols such as World System Teletext.

There are also three special cases for multi-byte codes. The code sequences ESC $ @, ESC $ A, and ESC $ B were all registered when the contemporary version of the standard allowed multi-byte sets only in G0, so must be accepted in place of the sequences ESC $ ( @ through ESC $ ( B to designate to the G0 character set.

There are additional (rarely used) features for switching control character sets, but this is a single-level lookup, in that (as noted above) the C0 set is always invoked over CL, and the C1 set is always invoked over CR or by using escape codes. As noted above, it is required that any C0 character set include the ESC character at position 0x1B, so that further changes are possible. The control set designation sequences (as opposed to the graphical set ones) may also be used from within ISO/IEC 10646 (UCS/Unicode), in contexts where processing ANSI escape codes is appropriate, provided that each byte in the sequence is padded to the code unit size of the encoding.

A table of escape sequence I bytes and the designation or other function which they perform is below.

Code	Hex	Abbr.	Name	Effect	Example
ESC SP F	1B 20 F	ACS	Announce code structure	Specifies code features used, e.g. working sets (see below).	ESC SP L (ISO 4873 level 1)
ESC ! F	1B 21 F	CZD	C0-designate	F selects a C0 control character set to be used.	ESC ! @ (ASCII C0 codes)
ESC " F	1B 22 F	C1D	C1-designate	F selects a C1 control character set to be used.	ESC " C (ISO 6429 C1 codes)
ESC # F	1B 23 F	-	(Single control function)	(Reserved for sequences for control functions, see above.)	ESC # 6 (private use: DEC Double Width Line)
ESC $ F ESC $ ( F	1B 24 F 1B 24 28 F	GZDM4	G0-designate multibyte 94-set	F selects a 94n-character set to be used for G0.	ESC $ ( C (KS X 1001 in G0)
ESC $ ) F	1B 24 29 F	G1DM4	G1-designate multibyte 94-set	F selects a 94n-character set to be used for G1.	ESC $ ) A (GB 2312 in G1)
ESC $ * F	1B 24 2A F	G2DM4	G2-designate multibyte 94-set	F selects a 94n-character set to be used for G2.	ESC $ * B (JIS X 0208 in G2)
ESC $ + F	1B 24 2B F	G3DM4	G3-designate multibyte 94-set	F selects a 94n-character set to be used for G3.	ESC $ + D (JIS X 0212 in G3)
ESC $ , F	1B 24 2C F	-	(not used)	(not used)	-
ESC $ - F	1B 24 2D F	G1DM6	G1-designate multibyte 96-set	F selects a 96n-character set to be used for G1.	ESC $ - 1 (private use)
ESC $ . F	1B 24 2E F	G2DM6	G2-designate multibyte 96-set	F selects a 96n-character set to be used for G2.	ESC $ . 2 (private use)
ESC $ / F	1B 24 2F F	G3DM6	G3-designate multibyte 96-set	F selects a 96n-character set to be used for G3.	ESC $ / 3 (private use)
ESC % F	1B 25 F	DOCS	Designate other coding system	Switches coding system, see below.	ESC % G (UTF-8)
ESC & F	1B 26 F	IRR	Identify revised registration	Prefixes designation escape to denote revision.	ESC & @ ESC $ B (JIS X 0208:1990 in G0)
ESC ' F	1B 27 F	-	(not used)	(not used)	-
ESC ( F	1B 28 F	GZD4	G0-designate 94-set	F selects a 94-character set to be used for G0.	ESC ( B (ASCII in G0)
ESC ) F	1B 29 F	G1D4	G1-designate 94-set	F selects a 94-character set to be used for G1.	ESC ) I (JIS X 0201 Kana in G1)
ESC * F	1B 2A F	G2D4	G2-designate 94-set	F selects a 94-character set to be used for G2.	ESC * v (ITU T.61 RHS in G2)
ESC + F	1B 2B F	G3D4	G3-designate 94-set	F selects a 94-character set to be used for G3.	ESC + D (NATS-SEFI-ADD in G3)
ESC , F	1B 2C F	-	(not used)	(not used)	-
ESC - F	1B 2D F	G1D6	G1-designate 96-set	F selects a 96-character set to be used for G1.	ESC - A (ISO 8859-1 RHS in G1)
ESC . F	1B 2E F	G2D6	G2-designate 96-set	F selects a 96-character set to be used for G2.	ESC . B (ISO 8859-2 RHS in G2)
ESC / F	1B 2F F	G3D6	G3-designate 96-set	F selects a 96-character set to be used for G3.	ESC / b (ISO 8859-15 RHS in G3)

Note that the registry of F bytes is independent for the different types. The 94-character graphic set designated by ESC ( A through ESC + A is not related in any way to the 96-character set designated by ESC - A through ESC / A. And neither of those is related to the 94ⁿ-character set designated by ESC $ ( A through ESC $ + A, and so on; the final bytes must be interpreted in context. (Indeed, without any intermediate bytes, ESC A is a way of specifying the C1 control code 0x81.)

Also note that C0 and C1 control character sets are independent; the C0 control character set designated by ESC ! A (which happens to be the NATS control set for newspaper text transmission) is not the same as the C1 control character set designated by ESC " A (the CCITT attribute control set for Videotex).

Interaction with other coding systems

The standard also defines a way to specify coding systems that do not follow its own structure.

A sequence is also defined for returning to ISO/IEC 2022; the registrations which support this sequence as encoded in ISO/IEC 2022 comprise (as of 2019) various Videotex formats, UTF-8, and UTF-1. A second I byte of 0x2F (/) is included in the designation sequences of codes which do not use that byte sequence to return to ISO 2022; they may have their own means to return to ISO 2022 (such as a different or padded sequence) or none at all. All existing registrations of the latter type (as of 2019) are either transparent raw data, Unicode/UCS formats, or subsets thereof.

Code	Hex	Abbr.	Name	Effect
ESC % @	1B 25 40	DOCS	Designate other coding system ("standard return")	Return to ISO/IEC 2022 from another encoding.
ESC % F	1B 25 F		Designate other coding system ("with standard return")	F selects an 8-bit code; use ESC % @ to return.
ESC % / F	1B 25 2F F		Designate other coding system ("without standard return")	F selects an 8-bit code; there is no standard way to return.
ESC d	1B 64	CMD	Coding method delimiter	Denotes the end of an ISO/IEC 2022 coded sequence.

Of particular interest are the sequences which switch to ISO/IEC 10646 (Unicode) formats which do not follow the ISO/IEC 2022 structure. These include UTF-8 (which does not reserve the range 0x80–0x9F for control characters), its predecessor UTF-1 (which mixes GR and GL bytes in multi-byte codes), and UTF-16 and UTF-32 (which use wider coding units).

Several codes were also registered for subsets (levels 1 and 2) of UTF-8, UTF-16 and UTF-32, as well as for three levels of UCS-2. However, the only codes currently specified by ISO/IEC 10646 are the level-3 codes for UTF-8, UTF-16 and UTF-32 and the unspecified-level code for UTF-8, with the rest being listed as deprecated. ISO/IEC 10646 stipulates that the big-endian formats of UTF-16 and UTF-32 are designated by their escape sequences.

Unicode Format	Code(s)	Hex	Deprecated codes	Deprecated hex
UTF-1	(UTF-1 not in current ISO/IEC 10646.)		ESC % B	1B 25 42
UTF-8	ESC % G, ESC % / I	1B 25 47, 1B 25 2F 49	ESC % / G, ESC % / H	1B 25 2F 47, 1B 25 2F 48
UTF-16	ESC % / L	1B 25 2F 4C	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-32	ESC % / F	1B 25 2F 46	ESC % / A, ESC % / D	1B 25 2F 41, 1B 25 2F 44

Of the sequences switching to UTF-8, ESC % G is the one supported by, for example, xterm.

Although use of a variant of the standard return sequence from UTF-16 and UTF-32 is permitted, the bytes of the escape sequence must be padded to the size of the code unit of the encoding (i.e. 001B 0025 0040 for UTF-16), i.e. the coding of the standard return sequence does not conform exactly to ISO/IEC 2022. For this reason, the designations for UTF-16 and UTF-32 use a without-standard-return syntax.

For specifying encodings by labels, the X Consortium's Compound Text format defines five private-use DOCS sequences.

Code structure announcements

The sequence "announce code structure" (ESC SP (0x20) F) is used to announce a specific code structure, or a specific group of ISO 2022 facilities which are used in a particular code version. Although announcements can be combined, certain contradictory combinations (specifically, using locking shift announcements 16–23 with announcements 1, 3 and 4) are prohibited by the standard, as is using additional announcements on top of ISO/IEC 4873 level announcements 12–14 (which fully specify the permissible structural features). Announcement sequences are as follows:

Number	Code	Hex	Code version feature announced
1	ESC SP A	1B 20 41	G0 in GL, GR absent or unused, no locking shifts.
2	ESC SP B	1B 20 42	G0 and G1 invoked to GL by locking shifts, GR absent or unused.
3	ESC SP C	1B 20 43	G0 in GL, G1 in GR, no locking shifts, requires an 8-bit environment.
4	ESC SP D	1B 20 44	G0 in GL, G1 in GR if 8-bit, no locking shifts unless in a 7-bit environment.
5	ESC SP E	1B 20 45	Shift functions preserved during 7-bit/8-bit conversion.
6	ESC SP F	1B 20 46	C1 controls using escape sequences.
7	ESC SP G	1B 20 47	C1 controls in CR region in 8-bit environments, as escape sequences otherwise.
8	ESC SP H	1B 20 48	94-character graphical sets only.
9	ESC SP I	1B 20 49	94-character and/or 96-character graphical sets.
10	ESC SP J	1B 20 4A	Uses a 7-bit code, even if an eighth bit is available for use.
11	ESC SP K	1B 20 4B	Requires an 8-bit code.
12	ESC SP L	1B 20 4C	Complies to ISO/IEC 4873 (ECMA-43) level 1.
13	ESC SP M	1B 20 4D	Complies to ISO/IEC 4873 (ECMA-43) level 2.
14	ESC SP N	1B 20 4E	Complies to ISO/IEC 4873 (ECMA-43) level 3.
16	ESC SP P	1B 20 50	SI / LS0 used.
18	ESC SP R	1B 20 52	SO / LS1 used.
19	ESC SP S	1B 20 53	LS1R used in 8-bit environments, SO used in 7-bit environments.
20	ESC SP T	1B 20 54	LS2 used.
21	ESC SP U	1B 20 55	LS2R used in 8-bit environments, LS2 used in 7-bit environments.
22	ESC SP V	1B 20 56	LS3 used.
23	ESC SP W	1B 20 57	LS3R used in 8-bit environments, LS3 used in 7-bit environments.
26	ESC SP Z	1B 20 5A	SS2 used.
27	ESC SP [	1B 20 5B	SS3 used.
28	ESC SP \	1B 20 5C	Single-shifts invoke over GR.

ISO/IEC 2022 code versions

Various ISO 2022 and other CJK encodings supported by Mozilla Firefox as of 2004. (This support has been reduced in later versions to avoid certain cross site scripting attacks.)

Six 7-bit ISO 2022 code versions (ISO-2022-CN, ISO-2022-CN-EXT, ISO-2022-JP, ISO-2022-JP-1, ISO-2022-JP-2 and ISO-2022-KR) are defined by IETF RFCs, of which ISO-2022-JP and ISO-2022-KR have been extensively used in the past. A number of other variants are defined by vendors, including IBM. Although UTF-8 is the preferred encoding in HTML5, legacy content in ISO-2022-JP remains sufficiently widespread that the WHATWG encoding standard retains support for it, in contrast to mapping ISO-2022-KR, ISO-2022-CN and ISO-2022-CN-EXT entirely to the replacement character, due to concerns about code injection attacks such as cross-site scripting.

8-bit code versions include Extended Unix Code. The ISO/IEC 8859 encodings also follow ISO 2022, in a subset stipulated in ISO/IEC 4873.

Japanese e-mail versions

ISO-2022-JP

ISO-2022-JP is a widely used encoding for Japanese, in particular in e-mail. It was introduced for use on the JUNET network and later codified in IETF RFC 1468, dated 1993. It has an advantage over other encodings for Japanese in that it does not require 8-bit clean transmission. Microsoft calls it Code page 50220. It starts in ASCII and includes the following escape sequences:

• ESC ( B to switch to ASCII (1 byte per character)
• ESC ( J to switch to JIS X 0201-1976 (ISO/IEC 646:JP) Roman set (1 byte per character)
• ESC $ @ to switch to JIS X 0208-1978 (2 bytes per character)
• ESC $ B to switch to JIS X 0208-1983 (2 bytes per character)

Use of the two characters added in JIS X 0208-1990 is permitted, but without including the IRR sequence, i.e. using the same escape sequence as JIS X 0208-1983. Also, due to being registered before designating multi-byte sets except to G0 was possible, the escapes for JIS X 0208 do not include the second I-byte (.

The RFC notes that some existing systems did not distinguish ESC ( B from ESC ( J, or did not distinguish ESC $ @ from ESC $ B, but stipulates that the escape sequences should not be changed by systems simply relaying messages such as e-mails. The WHATWG Encoding Standard referenced by HTML5 handles ESC ( B and ESC ( J distinctly, but treats ESC $ @ the same as ESC $ B when decoding, and uses only ESC $ B for JIS X 0208 when encoding. The RFC also notes that some past systems had made erroneous use of the sequence ESC ( H to switch away from JIS X 0208, which is actually registered for ISO-IR-11 (a Swedish variant of ISO 646 and World System Teletext).

Versions with halfwidth katakana

Use of ESC ( I to switch to the JIS X 0201-1976 Kana set (1 byte per character) is not part of the ISO-2022-JP profile, but is also sometimes used. Python allows it in a variant which it labels ISO-2022-JP-EXT (which also incorporates JIS X 0212 as described below, completing coverage of EUC-JP); по названию и структуре это близко к кодировке, обозначенной -2022-JPext ISO DEC , которая, кроме того, добавляет двухбайтовую пользовательскую область, доступ к которой осуществляется с помощью ESC $ ( 0 чтобы завершить описание кандзи Super DEC . Вариант WHATWG/HTML5 позволяет декодировать катакану JIS X 0201 во входных данных ISO-2022-JP, но при кодировании преобразует символы в их эквиваленты JIS X 0208. Кодовая страница Microsoft для ISO-2022-JP с дополнительно разрешенным кана JIS X 0201 — кодовая страница 50221 .

Другие, более старые варианты, известные как JIS7 ​​и JIS8, основаны непосредственно на 7-битных и 8-битных кодировках, определенных JIS X 0201 , и позволяют использовать кану JIS X 0201 из G1 без escape-последовательностей, используя Shift Out и Shift In или устанавливая восьмую бит (вызываемый GR) соответственно. Они не получили широкого распространения; Поддержка JIS X 0208 в расширенном 8-битном JIS X 0201 чаще достигается с помощью Shift JIS . Кодовая страница Microsoft для ISO 2022 на основе JIS X 0201 с однобайтовой катаканой через Shift Out и Shift In — кодовая страница 50222 .

ISO-2022-JP-2

ISO-2022-JP-2 — это многоязычное расширение ISO-2022-JP, определенное в RFC 1554 (от 1993 г.), которое допускает следующие escape-последовательности в дополнение к последовательностям ISO-2022-JP. Части ISO/IEC 8859 представляют собой наборы из 96 символов, которые не могут быть обозначены как G0, и доступны из G2 с использованием 7-битной escape-последовательности односменного кода SS2:

• ESC $ A для переключения на GB 2312-1980 (2 байта на символ)
• ESC $ ( C для перехода на KS X 1001-1992 (2 байта на символ)
• ESC $ ( D для перехода на JIS X 0212-1990 (2 байта на символ)
• ESC . A для переключения на старшую часть ISO/IEC 8859-1 , набор расширенной латиницы 1 (1 байт на символ) [обозначается G2]
• ESC . F для переключения на старшую часть ISO/IEC 8859-7 , набор базового греческого языка (1 байт на символ) [обозначается как G2]

ISO-2022-JP с представлением ISO-2022-JP-2 для JIS X 0212, но не с другими расширениями, впоследствии был назван ISO-2022-JP-1 в RFC 2237 от 1997 года.

IBM японский TCP

IBM реализует девять 7-битных кодировок японского языка на основе ISO 2022, каждая из которых использует свой набор escape-последовательностей: IBM-956, IBM-957, IBM-958, IBM-959, IBM-5052, IBM-5053, IBM-5054, IBM-5055 и ISO-2022-JP, которые вместе называются «наборами японских кодированных символов TCP/IP». CCSID 9148 — это стандарт (RFC 1468) ISO-2022-JP.

Варианты IBM ISO-2022-JP скрывать

Кодовая страница/CCSID	Номер определения ACRI	Escape-последовательности для ACRI
956	TCP-01	ESC ( J (ИИСУС X 0201 Роман) ESC $ ( B (JIS X 0208, 1983+, длинная escape-последовательность) ESC $ I (JIS X 0201 Катакана) ESC $ ( D
957	TCP-02	ESC ( J (ИИСУС X 0201 Роман) ESC $ ( @ (JIS X 0208, 1978, длинная escape-последовательность) ESC $ I (JIS X 0201 Катакана) ESC $ ( D (ДЖИС Х 0212)
958	TCP-03	ESC ( A (ASCII) ESC $ ( B (JIS X 0208, 1983+, длинная escape-последовательность) ESC $ I (JIS X 0201 Катакана) ESC $ ( D (ДЖИС Х 0212)
959	TCP-04	ESC ( A (ASCII) ESC $ ( @ (JIS X 0208, 1978, длинная escape-последовательность) ESC $ I (JIS X 0201 Катакана) ESC $ ( D (ДЖИС Х 0212)
5052	TCP-05	ESC ( J (ИИСУС X 0201 Роман) ESC $ B (JIS X 0208, 1983+) ESC $ I (JIS X 0201 Катакана) ESC $ ( D (ДЖИС Х 0212)
5053	TCP-06	ESC ( J (ИИСУС X 0201 Роман) ESC $ @ (JIS X 0208, 1978 г.) ESC $ I (JIS X 0201 Катакана) ESC $ ( D (ДЖИС Х 0212)
5054	TCP-07	ESC ( A (ASCII) ESC $ B (JIS X 0208, 1983+) ESC $ I (JIS X 0201 Катакана) ESC $ ( D (ДЖИС Х 0212)
5055	TCP-08	ESC ( A (ASCII) ESC $ @ (JIS X 0208, 1978 г.) ESC $ I (JIS X 0201 Катакана) ESC $ ( D (ДЖИС Х 0212)
9148	TCP-16	ESC ( A (ASCII) ESC ( J (ИИСУС X 0201 Роман) ESC $ @ (JIS X 0208, 1978 г.) ESC $ B (JIS X 0208, 1983+)

ДЖИС Х 0213

Стандарт JIS X 0213 , впервые опубликованный в 2000 году, определяет обновленную версию ISO-2022-JP без расширений ISO-2022-JP-2, получившую название ISO-2022-JP-3 . Дополнения, внесенные в JIS X 0213 по сравнению с базовым стандартом JIS X 0208, привели к новой регистрации расширенной плоскости JIS 1, а новая плоскость 2 получила собственную регистрацию. Дальнейшие дополнения к плоскости 1 в редакции стандарта 2004 года привели к добавлению дополнительной регистрации к дальнейшей версии профиля, получившей название ISO-2022-JP-2004 . Помимо основных кодов обозначений ISO-2022-JP, признаются следующие обозначения:

• ESC ( I для перехода на набор Kana JIS X 0201-1976 (1 байт на символ)
• ESC $ ( O для переключения на JIS X 0213-2000 Plane 1 (2 байта на символ)
• ESC $ ( P для перехода на JIS X 0213-2000 Plane 2 (2 байта на символ)
• ESC $ ( Q для переключения на плоскость 1 JIS X 0213-2004 (2 байта на символ, только ISO-2022-JP-2004)

Другие 7-битные версии

ISO-2022-KR определен в RFC 1557 от 1993 года. Он кодирует ASCII и корейский двухбайтовый код KS X 1001-1992 . ранее назывался KS C 5601-1987. В отличие от ISO-2022-JP-2, он использует символы Shift Out и Shift In для переключения между ними после включения ESC $ ) C один раз в начале строки для обозначения от KS X 1001 до G1.

ISO-2022-CN и ISO-2022-CN-EXT определены в RFC 1922, датированном 1996 годом. Это 7-битные кодировки, в которых используются функции Shift Out и Shift In (для переключения между G0 и G1), а также 7-битный escape-код. формы односменных функций SS2 и SS3 (для доступа к G2 и G3). Они поддерживают наборы символов GB 2312 (для упрощенного китайского ) и CNS 11643 (для традиционного китайского ).

Базовый профиль ISO-2022-CN использует ASCII в качестве набора G0 (сдвиг), а также включает GB 2312 и первые две плоскости CNS 11643 (поскольку этих двух плоскостей достаточно для представления всех традиционных китайских иероглифов из обычных Big5 , к которому RFC приводит соответствие в приложении):

• ESC $ ) A для переключения на GB 2312-1980 (2 байта на символ) [обозначается G1]
• ESC $ ) G для переключения на CNS 11643-1992 Plane 1 (2 байта на символ) [обозначается G1]
• ESC $ * H для переключения на CNS 11643-1992 Plane 2 (2 байта на символ) [обозначается как G2]

Профиль ISO-2022-CN-EXT допускает следующие дополнительные наборы и плоскости.

• ESC $ ) E для переключения на ISO-IR-165 (2 байта на символ) [обозначается G1]
• ESC $ + I для переключения на CNS 11643-1992 Plane 3 (2 байта на символ) [обозначается G3]
• ESC $ + J для переключения на CNS 11643-1992 Plane 4 (2 байта на символ) [обозначается G3]
• ESC $ + K для переключения на CNS 11643-1992 Plane 5 (2 байта на символ) [обозначается G3]
• ESC $ + L для переключения на CNS 11643-1992 Plane 6 (2 байта на символ) [обозначается G3]
• ESC $ + M для переключения на CNS 11643-1992 Plane 7 (2 байта на символ) [обозначается G3]

В профиле ISO-2022-CN-EXT дополнительные стандартные графические наборы Guobiao перечислены как разрешенные, но при условии, что им присвоены зарегистрированные escape-последовательности ISO 2022:

• ГБ 12345 в G1
• GB 7589 или GB 13131 в G2
• ГБ 7590 или ГБ 13132 в G3

Персонаж после ESC (для однобайтовых наборов символов) или ESC $ (для многобайтовых наборов символов) указывает тип набора символов и назначенный рабочий набор. В приведенных выше примерах персонаж ( (0x28) обозначает набор из 94 символов в наборе символов G0, тогда как ), * или + (0x29–0x2B) обозначает наборы символов G1–G3.

ISO-2022-KR и ISO-2022-CN используются реже, чем ISO-2022-JP, и иногда намеренно не поддерживаются из соображений безопасности. Примечательно, что стандарт кодирования WHATWG , используемый HTML5 , сопоставляет ISO-2022-KR, ISO-2022-CN и ISO-2022-CN-EXT (а также HZ-GB-2312 ) с «замещающим» декодером, который сопоставляет все входные данные с символом замены (�), чтобы предотвратить определенные межсайтовые сценарии и связанные с ними атаки, которые используют разницу в поддержке кодирования между клиентом и сервером. Хотя та же проблема безопасности (позволяющая по-разному интерпретировать последовательности байтов ASCII) также применима к ISO-2022-JP и UTF-16 , они не могут быть обработаны таким образом из-за того, что они гораздо чаще используются в развернутом контенте.

В апреле 2024 года обнаружена брешь в безопасности. был найден в реализации ISO-2022-CN-EXT в glibc , что привело к рекомендациям полностью отключить кодирование в системах Linux.

ИСО/МЭК 4873

Связь между редакциями и уровнями ECMA-43 (ISO/IEC 4873) и EUC .

Подмножество ISO 2022, применяемое к 8-битным однобайтовым кодировкам, определяется стандартом ISO/IEC 4873 , также опубликованным Ecma International как ECMA-43. ISO/IEC 8859 определяет 8-битные коды для ISO/IEC 4873 (или ECMA-43) уровня 1.

ISO/IEC 4873/ECMA-43 определяет три уровня кодирования:

• Уровень 1, который включает набор C0, набор ASCII G0, дополнительный набор C1 и дополнительный однобайтовый (94- или 96-символьный) набор G1. G0 вызывается через GL, а G1 вызывается через GR. Использование функций сдвига не допускается.
• Уровень 2, который включает однобайтовый набор G2 и/или G3 (94 или 96 символов) в дополнение к обязательному набору G1. Разрешены только функции одной смены SS2 и SS3 (т.е. блокирующие сдвиги запрещены), и они вызываются в области GL (включая 0x20 и 0x7F в случае набора 96). SS2 и SS3 должны быть доступны в C1 по адресам 0x8E и 0x8F соответственно. Этот минимальный необходимый набор C1 для ISO 4873 зарегистрирован как ISO-IR-105.
• Уровень 3, который разрешает функции блокировки-переключения GR LS1R, LS2R и LS3R в дополнение к одиночным переключениям, но в остальном имеет те же ограничения, что и уровень 2.

Более ранние версии стандарта допускали присвоения не-ASCII в наборе G0 при условии, что инвариантные позиции ISO/IEC 646 были сохранены, что другие позиции были назначены пробельным (не объединяемым) символам, что 0x23 был назначен либо £ , либо #. , и этот 0x24 был назначен либо $ , либо ¤ . Например, 8-битная кодировка JIS X 0201 совместима с более ранними редакциями. Впоследствии это было изменено, чтобы полностью определить набор ISO / IEC 646: 1991 IRV / ISO-IR № 6 (ASCII).

Использование ISO/IEC 646 IRV (синхронизировано с ASCII с 1991 года) по ISO/IEC 4873 уровня 1 без набора C1 или G1, т.е. использование IRV в 8-битной среде, в которой не используются коды сдвига и высокий уровень бит всегда равен нулю, известен как ISO 4873 DV , где DV означает «Версия по умолчанию».

В случаях, когда повторяющиеся символы доступны в разных наборах, действующая редакция ISO/IEC 4873/ECMA-43 разрешает использовать эти символы только в рабочем наборе с наименьшим номером, в котором они встречаются. Например, если символ присутствует как в наборе G1, так и в наборе G3, его необходимо использовать из набора G1. Однако использование других наборов разрешено в более ранних выпусках.

ISO/IEC 8859 определяет полные кодировки на уровне 1 ISO/IEC 4873 и не допускает совместного использования нескольких частей ISO/IEC 8859. Он предусматривает, что ISO/IEC 10367 . вместо уровней 2 и 3 ISO/IEC 4873 следует использовать ISO/IEC 10367:1991 включает наборы G0 и G1, соответствующие тем, которые используются в первых девяти частях ISO/IEC 8859 (т.е. те, которые существовали по состоянию на 1991 год, когда он был опубликован), а также некоторые дополнительные наборы.

Escape-последовательности обозначения набора символов используются для идентификации или переключения между версиями во время обмена информацией только в том случае, если этого требует дополнительный протокол; в этом случае стандарт требует последовательности объявлений ISO/IEC 2022, определяющей уровень ISO/IEC 4873, за которой следует полный набор escape-символов, определяющих обозначения наборов символов для C0, C1, G0, G1, G2 и G3 соответственно (но опуская обозначения G2 и G3 для уровня 1), с F -байтом 0x7E, обозначающим пустой набор. Каждый уровень ISO/IEC 4873 имеет свою собственную последовательность объявлений ISO/IEC 2022, а именно:

Код	Шестигранник	Объявление
ESC SP L	1B 20 4C	ИСО 4873 уровень 1
ESC SP M	1B 20 4D	ИСО 4873 уровень 2
ESC SP N	1B 20 4E	ИСО 4873 уровень 3

Расширенный код Unix

Основная статья: Расширенный код Unix

переменной ширины, Расширенный код Unix (EUC) — это 8-битная система кодирования символов используемая в основном для японского , корейского и упрощенного китайского языков . Он основан на ISO 2022, и только наборы символов, соответствующие структуре ISO 2022, могут иметь формы EUC. Могут быть представлены до четырех наборов кодированных символов (в G0, G1, G2 и G3). Набор G0 вызывается через GL, набор G1 вызывается через GR, а наборы G2 и G3 (если они присутствуют) вызываются с использованием одиночных сдвигов SS2 и SS3, которые используются как байты CR (т. е. 0x8E и 0x8F соответственно) и вызывать через GR (не GL). Коды блокировки смены не используются.

страны, Код, назначенный набору G0, — это ASCII или национальный набор символов ISO 646 например KS-Roman (KS X 1003) или JIS-Roman (нижняя половина JIS X 0201 ). Следовательно, 0x5C ( обратная косая черта в US-ASCII) используется для обозначения знака иены в некоторых версиях EUC-JP и знака вона в некоторых версиях EUC-KR.

G1 используется для кодированного набора символов 94x94, представленного двумя байтами. EUC -CN Форма GB 2312 и EUC-KR являются примерами таких двухбайтовых кодов EUC. EUC-JP включает символы, представленные тремя байтами (т. е. SS3 плюс два байта), тогда как в EUC-TW один символ может занимать до четырех байтов (т. е. SS2 плюс три байта).

Сам код EUC не использует последовательности объявлений или обозначений из ISO 2022; однако это соответствует следующей последовательности из четырех последовательностей дикторов, значения которых распределяются следующим образом.

Индивидуальная последовательность	Шестнадцатеричный	Особенность EUC обозначена
ESC SP C	1B 20 43	ISO-8 (8 бит, G0 в GL, G1 в GR)
ESC SP Z	1B 20 5A	Доступ к G2 осуществляется через SS2
ESC SP [	1B 20 5B	Доступ к G3 осуществляется через SS3
ESC SP \	1B 20 5C	Односменный вызов через GR

Составной текст (X11)

Консорциум X определил профиль ISO 2022 под названием Compound Text в качестве формата обмена в 1989 году. При этом используются только четыре управляющих кода: ХТ ( 0x09), NL (новая строка, кодируется как ЛФ , 0x0A) , ЭСК ( 0x1B) и CSI (в 8-битном представлении 0x9B), с СДС ( CSI … ]) Последовательность CSI используется для управления двунаправленным текстом. Это 8-битный код, использующий G0 и G1 для GL и GR, и соответствует ISO-8859-1 . в исходном состоянии Используются следующие F-байты:

Последовательности обозначений ISO 2022, используемые в составном тексте X11 скрывать

Тип escape-последовательности	Последний байт	Графический набор
GZD4, G1D4 (для наборов из 94 символов)	B ( 0x42)	ASCII
	I ( 0x49)	JIS X 0201 катакана
	J ( 0x4A)	ИИСУС X 0201 Романтика
G1D6 (для наборов из 96 символов)	A ( 0x41)	ISO-8859-1 верхняя часть
	B ( 0x42)	ISO-8859-2 верхняя часть
	C ( 0x43)	ISO-8859-3 верхняя часть
	D ( 0x44)	ISO-8859-4 верхняя часть
	F ( 0x46)	ISO-8859-7 верхняя часть
	G ( 0x47)	ISO-8859-6 верхняя часть
	H ( 0x48)	ISO-8859-8 верхняя часть
	L ( 0x4C)	ISO-8859-5 верхняя часть
	M ( 0x4D)	ISO-8859-9 верхняя часть
GZDM4, G1DM4 (для 2-байтовых наборов)	A ( 0x41)	ГБ 2312
	B ( 0x42)	ДЖИС Х 0208
	C ( 0x43)	КС С 5601

Для указания кодировок с помощью меток X11 Compound Text определяет пять последовательностей DOCS для частного использования: ESC % / 0 ( 1B 25 2F 30) для кодировок переменной длины и ESC % / 1 через ESC % / 4 для кодировок фиксированной длины с использованием от одного до четырех байтов соответственно. Вместо использования другой escape-последовательности для возврата к ISO 2022 два байта, следующие за исходной escape-последовательностью, определяют оставшуюся длину в байтах, закодированную в базе 128 с использованием байтов. 0x80–FF. Метка кодировки включается в ISO 8859-1 перед закодированным текстом и заканчивается СТХ ( 0x02).

Сравнение с другими кодировками

Преимущества

• Поскольку весь диапазон кодировок графических символов ISO/IEC 2022 можно использовать через GL, доступные глифы существенно не ограничены невозможностью представления GR и C1, например, в системе, ограниченной 7-битными кодировками. Соответственно, это позволяет представлять в такой системе большой набор символов. Как правило, эта 7-битная совместимость на самом деле не является преимуществом, за исключением обратной совместимости со старыми системами. Подавляющее большинство современных компьютеров используют 8 бит на каждый байт.
• По сравнению с Unicode, ISO/IEC 2022 обходит унификацию Хань , используя коды последовательности для переключения между дискретными кодировками для разных восточноазиатских языков. Это позволяет избежать проблем связанные с унификацией, например трудности с поддержкой нескольких языков CJK с соответствующими вариантами символов в одном документе и шрифте.

Недостатки

• Поскольку ISO/IEC 2022 представляет собой кодировку с отслеживанием состояния, программа не может переходить в середину блока текста для поиска, вставки или удаления символов. Это делает манипуляции с текстом очень громоздкими и медленными по сравнению с кодировками без сохранения состояния. Любой переход в середину текста может потребовать резервного копирования предыдущей escape-последовательности, прежде чем можно будет интерпретировать байты, следующие за escape-последовательностью.
• Из-за особенностей ISO/IEC 2022 с отслеживанием состояния идентичный и эквивалентный символ может быть закодирован в разных наборах символов, которые могут быть обозначены как любой из G0–G3, который может быть вызван с использованием одиночных сдвигов или с использованием блокирующих сдвигов для GL или ГР. Следовательно, символы могут быть представлены разными способами, а это означает, что две визуально идентичные и эквивалентные строки не могут быть надежно сопоставлены на предмет равенства.
• Некоторые системы, такие как DICOM и некоторые клиенты электронной почты, используют вариант ISO-2022 (например, «ISO 2022 IR 100»). ) в дополнение к поддержке нескольких других кодировок. Этот тип вариаций затрудняет портативную передачу текста между компьютерными системами.
• UTF-1 , многобайтовый формат преобразования Unicode , совместимый с представлением 8-битных управляющих символов ISO/IEC 2022, имеет различные недостатки по сравнению с UTF-8 и переключением с других кодировок или на другие кодировки, поддерживаемые ISO/IEC 2022. , обычно не требуется в документах Unicode.
• Благодаря escape-последовательностям можно создавать последовательности атакующих байтов, в которых вредоносная строка (например, межсайтовый скриптинг ) маскируется до тех пор, пока она не будет декодирована в Unicode, что может позволить ей обойти очистку. Таким образом, использование этой кодировки рассматривается комплектами защиты от вредоносных программ как подозрительное. а 7-битные данные ISO 2022 (за исключением ISO-2022-JP) полностью сопоставляются с символом замены в HTML5 для предотвращения атак. Ограниченные версии 8-битного кода ISO 2022, которые не используют escape-символы обозначения или коды блокировки блокировки, такие как расширенный код Unix , не разделяют эту проблему.
• Конкатенация может создать проблемы. Такие профили, как ISO-2022-JP, указывают, что поток начинается в состоянии ASCII и должен заканчиваться в состоянии ASCII. Это необходимо для того, чтобы гарантировать, что символы в объединенных потоках ISO-2022-JP и/или ASCII будут интерпретироваться в правильном наборе. Это приводит к тому, что если поток, который заканчивается многобайтовым символом, объединяется с потоком, который начинается с многобайтового символа, генерируется пара escape-кодов, переключающихся на ASCII и сразу же от него. Однако, как указано в Техническом отчете Unicode № 36 («Вопросы безопасности Unicode»), пары escape-последовательностей ISO 2022 без символов между ними должны генерировать замещающий символ («�»), чтобы предотвратить их использование для маскировки вредоносных последовательностей, таких как как межсайтовый скриптинг . Реализация этой меры, например, в Mozilla Thunderbird , привела к проблемам совместимости, поскольку при объединении двух потоков ISO-2022-JP генерировались неожиданные символы «��».

См. также

• ИСО 2709
• ИСО/МЭК 646
• ИСО-ИР-102
• Коды управления C0 и C1
• Персонажи CJK
• стандарты MARC
• Моджибаке
• оно сияет
• ИСО/МЭК ОТК 1/ПК 2

Ссылки

Приведенные стандарты и индексы реестра

• АРИБ (2008). ARIB STD-B24: Спецификация кодирования и передачи данных для цифрового вещания (PDF) (стандарт ARIB). 5.2-Е1. Том. 1. Архивировано (PDF) из оригинала 10 июля 2017 г. Проверено 10 июля 2017 г.
• ЭКМА (1980). ECMA-35: Расширение 7-битного набора кодированных символов (PDF) (стандарт ECMA) (2-е изд.).
• ЭКМА (1994). ECMA-35: Структура кода символов и методы расширения (PDF) (стандарт ECMA) (6-е изд.).
• ЭКМА (1985). ECMA-43: Структура и правила набора 8-битных кодированных символов (PDF) (стандарт ECMA) (2-е изд.).
• ЭКМА (1991). ECMA-43: Структура и правила набора 8-битных кодированных символов (PDF) (стандарт ECMA) (3-е изд.).
• ЭКМА (1991). ECMA-48: Функции управления для наборов кодированных символов (PDF) (стандарт ECMA) (5-е изд.).
• ЭКМА (2000). ECMA-144: наборы 8-битных однобайтовых графических символов: латинский алфавит № 6 (PDF) (стандарт ECMA) (3-е изд.).
• Европейский вещательный союз (1997). ETS 300 706: Спецификация расширенного телетекста (PDF) (Европейские стандарты телекоммуникаций). ЕТСИ .
• ИСО/МЭК ОТК 1/ПК 2 (2003 г.). ISO/IEC 2375:2003: Информационные технологии. Процедура регистрации escape-последовательностей и наборов кодированных символов . ИСО . {{cite book}}: CS1 maint: числовые имена: список авторов ( ссылка )
• ISO/IEC JTC 1/SC 2 (12 февраля 1998 г.). ISO/IEC FDIS 8859-10: Информационные технологии. 8-битные однобайтовые наборы графических символов. Часть 10. Латинский алфавит № 6 (PDF) (Окончательный проект международного стандарта). {{cite book}}: CS1 maint: числовые имена: список авторов ( ссылка )
• ISO/IEC JTC 1/SC 2 (2017). ISO/IEC 10646: Информационные технологии. Универсальный набор кодированных символов (UCS) (стандарт ISO) (5-е изд.). ИСО . {{cite book}}: CS1 maint: числовые имена: список авторов ( ссылка )
• ISO-IR: Международный реестр наборов кодированных символов ISO/IEC для использования с escape-последовательностями (PDF) (указатель реестра). ITSCJ/ IPSJ .
• Шайфлер, Роберт В. (1989). Кодирование сложного текста (стандарт X Консорциума). Х Консорциум .
• ван Кестерен, Энн . Стандарт кодирования WHATWG (Живой стандарт WHATWG). ЧТОРГ .

Указаны зарегистрированные наборы кодов

• ISO/TC 97/SC 2 (1 декабря 1975 г.). ISO-IR-1: Набор управляющих символов ISO 646 (PDF) . ITSCJ/ IPSJ . {{citation}}: CS1 maint: числовые имена: список авторов ( ссылка )
• Шведская комиссия по стандартизации (1 декабря 1975 г.). ISO-IR-7: Комплект управления NATS для передачи текста газеты (PDF) . ITSCJ/ IPSJ .
• Японский комитет промышленных стандартов (1 декабря 1975 г.). ISO-IR-14: Набор японских римских графических символов (PDF) . ITSCJ/ IPSJ .
• ИПТК (25 марта 1976 г.). ISO-IR-26: Комплект управления для передачи текста газеты (PDF) . ITSCJ/ IPSJ .
• ISO/TC 97/SC 2 (15 октября 1977 г.). ISO-IR-36: набор управляющих символов ISO 646, где IS4 заменен на Single Shift для G2 (SS2) (PDF) . ITSCJ/ IPSJ . {{citation}}: CS1 maint: числовые имена: список авторов ( ссылка )
• ISO/TC97/SC2/WG-7 ; ЭКМА (1 августа 1985 г.). ISO-IR-104: Минимальный набор C0 для ISO 4873 (PDF) . ITSCJ/ IPSJ . {{citation}}: CS1 maint: числовые имена: список авторов ( ссылка )
• ISO/TC97/SC2/WG-7 ; ЭКМА (1 августа 1985 г.). ISO-IR-105: Минимальный набор C1 для ISO 4873 (PDF) . ITSCJ/ IPSJ . {{citation}}: CS1 maint: числовые имена: список авторов ( ссылка )
• МСЭ (1 августа 1985 г.). ISO-IR-106: Основной набор функций управления Teletex (PDF) . ITSCJ/ IPSJ .
• Управление стандартизации и измерений (31 июля 1987 г.). ISO-IR-140: Набор управляющих символов C0 стандарта ISO 646, с заменой EM на SS2 (PDF) . ITSCJ/ IPSJ .
• Корейское бюро стандартов (1 октября 1988 г.). ISO-IR-149: Набор корейских графических символов для обмена информацией (KS C 5601:1987) (PDF) . ITSCJ/ IPSJ .
• ISO/IEC/JTC1/SC2/WG3 (16 апреля 1990 г.). ISO-IR-155: Базовый набор чертежей коробок (PDF) . ITSCJ/ IPSJ . {{citation}}: CS1 maint: числовые имена: список авторов ( ссылка )
• МКИТТ (13 июля 1992 г.). ISO-IR-164: Дополнительный набор графических символов иврита (PDF) . ITSCJ/ IPSJ .
• ЭКМА (22 апреля 1996 г.). ISO-IR-192: Формат преобразования UCS (UTF-8), уровень реализации 3, без стандартного возврата (PDF) . ITSCJ/ IPSJ .
• ЭКМА (22 апреля 1996 г.). ISO-IR-195: Формат преобразования UCS (UTF-16), уровень реализации 3, без стандартного возврата (PDF) . ITSCJ/ IPSJ .
• ЭКМА (22 апреля 1996 г.). ISO-IR-196: Формат преобразования UCS (UTF-8) со стандартным возвратом (PDF) . ITSCJ/ IPSJ .
• Национальное управление по стандартизации Ирландии (07.12.1999). ISO-IR-208: Набор символов в кодировке Огама для обмена информацией (PDF) . ITSCJ/ IPSJ .

Интернет-запросы на комментарии цитируются

• Мурай, Дж.; Криспин, М.; ван дер Поэль, Э. (1993). «RFC 1468: Кодировка японских символов для интернет-сообщений» . Запросы на комментарии . IETF . дои : 10.17487/rfc1468 .
• Охта, М.; Ханда, К. (1993). «RFC 1554: ISO-2022-JP-2: Многоязычное расширение ISO-2022-JP» . Запросы на комментарии . IETF . дои : 10.17487/rfc1554 .
• Чой, У.; Чон, К.; Парк, Х. (1993). «RFC 1557: Корейская кодировка символов для интернет-сообщений» . Запросы на комментарии . IETF . дои : 10.17487/rfc1557 .
• Чжу, ХФ.; Ху, Д.Ю.; Ван, ЗГ .; Као, ТК; Чанг, ЧМ.; Криспин, М. (1996). «RFC 1922: Кодировка китайских символов для интернет-сообщений» . Запросы на комментарии . IETF . дои : 10.17487/rfc1922 .
• Тамару, К. (1997). «RFC 2237: Кодировка японских символов для интернет-сообщений» . Запросы на комментарии . IETF . дои : 10.17487/rfc2237 .

Другие опубликованные работы, цитируемые

• Лунде, Кен (2008). Обработка информации CJKV (2-е изд.). О'Рейли Медиа . ISBN  9780596514471 .

Дальнейшее чтение

• Лунде, Кен (1998). Обработка информации CJKV . Кембридж, Массачусетс: O'Reilly & Associates . ISBN  1-56592-224-7 .

Внешние ссылки

• ИСО/МЭК 2022:1994.
• ИСО/МЭК 2022:1994/Кор 1:1999
• ECMA-35 , эквивалент ISO/IEC 2022, доступен для бесплатной загрузки.
• Международный реестр наборов кодированных символов, которые будут использоваться с Escape-последовательностями , полный список назначенных наборов символов и их escape-последовательностей.
• История кодов символов в Северной Америке, Европе и Восточной Азии с 1999 г., ред. 2004 г.
• Кена Лунде : CJK.INF документ по кодированию китайского, японского и корейского (CJK) языков, включая обсуждение различных вариантов ISO/IEC 2022.