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 различными способами, включая:
Однако существуют управляющие последовательности ISO 2022 для переключения в UTF-8 и обратно как «систему кодирования, отличную от ISO 2022» [13] , которые поддерживаются некоторыми эмуляторами терминала, такими как xterm . [14]
Стандарт ISO/IEC 2022 определяет следующее:
Конкретная реализация не обязательно должна реализовывать весь стандарт; уровень соответствия и поддерживаемые наборы символов определяются реализацией. Хотя многие из механизмов, определенных стандартом 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 n символов . Кроме того, наборы G1–G3 могут быть наборами из 96 или 96 n символов.
В наборе символов 96 или 96 n байты 0x20 — 0x7F при вызове GL или 0xA0 — 0xFF при вызове GR выделяются набору и могут им использоваться. В наборе символов 94 или 94 n байты 0x20 и 0x7F не используются. [33] Когда набор символов 96 или 96 n вызывается в регионе GL, символы пробела и удаления (коды 0x20 и 0x7F) недоступны, пока набор символов 94 или 94 n (например, набор 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]
Символ после 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]
Более ранние издания стандарта допускали не-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
@), 0x41 ( A) и 0x42 ( B) по историческим причинам. [89] Некоторые реализации, такие как кодировка эмодзи SoftBank 2G , используют дополнительные экранированные символы этой формы для целей, не соответствующих ISO-2022. [96]ESC , FESC 0x1B 0x2Cбыла определена в ранних изданиях стандарта как назначение дополнительных наборов из 94 символов для G0. [98] Поскольку наборы из 96 символов не могут быть назначены для G0, этот первый байт I не используется в текущем издании стандарта. Однако он все еще указан в MARC-8 . [3]ESC ( Hдля переключения на ASCII из DBCS.ESC 2/8 4/10.ESC ( J.{{citation}}: CS1 maint: числовые имена: список авторов ( ссылка ){{cite book}}: CS1 maint: числовые имена: список авторов ( ссылка ){{cite book}}: CS1 maint: числовые имена: список авторов ( ссылка ){{cite book}}: CS1 maint: числовые имена: список авторов ( ссылка ){{citation}}: CS1 maint: числовые имена: список авторов ( ссылка ){{citation}}: CS1 maint: числовые имена: список авторов ( ссылка ){{citation}}: CS1 maint: числовые имена: список авторов ( ссылка ){{citation}}: CS1 maint: числовые имена: список авторов ( ссылка ){{citation}}: CS1 maint: числовые имена: список авторов ( ссылка )