ИСО/МЭК 2022

Из Википедии, бесплатной энциклопедии
Не путать с ISO 20022 .

ИСО 2022
Язык(и) Различный.
Стандартный
Классификация с сохранением состояния Система кодировок (с предварительно настроенными подмножествами без сохранения состояния)
Преобразует/кодирует US-ASCII и, в зависимости от реализации:
Преемник ISO/IEC 10646 ( Юникод )
Другая связанная кодировка(и) Подмножества с состоянием :
Предварительно настроенные версии :

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

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

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

Кодировки и соответствие [ править ]

Набор символов ASCII поддерживает базовый латинский алфавит ISO (эквивалент английского алфавита ) и не обеспечивает хорошей поддержки языков, в которых используются дополнительные буквы или вообще используется другая система письма . Другие системы письма с относительно небольшим количеством символов, такие как греческая , кириллица , арабский или иврит , а также формы латинского алфавита с использованием диакритических знаков или букв, отсутствующих в базовом латинском алфавите ISO, исторически были представлены на персональных компьютерах с различными 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 ).

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

Обзор [ править ]

Элементы [ править ]

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

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

Версии кода [ править ]

Дополнительная информация: § Версии кода 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] и расширенный код Unix , который используется для восточноазиатских языков. [11] Более специализированные приложения ISO 2022 включают систему кодирования MARC-8, используемую в MARC 21 . библиотечных записях [3]

Обозначение escape-последовательностей [ править ]

Дополнительная информация: § Регистрация наборов графических и управляющих кодов и § Обозначения наборов символов.

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

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

Многобайтовые символы [ править ]

Дополнительная информация: JIS X 0208 § Кодовые точки и кодовые номера.

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

Для двухбайтовых наборов символов кодовая точка каждого символа обычно указывается в так называемой ячейке строки или кутене. [а] форма, состоящая из двух чисел от 1 до 94 включительно, определяющая строку [б] и клетка [с] этого персонажа в зоне. Для трехбайтового набора дополнительная плоскость [д] номер указан в начале. [20] Escape-последовательности не только объявляют, какой набор символов используется, но также является ли этот набор однобайтовым или многобайтовым (но не сколько байтов он использует, если он многобайтовый), а также содержит ли каждый байт 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» означает «оставшаяся графика»), а байты из диапазона «высокого ASCII» (0xA0–0xFF), если он доступен (т. е. в 8-битной среде), называются кодами «GR» («графическое право») . [5] Термины «CL» (0x00–0x1F) и «CR» (0x80–0x9F) определены для диапазонов управления, но диапазон CL всегда вызывает основные элементы управления (C0), тогда как диапазон CR всегда либо вызывает вторичные (C1) элементы управления. ) контролирует или не используется. [5]

Фиксированные кодированные символы [ править ]

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

Общий синтаксис escape-последовательностей [ править ]

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

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

