ИСО/МЭК 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 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, как показано ниже, является обязательным для уровней 2 и 3 ISO/IEC 4873 . [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 (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 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 | Г1ДМ4 | G1-обозначение многобайтового набора из 94 символов | F выбирает 94 н -набор символов, который будет использоваться для G1. [89] | ESC $ ) A ( ГБ 2312 в G1) |
ESC $ * F | 1B 24 2A F | Г2ДМ4 | 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 ( ДЖИС |
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 [ править ]
Шесть 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 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-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]
Кодовая страница/CCSID | Номер определения ACRI | Escape-последовательности для ACRI [110] |
---|---|---|
956 [125] | TCP-01 |
|
957 [126] | TCP-02 |
|
958 [127] | TCP-03 |
|
959 [128] | TCP-04 |
|
5052 [129] | TCP-05 |
|
5053 [130] | TCP-06 |
|
5054 [131] | TCP-07 |
|
5055 [132] | TCP-08 |
|
9148 [124] | TCP-16 |
|
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, признаются следующие обозначения:
ESC ( I
для перехода на набор Kana JIS X 0201-1976 (1 байт на символ)ESC $ ( O
для переключения на JIS X 0213-2000 Plane 1 (2 байта на символ)ESC $ ( P
для перехода на JIS X 0213-2000 Plane 2 (2 байта на символ)ESC $ ( Q
для переключения на плоскость 1 JIS X 0213-2004 (2 байта на символ, только ISO-2022-JP-2004)
Другие 7-битные версии [ править ]
ISO-2022-KR определен в RFC 1557 от 1993 года. [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 [ править ]
Подмножество 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 (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-байты:
Тип 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]
См. также [ править ]
- ИСО 2709
- ИСО/МЭК 646
- ИСО-ИР-102
- Коды управления C0 и C1
- Персонажи CJK
- стандарты MARC
- Моджибаке
- оно сияет
- ИСО/МЭК ОТК 1/ПК 2
Сноски [ править ]
- ^ Японский : 区 , латинизированный : кутен ; китайский : местоположение ; пиньинь : qūwèi ; корейский : 행렬 ; RR : хэннёль ; 点
- ^ Японский : 区 , латинизированный : ку , букв. 'зона'; Китайский : 区 ; пиньинь : цю ; Корейский 행: Ханджа : 行 ; RR : Хэнг
- ^ Японский : 点 , латинизированный : десять , букв. 'точка'; Китайский : 位 ; пиньинь : вэй ; горит. 'позиция'; Корейский : 열 ; Ханджа : 列 ; РР : йёль
- ^ Японский : 面 , латинизированный : мужчины , букв. 'лицо'
- ↑ Перейти обратно: Перейти обратно: а б Указано для F байтов 0x40 (
@
), 0x41 (A
) и 0x42 (B
) только по историческим причинам. [89] В некоторых реализациях, таких как SoftBank 2G кодировка смайлов , используются дополнительные escape-символы этой формы для целей, не соответствующих ISO-2022. [96] - ^ Внесено в список MARC-8 . [3] См. сноску для
ESC , F
ниже для фона. - ^ F , скорректированный в диапазоне 1-63, указывает, какая (совместимая с предыдущими версиями) версия следующей регистрации необходима, чтобы старые системы знали, что они устарели. [97]
- ^ В более ранних выпусках наборов из 96 символов не существовало, а escape-коды, которые теперь используются для наборов из 96 символов, были зарезервированы как место для дополнительных наборов из 94 символов. Соответственно,
ESC 0x1B 0x2C
последовательность была определена в ранних редакциях стандарта как обозначение дальнейших наборов из 94 символов для G0. [98] Поскольку наборы из 96 символов не могут быть обозначены как G0, этот первый байт I не используется текущей редакцией стандарта. Однако он по-прежнему указан в MARC-8 . [3] - ^ См. также, например, Printronix (2012 г.), Справочное руководство программиста OKI® (PDF) , стр. 26 для более новой системы, которая использует
ESC ( H
для переключения на ASCII из DBCS.
Ссылки [ править ]
- ^ ECMA-35 (1994) , Краткая история
- ^ ECMA-35 (1994) , с. 51, приложение Д
- ↑ Перейти обратно: Перейти обратно: а б с д и «Техника 2: Использование стандартных альтернативных наборов графических символов» . MARC 21 Спецификации для структуры записи, наборов символов и носителей обмена . Библиотека Конгресса . 05.12.2007. Архивировано из оригинала 22 июля 2020 г. Проверено 19 июля 2020 г.
- ^ «ECMA-35: Структура кода символов и методы расширения (веб-страница)» . Экма Интернешнл . Архивировано из оригинала 25 апреля 2022 г. Проверено 27 апреля 2022 г.
- ↑ Перейти обратно: Перейти обратно: а б с д ECMA-35 (1994) , стр. 15–16, глава 8.1.
- ↑ Перейти обратно: Перейти обратно: а б ECMA-35 (1994) , глава 13
- ↑ Перейти обратно: Перейти обратно: а б ECMA-35 (1994) , главы 12, 14
- ↑ Перейти обратно: Перейти обратно: а б ECMA-35 (1994) , глава 11
- ↑ Перейти обратно: Перейти обратно: а б с д и ISO/IEC FDIS 8859-10 (1998) , стр. 1, глава 1 («Объем применения»)
- ↑ Перейти обратно: Перейти обратно: а б с д и ECMA-144 (2000) , с. 1, глава 1 («Объем применения»)
- ↑ Перейти обратно: Перейти обратно: а б с д и ж Лунде (2008) , стр. 242–245, глава 4 («Методы кодирования»), раздел «Кодирование EUC».
- ↑ Перейти обратно: Перейти обратно: а б с д Лунде (2008) , стр. 253–255, глава 4 («Методы кодирования»), раздел «Кодировки EUC и ISO-2022».
- ↑ Перейти обратно: Перейти обратно: а б ИСО-ИР-196 (1996 г.)
- ↑ Перейти обратно: Перейти обратно: а б с Мой, Эдвард; Гильдеа, Стивен; Дикки, Томас. «Управление, начинающееся с ESC» . Управляющие последовательности XTerm . Архивировано из оригинала 10 октября 2019 г. Проверено 4 октября 2019 г.
- ^ ECMA-35 (1994) , главы 6, 7.
- ^ ECMA-35 (1994) , глава 8
- ^ ECMA-35 (1994) , глава 9
- ↑ Перейти обратно: Перейти обратно: а б ECMA-35 (1994) , глава 15
- ^ Лунде (2008) , стр. 228–234, глава 4 («Методы кодирования»), раздел «Кодирование ISO-2022»
- ^ Лунде (2008) , стр. 19–20, Глава 1 («Обзор обработки информации CJKV»), раздел «Что такое строка-ячейка и плоская-строка-ячейка?»
- ^ ECMA-35 (1994) , с. 4, определение 4.11
- ^ ECMA-35 (1994) , с. 5, определение 4.18
- ^ См., например, ISO-IR-14 (1975) , определяющий обозначение G0 римского набора JIS X 0201 как
ESC 2/8 4/10
. - ^ ECMA-35 (1994) , с. 5, глава 5.1
- ^ См., например, RFC 1468 (1993) , определяющий обозначение G0 римского набора JIS X 0201 как
ESC ( J
. - ^ ECMA-35 (1994) , с. 7, глава 6.2
- ^ ECMA-35 (1994) , с. 10, глава 6.3.2
- ^ ECMA-35 (1994) , с. 4, определение 4.17
- ^ ECMA-35 (1994) , с. 4, определение 4.14
- ^ ECMA-35 (1994) , с. 28, глава 13.1
- ↑ Перейти обратно: Перейти обратно: а б с ECMA-35 (1994) , с. 33, глава 13.3.3
- ^ ECMA-48 (1991) , стр. 24–26, глава 5.4.
- ↑ Перейти обратно: Перейти обратно: а б с д ECMA-35 (1994) , с. 11, глава 6.4.3
- ^ ИСО-ИР-208 (1999)
- ^ ИСО-ИР-155 (1990)
- ^ ИСО-ИР-164 (1992)
- ↑ Перейти обратно: Перейти обратно: а б ECMA-35 (1994) , с. 10, глава 6.3.3
- ^ Google Inc. (2014). "ansi.go, строка 134" . Библиотека escape-последовательностей ANSI для Go . Архивировано из оригинала 30 апреля 2022 г. Проверено 14 сентября 2019 г.
- ^ ECMA-43 (1991) , с. 5, глава 7 («Спецификация символов 8-битного кода»)
- ^ ISO/IEC FDIS 8859-10 (1998) , стр. 3, глава 6 («Спецификация кодированного набора символов»)
- ^ ECMA-144 (2000) , с. 3, глава 6 («Спецификация кодированного набора символов»)
- ^ ECMA-43 (1991) , с. 19, приложение С («Композитные графические символы»)
- ↑ Перейти обратно: Перейти обратно: а б ECMA-35 (1994) , с. 10, глава 6.4.1
- ↑ Перейти обратно: Перейти обратно: а б ECMA-35 (1994) , с. 11, глава 6.4.4
- ↑ Перейти обратно: Перейти обратно: а б с ECMA-35 (1994) , с. 11, глава 6.4.2
- ^ ИСО-ИР-104 (1985)
- ^ ИСО-ИР-1 (1975)
- ↑ Перейти обратно: Перейти обратно: а б ECMA-35 (1994) , с. 19, глава 8.5.1
- ↑ Перейти обратно: Перейти обратно: а б ECMA-35 (1994) , с. 19, глава 8.5.2
- ^ ECMA-43 (1991) , с. 8, глава 7.6 («Набор C1»)
- ↑ Перейти обратно: Перейти обратно: а б ECMA-35 (1994) , с. 29, глава 13.2.1
- ↑ Перейти обратно: Перейти обратно: а б ECMA-35 (1994) , с. 12, глава 6.5.1
- ^ ECMA-35 (1994) , с. 12, глава 6.5.2
- ↑ Перейти обратно: Перейти обратно: а б с ИСО-ИР , с. 19, глава 2.7 («Отдельные функции управления»)
- ^ ECMA-35 (1994) , с. 12, глава 6.5.4
- ^ ECMA-48 (1991) , глава 5.5.
- ^ ISO/TC 97/SC 2 (30 декабря 1976 г.). Возврат к исходному состоянию (RIS) (PDF) . ITSCJ/ IPSJ . ИСО-ИК -35.
{{citation}}
: CS1 maint: числовые имена: список авторов ( ссылка ) - ^ ECMA-35 (1994) , с. 12, глава 6.5.3
- ↑ Перейти обратно: Перейти обратно: а б ECMA-35 (1994) , с. 14, глава 7.3, таблица 2
- ^ ИСО-ИР-14 (1975)
- ↑ Перейти обратно: Перейти обратно: а б МСЭ-Т (11 августа 1995 г.). Рекомендация T.51 (1992 г.) Поправка 1 . Архивировано из оригинала 2 августа 2020 г. Проверено 25 декабря 2019 г.
- ^ ИСО-ИР-106 (1985)
- ^ ECMA-35 (1994) , с. 15, глава 7.3, примечание 23
- ^ ИСО-ИР-140 (1987)
- ^ ИСО-ИР-7 (1975)
- ^ ИСО-ИР-26 (1976)
- ^ ИСО-ИР-36 (1977)
- ^ ECMA-35 (1980) , с. 8, глава 5.1.7
- ↑ Перейти обратно: Перейти обратно: а б ИСО-ИР-105 (1985 г.)
- ↑ Перейти обратно: Перейти обратно: а б с д ECMA-35 (1994) , с. 17, глава 8.3.1
- ↑ Перейти обратно: Перейти обратно: а б с д ECMA-35 (1994) , с. 23, глава 9.3.1
- ↑ Перейти обратно: Перейти обратно: а б с ECMA-35 (1994) , с. 19, глава 8.4
- ↑ Перейти обратно: Перейти обратно: а б с ECMA-35 (1994) , с. 17, глава 8.3.2
- ^ ECMA-35 (1994) , стр. 23–24, глава 9.4.
- ^ ECMA-35 (1994) , с. 27, глава 11.1
- ^ ECMA-35 (1994) , с. 17, глава 8.3.3
- ^ ECMA-35 (1994) , с. 47, приложение Б
- ^ ИСО-ИК , с. 2, глава 1 («Введение»)
- ^ ИСО/МЭК 2375 (2003)
- ↑ Перейти обратно: Перейти обратно: а б «Обработка декларации SGML в SP» . SP: система SGML, соответствующая международному стандарту ISO 8879 .
- ^ «20: Декларация SGML HTML 4» . Спецификация HTML 4.01 . W3C .
- ^ ИСО-ИК , с. 10, глава 2.2 («Набор графических символов из 94 символов со вторым промежуточным байтом»)
- ^ ARIB STD-B24 (2008) , с. 39, часть 2, Таблица 7-3
- ^ Масчек, Свен; Ле Бретон, Стефан; Гамильтон, Ричард Л. «Об« альтернативном наборе символов рисования линий » » . ~sven_mascheck/ . Архивировано из оригинала 29 декабря 2019 г. Проверено 8 января 2020 г.
- ^ ECMA-35 (1994) , с. 36, глава 14.4
- ^ ECMA-35 (1994) , с. 36, глава 14.4.2, примечание 48
- ^ ECMA-35 (1994) , с. 36, глава 14.4.2, примечание 47
- ^ ETS 300 706 (1997) , с. 103, глава 14 («Динамически переопределяемые символы»)
- ↑ Перейти обратно: Перейти обратно: а б с д и ж г час я дж к л м н тот п д ECMA-35 (1994) , стр. 35–36, глава 14.3.2.
- ^ ISO/IEC 10646 (2017) , стр. 19–20, глава 12.4 («Идентификация набора функций управления»)
- ^ ECMA-35 (1994) , с. 32, таблица 5
- ↑ Перейти обратно: Перейти обратно: а б с ECMA-35 (1994) , стр. 37–41, глава 15.2.
- ^ ECMA-35 (1994) , с. 34, глава 14.2.2
- ^ ECMA-35 (1994) , с. 34, глава 14.2.3
- ^ Цифровой . «DECDWL — линия двойной ширины и одинарной высоты» . Информация о программаторе видеотерминала VT510 . Архивировано из оригинала 2 августа 2020 г. Проверено 17 января 2020 г.
- ^ Кавасаки, Юсуке (2010). «Кодировать::JP::Emoji::Кодировка» . Кодировать-JP-Emoji . Строка 268. Архивировано из оригинала 30 апреля 2022 г. Проверено 28 мая 2020 г.
- ^ ECMA-35 (1994) , стр. 36–37, глава 14.5.
- ^ ECMA-35 (1980) , стр. 14–15, глава 5.3.7.
- ↑ Перейти обратно: Перейти обратно: а б с д ИСО-ИР , с. 20, глава 2.8.1 («Системы кодирования со стандартным возвратом»)
- ↑ Перейти обратно: Перейти обратно: а б с д ECMA-35 (1994) , стр. 41–42, глава 15.4.
- ↑ Перейти обратно: Перейти обратно: а б с д и ИСО-ИР , с. 21, глава 2.8.2 («Системы кодирования без стандартного возврата»)
- ^ ECMA-35 (1994) , с. 41, глава 15.3
- ↑ Перейти обратно: Перейти обратно: а б с ISO/IEC 10646 (2017) , стр. 19, глава 12.2 («Идентификация схемы кодирования UCS»)
- ^ ISO/IEC 10646 (2017) , стр. 18–19, глава 12.1 («Цель и контекст идентификации»).
- ^ ИСО-ИР-192 (1996)
- ^ ИСО-ИР-195 (1996)
- ^ ISO/IEC 10646 (2017) , с. 20, глава 12.5 («Идентификация системы кодирования ISO/IEC 2022»)
- ↑ Перейти обратно: Перейти обратно: а б Шайфлер (1989) , § Кодировки нестандартных наборов символов
- ^ Лунде (2008) , стр. 229–230, глава 4 («Методы кодирования»), раздел «Кодировка ISO-2022» «Те кодировки, которые широко использовались в прошлом или продолжают использоваться сегодня для некоторых целей, были выделены».
- ↑ Перейти обратно: Перейти обратно: а б «Дополнительная необходимая информация, связанная с кодированием» . Идентификаторы наборов символов в кодировке IBM Globalization . ИБМ . Архивировано из оригинала 7 января 2015 г.
- ↑ Перейти обратно: Перейти обратно: а б с Стандарт кодирования WHATWG , раздел 2 («Безопасность»).
- ↑ Перейти обратно: Перейти обратно: а б с Стандарт кодирования WHATWG , глава 4.2 («Имена и метки»), привязка «замена»
- ↑ Перейти обратно: Перейти обратно: а б с д Стандарт кодирования WHATWG , раздел 14.1 («замена»)
- ↑ Перейти обратно: Перейти обратно: а б с д и ж RFC 1468 (1993)
- ↑ Перейти обратно: Перейти обратно: а б с «Идентификаторы кодовых страниц» . Центр разработки Windows . Майкрософт. Архивировано из оригинала 16 июня 2019 г. Проверено 16 сентября 2019 г.
- ↑ Перейти обратно: Перейти обратно: а б Стандарт кодирования WHATWG , раздел 12.2 («ISO-2022-JP»)
- ^ Чанг, Хе-Шик. «Модули/cjkcodecs/_codecs_iso2022.c, строка 1122» . Дерево исходного кода cPython . Фонд программного обеспечения Python. Архивировано из оригинала 30 апреля 2022 г. Проверено 15 сентября 2019 г.
- ^ «кодеки — реестр кодеков и базовые классы § Стандартные кодировки» . Документация Python 3.7.4 . Фонд программного обеспечения Python. Архивировано из оригинала 28 июля 2019 г. Проверено 16 сентября 2019 г.
- ^ «2: Кодовые наборы и преобразование кодовых наборов» . Технический справочник DIGITAL UNIX по использованию японских функций . Корпорация цифрового оборудования , Compaq . [ мертвая ссылка ]
- ↑ Перейти обратно: Перейти обратно: а б Лунде (2008) , стр. 236–238, глава 4 («Методы кодирования»), раздел «Предшественник кодировки ISO-2022-JP — кодировка JIS».
- ^ RFC 1554 (1993)
- ^ RFC 2237 (1997)
- ^ «PQ02042: Новая функция для поддержки C/370 iconv() для японского ISO-2022-JP» . ИБМ . 19 января 2021 г. Архивировано из оригинала 4 января 2022 г. Проверено 4 января 2022 г.
- ↑ Перейти обратно: Перейти обратно: а б «CCSID 9148» . Идентификаторы наборов символов в кодировке IBM Globalization . ИБМ . Архивировано из оригинала 29 ноября 2014 г.
- ^ «CCSID 956» . Идентификаторы наборов символов в кодировке IBM Globalization . ИБМ . Архивировано из оригинала 2 декабря 2014 г.
- ^ «CCSID 957» . Идентификаторы наборов символов в кодировке IBM Globalization . ИБМ . Архивировано из оригинала 30 ноября 2014 г.
- ^ «CCSID 958» . Идентификаторы наборов символов в кодировке IBM Globalization . ИБМ . Архивировано из оригинала 1 декабря 2014 г.
- ^ «CCSID 959» . Идентификаторы наборов символов в кодировке IBM Globalization . ИБМ . Архивировано из оригинала 2 декабря 2014 г.
- ^ «CCSID 5052» . Идентификаторы наборов символов в кодировке IBM Globalization . ИБМ . Архивировано из оригинала 29 ноября 2014 г.
- ^ «CCSID 5053» . Идентификаторы наборов символов в кодировке IBM Globalization . ИБМ . Архивировано из оригинала 29 ноября 2014 г.
- ^ «CCSID 5054» . Идентификаторы наборов символов в кодировке IBM Globalization . ИБМ . Архивировано из оригинала 29 ноября 2014 г.
- ^ «CCSID 5055» . Идентификаторы наборов символов в кодировке IBM Globalization . ИБМ . Архивировано из оригинала 29 ноября 2014 г.
- ↑ Перейти обратно: Перейти обратно: а б RFC 1557 (1993)
- ^ «КС Х 1001:1992» (PDF) . Архивировано (PDF) из оригинала 26 сентября 2007 г. Проверено 12 июля 2007 г.
- ^ ИСО-ИР-149 (1988)
- ↑ Перейти обратно: Перейти обратно: а б с д РФК 1922 (1996)
- ^ «CVE-2024-2961» .
- ^ «Уязвимость GLIBC на серверах, обслуживающих PHP» .
- ^ ECMA-43 (1991) , стр. 9–10, глава 8 («Уровни»).
- ^ ECMA-43 (1985) , стр. 7–11, глава 7.3 («Набор G0»)
- ^ ECMA-43 (1991) , стр. 6–8, глава 7.4 («Набор G0»)
- ^ ECMA-43 (1991) , с. 11, глава 10.3 («Идентификация версии»)
- ↑ Перейти обратно: Перейти обратно: а б ECMA-43 (1991) , с. 23, приложение E («Основные различия между вторым изданием (1985 г.) и настоящим (третьим) изданием настоящего стандарта ECMA»)
- ^ ИПТК (1995). Рекомендуемый формат сообщения IPTC (PDF) (5-е изд.). IPTC TEC 7901. Архивировано (PDF) из оригинала 25 января 2022 г. Проверено 14 января 2020 г.
- ^ ECMA-43 (1991) , стр. 10, глава 9.2 («Уникальное кодирование символов»)
- ^ ван Винген, Йохан В. (1999). «8. Расширение кода, ISO 2022 и 2375, ISO 4873 и 10367» . Наборы символов. Буквы, жетоны и коды . Терена. Архивировано из оригинала 01 августа 2020 г. Проверено 2 октября 2019 г.
- ^ ECMA-43 (1991) , стр. 10–11, глава 10 («Идентификация версии и уровня»).
- ^ ИБМ . «Архитектура представления символьных данных (CDRA)» . ИБМ . стр. 157–162. Архивировано из оригинала 23 июня 2019 г. Проверено 18 июня 2020 г.
- ^ Шайфлер (1989)
- ^ Шайфлер (1989) , § Управляющие персонажи
- ^ Шайфлер (1989) , § Направленность
- ^ Шайфлер (1989) , § Кодировки стандартного набора символов
- ^ Шайфлер (1989) , § Утвержденные стандартные кодировки
- ^ «DICOM PS3.2 2016d — соответствие; D.6.2 Наборы символов; D.6 Поддержка наборов символов» . Архивировано из оригинала 16 февраля 2020 г. Проверено 21 мая 2020 г.
- ^ «Вариант DICOM ISO 2022» . Архивировано из оригинала 30 апреля 2013 г. Проверено 25 июля 2009 г.
- ↑ Перейти обратно: Перейти обратно: а б Сивонен, Анри (17 декабря 2018 г.). «(НЕОТПРАВЛЕННЫЙ ЧЕРНОВИК) Нет генерации U + FFFD для содержимого ASCII-состояния нулевой длины между Escape-последовательностями ISO-2022-JP» (PDF) . Архивировано (PDF) из оригинала 21 февраля 2019 г. Проверено 21 февраля 2019 г.
- ^ «935453 — Соберите телеметрию о HZ и других кодировках, которые мы можем попытаться удалить» . Архивировано из оригинала 19 мая 2017 г. Проверено 18 июня 2018 г.
- ^ Дэвис, Марк; Суиньяр, Мишель (19 сентября 2014 г.). «3.6.2 Некоторые выходные данные для всех входных данных» . Технический отчет Unicode № 36: Вопросы безопасности Unicode (версия 15) . Консорциум Юникод. Архивировано из оригинала 22 февраля 2019 г. Проверено 21 февраля 2019 г.
реестра Цитируемые стандарты и индексы
- АРИБ (2008). ARIB STD-B24: Спецификация кодирования и передачи данных для цифрового вещания (PDF) (стандарт ARIB). 5.2-Е1. Том. 1. Архивировано (PDF) из оригинала 10 июля 2017 г. Проверено 10 июля 2017 г.
- ЭКМА (1980). ECMA-35: Расширение 7-битного набора кодированных символов (PDF) (стандарт ECMA) (2-е изд.).
- ЭКМА (1994). ECMA-35: Структура кода символов и методы расширения (PDF) (стандарт ECMA) (6-е изд.).
- ЭКМА (1985). ECMA-43: Структура и правила набора 8-битных кодированных символов (PDF) (стандарт ECMA) (2-е изд.).
- ЭКМА (1991). ECMA-43: Структура и правила набора 8-битных кодированных символов (PDF) (стандарт ECMA) (3-е изд.).
- ЭКМА (1991). ECMA-48: Функции управления для наборов кодированных символов (PDF) (стандарт ECMA) (5-е изд.).
- ЭКМА (2000). ECMA-144: наборы 8-битных однобайтовых графических символов: латинский алфавит № 6 (PDF) (стандарт ECMA) (3-е изд.).
- Европейский вещательный союз (1997). ETS 300 706: Спецификация расширенного телетекста (PDF) (Европейские стандарты телекоммуникаций). ЕТСИ .
- ИСО/МЭК ОТК 1/ПК 2 (2003 г.). ISO/IEC 2375:2003: Информационные технологии. Процедура регистрации escape-последовательностей и наборов кодированных символов . ИСО .
{{cite book}}
: CS1 maint: числовые имена: список авторов ( ссылка ) - ISO/IEC JTC 1/SC 2 (12 февраля 1998 г.). ISO/IEC FDIS 8859-10: Информационные технологии. 8-битные однобайтовые наборы графических символов. Часть 10. Латинский алфавит № 6 (PDF) (Окончательный проект международного стандарта).
{{cite book}}
: CS1 maint: числовые имена: список авторов ( ссылка ) - ISO/IEC JTC 1/SC 2 (2017). ISO/IEC 10646: Информационные технологии. Универсальный набор кодированных символов (UCS) (стандарт ISO) (5-е изд.). ИСО .
{{cite book}}
: CS1 maint: числовые имена: список авторов ( ссылка ) - ISO-IR: Международный реестр наборов кодированных символов ISO/IEC для использования с escape-последовательностями (PDF) (указатель реестра). ITSCJ/ IPSJ .
- Шайфлер, Роберт В. (1989). Кодирование сложного текста (стандарт X Консорциума). Х Консорциум .
- ван Кестерен, Энн . Стандарт кодирования WHATWG (Живой стандарт WHATWG). ЧТОРГ .
Зарегистрированные наборы кодов, цитируемые [ править ]
- ISO/TC 97/SC 2 (1 декабря 1975 г.). ISO-IR-1: Набор управляющих символов ISO 646 (PDF) . ITSCJ/ IPSJ .
{{citation}}
: CS1 maint: числовые имена: список авторов ( ссылка ) - Шведская комиссия по стандартизации (1 декабря 1975 г.). ISO-IR-7: Комплект управления NATS для передачи текста газеты (PDF) . ITSCJ/ IPSJ .
- Японский комитет промышленных стандартов (1 декабря 1975 г.). ISO-IR-14: Набор японских римских графических символов (PDF) . ITSCJ/ IPSJ .
- ИПТК (25 марта 1976 г.). ISO-IR-26: Комплект управления для передачи текста газеты (PDF) . ITSCJ/ IPSJ .
- ISO/TC 97/SC 2 (15 октября 1977 г.). ISO-IR-36: набор управляющих символов ISO 646, где IS4 заменен на Single Shift для G2 (SS2) (PDF) . ITSCJ/ IPSJ .
{{citation}}
: CS1 maint: числовые имена: список авторов ( ссылка ) - ISO/TC97/SC2/WG-7 ; ЭКМА (1 августа 1985 г.). ISO-IR-104: Минимальный набор C0 для ISO 4873 (PDF) . ITSCJ/ IPSJ .
{{citation}}
: CS1 maint: числовые имена: список авторов ( ссылка ) - ISO/TC97/SC2/WG-7 ; ЭКМА (1 августа 1985 г.). ISO-IR-105: Минимальный набор C1 для ISO 4873 (PDF) . ITSCJ/ IPSJ .
{{citation}}
: CS1 maint: числовые имена: список авторов ( ссылка ) - МСЭ (1 августа 1985 г.). ISO-IR-106: Основной набор функций управления Teletex (PDF) . ITSCJ/ IPSJ .
- Управление стандартизации и измерений (31 июля 1987 г.). ISO-IR-140: Набор управляющих символов C0 стандарта ISO 646, с заменой EM на SS2 (PDF) . ITSCJ/ IPSJ .
- Корейское бюро стандартов (1 октября 1988 г.). ISO-IR-149: Набор корейских графических символов для обмена информацией (KS C 5601:1987) (PDF) . ITSCJ/ IPSJ .
- ISO/IEC/JTC1/SC2/WG3 (16 апреля 1990 г.). ISO-IR-155: Базовый комплект чертежей коробок (PDF) . ITSCJ/ IPSJ .
{{citation}}
: CS1 maint: числовые имена: список авторов ( ссылка ) - МКИТТ (13 июля 1992 г.). ISO-IR-164: Дополнительный набор графических символов иврита (PDF) . ITSCJ/ IPSJ .
- ЭКМА (22 апреля 1996 г.). ISO-IR-192: Формат преобразования UCS (UTF-8), уровень реализации 3, без стандартного возврата (PDF) . ITSCJ/ IPSJ .
- ЭКМА (22 апреля 1996 г.). ISO-IR-195: Формат преобразования UCS (UTF-16), уровень реализации 3, без стандартного возврата (PDF) . ITSCJ/ IPSJ .
- ЭКМА (22 апреля 1996 г.). ISO-IR-196: Формат преобразования UCS (UTF-8) со стандартным возвратом (PDF) . ITSCJ/ IPSJ .
- Национальное управление по стандартизации Ирландии (07.12.1999). ISO-IR-208: Набор символов в кодировке Огама для обмена информацией (PDF) . ITSCJ/ IPSJ .
Интернет-запросы на комментарии цитируются [ править ]
- Мурай, Дж.; Криспин, М.; ван дер Поэль, Э. (1993). «RFC 1468: Кодировка японских символов для интернет-сообщений» . Запросы на комментарии . IETF . дои : 10.17487/rfc1468 .
- Охта, М.; Ханда, К. (1993). «RFC 1554: ISO-2022-JP-2: Многоязычное расширение ISO-2022-JP» . Запросы на комментарии . IETF . дои : 10.17487/rfc1554 .
- Чой, У.; Чон, К.; Парк, Х. (1993). «RFC 1557: Корейская кодировка символов для интернет-сообщений» . Запросы на комментарии . IETF . дои : 10.17487/rfc1557 .
- Чжу, ХФ.; Ху, Д.Ю.; Ван, ЗГ .; Као, ТК; Чанг, ЧМ.; Криспин, М. (1996). «RFC 1922: Кодировка китайских символов для интернет-сообщений» . Запросы на комментарии . IETF . дои : 10.17487/rfc1922 .
- Тамару, К. (1997). «RFC 2237: Кодировка японских символов для интернет-сообщений» . Запросы на комментарии . IETF . дои : 10.17487/rfc2237 .
Другие опубликованные работы цитируются [ править ]
- Лунде, Кен (2008). Обработка информации CJKV (2-е изд.). О'Рейли Медиа . ISBN 9780596514471 .
Дальнейшее чтение [ править ]
- Лунде, Кен (1998). Обработка информации CJKV . Кембридж, Массачусетс: O'Reilly & Associates . ISBN 1-56592-224-7 .
Внешние ссылки [ править ]
- ИСО/МЭК 2022:1994.
- ИСО/МЭК 2022:1994/Кор 1:1999
- ECMA-35 , эквивалент ISO/IEC 2022, доступен для бесплатной загрузки.
- Международный реестр наборов кодированных символов, которые будут использоваться с Escape-последовательностями , полный список назначенных наборов символов и их escape-последовательностей.
- История кодов символов в Северной Америке, Европе и Восточной Азии с 1999 г., ред. 2004 г.
- Кена Лунде : CJK.INF документ по кодированию китайского, японского и корейского (CJK) языков, включая обсуждение различных вариантов ISO/IEC 2022.