Jump to content

ИСО/МЭК 2022

(Перенаправлено из ISO 2022-JP )

ИСО 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. [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-последовательности не требуется.

Многобайтовые символы

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

Для представления больших наборов символов 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 a1B 61ИНТ. Прерывать Прерывает текущий процесс.
ESC b1B 62я Включить ручной ввод Включает возможности ручного ввода устройства.
ESC c1B 63РИС Сброс в исходное состояние Сбрасывает устройство в исходное состояние после включения. [57]
ESC d1B 64КМД Разделитель метода кодирования Используется при взаимодействии с внешней системой кодирования/представления, см. ниже.
ESC n1B 6EЛС2 Блокировка второй смены Функцию сдвига, см. ниже.
ESC o1B 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, как показано ниже, является обязательным для уровней 2 и 3 ISO/IEC 4873 . [69]

Код Шестигранник Сокр. Имя Эффект
SI0FИ
ЛС0
Сдвиг
Блокировка смещения нуля
GL теперь кодирует G0 [70] [71]
SO0EТАК
ЛС1
Сдвиг
Блокировка первой смены
GL теперь кодирует G1 [70] [71]
ESC n1B 6EЛС2 Блокировка второй смены GL теперь кодирует G2 [70] [71]
ESC o1B 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 (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) в контекстах, где обработка escape-кодов ANSI уместна , при условии, что каждый байт в последовательности дополняется до размер кодовой единицы кодирования. [90]

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

Код Шестигранник Сокр. Имя Эффект Пример
ESC SP F1B 20 FСКУД Анонсировать структуру кода Указывает используемые функции кода, например рабочие наборы (см. ниже ). [92] ESC SP L
( ISO 4873 уровень 1)
ESC ! F1B 21 FCZD C0-обозначить F выбирает набор управляющих символов C0, который будет использоваться. [93] ESC ! @
( коды ASCII C0 )
ESC " F1B 22 FC1D C1-обозначить F выбирает набор управляющих символов C1, который будет использоваться. [94] ESC " C
( Коды ISO 6429 C1 )
ESC # F1B 23 F- (Единая функция управления) (Зарезервировано для последовательностей функций управления, см. выше .) ESC # 6
(частное пользование: линия двойной ширины DEC ) [95]
ГЗДМ4 G0-обозначает многобайтовый набор из 94 символов F выбирает 94 н -набор символов, который будет использоваться для G0. [89] ESC $ ( C
( КС X 1001 в G0)
ESC $ ) F1B 24 29 FГ1ДМ4 G1-обозначение многобайтового набора из 94 символов F выбирает 94 н -набор символов, который будет использоваться для G1. [89] ESC $ ) A
( ГБ 2312 в G1)
ESC $ * F1B 24 2A FГ2ДМ4 G2-обозначение многобайтового набора из 94 байтов F выбирает 94 н -набор символов, который будет использоваться для G2. [89] ESC $ * B
( JIS X 0208 в G2)
ESC $ + F1B 24 2B FГ3ДМ4 G3-обозначает многобайтовый набор из 94 символов F выбирает 94 н -набор символов, который будет использоваться для G3. [89] ESC $ + D
( JIS X 0212 в G3)
ESC $ , F1B 24 2C F- (не используется) (не используется) [ф] -
ESC $ - F1B 24 2D FГ1ДМ6 G1-обозначение многобайтового набора из 96 символов F выбирает 96 н -набор символов, который будет использоваться для G1. [89] ESC $ - 1
(частное пользование)
ESC $ . F1B 24 2E FГ2ДМ6 G2-обозначение многобайтового набора из 96 символов F выбирает 96 н -набор символов, который будет использоваться для G2. [89] ESC $ . 2
(частное пользование)
ESC $ / F1B 24 2F FГ3ДМ6 G3-обозначает многобайтовый набор из 96 символов F выбирает 96 н -набор символов, который будет использоваться для G3. [89] ESC $ / 3
(частное пользование)
ESC % F1B 25 FДОКС Укажите другую систему кодирования Систему кодирования переключателей см. ниже . ESC % G
( UTF-8 )
ESC & F1B 26 Fвнутренняя норма доходности Определить измененную регистрацию Префиксы обозначения escape для обозначения версии. [г] ESC & @ ESC $ B
( JIS X 0208:1990 в G0)
ESC ' F1B 27 F- (не используется) (не используется) -
ESC ( F1B 28 FГЖД4 G0-обозначение 94-набора F выбирает набор из 94 символов, который будет использоваться для G0. [89] ESC ( B
( ASCII в G0)
ESC ) F1B 29 FG1D4 G1-обозначение 94-комплекта F выбирает набор из 94 символов, который будет использоваться для G1. [89] ESC ) I
( ДЖИС
ESC * F1B 2A FG2D4 G2-обозначение 94-комплекта F выбирает набор из 94 символов, который будет использоваться для G2. [89] ESC * v
( ITU T.61 RHS в G2)
ESC + F1B 2B FГ3Д4 G3-обозначение 94-комплекта F выбирает набор из 94 символов, который будет использоваться для G3. [89] ESC + D
( NATS-SEFI-ADD в G3)
ESC , F1B 2C F- (не используется) (не используется) [час] -
ESC - F1B 2D FG1D6 G1-обозначение 96-комплект F выбирает набор из 96 символов, который будет использоваться для G1. [89] ESC - A
( ISO 8859-1 RHS в G1)
ESC . F1B 2E FG2D6 G2-обозначение 96-комплект F выбирает набор из 96 символов, который будет использоваться для G2. [89] ESC . B
( ISO 8859-2 RHS в G2)
ESC / F1B 2F FG3D6 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 % F1B 25 FОбозначить другую систему кодирования («со стандартным возвратом») [99] F выбирает 8-битный код; использовать ESC % @ вернуться. [100]
ESC % / F1B 25 2F FОбозначить другую систему кодирования («без стандартного возврата») [101] F выбирает 8-битный код; стандартного способа возврата не существует. [100]
ESC d1B 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 % B1B 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 % / L1B 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 % / F1B 25 2F 46ESC % / 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 A1B 20 41G0 в GL, GR отсутствует или не используется, блокировки сдвигов нет.
2 ESC SP B1B 20 42G0 и G1 вызываются для GL путем блокировки сдвигов, GR отсутствует или не используется.
3 ESC SP C1B 20 43G0 в GL, G1 в GR, без блокировки сдвигов, требуется 8-битная среда.
4 ESC SP D1B 20 44G0 в GL, G1 в GR, если 8-битная версия, блокировка сдвигов отсутствует, кроме как в 7-битной среде.
5 ESC SP E1B 20 45Функции сдвига сохраняются во время 7-битного/8-битного преобразования.
6 ESC SP F1B 20 46C1 управляет с помощью escape-последовательностей.
7 ESC SP G1B 20 47C1 управляет областью CR в 8-битных средах, в противном случае — escape-последовательностями.
8 ESC SP H1B 20 48Только графические наборы из 94 символов.
9 ESC SP I1B 20 49Графические наборы из 94 и/или 96 символов.
10 ESC SP J1B 20 4AИспользует 7-битный код, даже если для использования доступен восьмой бит.
11 ESC SP K1B 20 4BТребуется 8-битный код.
12 ESC SP L1B 20 4CСоответствует ISO/IEC 4873 (ECMA-43) уровень 1.
13 ESC SP M1B 20 4DСоответствует стандарту ISO/IEC 4873 (ECMA-43), уровень 2.
14 ESC SP N1B 20 4EСоответствует стандарту ISO/IEC 4873 (ECMA-43), уровень 3.
16 ESC SP P1B 20 50Используется SI/LS0.
18 ESC SP R1B 20 52Используется SO/LS1.
19 ESC SP S1B 20 53LS1R используется в 8-битных средах, SO используется в 7-битных средах.
20 ESC SP T1B 20 54Используется ЛС2.
21 ESC SP U1B 20 55LS2R используется в 8-битных средах, LS2 используется в 7-битных средах.
22 ESC SP V1B 20 56Используется LS3.
23 ESC SP W1B 20 57LS3R используется в 8-битных средах, LS3 используется в 7-битных средах.
26 ESC SP Z1B 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 — широко используемая кодировка японского языка, особенно в электронной почте . Он был представлен для использования в сети 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 ISO DEC , которая, кроме того, добавляет двухбайтовую пользовательскую область, доступ к которой осуществляется с помощью 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, определенное в 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 (ИИСУС X 0201 Роман)
  • ESC $ ( B (JIS X 0208, 1983+, длинная escape-последовательность)
  • ESC $ I (JIS X 0201 Катакана)
  • ESC $ ( D
957 [126] TCP-02
  • ESC ( J (ИИСУС 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 (ИИСУС X 0201 Роман)
  • ESC $ B (JIS X 0208, 1983+)
  • ESC $ I (JIS X 0201 Катакана)
  • ESC $ ( D (ДЖИС Х 0212)
5053 [130] TCP-06
  • ESC ( J (ИИСУС 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 (ИИСУС X 0201 Роман)
  • ESC $ @ (JIS X 0208, 1978 г.)
  • ESC $ B (JIS X 0208, 1983+)

ДЖИС Х 0213

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

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

Другие 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 L1B 20 4CИСО 4873 уровень 1
ESC SP M1B 20 4DИСО 4873 уровень 2
ESC SP N1B 20 4EИСО 4873 уровень 3

Расширенный код 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 C1B 20 43ISO-8 (8 бит, G0 в GL, G1 в GR)
ESC SP Z1B 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) ИИСУС 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. ^ Японский : , латинизированный : десять , букв. 'точка'; Китайский : ; пиньинь : вэй ; горит. 'позиция'; Корейский : ; Ханджа : ; РР : йёль
  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) , стр. 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) , стр. 35–36, глава 14.3.2.
  90. ^ ISO/IEC 10646 (2017) , стр. 19–20, глава 12.4 («Идентификация набора функций управления»)
  91. ^ ECMA-35 (1994) , с. 32, таблица 5
  92. ^ Перейти обратно: а б с ECMA-35 (1994) , стр. 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) , стр. 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 г.


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

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

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

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

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

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

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

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

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

[ редактировать ]
[ редактировать ]
Arc.Ask3.Ru: конец переведенного документа.
Arc.Ask3.Ru
Номер скриншота №: 251cae06607956d8768da6ef1d751b60__1714278120
URL1:https://arc.ask3.ru/arc/aa/25/60/251cae06607956d8768da6ef1d751b60.html
Заголовок, (Title) документа по адресу, URL1:
ISO/IEC 2022 - Wikipedia
Данный printscreen веб страницы (снимок веб страницы, скриншот веб страницы), визуально-программная копия документа расположенного по адресу URL1 и сохраненная в файл, имеет: квалифицированную, усовершенствованную (подтверждены: метки времени, валидность сертификата), открепленную ЭЦП (приложена к данному файлу), что может быть использовано для подтверждения содержания и факта существования документа в этот момент времени. Права на данный скриншот принадлежат администрации Ask3.ru, использование в качестве доказательства только с письменного разрешения правообладателя скриншота. Администрация Ask3.ru не несет ответственности за информацию размещенную на данном скриншоте. Права на прочие зарегистрированные элементы любого права, изображенные на снимках принадлежат их владельцам. Качество перевода предоставляется как есть. Любые претензии, иски не могут быть предъявлены. Если вы не согласны с любым пунктом перечисленным выше, вы не можете использовать данный сайт и информация размещенную на нем (сайте/странице), немедленно покиньте данный сайт. В случае нарушения любого пункта перечисленного выше, штраф 55! (Пятьдесят пять факториал, Денежную единицу (имеющую самостоятельную стоимость) можете выбрать самостоятельно, выплаичвается товарами в течение 7 дней с момента нарушения.)