ISO/IEC 2022 Информационные технологии. Структура кода символов и методы расширения — это стандарт ISO / IEC в области кодирования символов . Он эквивалентен стандарту ECMA ECMA-35 , [1] [2], стандарту ANSI ANSI X3.41 [3] и японскому промышленному стандарту JIS X 0202 . Созданный в 1971 году, последний раз он был пересмотрен в 1994 году. [4]
ISO 2022 определяет общую структуру, которой могут соответствовать кодировки символов, выделяя определенные диапазоны байтов ( 0x00–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, в том числе:
Однако существуют escape-последовательности ISO 2022 для переключения на UTF-8 и обратно как «система кодирования, отличная от системы ISO 2022» [13] , которая поддерживается некоторыми эмуляторами терминала , такими как xterm . [14]
ISO/IEC 2022 определяет следующее:
Конкретная реализация не обязательно должна реализовывать весь стандарт; уровень соответствия и поддерживаемые наборы символов определяются реализацией. Хотя многие механизмы, определенные стандартом ISO/IEC 2022, используются нечасто, несколько установленных кодировок основаны на подмножестве системы ISO/IEC 2022. [19] В частности, 7-битные системы кодирования, использующие механизмы ISO/IEC 2022, включают ISO-2022-JP (или кодировку JIS ), которая в основном используется в электронной почте на японском языке . 8-битные системы кодирования, соответствующие ISO/IEC 2022, включают ISO/IEC 4873 (ECMA-43), который, в свою очередь, соответствует ISO/IEC 8859 , [9] [10] и расширенный код Unix , который используется для East Азиатские языки. [11] Более специализированные приложения ISO 2022 включают систему кодирования MARC-8 , используемую в библиотечных записях MARC 21 . [3]
Escape-последовательности для переключения на определенные наборы символов или кодировки регистрируются в реестре ISO-IR (за исключением тех, которые предназначены для частного использования, значения которых определяются поставщиками или спецификациями протокола, такими как ARIB STD-B24 ) и следовать шаблонам, определенным в стандарте. Кодировки символов, использующие эти escape-последовательности, требуют последовательной обработки данных в прямом направлении, поскольку правильная интерпретация данных зависит от ранее встречавшихся escape-последовательностей.
Определенные профили, такие как ISO-2022-JP, могут налагать дополнительные условия, например, что текущий набор символов сбрасывается на US-ASCII перед концом строки. Кроме того, escape-последовательности, объявляющие наборы национальных символов, могут отсутствовать, если конкретная кодировка на основе ISO-2022 разрешает или требует этого и требует использования определенных наборов национальных символов. Например, ISO-8859-1 утверждает, что определение escape-последовательности не требуется.
Для представления больших наборов символов ISO/IEC 2022 основывается на свойстве ISO/IEC 646 , согласно которому семибитное представление символов обычно может представлять 94 графических (печатных) символа (помимо пробела и 33 управляющих символов); если исключены только управляющие коды C0 (узко определенные), их можно расширить до 96 символов. Таким образом, используя два байта, можно представить до 8836 (94×94) символов; и, используя три байта, до 830 584 (94×94×94) символов. Хотя стандарт определяет это, ни один зарегистрированный набор символов не использует три байта (хотя незарегистрированный G2 EUC-TW использует это, как и аналогично незарегистрированный CCCII ).
Для двухбайтовых наборов символов кодовая точка каждого символа обычно указывается в так называемой форме строки-ячейки или кутен [a] , которая состоит из двух чисел от 1 до 94 включительно, определяющих строку [b] и ячейку [. c] этого персонажа в зоне. Для трехбайтового набора в начале добавляется дополнительный номер плоскости [d] . [20] 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]
Последовательности, использующие символ ESC (escape), принимают форму , где за символом ESC следует ноль или более промежуточных байтов [28] ( I ) из диапазона 0x20–0x2F и один последний байт [29] ( F ) из диапазона 0x30–0x7E. [30]ESC [I...] F
Первый I- байт или его отсутствие определяет тип escape-последовательности; оно может, например, обозначать рабочий набор или обозначать одну функцию управления. Во всех типах escape-последовательностей F -байты в диапазоне 0x30–0x3F зарезервированы для незарегистрированного частного использования, определенного по предварительному соглашению между сторонами. [31]
Функции управления из некоторых наборов могут использовать дополнительные байты, следующие за управляющей последовательностью. Например, за функцией управления ISO 6429 « Вводитель управляющей последовательности », которую можно представить с помощью escape-последовательности, следует ноль или более байтов в диапазоне 0x30–0x3F, затем ноль или более байтов в диапазоне 0x20–0x2F, затем одним байтом в диапазоне 0x40–0x7E, причем вся последовательность называется «управляющей последовательностью». [32]
Каждый из четырех рабочих наборов G0–G3 может представлять собой набор из 94 символов или многобайтовый набор из 94 n символов . Кроме того, G1-G3 может представлять собой набор из 96 или 96 n символов.
В наборе из 96 или 96 n символов байты от 0x20 до 0x7F при вызове GL или от 0xA0 до 0xFF при вызове GR выделяются и могут использоваться набором. В наборе символов из 94 или 94 n байты 0x20 и 0x7F не используются. [33] Когда в регионе GL вызывается набор из 96 или 96 n символов, символы пробела и удаления (коды 0x20 и 0x7F) недоступны до тех пор, пока не будет установлен набор из 94 или 94 n символов (например, набор G0). ) вызывается в GL. [5] Наборы из 96 символов не могут быть назначены G0.
Регистрация набора как набора из 96 символов не обязательно означает, что байты 0x20/A0 и 0x7F/FF фактически назначаются набором; некоторые примеры наборов графических символов, которые зарегистрированы как 96-наборы, но не используют эти байты, включают набор G1 из IS 434 , [34] набор чертежей рамки из ISO/IEC 10367 , [35] и ISO-IR-164 ( подмножество набора G1 ISO-8859-8 , содержащее только буквы, используемые CCITT ). [36]
Ожидается, что символы будут пробелами, а не объединяющими символами, если иное не указано в рассматриваемом графическом наборе. [37] ISO 2022/ECMA-35 также признает использование управляющих символов возврата и возврата каретки в качестве средства комбинирования символов, разделенных иначе, а также последовательности CSI «Комбинация графических символов» (GCC) [37] ( CSI 0x20 (SP) 0x5F (_)). [38]
Использование возврата каретки и возврата каретки таким образом разрешено ISO/IEC 646 , но запрещено ISO/IEC 4873 /ECMA-43 [39] и ISO/IEC 8859 , [40] [41] на том основании, что оно оставляет репертуар графических персонажей не определен. Однако ISO/IEC 4873/ECMA-43 разрешает использование функции GCC при условии, что последовательность символов сохраняется прежней и просто отображается в одном месте, а не перепечатывается для формирования символа с другим значением. . [42]
Наборы управляющих символов классифицируются как «первичные» или «вторичные» наборы управляющих кодов, [43] соответственно также называемые наборами управляющих кодов «C0» и «C1». [44]
Набор элементов управления C0 должен содержать управляющий символ ESC (escape) по адресу 0x1B [45] (набор C0, содержащий только ESC, регистрируется как ISO-IR-104), [46] тогда как набор элементов управления C1 вообще не может содержать элемент управления 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» (в диапазоне от ), [53] хотя в настоящее время последовательности «3Ft» не назначены (по состоянию на 2019 г.). [54] Некоторые из них указаны в ECMA-35 (ISO 2022/ANSI X3.41), другие – в ECMA-48 (ISO 6429/ANSI X3.64). [55] ECMA-48 называет их «независимыми функциями управления». [56]ESC 0x23 (#) [I...] 0x40 (@)ESC 0x23 (#) [I...] 0x7E (~)
Escape-последовательности типа «Fp» ( ESC 0x30 (0)через ESC 0x3F (?)) или типа «3Fp» ( через ) зарезервированы для одиночных управляющих кодов частного использования по предварительному соглашению между сторонами. [58] Несколько таких последовательностей обоих типов используются терминалами DEC , такими как VT100 , и, таким образом, поддерживаются эмуляторами терминалов . [14]ESC 0x23 (#) [I...] 0x30 (0)ESC 0x23 (#) [I...] 0x3F (?)
По умолчанию коды GL обозначают символы G0, а коды GR (там, где они доступны) указывают символы G1; иное может быть указано по предварительному соглашению. Набор, вызываемый для каждой области, также может быть изменен с помощью управляющих кодов, называемых сдвигами, как показано в таблице ниже. [59]
8-битный код может иметь коды GR, определяющие символы G1, т.е. с соответствующим 7-битным кодом, использующим Shift In и Shift Out для переключения между наборами (например, JIS X 0201 ), [60] хотя некоторые вместо этого имеют коды GR, определяющие G2. символы с соответствующим 7-битным кодом, использующим односменный код для доступа ко второму набору (например, T.51 ). [61]
Коды, показанные в таблице ниже, являются наиболее распространенными кодировками этих кодов управления, соответствующими стандарту ISO/IEC 6429 . Сдвиги LS2, LS3, LS1R, LS2R и LS3R регистрируются как отдельные функции управления и всегда кодируются как управляющие последовательности, перечисленные ниже, [54] , тогда как остальные являются частью набора управляющих кодов C0 или C1 (как показано ниже, SI (LS0) и SO (LS1) — элементы управления C0, а SS2 и SS3 — элементы управления C1), что означает, что их кодирование и доступность могут различаться в зависимости от того, какие наборы элементов управления назначены: они должны присутствовать в назначенных наборах элементов управления, если их функциональность используется. . [48] [49] Сами элементы управления C1, как упоминалось выше, могут быть представлены с помощью escape-последовательностей или 8-битных байтов, но не того и другого.
Альтернативные кодировки односменных кодов управления C0 доступны в определенных наборах управляющих кодов. Например, SS2 и SS3 обычно доступны по адресам 0x19 и 0x1D соответственно в T.51 [61] и T.61 . [62] В настоящее время это кодирование рекомендуется ISO/IEC 2022/ECMA-35 для приложений, требующих 7-битных однобайтовых представлений SS2 и SS3, [63] и может также использоваться только для SS2, [64] хотя более старый код наборы с SS2 по адресу 0x1C также существуют, [65] [66] [67] и упоминались как таковые в более ранней редакции стандарта. [68] Кодирование одиночных смен 0x8E и 0x8F, как показано ниже, является обязательным для уровней 2 и 3 ISO/IEC 4873. [69]
Хотя официально односменные коды считаются кодами сдвига и называются соответственно, они не всегда рассматриваются как сдвиги [12] и могут просто рассматриваться как префиксные байты (т.е. первые байты в многобайтовой последовательности), [11] поскольку они не требуют, чтобы кодер сохранял текущий активный набор как состояние , в отличие от блокировки кодов сдвига. В 8-битных средах в качестве области с одной сменой можно использовать либо GL, либо GR, но не оба одновременно. Это должно быть указано в определении версии кода. [72] Например, стандарт ISO/IEC 4873 определяет GL, тогда как упакованный EUC определяет GR. В 7-битных средах в качестве односменной области используется только GL. [74] [75] При необходимости о том, какая односменная зона используется, можно сообщить с помощью последовательностей дикторов.
Имена «блокировка смещения нуля» (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/IEC 2022. Процедура регистрации коды и наборы с реестром ISO-IR определены стандартом ISO/IEC 2375 . Каждая регистрация получает уникальную escape-последовательность и уникальный номер записи реестра для ее идентификации. [77] [78] Например, набор символов CCITT для упрощенного китайского языка известен как ISO-IR-165 .
Регистрация наборов кодированных символов в реестре ISO-IR идентифицирует документы, определяющие набор символов или функцию управления, связанную с escape-последовательностью нечастного использования ISO/IEC 2022. Это может быть стандартный документ; однако регистрация не создает новый стандарт ISO, не обязывает ISO или IEC принимать его в качестве международного стандарта и не обязывает ISO или IEC добавлять какие-либо символы в универсальный набор кодированных символов . [79]
Зарегистрированные в ISO-IR escape-последовательности также используются, инкапсулированные в формальный общедоступный идентификатор, для идентификации наборов символов, используемых для числовых ссылок на символы в SGML (ISO 8879). Например, строка ISO 646-1983//CHARSET International Reference Version (IRV)//ESC 2/5 4/0может использоваться для идентификации международной справочной версии ISO 646-1983 , [80] , а спецификация HTML 4.01 используется ISO Registration Number 177//CHARSET ISO/IEC 10646-1:1993 UCS-4 with implementation level 3//ESC 2/5 2/15 4/6для идентификации Unicode. [81] Текстовое представление escape-последовательности, включенное в третий элемент FPI, будет распознаваться реализациями SGML для поддерживаемых наборов символов. [80]
Escape-последовательности для обозначения наборов символов принимают форму . Как упоминалось выше, промежуточные ( I ) байты находятся в диапазоне 0x20–0x2F, а последний ( F ) байт — в диапазоне 0x30–0x7E. Первый байт I (или, для многобайтового набора, первые два) идентифицирует тип набора символов и рабочий набор, которому он должен быть назначен, тогда как байт F (и любые дополнительные байты I ) идентифицируют набор символов. сам по себе, как назначено в реестре ISO-IR (или, для escape-последовательностей частного использования, по предварительному соглашению).ESC I [I...] F
Дополнительные байты I могут быть добавлены перед байтом F , чтобы расширить диапазон байтов F. В настоящее время это используется только с наборами из 94 символов, которым были назначены коды формы . [82] С другой стороны, никаких многобайтовых 96-множеств не зарегистрировано, поэтому приведенные ниже последовательности являются строго теоретическими.ESC ( ! F
Как и в случае с другими типами escape-последовательностей, диапазон 0x30–0x3F зарезервирован для F - байтов частного использования, [31] в данном случае для определений наборов символов частного использования (которые могут включать незарегистрированные наборы, определенные такими протоколами, как ARIB STD-B24 [31 ]) . 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]
Обратите внимание, что реестр F -байтов независим для разных типов. Набор графических символов из 94 символов, обозначаемый через, ESC ( Aникак ESC + Aне связан с набором из 96 символов, обозначаемым ESC - Aчерез ESC / A. И ни один из них не имеет отношения к набору из 94 n символов, обозначенному 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]
Особый интерес представляют последовательности, которые переключаются на форматы ISO/IEC 10646 ( Unicode ), которые не соответствуют структуре ISO/IEC 2022. К ним относятся UTF-8 (которая не резервирует диапазон 0x80–0x9F для управляющих символов), ее предшественница UTF-1 (которая смешивает байты GR и GL в многобайтовых кодах), а также UTF-16 и UTF-32 (которые используют более широкие единицы кодирования). [99] [101]
Также было зарегистрировано несколько кодов для подмножеств (уровни 1 и 2) UTF-8, UTF-16 и UTF-32, а также для трёх уровней UCS-2 . [101] Однако единственными кодами, указанными в настоящее время в ISO/IEC 10646, являются коды уровня 3 для UTF-8, UTF-16 и UTF-32 и код неопределенного уровня для UTF-8, а остальные перечислены как устарел. [103] ISO/IEC 10646 предусматривает, что форматы UTF-16 и UTF-32 с обратным порядком байтов обозначаются их escape-последовательностями. [104]
Из последовательностей, переключающихся на UTF-8, ESC % Gподдерживается, например, xterm . [14]
Хотя использование варианта стандартной возвращаемой последовательности из UTF-16 и UTF-32 разрешено, байты escape-последовательности должны быть дополнены до размера кодовой единицы кодировки (т.е. 001B 0025 0040для UTF-16), т.е. кодирование стандартной возвращаемой последовательности не совсем соответствует ISO/IEC 2022. По этой причине в обозначениях UTF-16 и UTF-32 используется синтаксис без стандартного возврата. [107]
Для указания кодировок с помощью меток формат Compound Text Консорциума X определяет пять последовательностей DOCS для частного использования. [108]
Последовательность «объявление структуры кода» ( ) используется для объявления конкретной структуры кода или определенной группы средств ISO 2022, которые используются в конкретной версии кода. Хотя объявления можно комбинировать, некоторые противоречивые комбинации (в частности, использование объявлений 16–23 о блокировке смены с объявлениями 1, 3 и 4) запрещены стандартом, как и использование дополнительных объявлений поверх объявлений 12–14 уровня ISO/IEC 4873. [92] (в которых полностью указаны допустимые конструктивные особенности). Последовательность объявлений следующая:ESC SP (0x20) F
Шесть 7-битных версий кода ISO 2022 (ISO-2022-CN, ISO-2022-CN-EXT, ISO-2022-JP, ISO-2022-JP-1, ISO-2022-JP-2 и ISO-2022-KR ) определяются документами IETF RFC , из которых в прошлом широко использовались ISO-2022-JP и ISO-2022-KR. [109] Ряд других вариантов определен поставщиками, включая IBM . [110] Хотя UTF-8 является предпочтительной кодировкой в HTML5 , устаревший контент в ISO-2022-JP остается достаточно распространенным, поэтому стандарт кодирования WHATWG сохраняет его поддержку, [111] в отличие от сопоставления ISO-2022-KR, ISO- 2022-CN и ISO-2022-CN-EXT [112] полностью на заменяющий символ , [113] из-за опасений по поводу атак путем внедрения кода , таких как межсайтовый скриптинг . [111] [113]
Версии 8-битного кода включают расширенный код Unix . [11] [12] Кодировки ISO/IEC 8859 также соответствуют ISO 2022 в подмножестве, предусмотренном ISO/IEC 4873. [9] [10]
ISO-2022-JP — широко используемая кодировка японского языка, особенно вэлектронной почте. Он был введен для использования в сети JUNET и позже кодифицирован вIETF RFC1468 от 1993 года.[114]Он имеет преимущество перед другимикодировками для японского языка, поскольку не требует8-битной чистойпередачи. Microsoft называет этокодовой страницей 50220. [115]Он начинается в ASCII и включает следующие escape-последовательности:
ESC ( Bдля переключения на ASCII (1 байт на символ)ESC ( Jдля перехода на JIS X 0201-1976 (ISO/IEC 646:JP) Римский набор (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переключения на набор кана JIS X 0201-1976 (1 байт на символ) не является частью профиля ISO-2022-JP [114] , но также иногда используется. Python допускает это в варианте, который он обозначает ISO-2022-JP-EXT (который также включает JIS X 0212, как описано ниже, завершая покрытие EUC-JP ); [117] [118] По названию и структуре это близко к кодировке, обозначенной DEC ISO -2022-JPext , которая, кроме того, добавляет двухбайтовую определяемую пользователем область , доступ к которой осуществляется с помощью для завершения покрытия Super DEC Kanji . [119] Вариант WHATWG/HTML5 позволяет декодировать катакану JIS X 0201 во входных данных ISO-2022-JP, но при кодировании преобразует символы в их эквиваленты JIS X 0208. [116] Кодовая страница Microsoft для ISO-2022-JP с дополнительно разрешенным кана JIS X 0201 — кодовая страница 50221 . [115]ESC $ ( 0
Другие, более старые варианты, известные как 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 реализует девять 7-битных кодировок японского языка на основе ISO 2022, каждая из которых использует свой набор escape-последовательностей: IBM-956, IBM-957, IBM-958, IBM-959, IBM-5052, IBM-5053, IBM-5054, IBM-5055 и ISO-2022-JP, которые вместе называются «наборами японских кодированных символов TCP/IP». [123] CCSID 9148 — это стандарт (RFC 1468) ISO-2022-JP. [124]
Стандарт JIS X 0213 , впервые опубликованный в 2000 году, определяет обновленную версию ISO-2022-JP без расширений ISO-2022-JP-2, получившую название ISO-2022-JP-3 . Дополнения, внесенные в JIS X 0213 по сравнению с базовым стандартом JIS X 0208, привели к новой регистрации расширенной плоскости JIS 1, а новая плоскость 2 получила собственную регистрацию. Дальнейшие дополнения к плоскости 1 в редакции стандарта 2004 года привели к добавлению дополнительной регистрации к дальнейшей версии профиля, получившей название ISO-2022-JP-2004 . Помимо основных кодов обозначений ISO-2022-JP, признаются следующие обозначения:
ESC ( Iдля перехода на набор 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)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]
Символ после 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]
Подмножество ISO 2022, применяемое к 8-битным однобайтовым кодировкам, определяется стандартом ISO/IEC 4873 , также опубликованным Ecma International как ECMA-43. ISO/IEC 8859 определяет 8-битные коды для уровня 1 ISO/IEC 4873 (или ECMA-43). [9] [10]
ISO/IEC 4873/ECMA-43 определяет три уровня кодирования: [137]
Более ранние версии стандарта допускали присвоения не-ASCII в наборе G0 при условии, что инвариантные позиции ISO/IEC 646 были сохранены, что другие позиции были назначены пробельным (не объединяемым) символам, что 0x23 был назначен либо £ , либо # . , и этот 0x24 был назначен либо $ , либо ¤ . [138] Например, 8-битная кодировка JIS X 0201 совместима с более ранними редакциями. Впоследствии это было изменено, чтобы полностью определить набор ISO / IEC 646: 1991 IRV / ISO-IR № 6 (ASCII). [139] [140] [141]
Использование ISO/IEC 646 IRV (синхронизировано с ASCII с 1991 года) по ISO/IEC 4873 уровня 1 без набора C1 или G1, т.е. использование IRV в 8-битной среде, в которой не используются коды сдвига и высокий уровень бит всегда равен нулю, известен как ISO 4873 DV , где DV означает «Версия по умолчанию». [142]
В случаях, когда повторяющиеся символы доступны в разных наборах, действующая редакция ISO/IEC 4873/ECMA-43 разрешает использовать эти символы только в рабочем наборе с наименьшим номером, в котором они встречаются. [143] Например, если символ появляется в как набор G1, так и набор G3, его необходимо использовать из набора G1. Однако использование других наборов разрешено в более ранних выпусках. [141]
ISO/IEC 8859 определяет полные кодировки на уровне 1 ISO/IEC 4873 и не допускает совместного использования нескольких частей ISO/IEC 8859. Он предусматривает, что вместо этого для уровней 2 и 3 ISO/IEC 4873 следует использовать ISO/IEC 10367. [9] [10] ISO/IEC 10367:1991 включает наборы G0 и G1, соответствующие тем, которые используются в первых 9 частях ISO/ IEC 8859 (т.е. те, которые существовали по состоянию на 1991 год, когда он был опубликован), и некоторые дополнительные наборы. [144]
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, а именно: [145]
Расширенный код 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; однако это соответствует следующей последовательности из четырех последовательностей дикторов, значения которых распределяются следующим образом. [146]
Консорциум X определил профиль ISO 2022 под названием Compound Text в качестве формата обмена в 1989 году . _ 8-битное представление ), [148] с последовательностью SDS ( ) CSI, используемой для управления двунаправленным текстом. [149] Это 8-битный код, использующий G0 и G1 для GL и GR, и в исходном состоянии соответствует ISO-8859-1 . [150] Используются следующие F-байты:0x090x0A 0x1B0x9BCSI … ]
Для указания кодировок с помощью меток X11 Compound Text определяет пять последовательностей DOCS частного использования: ESC % / 0( 1B 25 2F 30) для кодировок переменной длины и ESC % / 1Through ESC % / 4для кодировок фиксированной длины, использующих от одного до четырех байтов соответственно. Вместо использования другой escape-последовательности для возврата к ISO 2022 два байта, следующие за исходной escape-последовательностью, определяют оставшуюся длину в байтах, закодированную в базе 128 с использованием bytes 0x80–FF. Метка кодировки включается в ISO 8859-1 перед закодированным текстом и заканчивается символом STX ( ). [108]0x02
@), 0x41 ( A) и 0x42 ( B) по историческим причинам. [89] Некоторые реализации, такие как кодирование эмодзи SoftBank 2G , используют дополнительные экранированные символы этой формы для целей, не соответствующих ISO-2022. [96]ESC , FESC 0x1B 0x2Cв ранних редакциях стандарта последовательность определялась как обозначение дальнейших наборов из 94 символов для G0. [98] Поскольку наборы из 96 символов не могут быть обозначены как G0, этот первый байт I не используется текущей редакцией стандарта. Однако он по-прежнему указан в MARC-8 . [3]ESC ( Hдля переключения на ASCII с DBCS.ESC 2/8 4/10.ESC ( J.{{citation}}: CS1 maint: числовые имена: список авторов ( ссылка ){{cite book}}: CS1 maint: числовые имена: список авторов ( ссылка ){{cite book}}: CS1 maint: числовые имена: список авторов ( ссылка ){{cite book}}: CS1 maint: числовые имена: список авторов ( ссылка ){{citation}}: CS1 maint: числовые имена: список авторов ( ссылка ){{citation}}: CS1 maint: числовые имена: список авторов ( ссылка ){{citation}}: CS1 maint: числовые имена: список авторов ( ссылка ){{citation}}: CS1 maint: числовые имена: список авторов ( ссылка ){{citation}}: CS1 maint: числовые имена: список авторов ( ссылка )