ИСО/МЭК 2022

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

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

ISO 2022 сам по себе также определяет конкретные управляющие коды и управляющие последовательности, которые могут использоваться для переключения между различными кодированными наборами символов (например, между ASCII и японским JIS X 0208 ), чтобы использовать несколько в одном документе, ^[7] эффективно объединяя их в единую кодировку с сохранением состояния (функция, менее важная с появлением Unicode ). Он разработан для использования как в 8-битных, так и в 7-битных средах (те, где в байте можно использовать только семь бит, например, электронная почта без 8BITMIME ). ^[8]

Набор символов ASCII поддерживает алфавит ISO Basic Latin (эквивалент английского алфавита ) и не обеспечивает хорошей поддержки для языков, которые используют дополнительные буквы или которые используют другую систему письма вообще. Другие системы письма с относительно небольшим количеством символов, такие как греческий , кириллический , арабский или иврит , а также формы латинского алфавита, использующие диакритические знаки или буквы, отсутствующие в алфавите ISO Basic Latin, исторически были представлены на персональных компьютерах с различными 8- битными , однобайтовыми , расширенными кодировками ASCII, которые следуют за ASCII, когда старший бит равен 0 (т. е. байты 0x00–7F, когда представлены в шестнадцатеричном виде ), и включают дополнительные символы для старшего бита 1 (т. е. байты 0x80–FF). Некоторые из них, такие как серия ISO 8859 , соответствуют ISO 2022, ^{[9] [10],} в то время как другие, такие как кодовая страница DOS 437, не соответствуют, обычно из-за того, что байты 0x80–9F не зарезервированы для управляющих кодов.

Некоторые восточноазиатские языки, в частности китайский , японский и корейский (совместно именуемые « CJK »), пишутся с использованием гораздо большего количества символов, чем максимум 256, которые могут быть представлены в одном байте, и впервые были представлены на компьютерах с языковыми двухбайтовыми кодировками или кодировками переменной ширины ; некоторые из них (например, упрощенная китайская кодировка GB 2312 ) соответствуют ISO 2022 , в то время как другие (например, традиционная китайская кодировка Big5 ) — нет. Управляющие коды в ISO 2022 всегда представлены одним байтом, независимо от количества байтов, используемых для графических символов. Кодировки CJK, используемые в 7-битных средах, которые используют механизмы ISO 2022 для переключения между наборами символов, часто получают имена, начинающиеся с «ISO-2022-», в первую очередь ISO-2022-JP, хотя некоторые другие кодировки CJK, такие как EUC-JP, также используют механизмы ISO 2022. ^{[11] [12]}

Поскольку первые 256 кодовых точек Unicode были взяты из ISO 8859-1 , Unicode наследует концепцию управляющих кодов C0 и C1 из ISO 2022, хотя он добавляет другие непечатаемые символы помимо управляющих кодов ISO 2022. Однако форматы преобразования Unicode , такие как UTF-8, обычно отклоняются от структуры ISO 2022 различными способами, включая:

• Используют 8-битные байты, но не представляют коды C1 в их однобайтовых формах, указанных в ISO 2022 (большинство UTF, за исключением устаревшего UTF-1 )
• Представление всех символов, включая управляющие коды, с помощью нескольких байтов (например, UTF-16 , UTF-32 )
• Смешивание байтов с установленным и неустановленным старшим битом в кодированном представлении для одной кодовой точки (например, UTF-1, GB 18030 )

Однако существуют управляющие последовательности ISO 2022 для переключения в UTF-8 и обратно как «систему кодирования, отличную от ISO 2022» ^[13] , которые поддерживаются некоторыми эмуляторами терминала, такими как xterm . ^[14]

Стандарт ISO/IEC 2022 определяет следующее:

• Инфраструктура из нескольких наборов символов с определенными структурами, которые могут быть включены в единую систему кодирования символов , включая несколько графических наборов символов и несколько наборов как первичных (C0), так и вторичных (C1) управляющих кодов , ^[15]
• Формат кодирования этих наборов, предполагающий, что на байт приходится 8 бит, ^[16]
• Формат для кодирования этих наборов в той же системе кодирования, когда на байт доступно только 7 бит, ^[17] и метод преобразования любых соответствующих символьных данных для прохождения через такую ​​7-битную среду, ^[8]
• Общая структура управляющих кодов ANSI , ^[6] и
• Специальные форматы управляющих кодов для идентификации отдельных наборов символов ^[7] , для объявления использования определенных функций кодирования или подмножеств ^{[18] , а также для взаимодействия с другими системами кодирования или переключения на них [18]} .

Конкретная реализация не обязательно должна реализовывать весь стандарт; уровень соответствия и поддерживаемые наборы символов определяются реализацией. Хотя многие из механизмов, определенных стандартом ISO/IEC 2022, используются нечасто, несколько установленных кодировок основаны на подмножестве системы ISO/IEC 2022. ^[19] В частности, 7-битные системы кодирования, использующие механизмы ISO/IEC 2022, включают ISO-2022-JP (или кодировку JIS ), которая в основном использовалась в электронной почте на японском языке . 8-битные системы кодирования, соответствующие ISO/IEC 2022, включают ISO/IEC 4873 (ECMA-43), который, в свою очередь, соответствует ISO/IEC 8859 , ^{[9] [10]} и Extended Unix Code , который используется для восточноазиатских языков. ^[11] Более специализированные приложения ISO 2022 включают систему кодирования MARC-8 , используемую в библиотечных записях MARC 21. ^[3]