Функции управления из некоторых наборов могут использовать дополнительные байты, следующие за управляющей последовательностью. Например, ISO 6429 » функция управления За вводной управляющей последовательностью , которую можно представить с помощью escape-последовательности, следует ноль или более байтов в диапазоне 0x30–0x3F, затем ноль или более байтов в диапазоне 0x20–0x2F, затем один байт в диапазоне 0x40– 0x7E, причем вся последовательность называется «управляющей последовательностью». [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 может вообще не содержать элемента управления escape. [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» (в диапазоне ESC 0x23 (#) [I...] 0x40 (@) через ESC 0x23 (#) [I...] 0x7E (~)), [53] хотя последовательности «3Ft» в настоящее время не назначены (по состоянию на 2019 год). [54] Некоторые из них указаны в ECMA-35 (ISO 2022/ANSI X3.41), другие – в ECMA-48 (ISO 6429/ANSI X3.64). [55] ECMA-48 называет их «независимыми функциями управления». [56]

Код Шестигранник Сокр. Имя Эффект [54]
ESC ` 1B 60 ДМИ Отключить ручной ввод Отключает некоторые или все возможности ручного ввода устройства.
ESC a 1B 61 ИНТ. Прерывать Прерывает текущий процесс.
ESC b 1B 62 я Включить ручной ввод Включает возможности ручного ввода устройства.
ESC c 1B 63 РИС Сброс в исходное состояние Сбрасывает устройство в исходное состояние после включения. [57]
ESC d 1B 64 КМД Разделитель метода кодирования Используется при взаимодействии с внешней системой кодирования/представления, см. ниже.
ESC n 1B 6E ЛС2 Блокировка второй смены Функцию сдвига, см. ниже.
ESC o 1B 6F ЛС3 Блокировка третьей смены Функцию сдвига, см. ниже.
ESC | 1B 7C ЛС3Р Блокировка переключения три вправо Функцию сдвига, см. ниже.
ESC } 1B 7D ЛС2Р Блокировка второй смены вправо Функцию сдвига, см. ниже.
ESC ~ 1B 7E ЛС1Р Блокировка сдвига вправо Функцию сдвига, см. ниже.

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

Функции смены [ править ]

По умолчанию коды 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] и Т.61 . [62] Это кодирование в настоящее время рекомендуется ISO/IEC 2022/ECMA-35 для приложений, требующих 7-битных однобайтовых представлений SS2 и SS3. [63] а также может использоваться только для SS2, [64] хотя существуют и более старые наборы кодов с SS2 по адресу 0x1C, [65] [66] [67] и были упомянуты как таковые в более ранней редакции стандарта. [68] Кодирование одиночных смен 0x8E и 0x8F, как показано ниже, является обязательным для ISO/IEC 4873 . уровней 2 и 3 [69]

Код Шестигранник Сокр. Имя Эффект
SI 0F И
ЛС0 		Перейти в
Блокировка смещения нуля 		GL теперь кодирует G0 [70] [71]
SO 0E ТАК
ЛС1 		Сдвиг
Блокировка первой смены 		GL теперь кодирует G1 [70] [71]
ESC n 1B 6E ЛС2 Блокировка второй смены GL теперь кодирует G2 [70] [71]
ESC o 1B 6F ЛС3 Блокировка третьей смены GL теперь кодирует G3 [70] [71]
Район ЧР: SS2
Код выхода: ESC N		 Район ЧР: 8E
Код выхода: 1B 4E		 СС2 Две смены в одну смену GL или GR (см. ниже) кодируют G2 только для следующего символа. [72]
Район ЧР: SS3
Код выхода: ESC O		 Район ЧР: 8F
Код выхода: 1B 4F		 СС3 Одна смена три GL или GR (см. ниже) кодируют G3 только для следующего символа. [72]
ESC ~ 1B 7E ЛС1Р Блокировка сдвига вправо GR теперь кодирует G1 [73]
ESC } 1B 7D ЛС2Р Блокировка второй смены вправо GR теперь кодирует G2 [73]
ESC | 1B 7C ЛС3Р Блокировка переключения три вправо GR теперь кодирует G3 [73]

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

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

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

Регистрация наборов графических и управляющих кодов [ править ]

Международный реестр наборов кодированных символов, используемых с 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 для идентификации Юникод. [81] Текстовое представление escape-последовательности, включенное в третий элемент FPI, будет распознаваться реализациями SGML для поддерживаемых наборов символов. [80]

Обозначения наборов символов [ править ]

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

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

Как и в случае с другими типами 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) в контекстах, где уместна обработка управляющих кодов ANSI , при условии, что каждый байт в последовательности дополняется до размер кодовой единицы кодирования. [90]

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

Код Шестигранник Сокр. Имя Эффект Пример
ESC SP F 1B 20 F СКУД Анонсировать структуру кода Указывает используемые функции кода, например рабочие наборы (см. ниже ). [92] ESC SP L
( ISO 4873 уровень 1)
ESC ! F 1B 21 F CZD C0-обозначить F выбирает набор управляющих символов C0, который будет использоваться. [93] ESC ! @
( коды ASCII C0 )
ESC " F 1B 22 F C1D C1-обозначить F выбирает набор управляющих символов C1, который будет использоваться. [94] ESC " C
( Коды ISO 6429 C1 )
ESC # F 1B 23 F - (Единая функция управления) (Зарезервировано для последовательностей функций управления, см. выше .) ESC # 6
(частное пользование: двойной ширины DEC) линия [95]
ГЗДМ4 G0-обозначает многобайтовый набор из 94 символов F выбирает 94 н -набор символов, который будет использоваться для G0. [89] ESC $ ( C
( КС X 1001 в G0)
ESC $ ) F 1B 24 29 F G1DM4 G1-обозначение многобайтового набора из 94 символов F выбирает 94 н -набор символов, который будет использоваться для G1. [89] ESC $ ) A
( ГБ 2312 в G1)
ESC $ * F 1B 24 2A F G2DM4 G2-обозначение многобайтового набора из 94 байтов F выбирает 94 н -набор символов, который будет использоваться для G2. [89] ESC $ * B
( JIS X 0208 в G2)
ESC $ + F 1B 24 2B F Г3ДМ4 G3-обозначает многобайтовый 94-набор F выбирает 94 н -набор символов, который будет использоваться для G3. [89] ESC $ + D
( JIS X 0212 в G3)
ESC $ , F 1B 24 2C F - (не используется) (не используется) [ф] -
ESC $ - F 1B 24 2D F Г1ДМ6 G1-обозначение многобайтового набора из 96 символов F выбирает 96 н -набор символов, который будет использоваться для G1. [89] ESC $ - 1
(частное пользование)
ESC $ . F 1B 24 2E F Г2ДМ6 G2-обозначение многобайтового набора из 96 символов F выбирает 96 н -набор символов, который будет использоваться для G2. [89] ESC $ . 2
(частное пользование)
ESC $ / F 1B 24 2F F Г3ДМ6 G3-обозначает многобайтовый набор из 96 символов F выбирает 96 н -набор символов, который будет использоваться для G3. [89] ESC $ / 3
(частное пользование)
ESC % F 1B 25 F ДОКС Укажите другую систему кодирования Систему кодирования переключателей см. ниже . ESC % G
( UTF-8 )
ESC & F 1B 26 F внутренняя норма доходности Определить измененную регистрацию Префиксы обозначения escape для обозначения версии. [г] ESC & @ ESC $ B
( JIS X 0208:1990 в G0)
ESC ' F 1B 27 F - (не используется) (не используется) -
ESC ( F 1B 28 F ГЖД4 G0-обозначение 94-набора F выбирает набор из 94 символов, который будет использоваться для G0. [89] ESC ( B
( ASCII в G0)
ESC ) F 1B 29 F G1D4 G1-обозначение 94-комплекта F выбирает набор из 94 символов, который будет использоваться для G1. [89] ESC ) I
( JIS X 0201 Кана в G1)
ESC * F 1B 2A F G2D4 G2-обозначение 94-комплекта F выбирает набор из 94 символов, который будет использоваться для G2. [89] ESC * v
( ITU T.61 RHS в G2)
ESC + F 1B 2B F Г3Д4 G3-обозначение 94-комплекта F выбирает набор из 94 символов, который будет использоваться для G3. [89] ESC + D
( NATS-SEFI-ADD в G3)
ESC , F 1B 2C F - (не используется) (не используется) [час] -
ESC - F 1B 2D F G1D6 G1-обозначение 96-комплект F выбирает набор из 96 символов, который будет использоваться для G1. [89] ESC - A
( ISO 8859-1 RHS в G1)
ESC . F 1B 2E F G2D6 G2-обозначение 96-комплект F выбирает набор из 96 символов, который будет использоваться для G2. [89] ESC . B
( ISO 8859-2 RHS в G2)
ESC / F 1B 2F F G3D6 G3-обозначение 96-комплект F выбирает набор из 96 символов, который будет использоваться для G3. [89] ESC / b
( ISO 8859-15 RHS в G3)

Обратите внимание, что реестр F -байтов независим для разных типов. Графический набор из 94 символов, обозначенный ESC ( A через ESC + A никак не связан с набором из 96 символов, обозначенным ESC - A через ESC / A. И ни один из них не имеет отношения к 94-му. н -набор символов, обозначенный ESC $ ( A через 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]

Код Шестигранник Сокр. Имя Эффект
ESC % @ 1B 25 40 ДОКС Укажите другую систему кодирования («стандартный возврат»). Вернитесь к ISO/IEC 2022 из другой кодировки. [100]
ESC % F 1B 25 F Обозначить другую систему кодирования («со стандартным возвратом») [99] F выбирает 8-битный код; использовать ESC % @ вернуться. [100]
ESC % / F 1B 25 2F F Обозначить другую систему кодирования («без стандартного возврата») [101] F выбирает 8-битный код; стандартного способа возврата не существует. [100]
ESC d 1B 64 КМД Разделитель метода кодирования Обозначает конец кодовой последовательности ISO/IEC 2022. [102]

Особый интерес представляют последовательности, которые переключаются на форматы 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]

Формат Юникод Код(ы) Шестигранник [103] Устаревшие коды Устаревший шестнадцатеричный код [99] [101] [103]
UTF-1 (UTF-1 отсутствует в текущем стандарте ISO/IEC 10646.) ESC % B 1B 25 42
UTF-8 ESC % G,
ESC % / I		 1B 25 47, [13]
1B 25 2F 49[105] 		ESC % / G,
ESC % / H		 1B 25 2F 47,
1B 25 2F 48
UTF-16 ESC % / L 1B 25 2F 4C[106] ESC % / @,
ESC % / C,
ESC % / E,
ESC % / J,
ESC % / K		 1B 25 2F 40,
1B 25 2F 43,
1B 25 2F 45,
1B 25 2F 4A,
1B 25 2F 4B
UTF-32 ESC % / F 1B 25 2F 46 ESC % / A,
ESC % / D		 1B 25 2F 41,
1B 25 2F 44

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

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

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

Объявления о структуре кода [ править ]

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

Число Код Шестигранник Объявлена ​​функция версии кода [92]
1 ESC SP A 1B 20 41 G0 в GL, GR отсутствует или не используется, блокировки сдвигов нет.
2 ESC SP B 1B 20 42 G0 и G1 вызываются для GL путем блокировки сдвигов, GR отсутствует или не используется.
3 ESC SP C 1B 20 43 G0 в GL, G1 в GR, без блокировки сдвигов, требуется 8-битная среда.
4 ESC SP D 1B 20 44 G0 в GL, G1 в GR, если 8-битная версия, блокировка сдвигов отсутствует, кроме как в 7-битной среде.
5 ESC SP E 1B 20 45 Функции сдвига сохраняются при преобразовании 7-бит/8-бит.
6 ESC SP F 1B 20 46 C1 управляет с помощью escape-последовательностей.
7 ESC SP G 1B 20 47 C1 управляет областью CR в 8-битных средах, в противном случае — escape-последовательностями.
8 ESC SP H 1B 20 48 Только графические наборы из 94 символов.
9 ESC SP I 1B 20 49 Графические наборы из 94 и/или 96 символов.
10 ESC SP J 1B 20 4A Использует 7-битный код, даже если для использования доступен восьмой бит.
11 ESC SP K 1B 20 4B Требуется 8-битный код.
12 ESC SP L 1B 20 4C Соответствует стандарту ISO/IEC 4873 (ECMA-43), уровень 1.
13 ESC SP M 1B 20 4D Соответствует ISO/IEC 4873 (ECMA-43), уровень 2.
14 ESC SP N 1B 20 4E Соответствует стандарту ISO/IEC 4873 (ECMA-43), уровень 3.
16 ESC SP P 1B 20 50 Используется SI/LS0.
18 ESC SP R 1B 20 52 Используется SO/LS1.
19 ESC SP S 1B 20 53 LS1R используется в 8-битных средах, SO используется в 7-битных средах.
20 ESC SP T 1B 20 54 Используется ЛС2.
21 ESC SP U 1B 20 55 LS2R используется в 8-битных средах, LS2 используется в 7-битных средах.
22 ESC SP V 1B 20 56 Используется LS3.
23 ESC SP W 1B 20 57 LS3R используется в 8-битных средах, LS3 используется в 7-битных средах.
26 ESC SP Z 1B 20 5A Используется SS2.
27 ESC SP [ 1B 20 5B Используется SS3.
28 ESC SP \ 1B 20 5C Односменный вызов через GR.

Версии кода ISO/IEC 2022 [ править ]

(Скриншот старой версии Firefox, показывающий Big5, GB 2312, GBK, GB 18030, HZ, ISO-2022-CN, Big5-HKSCS, EUC-TW, EUC-JP, ISO-2022-JP, Shift_JIS, EUC- KR, UHC, Johab и ISO-2022-KR в качестве доступных кодировок в подменю CJK.)
Различные кодировки ISO 2022 и другие CJK , поддерживаемые Mozilla Firefox с 2004 года. (Эта поддержка была сокращена в более поздних версиях, чтобы избежать определенных атак с использованием межсайтовых сценариев .)

Шесть 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-битного кода включают расширенный код Unix . [11] [12] Кодировки ISO/IEC 8859 также соответствуют ISO 2022 в подмножестве, предусмотренном ISO/IEC 4873. [9] [10]

Японские версии электронной почты [ править ]

ISO-2022-JP [ править ]

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

  • ESC ( B для переключения на ASCII (1 байт на символ)
  • ESC ( J для перехода на JIS X 0201-1976 (ISO/IEC 646:JP) Римский набор (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, но предусматривает, что escape-последовательности не должны изменяться системами, просто передающими сообщения, такие как электронные письма. [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 и World System Teletext ). [114] [я]

Версии с половинной катаканой ширины

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

Другие, более старые варианты, известные как JIS7 ​​и JIS8, основаны непосредственно на 7-битных и 8-битных кодировках, определенных JIS X 0201 , и позволяют использовать кану JIS X 0201 из 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-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 , набор расширенной латиницы 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, японский TCP [ править ]

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

Варианты IBM ISO-2022-JP
Кодовая страница/CCSID Номер определения ACRI Escape-последовательности для ACRI [110]
956 [125] TCP-01
  • ESC ( J (HE X 0201 Роман)
  • ESC $ ( B (JIS X 0208, 1983+, длинная escape-последовательность)
  • ESC $ I (JIS X 0201 Катакана)
  • ESC $ ( D
957 [126] TCP-02
  • ESC ( J (HE X 0201 Роман)
  • ESC $ ( @ (JIS X 0208, 1978, длинная escape-последовательность)
  • ESC $ I (JIS X 0201 Катакана)
  • ESC $ ( D (НЕ Х 0212)
958 [127] TCP-03
  • ESC ( A (ASCII)
  • ESC $ ( B (JIS X 0208, 1983+, длинная escape-последовательность)
  • ESC $ I (JIS X 0201 Катакана)
  • ESC $ ( D (НЕ Х 0212)
959 [128] TCP-04
  • ESC ( A (ASCII)
  • ESC $ ( @ (JIS X 0208, 1978, длинная escape-последовательность)
  • ESC $ I (JIS X 0201 Катакана)
  • ESC $ ( D (НЕ Х 0212)
5052 [129] TCP-05
  • ESC ( J (HE X 0201 Роман)
  • ESC $ B (JIS X 0208, 1983+)
  • ESC $ I (JIS X 0201 Катакана)
  • ESC $ ( D (НЕ Х 0212)
5053 [130] TCP-06
  • ESC ( J (HE X 0201 Роман)
  • ESC $ @ (JIS X 0208, 1978 г.)
  • ESC $ I (JIS X 0201 Катакана)
  • ESC $ ( D (НЕ Х 0212)
5054 [131] TCP-07
  • ESC ( A (ASCII)
  • ESC $ B (JIS X 0208, 1983+)
  • ESC $ I (JIS X 0201 Катакана)
  • ESC $ ( D (НЕ Х 0212)
5055 [132] TCP-08
  • ESC ( A (ASCII)
  • ESC $ @ (JIS X 0208, 1978 г.)
  • ESC $ I (JIS X 0201 Катакана)
  • ESC $ ( D (НЕ Х 0212)
9148 [124] TCP-16
  • ESC ( A (ASCII)
  • ESC ( J (HE X 0201 Роман)
  • ESC $ @ (JIS X 0208, 1978 г.)
  • ESC $ B (JIS X 0208, 1983+)

JIS X 0213 [ править ]

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

Другие 7-битные версии [ править ]

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-битный escape-код. формы односменных функций 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 перечислены как разрешенные, но при условии, что им присвоены зарегистрированные escape-последовательности ISO 2022: [136]

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

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

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

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

ИСО/МЭК 4873 [ править ]

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

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

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

  • Уровень 1, который включает набор C0, набор ASCII G0, дополнительный набор C1 и дополнительный однобайтовый (94- или 96-символьный) набор G1. G0 вызывается через GL, а G1 вызывается через GR. Использование функций сдвига не допускается.
  • Уровень 2, который включает однобайтовый набор G2 и/или G3 (94 или 96 символов) в дополнение к обязательному набору G1. Разрешены только функции одной смены SS2 и SS3 (т.е. блокирующие сдвиги запрещены), и они вызываются в области GL (включая 0x20 и 0x7F в случае набора 96). SS2 и SS3 должны быть доступны в C1 по адресам 0x8E и 0x8F соответственно. Этот минимальный необходимый набор C1 для ISO 4873 зарегистрирован как ISO-IR-105. [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 года) по ISO/IEC 4873 уровня 1 без набора 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. Он предусматривает, что ISO/IEC 10367 . вместо уровней 2 и 3 ISO/IEC 4873 следует использовать [9] [10] ISO/IEC 10367:1991 включает наборы G0 и G1, соответствующие тем, которые использовались в первых девяти частях 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]

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

Расширенный код Unix [ править ]

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

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

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

Составной текст (X11) [ править ]

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

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

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

Сравнение с другими кодировками [ править ]

Преимущества [ править ]

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

Недостатки [ править ]

  • Поскольку ISO/IEC 2022 представляет собой кодировку с отслеживанием состояния, программа не может переходить в середину блока текста для поиска, вставки или удаления символов. Это делает манипуляции с текстом очень громоздкими и медленными по сравнению с кодировками без сохранения состояния. Любой переход в середину текста может потребовать резервного копирования предыдущей escape-последовательности, прежде чем можно будет интерпретировать байты, следующие за escape-последовательностью.
  • Из-за особенностей ISO/IEC 2022 с отслеживанием состояния идентичный и эквивалентный символ может быть закодирован в разных наборах символов, которые могут быть обозначены как любой из G0–G3, который может быть вызван с использованием одиночных сдвигов или с использованием блокирующих сдвигов для GL или ГР. Следовательно, символы могут быть представлены разными способами, а это означает, что две визуально идентичные и эквивалентные строки невозможно надежно сравнить на предмет равенства.
  • Некоторые системы, такие как DICOM и некоторые клиенты электронной почты, используют вариант ISO-2022 (например, «ISO 2022 IR 100»). [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-символы обозначения или коды блокировки сдвига, такие как расширенный код Unix , не разделяют эту проблему.
  • Конкатенация может создать проблемы. Такие профили, как 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]

См. также [ править ]

Сноски [ править ]

  1. ^ Японский : 区 , латинизированный : кутен ; китайский : местоположение ; пиньинь : qūwèi ; корейский : 행렬 ; RR : хэннёль ; ​ ​ 点
  2. ^ Японский : 区 , латинизированный : ку , букв.   'зона'; Китайский : 区 ; пиньинь : цю ; Корейский 행: Ханджа : 行 ; RR : Хэнг
  3. ^ Японский : точка , латинизированная : десять , букв   ; китайский : 位 ; пиньинь : вэй ; ; точка корейский : 열 ; RR : йол ​ . « »
  4. ^ Японский : 面 , латинизированный : мужчины , букв.   'лицо'
  5. ^ Перейти обратно: а б Указано для F байтов 0x40 ( @), 0x41 ( A) и 0x42 ( B) только по историческим причинам. [89] В некоторых реализациях, таких как SoftBank 2G кодировка смайлов , используются дополнительные escape-символы этой формы для целей, не соответствующих ISO-2022. [96]
  6. ^ Внесено в список MARC-8 . [3] См. сноску для ESC , F ниже для фона.
  7. ^ F , скорректированный в диапазоне 1-63, указывает, какая (совместимая с предыдущими версиями) версия следующей регистрации необходима, чтобы старые системы знали, что они устарели. [97]
  8. ^ В более ранних выпусках наборов из 96 символов не существовало, а escape-коды, которые теперь используются для наборов из 96 символов, были зарезервированы как место для дополнительных наборов из 94 символов. Соответственно, ESC 0x1B 0x2C последовательность была определена в ранних редакциях стандарта как обозначение дальнейших наборов из 94 символов для G0. [98] Поскольку наборы из 96 символов не могут быть обозначены как G0, этот первый байт I не используется текущей редакцией стандарта. Однако он по-прежнему указан в MARC-8 . [3]
  9. ^ См. также, например, Printronix (2012 г.), Справочное руководство программиста OKI® (PDF) , стр. 26 для более новой системы, которая использует ESC ( H для переключения на ASCII из DBCS.

Ссылки [ править ]

  1. ^ ECMA-35 (1994) , Краткая история
  2. ^ ECMA-35 (1994) , с. 51, Приложение Д
  3. ^ Перейти обратно: а б с д Это «Техника 2: Использование стандартных альтернативных наборов графических символов» . MARC 21 Спецификации для структуры записи, наборов символов и носителей обмена . Библиотека Конгресса . 05.12.2007. Архивировано из оригинала 22 июля 2020 г. Проверено 19 июля 2020 г.
  4. ^ «ECMA-35: Структура кода символов и методы расширения (веб-страница)» . Экма Интернешнл . Архивировано из оригинала 25 апреля 2022 г. Проверено 27 апреля 2022 г.
  5. ^ Перейти обратно: а б с д ECMA-35 (1994) , стр. 101–111. 15–16, глава 8.1
  6. ^ Перейти обратно: а б ECMA-35 (1994) , глава 13
  7. ^ Перейти обратно: а б ECMA-35 (1994) , главы 12, 14
  8. ^ Перейти обратно: а б ECMA-35 (1994) , глава 11
  9. ^ Перейти обратно: а б с д Это ISO/IEC FDIS 8859-10 (1998) , стр. 1, глава 1 («Объем применения»)
  10. ^ Перейти обратно: а б с д Это ECMA-144 (2000) , с. 1, глава 1 («Объем применения»)
  11. ^ Перейти обратно: а б с д Это ж Лунде (2008) , стр. 242–245, глава 4 («Методы кодирования»), раздел «Кодирование EUC».
  12. ^ Перейти обратно: а б с д Лунде (2008) , стр. 253–255, глава 4 («Методы кодирования»), раздел «Кодировки EUC и ISO-2022».
  13. ^ Перейти обратно: а б ИСО-ИР-196 (1996 г.)
  14. ^ Перейти обратно: а б с Мой, Эдвард; Гильдеа, Стивен; Дикки, Томас. «Управление, начинающееся с ESC» . Управляющие последовательности XTerm . Архивировано из оригинала 10 октября 2019 г. Проверено 4 октября 2019 г.
  15. ^ ECMA-35 (1994) , главы 6, 7.
  16. ^ ECMA-35 (1994) , глава 8
  17. ^ ECMA-35 (1994) , глава 9
  18. ^ Перейти обратно: а б ECMA-35 (1994) , глава 15
  19. ^ Лунде (2008) , стр. 228–234, глава 4 («Методы кодирования»), раздел «Кодирование ISO-2022»
  20. ^ Лунде (2008) , стр. 19–20, Глава 1 («Обзор обработки информации CJKV»), раздел «Что такое строка-ячейка и плоская-строка-ячейка?»
  21. ^ ECMA-35 (1994) , с. 4, определение 4.11
  22. ^ ECMA-35 (1994) , с. 5, определение 4.18
  23. ^ См., например, ISO-IR-14 (1975) , определяющий обозначение G0 римского набора JIS X 0201 как ESC 2/8 4/10.
  24. ^ ECMA-35 (1994) , с. 5, глава 5.1
  25. ^ См., например, RFC 1468 (1993) , определяющий обозначение G0 римского набора JIS X 0201 как ESC ( J.
  26. ^ ECMA-35 (1994) , с. 7, глава 6.2
  27. ^ ECMA-35 (1994) , с. 10, глава 6.3.2
  28. ^ ECMA-35 (1994) , с. 4, определение 4.17
  29. ^ ECMA-35 (1994) , с. 4, определение 4.14
  30. ^ ECMA-35 (1994) , с. 28, глава 13.1
  31. ^ Перейти обратно: а б с ECMA-35 (1994) , с. 33, глава 13.3.3
  32. ^ ECMA-48 (1991) , с. 24–26, глава 5.4
  33. ^ Перейти обратно: а б с д ECMA-35 (1994) , с. 11, глава 6.4.3
  34. ^ ИСО-ИР-208 (1999)
  35. ^ ИСО-ИР-155 (1990)
  36. ^ ИСО-ИР-164 (1992)
  37. ^ Перейти обратно: а б ECMA-35 (1994) , с. 10, глава 6.3.3
  38. ^ Google Inc. (2014). "ansi.go, строка 134" . Библиотека escape-последовательностей ANSI для Go . Архивировано из оригинала 30 апреля 2022 г. Проверено 14 сентября 2019 г.
  39. ^ ECMA-43 (1991) , с. 5, глава 7 («Спецификация символов 8-битного кода»)
  40. ^ ISO/IEC FDIS 8859-10 (1998) , стр. 3, глава 6 («Спецификация кодированного набора символов»)
  41. ^ ECMA-144 (2000) , с. 3, глава 6 («Спецификация кодированного набора символов»)
  42. ^ ECMA-43 (1991) , с. 19, приложение С («Композитные графические символы»)
  43. ^ Перейти обратно: а б ECMA-35 (1994) , с. 10, глава 6.4.1
  44. ^ Перейти обратно: а б ECMA-35 (1994) , с. 11, глава 6.4.4
  45. ^ Перейти обратно: а б с ECMA-35 (1994) , с. 11, глава 6.4.2
  46. ^ ИСО-ИР-104 (1985)
  47. ^ ИСО-ИР-1 (1975)
  48. ^ Перейти обратно: а б ECMA-35 (1994) , с. 19, глава 8.5.1
  49. ^ Перейти обратно: а б ECMA-35 (1994) , с. 19, глава 8.5.2
  50. ^ ECMA-43 (1991) , с. 8, глава 7.6 («Набор C1»)
  51. ^ Перейти обратно: а б ECMA-35 (1994) , с. 29, глава 13.2.1
  52. ^ Перейти обратно: а б ECMA-35 (1994) , с. 12, глава 6.5.1
  53. ^ ECMA-35 (1994) , с. 12, глава 6.5.2
  54. ^ Перейти обратно: а б с ИСО-ИР , с. 19, глава 2.7 («Отдельные функции управления»)
  55. ^ ECMA-35 (1994) , с. 12, глава 6.5.4
  56. ^ ECMA-48 (1991) , глава 5.5.
  57. ^ ISO/TC 97/SC 2 (30 декабря 1976 г.). Возврат к исходному состоянию (RIS) (PDF) . ITSCJ/ IPSJ . ИСО-ИК -35. {{citation}}: CS1 maint: числовые имена: список авторов ( ссылка )
  58. ^ ECMA-35 (1994) , с. 12, глава 6.5.3
  59. ^ Перейти обратно: а б ECMA-35 (1994) , с. 14, глава 7.3, таблица 2
  60. ^ ИСО-ИР-14 (1975)
  61. ^ Перейти обратно: а б МСЭ-Т (11 августа 1995 г.). Рекомендация T.51 (1992 г.) Поправка 1 . Архивировано из оригинала 2 августа 2020 г. Проверено 25 декабря 2019 г.
  62. ^ ИСО-ИР-106 (1985)
  63. ^ ECMA-35 (1994) , с. 15, глава 7.3, примечание 23
  64. ^ ИСО-ИР-140 (1987)
  65. ^ ИСО-ИР-7 (1975)
  66. ^ ИСО-ИР-26 (1976)
  67. ^ ИСО-ИР-36 (1977)
  68. ^ ECMA-35 (1980) , с. 8, глава 5.1.7
  69. ^ Перейти обратно: а б ИСО-ИР-105 (1985 г.)
  70. ^ Перейти обратно: а б с д ECMA-35 (1994) , с. 17, глава 8.3.1
  71. ^ Перейти обратно: а б с д ECMA-35 (1994) , с. 23, глава 9.3.1
  72. ^ Перейти обратно: а б с ECMA-35 (1994) , с. 19, глава 8.4
  73. ^ Перейти обратно: а б с ECMA-35 (1994) , с. 17, глава 8.3.2
  74. ^ ECMA-35 (1994) , с. 23–24, глава 9.4
  75. ^ ECMA-35 (1994) , с. 27, глава 11.1
  76. ^ ECMA-35 (1994) , с. 17, глава 8.3.3
  77. ^ ECMA-35 (1994) , с. 47, приложение Б
  78. ^ ИСО-ИК , с. 2, глава 1 («Введение»)
  79. ^ ИСО/МЭК 2375 (2003)
  80. ^ Перейти обратно: а б «Обработка декларации SGML в SP» . SP: система SGML, соответствующая международному стандарту ISO 8879 .
  81. ^ «20: Декларация SGML HTML 4» . Спецификация HTML 4.01 . W3C .
  82. ^ ИСО-ИК , с. 10, глава 2.2 («Набор графических символов из 94 символов со вторым промежуточным байтом»)
  83. ^ ARIB STD-B24 (2008) , с. 39, часть 2, Таблица 7-3
  84. ^ Масчек, Свен; Ле Бретон, Стефан; Гамильтон, Ричард Л. «Об« альтернативном наборе символов рисования линий » » . ~sven_mascheck/ . Архивировано из оригинала 29 декабря 2019 г. Проверено 8 января 2020 г.
  85. ^ ECMA-35 (1994) , с. 36, глава 14.4
  86. ^ ECMA-35 (1994) , с. 36, глава 14.4.2, примечание 48
  87. ^ ECMA-35 (1994) , с. 36, глава 14.4.2, примечание 47
  88. ^ ETS 300 706 (1997) , с. 103, глава 14 («Динамически переопределяемые символы»)
  89. ^ Перейти обратно: а б с д Это ж г час я дж к л м н О п д ECMA-35 (1994) , стр. 101–111. 35–36, глава 14.3.2
  90. ^ ISO/IEC 10646 (2017) , стр. 19–20, глава 12.4 («Идентификация набора функций управления»)
  91. ^ ECMA-35 (1994) , с. 32, таблица 5
  92. ^ Перейти обратно: а б с ECMA-35 (1994) , стр. 101–111. 37–41, глава 15.2.
  93. ^ ECMA-35 (1994) , с. 34, глава 14.2.2
  94. ^ ECMA-35 (1994) , с. 34, глава 14.2.3
  95. ^ Цифровой . «DECDWL — линия двойной ширины и одинарной высоты» . Информация о программаторе видеотерминала VT510 . Архивировано из оригинала 2 августа 2020 г. Проверено 17 января 2020 г.
  96. ^ Кавасаки, Юсуке (2010). «Кодировать::JP::Emoji::Кодировка» . Кодировать-JP-Emoji . Строка 268. Архивировано из оригинала 30 апреля 2022 г. Проверено 28 мая 2020 г.
  97. ^ ECMA-35 (1994) , с. 36–37, глава 14.5.
  98. ^ ECMA-35 (1980) , с. 14–15, глава 5.3.7
  99. ^ Перейти обратно: а б с д ИСО-ИР , с. 20, глава 2.8.1 («Системы кодирования со стандартным возвратом»)
  100. ^ Перейти обратно: а б с д ECMA-35 (1994) , стр. 101–111. 41–42, глава 15.4.
  101. ^ Перейти обратно: а б с д Это ИСО-ИР , с. 21, глава 2.8.2 («Системы кодирования без стандартного возврата»)
  102. ^ ECMA-35 (1994) , с. 41, глава 15.3
  103. ^ Перейти обратно: а б с ISO/IEC 10646 (2017) , стр. 19, глава 12.2 («Идентификация схемы кодирования UCS»)
  104. ^ ISO/IEC 10646 (2017) , стр. 18–19, глава 12.1 («Цель и контекст идентификации»).
  105. ^ ИСО-ИР-192 (1996)
  106. ^ ИСО-ИР-195 (1996)
  107. ^ ISO/IEC 10646 (2017) , с. 20, глава 12.5 («Идентификация системы кодирования ISO/IEC 2022»)
  108. ^ Перейти обратно: а б Шайфлер (1989) , § Кодировки нестандартных наборов символов
  109. ^ Лунде (2008) , стр. 229–230, глава 4 («Методы кодирования»), раздел «Кодировка ISO-2022» «Те кодировки, которые широко использовались в прошлом или продолжают использоваться сегодня для некоторых целей, были выделены».
  110. ^ Перейти обратно: а б «Дополнительная необходимая информация, связанная с кодированием» . Идентификаторы наборов символов в кодировке IBM Globalization . ИБМ . Архивировано из оригинала 7 января 2015 г.
  111. ^ Перейти обратно: а б с Стандарт кодирования WHATWG , раздел 2 («Безопасность»).
  112. ^ Перейти обратно: а б с Стандарт кодирования WHATWG , глава 4.2 («Имена и метки»), привязка «замена»
  113. ^ Перейти обратно: а б с д Стандарт кодирования WHATWG , раздел 14.1 («замена»)
  114. ^ Перейти обратно: а б с д Это ж RFC 1468 (1993)
  115. ^ Перейти обратно: а б с «Идентификаторы кодовых страниц» . Центр разработки Windows . Майкрософт. Архивировано из оригинала 16 июня 2019 г. Проверено 16 сентября 2019 г.
  116. ^ Перейти обратно: а б Стандарт кодирования WHATWG , раздел 12.2 («ISO-2022-JP»)
  117. ^ Чанг, Хе-Шик. «Модули/cjkcodecs/_codecs_iso2022.c, строка 1122» . Дерево исходного кода cPython . Фонд программного обеспечения Python. Архивировано из оригинала 30 апреля 2022 г. Проверено 15 сентября 2019 г.
  118. ^ «кодеки — реестр кодеков и базовые классы § Стандартные кодировки» . Документация Python 3.7.4 . Фонд программного обеспечения Python. Архивировано из оригинала 28 июля 2019 г. Проверено 16 сентября 2019 г.
  119. ^ «2: Кодовые наборы и преобразование кодовых наборов» . Технический справочник DIGITAL UNIX по использованию японских функций . Корпорация цифрового оборудования , Compaq . [ мертвая ссылка ]
  120. ^ Перейти обратно: а б Лунде (2008) , стр. 236–238, глава 4 («Методы кодирования»), раздел «Предшественник кодировки ISO-2022-JP — кодировка JIS».
  121. ^ RFC 1554 (1993)
  122. ^ RFC 2237 (1997)
  123. ^ «PQ02042: Новая функция для поддержки C/370 iconv() для японского ISO-2022-JP» . ИБМ . 19 января 2021 г. Архивировано из оригинала 4 января 2022 г. Проверено 4 января 2022 г.
  124. ^ Перейти обратно: а б «CCSID 9148» . Идентификаторы наборов символов в кодировке IBM Globalization . ИБМ . Архивировано из оригинала 29 ноября 2014 г.
  125. ^ «CCSID 956» . Идентификаторы наборов символов в кодировке IBM Globalization . ИБМ . Архивировано из оригинала 2 декабря 2014 г.
  126. ^ «CCSID 957» . Идентификаторы наборов символов в кодировке IBM Globalization . ИБМ . Архивировано из оригинала 30 ноября 2014 г.
  127. ^ «CCSID 958» . Идентификаторы наборов символов в кодировке IBM Globalization . ИБМ . Архивировано из оригинала 1 декабря 2014 г.
  128. ^ «CCSID 959» . Идентификаторы наборов символов в кодировке IBM Globalization . ИБМ . Архивировано из оригинала 2 декабря 2014 г.
  129. ^ «CCSID 5052» . Идентификаторы наборов символов в кодировке IBM Globalization . ИБМ . Архивировано из оригинала 29 ноября 2014 г.
  130. ^ «CCSID 5053» . Идентификаторы наборов символов в кодировке IBM Globalization . ИБМ . Архивировано из оригинала 29 ноября 2014 г.
  131. ^ «CCSID 5054» . Идентификаторы наборов символов в кодировке IBM Globalization . ИБМ . Архивировано из оригинала 29 ноября 2014 г.
  132. ^ «CCSID 5055» . Идентификаторы наборов символов в кодировке IBM Globalization . ИБМ . Архивировано из оригинала 29 ноября 2014 г.
  133. ^ Перейти обратно: а б RFC 1557 (1993)
  134. ^ «КС Х 1001:1992» (PDF) . Архивировано (PDF) из оригинала 26 сентября 2007 г. Проверено 12 июля 2007 г.
  135. ^ ИСО-ИР-149 (1988)
  136. ^ Перейти обратно: а б с д РФК 1922 (1996)
  137. ^ «CVE-2024-2961» .
  138. ^ «Уязвимость GLIBC на серверах, обслуживающих PHP» .
  139. ^ ECMA-43 (1991) , стр. 9–10, глава 8 («Уровни»).
  140. ^ ECMA-43 (1985) , стр. 7–11, глава 7.3 («Набор G0»)
  141. ^ ECMA-43 (1991) , стр. 6–8, глава 7.4 («Набор G0»)
  142. ^ ECMA-43 (1991) , с. 11, глава 10.3 («Идентификация версии»)
  143. ^ Перейти обратно: а б ECMA-43 (1991) , с. 23, приложение E («Основные различия между вторым изданием (1985 г.) и настоящим (третьим) изданием настоящего стандарта ECMA»)
  144. ^ ИПТК (1995). Рекомендуемый формат сообщения IPTC (PDF) (5-е изд.). IPTC TEC 7901. Архивировано (PDF) из оригинала 25 января 2022 г. Проверено 14 января 2020 г.
  145. ^ ECMA-43 (1991) , стр. 10, глава 9.2 («Уникальное кодирование символов»)
  146. ^ ван Винген, Йохан В. (1999). «8. Расширение кода, ISO 2022 и 2375, ISO 4873 и 10367» . Наборы символов. Буквы, жетоны и коды . Терена. Архивировано из оригинала 01 августа 2020 г. Проверено 2 октября 2019 г.
  147. ^ ECMA-43 (1991) , стр. 10–11, глава 10 («Идентификация версии и уровня»)
  148. ^ ИБМ . «Архитектура представления символьных данных (CDRA)» . ИБМ . стр. 157–162. Архивировано из оригинала 23 июня 2019 г. Проверено 18 июня 2020 г.
  149. ^ Шайфлер (1989)
  150. ^ Шайфлер (1989) , § Управляющие персонажи
  151. ^ Шайфлер (1989) , § Направленность
  152. ^ Шайфлер (1989) , § Кодировки стандартного набора символов
  153. ^ Шайфлер (1989) , § Утвержденные стандартные кодировки
  154. ^ «DICOM PS3.2 2016d — соответствие; D.6.2 Наборы символов; D.6 Поддержка наборов символов» . Архивировано из оригинала 16 февраля 2020 г. Проверено 21 мая 2020 г.
  155. ^ «Вариант DICOM ISO 2022» . Архивировано из оригинала 30 апреля 2013 г. Проверено 25 июля 2009 г.
  156. ^ Перейти обратно: а б Сивонен, Анри (17 декабря 2018 г.). «(НЕОТПРАВЛЕННЫЙ ЧЕРНОВИК) Нет генерации U + FFFD для содержимого ASCII-состояния нулевой длины между Escape-последовательностями ISO-2022-JP» (PDF) . Архивировано (PDF) из оригинала 21 февраля 2019 г. Проверено 21 февраля 2019 г.
  157. ^ «935453 — Соберите телеметрию о HZ и других кодировках, которые мы можем попытаться удалить» . Архивировано из оригинала 19 мая 2017 г. Проверено 18 июня 2018 г.
  158. ^ Дэвис, Марк; Суиньяр, Мишель (19 сентября 2014 г.). «3.6.2 Некоторые выходные данные для всех входных данных» . Технический отчет Unicode № 36: Вопросы безопасности Unicode (версия 15) . Консорциум Юникод. Архивировано из оригинала 22 февраля 2019 г. Проверено 21 февраля 2019 г.


индексы реестра Цитируемые стандарты и

Зарегистрированные наборы кодов, цитируемые [ править ]

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

Другие опубликованные работы цитируются [ править ]

Дальнейшее чтение [ править ]

Внешние ссылки [ править ]

Retrieved from "https://en.wikipedia.org/w/index.php?title=ISO/IEC_2022&oldid=1221162761"