Escape-последовательности для переключения на определенные наборы символов или кодировки регистрируются в реестре ISO-IR (за исключением тех, которые выделены для частного использования, значения которых определяются поставщиками или спецификациями протоколов, такими как ARIB STD-B24 ) и следуют шаблонам, определенным в стандарте. Кодировки символов, использующие эти escape-последовательности, требуют последовательной обработки данных в прямом направлении, поскольку правильная интерпретация данных зависит от ранее встреченных escape-последовательностей.

Определенные профили, такие как ISO-2022-JP, могут налагать дополнительные условия, например, что текущий набор символов сбрасывается на US-ASCII перед концом строки. Кроме того, escape-последовательности, объявляющие национальные наборы символов, могут отсутствовать, если конкретная кодировка на основе ISO-2022 разрешает или требует этого и предписывает использовать определенные национальные наборы символов. Например, ISO-8859-1 утверждает, что определяющая escape-последовательность не нужна.

Для представления больших наборов символов ISO/IEC 2022 основывается на свойстве ISO/IEC 646 , согласно которому семибитное представление символа обычно способно представлять 94 графических (печатаемых) символа (в дополнение к пробелу и 33 управляющим символам); если исключить только управляющие коды C0 (узко определенные), это можно расширить до 96 символов. Используя два байта, таким образом, можно представить до 8836 (94×94) символов; а используя три байта, до 830 584 (94×94×94) символов. Хотя стандарт определяет это, ни один зарегистрированный набор символов не использует три байта (хотя незарегистрированный G2 EUC-TW делает это, как и аналогичный незарегистрированный CCCII ).

Для двухбайтовых наборов символов кодовая точка каждого символа обычно указывается в так называемой форме строка-ячейка или кутэн ^[a] , которая состоит из двух чисел от 1 до 94 включительно, определяющих строку ^[b] и ячейку ^[c] этого символа в зоне. Для трехбайтового набора в начале указывается дополнительный номер плоскости ^{[d] . [20]} Управляющие последовательности не только объявляют, какой набор символов используется, но и является ли набор однобайтовым или многобайтовым (хотя и не сообщают, сколько байтов он использует, если он многобайтовый), а также имеет ли каждый байт 94 или 96 разрешенных значений.

Кодировка ISO/IEC 2022 определяет двухслойное отображение между кодами символов и отображаемыми символами. Escape-последовательности позволяют «назначить» ^[21] любой из большого реестра графических наборов символов в один из четырех рабочих наборов, называемых G0–G3, а более короткие управляющие последовательности указывают рабочий набор, который «вызывается» ^[22] для интерпретации байтов в потоке.

Кодирование значений байтов («комбинации битов») часто приводится в столбцово-строчной нотации , где два десятичных числа в диапазоне 00–15 (каждое соответствует одной шестнадцатеричной цифре) разделены косой чертой. ^[23] Следовательно, например, коды от 2/0 (0x20) до 2/15 (0x2F) включительно могут называться «столбцом 02». Это нотация, используемая в самом стандарте ISO/IEC 2022 / ECMA-35. ^[24] Они могут быть описаны в другом месте с использованием шестнадцатеричной системы счисления , как это часто используется в этой статье, или с использованием соответствующих символов ASCII, ^[25] хотя escape-последовательности фактически определяются в терминах байтовых значений, и графика, назначенная этому байтовому значению, может быть изменена без влияния на управляющую последовательность.

Значения байтов из 7-битного графического диапазона ASCII (шестнадцатеричное 0x20–0x7F), находящиеся в левой части таблицы кодов символов, называются кодами «GL» (где «GL» означает «графика слева»), в то время как байты из диапазона «high ASCII» (0xA0–0xFF), если они доступны (т. е. в 8-битной среде), называются кодами «GR» («графика справа») . ^[5] Термины «CL» (0x00–0x1F) и «CR» (0x80–0x9F) определены для диапазонов управления, но диапазон CL всегда вызывает первичные (C0) элементы управления, тогда как диапазон CR всегда либо вызывает вторичные (C1) элементы управления, либо не используется. ^[5]

Символ удаления DEL (0x7F), символ перехода ESC (0x1B) и символ пробела SP (0x20) обозначены как "фиксированные" кодированные символы ^[26] и всегда доступны, когда G0 вызывается через GL, независимо от того, какие наборы символов обозначены. Они не могут быть включены в графические наборы символов, хотя другие размеры или типы пробельных символов могут быть включены. ^[27]

Последовательности, использующие символ ESC (escape), имеют вид , где за символом ESC следует ноль или более промежуточных байтов ^[28] ( I ) из диапазона 0x20–0x2F и один конечный байт ^[29] ( F ) из диапазона 0x30–0x7E. ^[30]ESC [I...] F

Первый байт I или его отсутствие определяет тип escape-последовательности; он может, например, обозначать рабочий набор или обозначать одну функцию управления. Во всех типах escape-последовательностей байты F в диапазоне 0x30–0x3F зарезервированы для незарегистрированного частного использования, определенного предварительным соглашением между сторонами. ^[31]

Функции управления из некоторых наборов могут использовать дополнительные байты, следующие за escape-последовательностью. Например, функция управления ISO 6429 " Control Sequence Introducer ", которая может быть представлена ​​с помощью escape-последовательности, сопровождается нулем или более байтов в диапазоне 0x30–0x3F, затем нулем или более байтов в диапазоне 0x20–0x2F, затем одним байтом в диапазоне 0x40–0x7E, вся последовательность называется "control sequence". ^[32]

Каждый из четырех рабочих наборов G0–G3 может быть набором из 94 символов или многобайтовым набором из 94 ⁿ символов . Кроме того, наборы G1–G3 могут быть наборами из 96 или 96 ⁿ символов.

В наборе символов 96 или 96 ⁿ байты 0x20 — 0x7F при вызове GL или 0xA0 — 0xFF при вызове GR выделяются набору и могут им использоваться. В наборе символов 94 или 94 ⁿ байты 0x20 и 0x7F не используются. ^[33] Когда набор символов 96 или 96 ⁿ вызывается в регионе GL, символы пробела и удаления (коды 0x20 и 0x7F) недоступны, пока набор символов 94 или 94 ⁿ (например, набор G0) не будет вызван в GL. ^[5] Наборы символов 96 не могут быть назначены для G0.

Регистрация набора как 96-символьного набора не обязательно означает, что байты 0x20/A0 и 0x7F/FF фактически назначены набором; некоторые примеры графических наборов символов, которые зарегистрированы как 96-символьные наборы, но не используют эти байты, включают набор G1 IS 434 ^[34] , набор чертежей коробок из ISO/IEC 10367 [ ^35] и ISO-IR-164 (подмножество набора G1 ISO-8859-8 только с буквами, используемое CCITT ). ^[36]

Предполагается, что символы будут пробельными, а не объединяющими символами, если иное не указано в рассматриваемом графическом наборе. ^[37] ISO 2022 / ECMA-35 также признает использование управляющих символов возврата на одну позицию и возврата каретки в качестве средств объединения иных пробельных символов, а также последовательности CSI «Комбинация графических символов» (GCC) ^[37] ( CSI 0x20 (SP) 0x5F (_)). ^[38]

Использование возврата каретки и возврата на одну позицию таким образом разрешено стандартом ISO/IEC 646 , но запрещено стандартами ISO/IEC 4873 / ECMA-43 ^[39] и ISO/IEC 8859 [ ^{40] [41]} на том основании, что это оставляет набор графических символов неопределенным. Однако стандарт ISO/IEC 4873 / ECMA-43 разрешает использование функции GCC при условии, что последовательность символов остается неизменной и просто отображается в одном месте, а не перепечатывается для формирования символа с другим значением. ^[42]

Наборы управляющих символов классифицируются как «первичные» или «вторичные» наборы управляющих кодов, ^[43] соответственно также называемые наборами управляющих кодов «C0» и «C1». ^[44]

Набор элементов управления C0 должен содержать управляющий символ ESC (escape) по адресу 0x1B ^[45] (набор C0, содержащий только ESC, зарегистрирован как ISO-IR-104), ^[46] тогда как набор элементов управления C1 может вообще не содержать управляющий символ ESC. ^[33] Следовательно, это совершенно отдельные регистрации, при этом набор C0 является только набором C0, а набор C1 является только набором C1. ^[44]

Если коды из набора C0 ISO 6429 / ECMA-48, т. е. управляющие коды ASCII , появляются в наборе C0, они должны появляться в своих местах ISO 6429 / ECMA-48. ^[45] Включение символов управления передачей в набор C0, помимо десяти, включенных ISO 6429 / ECMA-48 (а именно SOH, STX, ETX, EOT, ENQ, ACK, DLE, NAK, SYN и ETB), ^[47] или включение любого из этих десяти в набор C1 также запрещено стандартом ISO/IEC 2022 / ECMA-35. ^{[45] [33]}

Набор элементов управления C0 вызывается в диапазоне CL от 0x00 до 0x1F, ^[48] тогда как функция управления C1 может вызываться в диапазоне CR от 0x80 до 0x9F (в 8-битной среде) или с помощью escape-последовательностей (в 7-битной или 8-битной среде), ^[43] , но не обоими способами. Какой стиль вызова C1 используется, должно быть указано в определении версии кода. ^[49] Например, ISO/IEC 4873 определяет байты CR для элементов управления C1, которые он использует (SS2 и SS3). ^[50] При необходимости, какой вызов используется, может быть сообщено с помощью последовательностей оповещателей.

В последнем случае отдельные функции управления из набора управляющих кодов C1 вызываются с использованием escape-последовательностей «типа Fe», ^[33] то есть тех, где за управляющим символом ESC следует байт из столбцов 04 или 05 (то есть, ESC 0x40 (@)до ESC 0x5F (_)). ^[51]

Дополнительные функции управления назначаются escape-последовательностям типа «Fs» (в диапазоне ESC 0x60 (`)до ESC 0x7E (~)); они имеют постоянно назначенные значения, а не зависят от обозначений C0 или C1. ^{[51] [52]} Регистрация функций управления для последовательностей типа «Fs» должна быть одобрена ISO/IEC JTC 1/SC 2. [ ^52] Другие отдельные функции управления могут быть зарегистрированы для escape-последовательностей типа «3Ft» (в диапазоне до ), ^[53] хотя в настоящее время последовательности «3Ft» не назначены (по состоянию на 2019 год). ^[54] Некоторые из них указаны в ECMA-35 (ISO 2022 / ANSI X3.41), другие в ECMA-48 (ISO 6429 / ANSI X3.64). ^[55] ECMA-48 называет их «независимыми функциями управления». ^[56]ESC 0x23 (#) [I...] 0x40 (@)ESC 0x23 (#) [I...] 0x7E (~)

Escape-последовательности типа «Fp» ( ESC 0x30 (0)через ESC 0x3F (?)) или типа «3Fp» ( через ) зарезервированы для кодов управления одноразового частного использования по предварительному соглашению между сторонами. ^[58] Несколько таких последовательностей обоих типов используются терминалами DEC , такими как VT100 , и, таким образом, поддерживаются эмуляторами терминалов . ^[14]ESC 0x23 (#) [I...] 0x30 (0)ESC 0x23 (#) [I...] 0x3F (?)

По умолчанию коды GL указывают символы G0, а коды GR (где доступно) указывают символы G1; это может быть указано иным образом по предварительному соглашению. Набор, вызываемый для каждой области, также может быть изменен с помощью кодов управления, называемых сдвигами, как показано в таблице ниже. ^[59]

8-битный код может иметь коды GR, указывающие символы G1, то есть с соответствующим 7-битным кодом, использующим Shift In и Shift Out для переключения между наборами (например, JIS X 0201 ), ^[60] хотя некоторые вместо этого имеют коды GR, указывающие символы G2, с соответствующим 7-битным кодом, использующим код с одним сдвигом для доступа ко второму набору (например, T.51 ). ^[61]

Коды, показанные в таблице ниже, являются наиболее распространенными кодировками этих управляющих кодов, соответствующими стандарту ISO/IEC 6429. Сдвиги LS2, LS3, LS1R, LS2R и LS3R регистрируются как отдельные управляющие функции и всегда кодируются как escape-последовательности, перечисленные ниже, ^[54] тогда как другие являются частью набора управляющих кодов C0 или C1 (как показано ниже, SI (LS0) и SO (LS1) являются управляющими элементами C0, а SS2 и SS3 являются управляющими элементами C1), что означает, что их кодирование и доступность могут различаться в зависимости от того, какие управляющие наборы обозначены: они должны присутствовать в обозначенных управляющих наборах, если используется их функциональность. ^{[48] [49]} Сами управляющие элементы C1, как упоминалось выше, могут быть представлены с использованием escape-последовательностей или 8-битных байтов, но не того и другого.

Альтернативные кодировки одиночных сдвигов в качестве кодов управления C0 доступны в определенных наборах кодов управления. Например, SS2 и SS3 обычно доступны в 0x19 и 0x1D соответственно в T.51 ^[61] и T.61 . ^[62] Это кодирование в настоящее время рекомендуется ISO/IEC 2022 / ECMA-35 для приложений, требующих 7-битных однобайтовых представлений SS2 и SS3, ^[63] и может также использоваться только для SS2, ^[64] хотя существуют также более старые наборы кодов с SS2 в 0x1C, ^{[65] [66] [67]} и упоминались как таковые в более ранней редакции стандарта. ^[68] Кодировка 0x8E и 0x8F одиночных сдвигов, как показано ниже, является обязательной для уровней 2 и 3 ISO/IEC 4873. ^[69]

Хотя официально они считаются кодами сдвига и называются соответственно, коды с одним сдвигом не всегда рассматриваются как сдвиги, ^[12] и их можно просто рассматривать как префиксные байты (т. е. первые байты в многобайтовой последовательности), ^[11] поскольку они не требуют, чтобы кодер сохранял текущий активный набор как состояние , в отличие от кодов с блокировкой сдвига. В 8-битных средах в качестве области с одним сдвигом может использоваться либо GL, либо GR, но не оба. Это должно быть указано в определении версии кода. ^[72] Например, ISO/IEC 4873 определяет GL, тогда как упакованный EUC определяет GR. В 7-битных средах в качестве области с одним сдвигом используется только GL. ^{[74] [75]} При необходимости, какая область с одним сдвигом используется, можно сообщить с помощью последовательностей диктора.

Названия «locking shift zero» (LS0) и «locking shift one» (LS1) относятся к той же паре управляющих символов C0 (0x0F и 0x0E), что и названия «shift in» (SI) и «shift out» (SO). Однако стандарт называет их LS0 и LS1, когда они используются в 8-битных средах, и SI и SO, когда они используются в 7-битных средах. ^[59]

Стандарт ISO/IEC 2022 / ECMA-35 допускает, но не рекомендует, одновременное использование G1, G2 или G3 как в GL, так и в GR. ^[76]

Международный регистр кодированных наборов символов ISO для использования с escape-последовательностями (ISO-IR) содержит список графических наборов символов, наборов управляющих кодов, отдельных управляющих кодов и т. д., которые были зарегистрированы для использования с ISO/IEC 2022. Процедура регистрации кодов и наборов в реестре ISO-IR определена в ISO/IEC 2375. Каждая регистрация получает уникальную escape-последовательность и уникальный номер записи в реестре для ее идентификации. ^{[77] [78]} Например, набор символов CCITT для упрощенного китайского языка известен как ISO-IR-165 .

Регистрация кодированных наборов символов в реестре ISO-IR определяет документы, определяющие набор символов или функцию управления, связанную с escape-последовательностью ISO/IEC 2022, не предназначенной для частного использования. Это может быть стандартный документ; однако регистрация не создает новый стандарт ISO, не обязывает ISO или IEC принять его в качестве международного стандарта и не обязывает ISO или IEC добавлять какие-либо его символы в Универсальный набор кодированных символов . ^[79]

Зарегистрированные в ISO-IR escape-последовательности также используются инкапсулированными в формальный публичный идентификатор для идентификации наборов символов, используемых для числовых ссылок на символы в SGML (ISO 8879). Например, строка ISO 646-1983//CHARSET International Reference Version (IRV)//ESC 2/5 4/0может использоваться для идентификации международной справочной версии ISO 646 -1983, ^[80] а спецификация HTML 4.01 использует ISO Registration Number 177//CHARSET ISO/IEC 10646-1:1993 UCS-4 with implementation level 3//ESC 2/5 2/15 4/6для идентификации Unicode. ^[81] Текстовое представление escape-последовательности, включенное в третий элемент FPI, будет распознаваться реализациями SGML для поддерживаемых наборов символов. ^[80]

Escape-последовательности для обозначения наборов символов имеют вид . Как упоминалось выше, промежуточные ( I ) байты находятся в диапазоне 0x20–0x2F, а последний ( F ) байт находится в диапазоне 0x30–0x7E. Первый байт I (или, для многобайтового набора, первые два) идентифицирует тип набора символов и рабочий набор, к которому он должен быть привязан, тогда как байт F (и любые дополнительные байты I ) идентифицируют сам набор символов, как назначено в регистре ISO-IR (или, для escape-последовательностей частного использования, по предварительному соглашению).ESC I [I...] F

Дополнительные байты I могут быть добавлены перед байтом F для расширения диапазона байтов F. В настоящее время это используется только с 94-символьными наборами, где были назначены коды формы . ^[82] С другой стороны, не было зарегистрировано ни одного многобайтового 96-набора, поэтому последовательности ниже являются строго теоретическими.ESC ( ! F

Как и в случае с другими типами escape-последовательностей, диапазон 0x30–0x3F зарезервирован для байтов F частного использования , ^[31] в данном случае для определений наборов символов частного использования (которые могут включать незарегистрированные наборы, определенные такими протоколами, как ARIB STD-B24 ^[83] или MARC-8 , ^[3] или наборы, специфичные для поставщика, такие как DEC Special Graphics ). ^[84] Однако в последовательности обозначения графического набора, если второй байт I (для однобайтового набора) или третий байт I (для двухбайтового набора) равен 0x20 (пробел), обозначенный набор является « динамически переопределяемым набором символов » (DRCS), определенным по предварительному соглашению, ^[85] который также считается частным использованием. ^[31] Графический набор, рассматриваемый как DRCS, подразумевает, что он представляет собой шрифт точных глифов, а не набор абстрактных символов. ^[86] Способ передачи, распределения и управления наборами DRCS и связанными с ними шрифтами не предусмотрен самим ISO/IEC 2022 / ECMA-35, хотя он рекомендует выделять их последовательно, начиная с байта F@ 0x40 ( ); ^[87] однако способ передачи шрифтов DRCS определен в некоторых телекоммуникационных протоколах, таких как World System Teletext . ^[88]

Также есть три особых случая для многобайтовых кодов. Кодовые последовательности ESC $ @, ESC $ A, и ESC $ Bбыли зарегистрированы, когда современная версия стандарта допускала многобайтовые наборы только в G0, поэтому должны быть приняты вместо последовательностей , ESC $ ( @чтобы ESC $ ( Bобозначить набор символов G0. ^[89]

Существуют дополнительные (редко используемые) функции для переключения наборов управляющих символов, но это одноуровневый поиск, в котором (как отмечено выше) набор C0 всегда вызывается через CL, а набор C1 всегда вызывается через CR или с использованием escape-кодов. Как отмечено выше, требуется, чтобы любой набор символов C0 включал символ ESC в позиции 0x1B, чтобы были возможны дальнейшие изменения. Последовательности обозначения управляющего набора (в отличие от графических наборов) также могут использоваться из ISO/IEC 10646 (UCS/Unicode) в контекстах, где обработка escape-кодов ANSI уместна, при условии, что каждый байт в последовательности дополняется до размера кодовой единицы кодировки. ^[90]

Ниже приведена таблица байтов escape-последовательности I и обозначение или другая функция, которую они выполняют. ^[91]

Обратите внимание, что реестр байтов F независим для разных типов. 94-символьный графический набор, обозначенный through ESC ( A, ESC + Aникак не связан с 96-символьным набором, обозначенным ESC - Athrough ESC / A. И ни один из них не связан с 94 ^n- символьным набором, обозначенным ESC $ ( Athrough ESC $ + A, и так далее; последние байты должны интерпретироваться в контексте. (Действительно, без каких-либо промежуточных байтов, ESC Aэто способ указания управляющего кода C1 0x81.)

Также обратите внимание, что наборы управляющих символов C0 и C1 независимы; набор управляющих символов C0, обозначенный ESC ! A(который является набором управляющих символов NATS для передачи газетного текста), не совпадает с набором управляющих символов C1, обозначенным ESC " A( набором управляющих атрибутов CCITT для Videotex ).

Стандарт также определяет способ указания систем кодирования, которые не следуют его собственной структуре.

Последовательность также определена для возврата к ISO/IEC 2022; регистрации, которые поддерживают эту последовательность, закодированную в ISO/IEC 2022, включают (по состоянию на 2019 год) различные форматы Videotex , UTF-8 и UTF-1 . ^[99] Второй байт I 0x2F ( /) включен в последовательности обозначений кодов, которые не используют эту последовательность байтов для возврата к ISO 2022; у них могут быть свои собственные средства для возврата к ISO 2022 (например, другая или дополненная последовательность) или вообще никаких. ^[100] Все существующие регистрации последнего типа (по состоянию на 2019 год) представляют собой либо прозрачные необработанные данные, либо форматы Unicode/UCS , либо их подмножества. ^[101]

Особый интерес представляют последовательности, которые переключаются на форматы ISO/IEC 10646 ( Unicode ), которые не следуют структуре ISO/IEC 2022. К ним относятся UTF-8 (который не резервирует диапазон 0x80–0x9F для управляющих символов), его предшественник UTF-1 (который смешивает байты GR и GL в многобайтовых кодах), а также UTF-16 и UTF-32 (которые используют более широкие единицы кодирования). ^{[99] [101]}

Несколько кодов были также зарегистрированы для подмножеств (уровней 1 и 2) UTF-8, UTF-16 и UTF-32, а также для трех уровней UCS-2 . ^[101] Однако единственными кодами, указанными в настоящее время ISO/IEC 10646, являются коды уровня 3 для UTF-8, UTF-16 и UTF-32 и код неопределенного уровня для UTF-8, а остальные перечислены как устаревшие. ^[103] ISO/IEC 10646 предусматривает, что форматы с обратным порядком байтов UTF-16 и UTF-32 обозначаются их escape-последовательностями. ^[104]

Из последовательностей переключения на UTF-8, ESC % Gподдерживается, например, xterm . ^[14]

Хотя использование варианта стандартной последовательности возврата из UTF-16 и UTF-32 разрешено, байты escape-последовательности должны быть дополнены до размера кодовой единицы кодировки (т. е. 001B 0025 0040для UTF-16), т. е. кодировка стандартной последовательности возврата не соответствует в точности ISO/IEC 2022. По этой причине обозначения для UTF-16 и UTF-32 используют синтаксис без стандартного возврата. ^[107]

Для указания кодировок с помощью меток формат Compound Text консорциума X определяет пять последовательностей DOCS для частного использования. ^[108]

Последовательность "announce code structure" ( ) используется для объявления определенной структуры кода или определенной группы объектов ISO 2022, которые используются в определенной версии кода. Хотя объявления можно комбинировать, некоторые противоречивые комбинации (в частности, использование блокирующих объявлений сдвига 16–23 с объявлениями 1, 3 и 4) запрещены стандартом, как и использование дополнительных объявлений поверх объявлений уровня ISO/IEC 4873 12–14 ^[92] (которые полностью определяют допустимые структурные особенности). Последовательности объявлений следующие:ESC SP (0x20) F

Шесть 7-битных версий кода ISO 2022 (ISO-2022-CN, ISO-2022-CN-EXT, ISO-2022-JP, ISO-2022-JP-1, ISO-2022-JP-2 и ISO-2022-KR) определены в документах IETF RFC , из которых ISO-2022-JP и ISO-2022-KR широко использовались в прошлом. ^[109] Ряд других вариантов определены поставщиками, включая IBM . ^[110] Хотя UTF-8 является предпочтительной кодировкой в ​​HTML5 , устаревший контент в ISO-2022-JP остается достаточно распространенным, поэтому стандарт кодирования WHATWG сохраняет его поддержку, ^[111] в отличие от сопоставления ISO-2022-KR, ISO-2022-CN и ISO-2022-CN-EXT ^[112] полностью с заменяющим символом , ^[113] из-за опасений по поводу атак с внедрением кода, таких как межсайтовый скриптинг . ^{[111] [113]}

Версии 8-битного кода включают Extended Unix Code . ^{[11] [12]} Кодировки ISO/IEC 8859 также следуют ISO 2022 в подмножестве, предусмотренном в ISO/IEC 4873. ^{[9] [10]}

ISO-2022-JP — широко используемая кодировка для японского языка, в частности, вэлектронной почте. Она была введена для использования в сети JUNET и позже кодифицирована вIETF RFC1468 от 1993 года.^[114]Она имеет преимущество перед другимикодировками для японского языкав том, что не требует8-битной чистойпередачи. Microsoft называет еекодовой страницей 50220.[^115]Она начинается в ASCII и включает следующие escape-последовательности:

• ESC ( Bдля переключения в ASCII (1 байт на символ)
• ESC ( Jдля перехода на JIS X 0201-1976 (ISO/IEC 646:JP) Roman set (1 байт на символ)
• ESC $ @для перехода на JIS X 0208-1978 (2 байта на символ)
• ESC $ Bдля перехода на JIS X 0208-1983 (2 байта на символ)

Использование двух символов, добавленных в JIS X 0208-1990, разрешено, но без включения последовательности IRR, т.е. с использованием той же escape-последовательности, что и в JIS X 0208-1983. ^[114] Кроме того, из-за регистрации до того, как стало возможным обозначение многобайтовых наборов, за исключением G0, escape-последовательности для JIS X 0208 не включают второй I -байт (. ^[89]

RFC отмечает, что некоторые существующие системы не отличали ESC ( Bот ESC ( J, или не отличали ESC $ @от ESC $ B, но оговаривает, что управляющие последовательности не должны изменяться системами, просто передающими сообщения, такие как электронные письма. ^[114] Стандарт кодирования WHATWG , на который ссылается HTML5, обрабатывает ESC ( Bи ESC ( Jпо-разному, но обрабатывает ESC $ @так же, как ESC $ Bпри декодировании, и использует только ESC $ Bдля JIS X 0208 при кодировании. ^[116] RFC также отмечает, что некоторые прошлые системы ошибочно использовали последовательность ESC ( Hдля переключения с JIS X 0208, который на самом деле зарегистрирован для ISO-IR-11 (шведский вариант ISO 646 и Всемирной системы телетекста ). ^{[114] [i]}

Использование для ESC ( Iпереключения на набор JIS X 0201-1976 Kana (1 байт на символ) не является частью профиля ISO-2022-JP, ^[114] , но иногда также используется. Python допускает это в варианте, который он называет ISO-2022-JP-EXT (который также включает JIS X 0212, как описано ниже, завершая покрытие EUC-JP ); ^{[117] [118]} это близко как по названию, так и по структуре к кодировке, обозначенной ISO-2022-JPext по DEC , которая, кроме того, добавляет двухбайтовую определяемую пользователем область , доступ к которой осуществляется с помощью ESC $ ( 0для завершения покрытия Super DEC Kanji . ^[119] Вариант WHATWG/HTML5 допускает декодирование катаканы JIS X 0201 во входных данных ISO-2022-JP, но преобразует символы в их эквиваленты JIS X 0208 при кодировании. ^[116] Кодовая страница Microsoft для ISO-2022-JP с дополнительно разрешенной JIS X 0201 kana — это кодовая страница 50221. [ ^115]

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

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

• 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 , расширенный набор Latin 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 года. ^[122]

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». ^[123] CCSID 9148 — это стандарт (RFC 1468) ISO-2022-JP. ^[124]

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

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

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

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

• 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 допускает следующие дополнительные наборы и плоскости. ^[136]

• 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 , которые разрешены, но при условии, что им назначены зарегистрированные управляющие последовательности ISO 2022: ^[136]

• ГБ 12345 в G1
• GB 7589 или GB 13131 в G2
• GB 7590 или GB 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 ) с декодером «замены», ^[112] который сопоставляет все входные данные с символом замены (�), чтобы предотвратить определенный межсайтовый скриптинг и связанные с ним атаки, которые используют разницу в поддержке кодировки между клиентом и сервером. ^[113] Хотя та же проблема безопасности (позволяющая по-разному интерпретировать последовательности байтов ASCII) также применима к ISO-2022-JP и UTF-16 , им нельзя было дать такую ​​обработку из-за того, что они гораздо чаще использовались в развернутом контенте. ^[111]

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

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

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

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

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

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

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

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

Последовательности 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, которая выглядит следующим образом: ^[147]

Расширенный код 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). ^[11] Коды сдвига блокировки не используются. ^[12]

Код, назначенный набору G0, — это ASCII или национальный набор символов ISO 646 страны , такой как KS-Roman (KS X 1003) или JIS-Roman (нижняя половина JIS X 0201 ). ^[11] Таким образом, 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; однако он соответствует следующей последовательности из четырех последовательностей оповещателей, значения которых разбиваются следующим образом. ^[148]

X Consortium определил профиль ISO 2022 под названием Compound Text в качестве формата обмена в 1989 году. ^[149] Он использует только четыре управляющих кода: HT ( ), NL (перевод строки, закодированный как LF , ) , ESC ( ) и CSI (в его 8-битном представлении ), ^[150] с последовательностью SDS ( ) CSI, используемой для управления двунаправленным текстом. ^[151] Это 8-битный код, использующий G0 и G1 для GL и GR, и соответствующий ISO-8859-1 в своем исходном состоянии. ^[152] Используются следующие F-байты:0x090x0A 0x1B0x9BCSI … ]

Для указания кодировок метками X11 Compound Text определяет пять последовательностей DOCS для частного использования: ESC % / 0( 1B 25 2F 30) для кодировок переменной длины и ESC % / 1через ESC % / 4для кодировок фиксированной длины, используя от одного до четырех байтов соответственно. Вместо того, чтобы использовать другую escape-последовательность для возврата к ISO 2022 , два байта, следующие за начальной escape-последовательностью, указывают оставшуюся длину в байтах, закодированную в base-128 с помощью bytes 0x80–FF. Метка кодировки включена в ISO 8859-1 перед закодированным текстом и заканчивается STX ( ). ^[108]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 или GR. Следовательно, символы могут быть представлены несколькими способами, что означает, что две визуально идентичные и эквивалентные строки не могут быть надежно сравнены на предмет равенства.
• Некоторые системы, такие как DICOM и несколько почтовых клиентов, используют вариант ISO-2022 (например, «ISO 2022 IR 100» ^[154] ) в дополнение к поддержке нескольких других кодировок. ^[155] Этот тип вариаций затрудняет переносимость текста между компьютерными системами.
• UTF-1 — многобайтовый формат преобразования Unicode , совместимый с представлением 8-битных управляющих символов ISO/IEC 2022, — имеет ряд недостатков по сравнению с UTF-8 , а переключение с других наборов символов или на другие наборы символов, поддерживаемые ISO/IEC 2022, обычно не требуется в документах Unicode.
• Благодаря своим escape-последовательностям можно создавать последовательности атакующих байтов, в которых вредоносная строка (например, межсайтовый скриптинг ) маскируется до тех пор, пока она не будет декодирована в Unicode, что может позволить обойти очистку. ^[156] Таким образом, использование этой кодировки рассматривается как подозрительное пакетами защиты от вредоносных программ, ^{[157] [ необходим лучший источник ]} и 7-битные данные ISO 2022 (за исключением ISO-2022-JP) полностью сопоставляются с заменяющим символом в HTML5 для предотвращения атак. ^{[112] [113]} Ограниченные версии 8-битного кода ISO 2022, которые не используют escape-последовательности обозначений или коды блокировки сдвига, такие как Extended Unix Code , не имеют этой проблемы.
• Конкатенация может вызывать проблемы. Такие профили, как ISO-2022-JP, указывают, что поток начинается в состоянии ASCII и должен заканчиваться в состоянии ASCII. ^[114] Это необходимо для того, чтобы гарантировать, что символы в конкатенированных потоках ISO-2022-JP и/или ASCII будут интерпретироваться в правильном наборе. Это приводит к тому, что если поток, заканчивающийся многобайтовым символом, конкатенируется с потоком, начинающимся с многобайтового символа, генерируется пара escape-кодов, переключающихся на ASCII и немедленно от него. Однако, как указано в Техническом отчете Unicode № 36 («Соображения безопасности Unicode»), пары escape-последовательностей ISO 2022 без символов между ними должны генерировать заменяющий символ («�»), чтобы предотвратить их использование для маскировки вредоносных последовательностей, таких как межсайтовый скриптинг . ^[158] Реализация этой меры, например, в Mozilla Thunderbird , привела к проблемам взаимодействия, при которых при объединении двух потоков ISO-2022-JP генерировались неожиданные символы «�». ^[156]

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

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

• ISO/TC 97/SC 2 (1975-12-01). ISO-IR-1: Набор управляющих символов ISO 646 (PDF) . ITSCJ/ IPSJ .{{citation}}: CS1 maint: числовые имена: список авторов ( ссылка )
• Шведская комиссия по стандартизации (1 декабря 1975 г.). ISO-IR-7: Комплект управления NATS для передачи текста газеты (PDF) . ITSCJ/ IPSJ .
• Японский комитет по промышленным стандартам (1975-12-01). ISO-IR-14: Японский римский графический набор символов (PDF) . ITSCJ/ IPSJ .
• ИПТК (25 марта 1976 г.). ISO-IR-26: Комплект управления для передачи текста газеты (PDF) . ITSCJ/ IPSJ .
• ISO/TC 97/SC 2 (1977-10-15). 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: числовые имена: список авторов ( ссылка )
• ITU (1985-08-01). ISO-IR-106: Основной набор функций управления Teletex (PDF) . ITSCJ/ IPSJ .
• Úřad pro нормализации и мержени (31 июля 1987 г.). ISO-IR-140: Набор управляющих символов C0 стандарта ISO 646, с заменой EM на SS2 (PDF) . ITSCJ/ IPSJ .
• Корейское бюро стандартов (1988-10-01). ISO-IR-149: Корейский набор графических символов для обмена информацией (KS C 5601:1987) (PDF) . ITSCJ/ IPSJ .
• ISO/IEC/JTC1/SC2/WG3 (1990-04-16). ISO-IR-155: Базовый набор чертежей коробок (PDF) . ITSCJ/ IPSJ .{{citation}}: CS1 maint: числовые имена: список авторов ( ссылка )
• CCITT (1992-07-13). ISO-IR-164: Дополнительный набор графических символов для иврита (PDF) . ITSCJ/ IPSJ .
• ECMA (1996-04-22). ISO-IR-192: Формат преобразования UCS (UTF-8), уровень реализации 3, без стандартного возврата (PDF) . ITSCJ/ IPSJ .
• ECMA (1996-04-22). ISO-IR-195: Формат преобразования UCS (UTF-16), уровень реализации 3, без стандартного возврата (PDF) . ITSCJ/ IPSJ .
• ECMA (1996-04-22). ISO-IR-196: Формат преобразования UCS (UTF-8), со стандартным возвратом (PDF) . ITSCJ/ IPSJ .
• Национальный орган по стандартизации Ирландии (1999-12-07). ISO-IR-208: Набор символов огамического кодирования для обмена информацией (PDF) . ITSCJ/ IPSJ .

• Murai, J.; Crispin, M.; van der Poel, E. (1993). "RFC 1468: Кодировка японских символов для интернет-сообщений". Запросы комментариев . IETF . doi : 10.17487/rfc1468 .
• Охта, М.; Ханда, К. (1993). "RFC 1554: ISO-2022-JP-2: Многоязычное расширение ISO-2022-JP". Запросы комментариев . IETF . doi : 10.17487/rfc1554 .
• Choi, U.; Chon, K.; Park, H. (1993). "RFC 1557: Кодировка корейских символов для сообщений в Интернете". Запросы комментариев . IETF . doi : 10.17487/rfc1557 .
• Zhu, HF.; Hu, DY.; Wang, ZG.; Kao, TC.; Chang, WCH.; Crispin, M. (1996). "RFC 1922: Кодировка китайских символов для сообщений в Интернете" . Запросы на комментарии . IETF . doi :10.17487/rfc1922.
• Тамару, К. (1997). "RFC 2237: Кодировка японских символов для сообщений в Интернете". Запросы комментариев . IETF . doi : 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 и доступный для бесплатной загрузки.
• Международный регистр кодированных наборов символов, используемых с управляющими последовательностями, полный список назначенных наборов символов и их управляющих последовательностей
• История кодов символов в Северной Америке, Европе и Восточной Азии с 1999 г., ред. 2004 г.
• CJK.INF Кена Лунде : документ по кодированию китайского, японского и корейского (CJK) языков, включая обсуждение различных вариантов ISO/IEC 2022.