Из Википедии, бесплатной энциклопедии
  (Перенаправлено с ISO-2022 )
Перейти к навигации Перейти к поиску

ISO / IEC 2022 структура данных код технологии символов и методы расширения , является ISO стандартом (эквивалентно ECMA стандарта ECMA-35 , [1] [2] ANSI стандарт ANSI X3.41 [3] и японский промышленный стандарт JIS X 0202 ) с указанием:

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

Многие из наборов символов, включенных как кодировки ISO / IEC 2022, являются «двухбайтовыми» кодировками, где два байта соответствуют одному символу. Это делает ISO-2022 кодировкой переменной ширины. Но конкретная реализация не обязательно должна реализовывать весь стандарт; уровень соответствия и поддерживаемые наборы символов определяются реализацией.

Хотя многие механизмы, определенные стандартом ISO / IEC 2022, используются нечасто, несколько установленных кодировок основаны на подмножестве системы ISO / IEC 2022. [11] В частности, 7-битные системы кодирования, использующие механизмы ISO / IEC 2022, включают ISO-2022-JP (или кодирование JIS ), которое в основном использовалось в электронной почте на японском языке . 8-битные системы кодирования, соответствующие ISO / IEC 2022, включают ISO / IEC 4873 (ECMA-43), который, в свою очередь, соответствует ISO / IEC 8859 , [12] [13] и Extended Unix Code , который используется для Востока. Азиатские языки. [14]Более специализированные приложения ISO 2022 включают систему кодирования MARC-8, используемую в записях библиотеки MARC 21 . [3]

Введение [ править ]

Многие языки или языковые семьи, не основанные на латинском алфавите, такие как греческий , кириллица , арабский или иврит , исторически были представлены на компьютерах с различными 8-битными расширенными кодировками ASCII . Письменные языки Восточной Азии , в частности китайский , японский и корейский , используют гораздо больше символов, чем может быть представлено в 8- битном компьютерном байте, и впервые были представлены на компьютерах с двухбайтовой кодировкой, зависящей от языка .

ИСО / МЭК 2022 был разработан как метод решения обеих этих проблем: для представления символов в нескольких наборах символов в рамках единой кодировки символов и для представления больших наборов символов.

Второе требование ISO-2022 заключалось в том, что он должен быть совместим с 7-битными каналами связи. Таким образом, даже несмотря на то, что ISO-2022 представляет собой 8-битный набор символов, любую 8-битную последовательность можно перекодировать, чтобы использовать только 7 бит без потерь и, как правило, лишь с небольшим увеличением размера.

Для представления нескольких наборов символов кодировки символов ISO / IEC 2022 включают escape-последовательности, которые указывают набор символов для следующих символов. Управляющие последовательности зарегистрированы в ISO и следуют шаблонам, определенным в стандарте. Эти кодировки символов требуют, чтобы данные обрабатывались последовательно в прямом направлении, поскольку правильная интерпретация данных зависит от ранее встреченных управляющих последовательностей. Однако обратите внимание, что другие стандарты, такие как ISO-2022-JP, могут налагать дополнительные условия, такие как текущий набор символов сбрасывается до US-ASCII перед концом строки.

Для представления больших наборов символов ISO / IEC 2022 основывается на свойстве ISO / IEC 646 , согласно которому один семибитный символ обычно определяет 94 графических (печатаемых) символа (в дополнение к пробелу и 33 управляющим символам). Таким образом, используя два байта, можно представить до 8 836 (94 × 94) символов; и, используя три байта, до 830 584 (94 × 94 × 94) символов. Хотя стандарт определяет это, ни один зарегистрированный набор символов не использует три байта (хотя незарегистрированный G2 EUC-TW использует). Для двухбайтовых наборов символов кодовая точка каждого символа обычно указывается в так называемой форме kuten (японский:区 点) (иногда называемой qūwèi (китайский:区 位), особенно при работе с GB2312).и связанные стандарты), который определяет зону (, японский: ku , китайский: ), а также точку (японский: ten ) или положение (китайский: wèi ) этого символа в зоне.

Следовательно, управляющие последовательности не только объявляют, какой набор символов используется, но также, зная свойства этих наборов символов, знают, какая кодировка - 94, 96, 8 836 или 830 584 символов (или другого размера). решается.

На практике управляющие последовательности, объявляющие наборы национальных символов, могут отсутствовать, если контекст или соглашение диктует, что должен использоваться определенный набор национальных символов. Например, ISO-8859-1 заявляет, что никакой управляющей последовательности не требуется, а RFC 1922, который определяет ISO-2022-CN, позволяет использовать символы SHIFT ISO-2022 без явного использования escape-последовательностей.

Определения ISO-2022 наборов символов ISO-8859-X представляют собой конкретные фиксированные комбинации компонентов, которые образуют ISO-2022. В частности, нижние управляющие символы (C0), набор символов US-ASCII (в GL) и верхние управляющие символы (C1) являются стандартными, а старшие символы (GR) определены для каждого из вариантов ISO-8859-X; например, ISO-8859-1 определяется [ необходима ссылка ] комбинацией ISO-IR-1, ISO-IR-6, ISO-IR-77 и ISO-IR-100 без каких-либо сдвигов или изменений символов.

Хотя наборы символов ISO / IEC 2022, использующие управляющие последовательности, все еще широко используются, особенно ISO-2022-JP, большинство современных приложений электронной почты преобразуются для использования более простых преобразований Unicode, таких как UTF-8 . Кодировки, которые не используют управляющие последовательности, такие как наборы ISO-8859, по-прежнему очень распространены.

Структура кода [ править ]

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

Кодирование ISO / IEC 2022 определяет двухуровневое соответствие между кодами символов и отображаемыми символами. Управляющие последовательности позволяют «назначить» [15] любой из большого реестра наборов графических символов в один из четырех рабочих наборов с именами от G0 до G3, а более короткие управляющие последовательности определяют рабочий набор, который «вызывается» [16] для интерпретации байтов в потоке.

Значения байтов кодирования («битовые комбинации») часто даются в виде столбцов , где два десятичных числа в диапазоне 00–15 (каждое соответствует одной шестнадцатеричной цифре) разделены косой чертой. [17] Следовательно, например, коды с 2/0 (0x20) по 2/15 (0x2F) включительно могут упоминаться как «столбец 02». Это обозначение, используемое в самом стандарте ISO / IEC 2022 / ECMA-35. [18] Они могут быть описаны в другом месте с использованием шестнадцатеричного числа , как это часто используется в этой статье, или с использованием соответствующих символов ASCII, [19] хотя escape-последовательности на самом деле определены в терминах байтовых значений, а графика, присвоенная этому байтовому значению. могут быть изменены, не влияя на последовательность управления.

Байтовые значения из 7-битного графического диапазона ASCII (шестнадцатеричный 0x20–0x7F), находящиеся в левой части таблицы кодов символов, называются кодами «GL» (где «GL» означает «графика слева»), в то время как байты из диапазона «high ASCII» (0xA0–0xFF), если он доступен (т. е. в 8-битной среде), называются кодами «GR» («графика справа») . [20] Термины «CL» (0x00–0x1F) и «CR» (0x80–0x9F) определены для диапазонов управления, но диапазон CL всегда вызывает основные (C0) элементы управления, тогда как диапазон CR всегда либо вызывает вторичный (C1) управляет или не используется. [20]

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

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

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

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

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

Наборы графических символов [ править ]

Каждый из четырех рабочих наборов G0 через G3 может представлять собой набор 94-символьного или 94 п -character множества многобайтового . Кроме того, G1 , G3 через может быть 96- или 96 - п -character множество.

В 96- или 96 - п -character набора, то байты 0x20 через 0x7F , когда GL-вызов или 0xA0 через 0xFF при GR-вызове выделены и может быть использован в наборе. В 94- или 94 п -character набора, байты 0x20 и 0x7F не используются. [27] Когда 96- или 96 - п -character множество вызывается в области GL, пространство и удаления символов (коды 0x20 и 0x7F) не доступны до получения 94- или 94 п -character множества (например, множество G0 ) вызывается в GL. [20] Наборы из 96 символов не могут быть назначены для G0.

Регистрация набора как 96-символьного не обязательно означает, что байты 0x20 / A0 и 0x7F / FF фактически назначаются набором; некоторые примеры графических наборов символов, которые зарегистрированы как 96-наборы, но не используют эти байты, включают набор G1 IS 434 , [28] набор чертежей коробки из ISO / IEC 10367 , [29] и ISO-IR-164 ( подмножество набора G1 стандарта ISO-8859-8 только с буквами, используемым CCITT ). [30]

Комбинирование персонажей [ править ]

Ожидается, что символы будут символами-пробелами, а не комбинациями символов, если иное не указано в рассматриваемом графическом наборе. [31] ИСО 2022 / ECMA-35 также признает использование Backspace и перевозки контрольных символов возврата как средство объединения в противном случае Spacing символов, а также последовательность CSI «графический символ» Combination (GCC) [31] ( CSI 0x20 (SP) 0x5F (_)). [32]

Использование обратного пробела и возврата каретки таким образом разрешено ISO / IEC 646, но запрещено ISO / IEC 4873 / ECMA-43 [33] и ISO / IEC 8859 , [34] [35] на том основании, что он оставляет репертуар графического персонажа не определен. ISO / IEC 4873 / ECMA-43, однако, разрешает использование функции GCC на основании того, что последовательность символов остается неизменной и просто отображается в одном пространстве, а не штампуется поверх, чтобы сформировать символ с другое значение. [36]

Наборы управляющих символов [ править ]

Наборы управляющих символов классифицируются как «первичные» или «вторичные» наборы управляющих символов [37], соответственно, также называемые наборами управляющих символов «C0» и «C1». [38]

Управляющий набор C0 должен содержать управляющий символ ESC (escape) в 0x1B [39] (набор C0, содержащий только ESC, зарегистрирован как ISO-IR-104) [40], тогда как набор управления C1 может не содержать управляющего символа вообще . [27] Следовательно, это полностью отдельные регистрации: набор C0 - это только набор C0, а набор C1 - только набор C1. [38]

Если коды из набора C0 стандарта ISO 6429 / ECMA-48, т. Е. Управляющие коды ASCII , появляются в наборе C0, они должны появиться в своих местоположениях ISO 6429 / ECMA-48. [39] Включение символов управления передачей в набор C0, помимо десяти, включенных в ISO 6429 / ECMA-48 (а именно SOH, STX, ETX, EOT, ENQ, ACK, DLE, NAK, SYN и ETB), [41] или включение любого из этих десяти в набор C1 также запрещено стандартом ISO / IEC 2022 / ECMA-35. [39] [27]

Управляющий набор C0 вызывается в диапазоне CL от 0x00 до 0x1F, [42] тогда как управляющий символ C1 может быть вызван в диапазоне CR от 0x80 до 0x9F (в 8-битной среде) или с помощью управляющих последовательностей (в 7- битовая или 8-битная среда), [37], но не то и другое одновременно. Какой стиль вызова C1 используется, необходимо указать в определении версии кода. [43] Например, ISO / IEC 4873 определяет байты CR для используемых элементов управления C1 (SS2 и SS3). [44] При необходимости, о том, какой вызов используется, можно сообщить с помощью последовательностей извещателей .

В последнем случае одиночные управляющие символы из набора управляющих символов C1 вызываются с использованием управляющих последовательностей типа Fe [27], означающих те, в которых за управляющим символом ESC следует байт из столбцов 04 или 05 (то есть, ESC 0x40 (@)через ESC 0x5F (_)). [45]

Другие функции управления [ править ]

Дополнительные функции управления назначаются управляющим последовательностям типа Fs (в диапазоне ESC 0x60 (`)до ESC 0x7E (~)); они имеют постоянно присвоенные значения, а не зависят от обозначений C0 или C1. [45] [46] Регистрация функций управления в последовательностях типа «Fs» должна быть одобрена ISO / IEC JTC 1 / SC 2 . [46] Другие одиночные функции управления могут быть зарегистрированы для управляющих последовательностей типа «3Ft» (в диапазоне до ), [47] хотя в настоящее время последовательности «3Ft» не назначаются (по состоянию на 2019 год). [48]ESC 0x23 (#) [I...] 0x40 (@)ESC 0x23 (#) [I...] 0x7E (~)

Следующие escape-последовательности назначены для отдельных функций управления: [48]

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

Функции сдвига [ править ]

По умолчанию коды GL определяют символы G0, а коды GR (если они доступны) определяют символы G1; это может быть иначе оговорено по предварительному согласованию. Набор, вызываемый для каждой области, также может быть изменен с помощью управляющих кодов, называемых сдвигами, как показано в таблице ниже. [51]

8-битный код может иметь коды GR, определяющие символы G1, то есть с соответствующим 7-битным кодом, использующим Shift In и Shift Out для переключения между наборами (например, JIS X 0201 ), [52] хотя некоторые вместо этого имеют коды GR, определяющие G2 символов с соответствующим 7-битным кодом, использующим односменный код для доступа ко второму набору (например, T.51 ). [53]

Коды, показанные в таблице ниже, являются наиболее распространенными кодировками этих управляющих кодов, соответствующими ISO / IEC 6429 . Сдвиги LS2, LS3, LS1R, LS2R и LS3R регистрируются как отдельные функции управления и всегда кодируются как escape-последовательности, перечисленные ниже [48], тогда как другие являются частью набора управляющих кодов C0 или C1 (как показано ниже, SI (LS0) и SO (LS1) - это элементы управления C0, а SS2 и SS3 - элементы управления C1), что означает, что их кодирование и доступность могут различаться в зависимости от того, какие наборы элементов управления назначены: они должны присутствовать в назначенных наборах элементов управления, если используются их функции. . [42] [43] Сами элементы управления C1, как упомянуто выше, могут быть представлены с помощью управляющих последовательностей или 8-битных байтов, но не обоих одновременно.

Альтернативные кодировки односменных передач в виде управляющих кодов C0 доступны в определенных наборах управляющих кодов. Например, SS2 и SS3 обычно доступны по адресу 0x19 и 0x1D соответственно в T.51 [53] и T.61 . [54] Это кодирование в настоящее время рекомендуется ISO / IEC 2022 / ECMA-35 для приложений, требующих 7-битных однобайтовых представлений SS2 и SS3, [55], а также может использоваться только для SS2, [56] хотя старый код также существуют наборы с SS2 на 0x1C [57] [58] [59], и они были упомянуты как таковые в более ранней редакции стандарта. [60] Кодирование одиночных смен 0x8E и 0x8F, как показано ниже, является обязательным дляISO / IEC 4873 уровни 2 и 3. [61]

В 8-битных средах в качестве области с одинарным сдвигом может использоваться либо GL, либо GR, но не оба вместе. Это должно быть указано в определении версии кода. [64] Например, ISO / IEC 4873 определяет GL, а упакованный EUC определяет GR. В 7-битных средах в качестве односменной области используется только GL. [66] [67] Если необходимо, информация о том, какая односменная область используется, может быть передана с использованием последовательностей извещателей .

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

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

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

ИСО Международный регистр кодированных наборов символов , которые будут использованы с помощью управляющих последовательностей (ISO-IR) списки графических наборов символов, контрольных кодовых наборов, кодов одного управления и так далее , которые были зарегистрированы для использования с ISO / IEC 2022. Процедура регистрации коды и наборы с реестром ISO-IR указаны в ISO / IEC 2375 . Каждая регистрация получает уникальную escape-последовательность и уникальный номер записи реестра для ее идентификации. [69] [70] Например, набор символов CCITT для упрощенного китайского языка известен как ISO-IR-165 .

Регистрация кодированных наборов символов в реестре ISO-IR определяет документы, определяющие набор символов или функцию управления, связанную с управляющей последовательностью ISO / IEC 2022, не предназначенной для частного использования. Это может быть стандартный документ; однако регистрация не создает новый стандарт ISO, не обязывает ISO или IEC принять его в качестве международного стандарта и не обязывает ISO или IEC добавлять какие-либо из своих символов в универсальный набор кодированных символов . [71]

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

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

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

Как и в случае с другими типами управляющих последовательностей, диапазон 0x30–0x3F зарезервирован для байтов F частного использования [26], в данном случае для определений наборов символов частного использования (которые могут включать незарегистрированные наборы, определенные протоколами, такими как ARIB STD-B24 [ 73] или MARC-8 , [3] или наборы, зависящие от поставщика, такие как DEC Special Graphics ). [74] Однако в последовательности обозначений графического набора, если второй байт I (для однобайтового набора) или третий байт I (для двухбайтового набора) равен 0x20 (пробел), обозначенный набор будет " динамически переопределяемый набор символов "(DRCS), определенный по предварительному соглашению,[75], который также считается частным использованием. [26] Графический набор, рассматриваемый как DRCS, подразумевает, что он представляет собой шрифт точных глифов, а не набор абстрактных символов. [76] Способ, которым наборы DRCS и связанные шрифты передаются, выделяются и управляются, не оговаривается самим стандартом ISO / IEC 2022 / ECMA-35, хотя он рекомендует распределять их последовательно, начиная сбайта F 0x40 (@); [77] однако способ передачи шрифтов DRCS определяется в некоторых телекоммуникационных протоколах, таких как World System Teletext . [78]

Также есть три особых случая для многобайтовых кодов. Все кодовые последовательности ESC $ @, ESC $ Aи ESC $ Bбыли зарегистрированы, когда современная версия стандарта разрешала многобайтовые наборы только в G0, поэтому они должны быть приняты вместо последовательностей до ESC $ ( @конца ESC $ ( Bдля обозначения набора символов G0. [79]

Существуют дополнительные (редко используемые) функции для переключения наборов управляющих символов, но это одноуровневый поиск, в котором (как отмечено выше) набор C0 всегда вызывается через CL, а набор C1 всегда вызывается через CR или через используя escape-коды. Как отмечалось выше, требуется, чтобы любой набор символов C0 включал символ ESC в позиции 0x1B, чтобы были возможны дальнейшие изменения. Последовательности обозначений контрольных наборов (в отличие от графических наборов) могут также использоваться в рамках ISO / IEC 10646 (UCS / Unicode) в контекстах, где уместна обработка управляющих кодов ANSI , при условии, что каждый байт в последовательности дополнен до размер кодовой единицы кодирования. [80]

Таблица I байтов escape-последовательности и обозначение или другая функция, которую они выполняют, приведена ниже. [81]

Обратите внимание, что реестр 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 . [89] Второй байт I 0x2F ( /) включен в последовательности обозначений кодов, которые не используют эту последовательность байтов для возврата к ISO 2022; у них могут быть собственные средства для возврата к ISO 2022 (например, другая или дополненная последовательность) или вообще не быть. [90] Все существующие регистрации последнего типа (по состоянию на 2019 год) представляют собой прозрачные необработанные данные, форматы Unicode / UCS или их подмножества. [91]

Особый интерес представляют последовательности, которые переключаются на форматы ISO / IEC 10646 ( Unicode ), которые не соответствуют структуре ISO / IEC 2022. К ним относятся UTF-8 (который не резервирует диапазон 0x80–0x9F для управляющих символов), его предшественник UTF-1 (который смешивает байты GR и GL в многобайтовых кодах), а также UTF-16 и UTF-32 (которые используют более широкие единицы кодирования). [89] [91]

Также было зарегистрировано несколько кодов для подмножеств (уровни 1 и 2) UTF-8, UTF-16 и UTF-32, а также для трех уровней UCS-2 . [91] Однако в настоящее время в стандарте ISO / IEC 10646 указаны только коды уровня 3 для UTF-8, UTF-16 и UTF-32 и код неопределенного уровня для UTF-8, а остальные указаны как устарело. [93] ISO / IEC 10646 предусматривает, что форматы с прямым порядком байтов UTF-16 и UTF-32 обозначаются их управляющими последовательностями. [94]

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

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

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

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

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

Различные кодировки ISO 2022 и другие кодировки CJK, поддерживаемые Mozilla Firefox с 2004 года (эта поддержка была сокращена в более поздних версиях, чтобы избежать некоторых атак межсайтового скриптинга ).

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

ISO-2022-JP - широко используемая кодировка японского языка, в частности, в электронной почте . Он был введен для использования в сети JUNET и позже кодифицирован в IETF RFC 1468 от 1993 года. [99] Он имеет преимущество перед другими кодировками для японского языка в том, что не требует 8-битной чистой передачи. Microsoft называет это кодовой страницей 50220 . [100] Он начинается с 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. [99] Кроме того, из-за возможности регистрации до назначения многобайтовых наборов, за исключением G0, escape-последовательности для JIS X 0208 не включают второй I- байт (. [79]

Примечания RFC , что некоторые существующие системы не отличающие ESC ( Bот ESC ( J, или не отличающих ESC $ @от ESC $ B, но оговаривает , что управляющие последовательности не должны быть изменены с помощью систем просто ретрансляция сообщений , таких как сообщения электронной почты. [99] WHATWG Кодирование Стандарт ссылается HTML5 ручками ESC ( Bи ESC ( Jотчетливо, но лечит ESC $ @такие же , как ESC $ Bпри декодировании, и используют только ESC $ Bдля JIS X 0208 при кодировании. [101] RFC также отмечает, что некоторые прошлые системы ошибочно использовали последовательность ESC ( Hдля перехода от JIS X 0208, который фактически зарегистрирован для ISO-IR-11 (шведский вариант ISO 646и World System Teletext ). [99] [e]

Использование ESC ( Iдля переключения на набор Kana JIS X 0201-1976 (1 байт на символ) не является частью профиля ISO-2022-JP, [99], но также иногда используется. Python допускает это в варианте, который он обозначает ISO-2022-JP-EXT (который также включает JIS X 0212, как описано ниже, завершая охват EUC-JP ); [102] [103] это близко как в имени и структуры в кодировке обозначается ISO-2022-JPext от DEC , который , кроме того , добавляет двухбайтовый определенный пользователем регион доступ с , ESC $ ( 0чтобы завершить охват Супер DEC Kanji . [104]Вариант WHATWG / HTML5 позволяет декодировать катакану JIS X 0201 во входных данных ISO-2022-JP, но при кодировании преобразует символы в их эквиваленты JIS X 0208. [101] Кодовая страница Microsoft для ISO-2022-JP с дополнительно разрешенной кана JIS X 0201 - это кодовая страница 50221 . [100]

Другие, более старые варианты, известные как JIS7 и JIS8, основаны непосредственно на 7-битных и 8-битных кодировках, определенных JIS X 0201, и позволяют использовать JIS X 0201 kana из G1 без управляющих последовательностей, используя Shift Out и Shift In или установку восьмого bit (вызывается GR) соответственно. [105] Они не получили широкого распространения; [105] Поддержка JIS X 0208 в расширенном 8-битном JIS X 0201 чаще всего достигается с помощью Shift JIS . Кодовая страница Microsoft для ISO 2022 на основе JIS X 0201 с однобайтовой катаканой через Shift Out и Shift In - это кодовая страница 50222 . [100]

ISO-2022-JP-2 - это многоязычное расширение ISO-2022-JP, определенное в RFC 1554 (от 1993 г.), которое разрешает следующие escape-последовательности в дополнение к ISO-2022-JP. В ИСО / МЭК 8859 части набора 96-символьныхкоторые не могут быть назначены к G0, а доступиз G2используя 7-битный вид последовательности выхода из одного сдвига кода SS2: [106]

  • ESC $ Aдля перехода на GB 2312-1980 (2 байта на символ)
  • ESC $ ( Cдля перехода на KS X 1001-1992 (2 байта на символ)
  • ESC $ ( Dдля перехода на JIS X 0212-1990 (2 байта на символ)
  • ESC . Aдля переключения на старшую часть ISO / IEC 8859-1 , расширенный набор Latin 1 (1 байт на символ) [обозначен как G2]
  • ESC . Fдля переключения на старшую часть ISO / IEC 8859-7 , базовый греческий набор (1 байт на символ) [обозначен как G2]

ISO-2022-JP с представлением ISO-2022-JP-2 для JIS X 0212, но не с другими расширениями, впоследствии был назван ISO-2022-JP-1 в RFC 2237 от 1997 года. [107]

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

  • ESC ( Iдля перехода на JIS X 0201-1976 набор Kana (1 байт на символ)
  • ESC $ ( Oдля перехода на JIS X 0213-2000 Plane 1 (2 байта на символ)
  • ESC $ ( Pдля перехода на JIS X 0213-2000 Plane 2 (2 байта на символ)
  • ESC $ ( Qдля перехода на JIS X 0213-2004 Plane 1 (2 байта на символ, только ISO-2022-JP-2004)

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

ISO-2022-KR определен в RFC 1557 от 1993 года. [108] Он кодирует ASCII и корейский двухбайтовый KS X 1001-1992 , [109] [110], ранее называвшийся KS C 5601-1987. В отличие от ISO-2022-JP-2, он использует символы Shift Out и Shift In для переключения между ними, после включенияESC $ ) Cодного раза в начало строки для обозначения KS X 1001 в G1. [108]

ISO-2022-CN и ISO-2022-CN-EXT определены в RFC 1922 от 1996 года. Это 7-битные кодировки, в которых используются как функции Shift Out и Shift In (для переключения между G0 и G1), так и 7-битный escape-код формирует односменные функции SS2 и SS3 (для доступа к G2 и G3). [111] Они поддерживают наборы символов GB 2312 (для упрощенного китайского ) и CNS 11643 (для традиционного китайского ).

Базовый профиль ISO-2022-CN использует ASCII в качестве набора G0 (сдвиг), а также включает GB 2312 и первые две плоскости CNS 11643 (поскольку этих двух плоскостей достаточно для представления всех традиционных китайских иероглифов из общего Big5 , к которому RFC предоставляет соответствие в приложении): [111]

  • ESC $ ) Aдля перехода на GB 2312-1980 (2 байта на символ) [назначен G1]
  • ESC $ ) Gдля переключения на CNS 11643-1992 Плоскость 1 (2 байта на символ) [назначен G1]
  • ESC $ * Hдля переключения на CNS 11643-1992 Плоскость 2 (2 байта на символ) [назначен G2]

Профиль ISO-2022-CN-EXT допускает следующие дополнительные наборы и плоскости. [111]

  • ESC $ ) Eдля перехода на ISO-IR-165 (2 байта на символ) [обозначено как G1]
  • ESC $ + Iдля переключения на CNS 11643-1992 Плоскость 3 (2 байта на символ) [назначен G3]
  • ESC $ + Jдля переключения на CNS 11643-1992 Плоскость 4 (2 байта на символ) [назначен G3]
  • ESC $ + Kдля переключения на CNS 11643-1992 Плоскость 5 (2 байта на символ) [назначен G3]
  • ESC $ + Lдля переключения на CNS 11643-1992 Плоскость 6 (2 байта на символ) [назначен G3]
  • ESC $ + Mдля переключения на CNS 11643-1992 Плоскость 7 (2 байта на символ) [назначен G3]

Профиль ISO-2022-CN-EXT дополнительно перечисляет дополнительные стандартные графические наборы Guobiao как разрешенные, но при условии, что им назначены зарегистрированные управляющие последовательности ISO 2022: [111]

  • GB 12345 в G1
  • GB 7589 или GB 13131 в G2
  • GB 7590 или GB 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, их нельзя было обработать таким образом, поскольку они гораздо чаще используются в развернутом контенте. [114]

ISO / IEC 4873 [ править ]

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

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

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

  • Уровень 1, который включает набор C0, набор ASCII G0, необязательный набор C1 и необязательный однобайтовый (94-символьный или 96-символьный) набор G1. G0 вызывается над GL, а G1 вызывается над GR. Использование сдвиговых функций не допускается.
  • Уровень 2, который включает (94 или 96 символов) однобайтовый набор G2 и / или G3 в дополнение к обязательному набору G1. Разрешены только функции SS2 и SS3 с одинарным сдвигом (т. Е. Блокирующие сдвиги запрещены), и они активизируются в области GL (включая 0x 20 и 0x7F в случае набора 96). SS2 и SS3 должны быть доступны в C1 по адресу 0x8E и 0x8F соответственно. Этот минимальный необходимый набор C1 для ISO 4873 зарегистрирован как ISO-IR-105. [116]
  • Уровень 3, который разрешает функции блокировки-сдвига GR LS1R, LS2R и LS3R в дополнение к одиночным сдвигам, но в остальном имеет те же ограничения, что и уровень 2.

Более ранние редакции стандарта разрешали присвоения не-ASCII в наборе G0 при условии, что инвариантные позиции ISO 646 были сохранены, что другие позиции были назначены символам интервалов (не объединению), что 0x23 было присвоено либо £, либо # , и что 0x24 был присвоен либо $, либо ¤ . [117] Например, 8-битное кодирование JIS X 0201 совместимо с более ранними версиями. Впоследствии это было изменено, чтобы полностью указать набор ISO 646: 1991 IRV / ISO-IR No. 6 ( ASCII ). [118] [119] [120]

Использование ISO 646 IRV (синхронизировано с ASCII с 1991 года) на уровне 1 ISO / IEC 4873 без установки C1 или G1, то есть использование IRV в 8-битной среде, в которой коды сдвига не используются, а старший бит всегда нулевой, известен как ISO 4873 DV , в котором DV означает «Версия по умолчанию». [121]

В случаях, когда повторяющиеся символы доступны в разных наборах, текущая редакция ISO / IEC 4873 / ECMA-43 разрешает использование этих символов только в рабочем наборе с наименьшим номером, в котором они появляются. [122] Например, если символ появляется в как набор G1, так и набор G3, он должен использоваться из набора G1. Однако использование других наборов отмечено как разрешенное в более ранних версиях. [120]

ISO / IEC 8859 определяет полные кодировки на уровне 1 ISO / IEC 4873 и не позволяет использовать несколько частей ISO / IEC 8859 вместе. В нем оговаривается, что ISO / IEC 10367 должен использоваться вместо уровней 2 и 3 ISO / IEC 4873. [12] [13] ISO / IEC 10367: 1991 включает наборы G0 и G1, соответствующие тем, которые используются в первых 9 частях ISO / IEC 8859 (т.е. те, которые существовали по состоянию на 1991 год, когда он был опубликован), и некоторые дополнительные наборы. [123]

Управляющие последовательности обозначения набора символов используются для идентификации или переключения между версиями во время обмена информацией только в том случае, если этого требует другой протокол, и в этом случае стандарт требует последовательности извещателя ISO / IEC 2022, определяющей уровень ISO / IEC 4873, за которой следует полный набор экранирований, определяющих обозначения набора символов для C0, C1, G0, G1, G2 и G3 соответственно (но опуская обозначения G2 и G3 для уровня 1), с F- байтом 0x7E, обозначающим пустой набор. Каждый уровень ISO / IEC 4873 имеет свою собственную последовательность дикторов ISO / IEC 2022, которая выглядит следующим образом: [124]

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

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

Код, присвоенный набору G0, - это ASCII или национальный набор символов ISO 646, например KS-Roman (KS X 1003) или JIS-Roman (нижняя половина JIS X 0201 ). [14] Следовательно, 0x5C ( обратная косая черта в US-ASCII) используется для обозначения знака иены в некоторых версиях EUC-JP и знака Won в некоторых версиях EUC-KR.

G1 используется для набора кодированных символов 94x94, представленного в двух байтах. Форма EUC-CN из GB2312 и EUC-KR являются примерами таких двухбайтовых кодов EUC. EUC-JP включает символы, представленные до трех байтов (т. Е. SS3 плюс два байта), тогда как один символ в EUC-TW может занимать до четырех байтов (т. Е. SS2 плюс три байта).

Сам код EUC не использует диктор или последовательности обозначений из ISO 2022; тем не менее, это соответствует следующей последовательности из четырех последовательностей дикторов, значения которых разбиваются следующим образом. [126]

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

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

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

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

  • Поскольку ISO / IEC 2022 является кодировкой с отслеживанием состояния, программа не может перемещаться в середине блока текста для поиска, вставки или удаления символов. Это делает манипуляции с текстом очень громоздкими и медленными по сравнению с кодировками без сохранения состояния. Любой переход в середине текста может потребовать возврата к предыдущей escape-последовательности, прежде чем байты, следующие за escape-последовательностью, могут быть интерпретированы.
  • Из-за природы ИСО / МЭК 2022 с отслеживанием состояния идентичный и эквивалентный символ может быть закодирован в различных наборах символов, которые могут быть обозначены для любого из G0 - G3, которые могут быть вызваны с использованием одиночных сдвигов или блокирующих сдвигов для GL или GR. Следовательно, символы могут быть представлены несколькими способами, а это означает, что две визуально идентичные и эквивалентные строки нельзя надежно сравнивать на предмет равенства.
  • Некоторые системы, такие как DICOM и несколько клиентов электронной почты, используют вариант ISO-2022 (например, «ISO 2022 IR 100» [127] ) в дополнение к поддержке нескольких других кодировок. [128] Этот тип вариаций затрудняет переносимую передачу текста между компьютерными системами.
  • UTF-1 , многобайтовый формат преобразования Unicode , совместимый с представлением 8-битных управляющих символов ISO / IEC 2022, имеет различные недостатки по сравнению с UTF-8 , а также переключение с или на другие наборы символов в соответствии с ISO / IEC 2022. , как правило, не требуется в документах Unicode.
  • Благодаря escape-последовательностям можно создавать последовательности байтов атаки, в которых вредоносная строка (например, межсайтовый скриптинг ) маскируется до тех пор, пока она не будет декодирована в Unicode, что может позволить ей обойти дезинфекцию. [129] Таким образом, использование этой кодировки рассматривается как подозрительное в пакетах защиты от вредоносных программ, [130] [ необходим лучший источник ] и 7-битные данные ISO 2022 (за исключением ISO-2022-JP) полностью отображаются на заменяющий символ в HTML5 для предотвращения атак. [131] [132] Ограниченные версии 8-битного кода ISO 2022, в которых не используются escape-символы или коды блокировки, например расширенный код Unix., не разделяйте эту проблему.
  • Конкатенация может создавать проблемы. Такие профили, как ISO-2022-JP, указывают, что поток начинается в состоянии ASCII и должен заканчиваться в состоянии ASCII. [99] Это необходимо, чтобы гарантировать, что символы в объединенных потоках ISO-2022-JP и / или ASCII будут интерпретироваться в правильном наборе. Это приводит к тому, что если поток, который заканчивается многобайтовым символом, объединяется с потоком, который начинается с многобайтового символа, генерируется пара escape-кодов, переключающихся на ASCII и сразу же уходящих от него. Однако, как указано в Техническом отчете Unicode № 36 («Вопросы безопасности Unicode»), пары управляющих последовательностей ISO 2022 без символов между ними должны генерировать заменяющий символ (« »), чтобы предотвратить их использование для маскировки вредоносных последовательностей, таких как в видемежсайтовый скриптинг . [133] Внедрение этой меры, например, в Mozilla Thunderbird , привело к проблемам взаимодействия с неожиданными символами « », генерируемыми при объединении двух потоков ISO-2022-JP. [129]

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

  • ISO 2709
  • ISO / IEC 646
  • ISO-IR-102
  • Коды управления C0 и C1
  • CJK
  • Стандарты MARC
  • Моджибаке
  • люит
  • ISO / IEC JTC 1 / SC 2

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

  1. ^ a b Указано только для F байтов 0x40 ( @), 0x41 ( A) и 0x42 ( B) по историческим причинам. [79] Некоторые реализации, такие как кодирование эмодзи SoftBank 2G , используют дополнительные escape- последовательности этой формы для целей, не соответствующих требованиям ISO-2022. [86]
  2. Перечислено MARC-8 . [3] Историю см. В сноскениже.ESC , F
  3. ^ F , скорректированный до диапазона 1-63, указывает, какая (совместимая снизу вверх) ревизия следующей регистрации необходима, чтобы старые системы знали, что они старые. [87]
  4. ^ В более ранних выпусках 96-символьных наборов не существовало, и escape-коды, используемые теперь для 96-символьных наборов, были зарезервированы как пространство для дополнительных 94-символьных наборов. Соответственно,ESC 0x1B 0x2Cпоследовательность была определена в ранних редакциях стандарта как обозначение дополнительных 94-значных наборов символов для G0. [88] Поскольку 96-символьные наборы не могут быть назначены для G0, этот первыйбайт I не используется в текущей редакции стандарта. Тем не менее, он все еще включен в список MARC-8 . [3]
  5. ^ См. Также, например, Printronix (2012), Справочное руководство программиста OKI® (PDF) , стр. 26 годдля более новой системы, которая использует ESC ( Hдля перехода на ASCII из DBCS.

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

  1. ECMA-35 (1994) , Краткая история
  2. ECMA-35 (1994) , стр. 51, приложение D
  3. ^ a b c d e «Техника 2: Использование стандартных наборов альтернативных графических символов» . Спецификации MARC 21 для структуры записи, наборов символов и средств обмена . Библиотека Конгресса . 2007-12-05.
  4. ECMA-35 (1994) , главы 6, 7
  5. ECMA-35 (1994) , глава 8
  6. ECMA-35 (1994) , глава 9
  7. ECMA-35 (1994) , глава 11
  8. ECMA-35 (1994) , глава 13
  9. ECMA-35 (1994) , главы 12, 14
  10. ^ a b ECMA-35 (1994) , глава 15
  11. ^ Lunde (2008) , стр. 228-234, глава 4 («Методы кодирования»), раздел «Кодирование ISO-2022»
  12. ^ a b c ISO / IEC FDIS 8859-10 (1998) , стр. 1, глава 1 («Объем»)
  13. ^ a b c ECMA-144 (2000) , стр. 1, глава 1 («Объем»)
  14. ^ a b c Lunde (2008) , стр. 242-245, глава 4 («Методы кодирования»), раздел «Кодирование EUC»
  15. ECMA-35 (1994) , стр. 4, определение 4.11
  16. ECMA-35 (1994) , стр. 5, определение 4.18
  17. ^ См., Например, ISO-IR-14 (1975) , в котором обозначение G0 римского набора JIS X 0201 определяется как.ESC 2/8 4/10
  18. ECMA-35 (1994) , стр. 5, глава 5.1
  19. ^ См., Например, RFC 1468 (1993) , определяющий обозначение G0 для набора римских символов JIS X 0201 какESC ( J.
  20. ^ a b c ECMA-35 (1994) , стр. 15–16, глава 8.1
  21. ECMA-35 (1994) , стр. 7, глава 6.2
  22. ECMA-35 (1994) , стр. 10, глава 6.3.2
  23. ECMA-35 (1994) , стр. 4, определение 4.17
  24. ECMA-35 (1994) , стр. 4, определение 4.14
  25. ECMA-35 (1994) , стр. 28, глава 13.1
  26. ^ a b c ECMA-35 (1994) , стр. 33, глава 13.3.3
  27. ^ а б в г ECMA-35 (1994) , стр. 11, глава 6.4.3
  28. ISO-IR-208 (1999)
  29. ISO-IR-155 (1990)
  30. ISO-IR-164 (1992)
  31. ^ а б ECMA-35 (1994) , стр. 10, глава 6.3.3
  32. ^ Google Inc. (2014). "ansi.go, строка 134" . Библиотека управляющих последовательностей ANSI для Go .
  33. ECMA-43 (1991) , стр. 5, глава 7 («Спецификация символов 8-битного кода»)
  34. ISO / IEC FDIS 8859-10 (1998) , стр. 3, глава 6 («Спецификация набора кодированных символов»)
  35. ECMA-144 (2000) , стр. 3, глава 6 («Спецификация набора кодированных символов»)
  36. ECMA-43 (1991) , стр. 19, приложение C («Составные графические символы»)
  37. ^ а б ECMA-35 (1994) , стр. 10, глава 6.4.1
  38. ^ а б ECMA-35 (1994) , стр. 11, глава 6.4.4
  39. ^ a b c ECMA-35 (1994) , стр. 11, глава 6.4.2
  40. ISO-IR-104 (1985)
  41. ISO-IR-1 (1975)
  42. ^ а б ECMA-35 (1994) , стр. 19, глава 8.5.1
  43. ^ а б ECMA-35 (1994) , стр. 19, глава 8.5.2
  44. ECMA-43 (1991) , стр. 8, глава 7.6 («Набор С1»)
  45. ^ а б ECMA-35 (1994) , стр. 29, глава 13.2.1
  46. ^ а б ECMA-35 (1994) , стр. 12, глава 6.5.1
  47. ECMA-35 (1994) , стр. 12, глава 6.5.2
  48. ^ a b c ISO-IR , стр. 19, глава 2.7 («Функции единого управления»)
  49. ECMA-35 (1994) , стр. 12, глава 6.5.3
  50. ^ a b Мой, Эдвард; Гильдея, Стивен; Дики, Томас. «Элементы управления, начинающиеся с ESC» . Последовательности управления XTerm .
  51. ^ а б ECMA-35 (1994) , стр. 14, глава 7.3, таблица 2
  52. ISO-IR-14 (1975)
  53. ^ a b ITU-T (1995-08-11). Рекомендация T.51 (1992) Поправка 1 .
  54. ISO-IR-106 (1985)
  55. ECMA-35 (1994) , стр. 15, глава 7.3, примечание 23
  56. ISO-IR-140 (1987)
  57. ISO-IR-7 (1975)
  58. ISO-IR-26 (1976)
  59. ISO-IR-36 (1977)
  60. ECMA-35 (1980) , стр. 8, глава 5.1.7
  61. ISO-IR-105 (1985)
  62. ^ а б в г ECMA-35 (1994) , стр. 17, глава 8.3.1
  63. ^ а б в г ECMA-35 (1994) , стр. 23, глава 9.3.1
  64. ^ a b c ECMA-35 (1994) , стр. 19, глава 8.4
  65. ^ a b c ECMA-35 (1994) , стр. 17, глава 8.3.2
  66. ECMA-35 (1994) , стр. 23-24, глава 9.4.
  67. ECMA-35 (1994) , стр. 27, глава 11.1
  68. ECMA-35 (1994) , стр. 17, глава 8.3.3
  69. ECMA-35 (1994) , стр. 47, приложение B
  70. ^ ISO-IR , стр. 2, глава 1 («Введение»)
  71. ^ ISO / IEC 2375 (2003)
  72. ^ ISO-IR , стр. 10, глава 2.2 («Набор графических символов из 94 символов со вторым промежуточным байтом»)
  73. ^ ARIB STD-B24 (2008) , стр. 39, часть 2, таблица 7-3
  74. ^ Mascheck, Свен; Ле Бретон, Стефан; Гамильтон, Ричард Л. «О« альтернативном наборе символов рисования линий » » . ~ sven_mascheck / .
  75. ECMA-35 (1994) , стр. 36, глава 14.4
  76. ECMA-35 (1994) , стр. 36, глава 14.4.2, примечание 48
  77. ECMA-35 (1994) , стр. 36, глава 14.4.2, примечание 47
  78. ETS 300706 (1997) , стр. 103, глава 14 («Динамически повторно определяемые персонажи»)
  79. ^ a b c d e f g h i j k l m n o p q ECMA-35 (1994) , стр. 35-36, глава 14.3.2
  80. ^ ISO / IEC 10646 (2017) , стр. 19-20, глава 12.4 («Идентификация набора функций управления»)
  81. ECMA-35 (1994) , стр. 32, таблица 5
  82. ^ a b c ECMA-35 (1994) , стр. 37-41, глава 15.2
  83. ECMA-35 (1994) , стр. 34, глава 14.2.2
  84. ECMA-35 (1994) , стр. 34, глава 14.2.3
  85. ^ Цифровой . «DECDWL - линия двойной ширины, линия одинарной высоты» . Информация для программиста видеотерминала VT510 .
  86. Перейти ↑ Kawasaki, Yusuke (2010). «Кодировать :: JP :: Emoji :: Кодирование» . Кодировать-JP-Emoji . Строка 268.
  87. ECMA-35 (1994) , стр. 36-37, глава 14.5.
  88. ECMA-35 (1980) , стр. 14-15, глава 5.3.7.
  89. ^ a b c d ISO-IR , стр. 20, глава 2.8.1 («Системы кодирования со стандартным возвратом»)
  90. ↑ a b c d ECMA-35 (1994) , стр. 41-42, глава 15.4.
  91. ^ a b c d e ISO-IR , стр. 21, глава 2.8.2 («Системы кодирования без стандартного возврата»)
  92. ECMA-35 (1994) , стр. 41, глава 15.3
  93. ^ a b c ISO / IEC 10646 (2017) , стр. 19, глава 12.2 («Идентификация схемы кодирования UCS»)
  94. ISO / IEC 10646 (2017) , стр. 18–19, глава 12.1 («Цель и контекст идентификации»)
  95. ISO-IR-196 (1996)
  96. ISO-IR-192 (1996)
  97. ISO-IR-195 (1996)
  98. ISO / IEC 10646 (2017) , стр. 20, глава 12.5 («Идентификация системы кодирования ISO / IEC 2022»)
  99. ^ Б с д е е RFC 1468 (1993)
  100. ^ a b c «Идентификаторы кодовой страницы» . Центр разработки для Windows . Microsoft.
  101. ^ a b Стандарт кодирования WHATWG , раздел 12.2 («ISO-2022-JP»)
  102. ^ Чанг, Хе-Шик. «Модули / cjkcodecs / _codecs_iso2022.c, строка 1122» . Исходное дерево cPython . Фонд программного обеспечения Python.
  103. ^ «кодеки - Реестр кодеков и базовые классы § Стандартные кодировки» . Документация Python 3.7.4 . Фонд программного обеспечения Python.
  104. ^ «2: Кодовые наборы и преобразование кодовых наборов» . Технический справочник DIGITAL UNIX по использованию японских функций . Корпорация цифрового оборудования , Compaq .
  105. ^ a b Lunde (2008) , стр. 236-238, глава 4 («Методы кодирования»), раздел «Предшественник кодирования ISO-2022-JP - кодирование JIS»
  106. ^ RFC 1554 (1993)
  107. ^ RFC 2237 (1997)
  108. ^ a b RFC 1557 (1993)
  109. ^ "KS X 1001: 1992" (PDF) .
  110. ISO-IR-149 (1988)
  111. ^ а б в г RFC 1922 (1996)
  112. ^ WHATWG Encoding Standard , глава 4.2 («Имена и метки»), привязка «замена»
  113. ^ Стандарт кодирования WHATWG , раздел 14.1 («замена»)
  114. ^ WHATWG Encoding Standard , раздел 2 («Предпосылки безопасности»)
  115. ECMA-43 (1991) , стр. 9-10, глава 8 («Уровни»)
  116. ISO-IR-105 (1985)
  117. ECMA-43 (1985) , стр. 7-11, глава 7.3 («Набор G0»)
  118. ECMA-43 (1991) , стр. 6-8, глава 7.4 («Набор G0»)
  119. ECMA-43 (1991) , стр. 11, глава 10.3 («Определение версии»)
  120. ^ а б ECMA-43 (1991) , стр. 23, приложение E («Основные различия между вторым изданием (1985 г.) и настоящим (третьим) изданием этого стандарта ECMA»)
  121. ^ IPTC (1995). Рекомендуемый формат сообщений IPTC (PDF) (5-е изд.). IPTC TEC 7901.
  122. ECMA-43 (1991) , стр. 10, глава 9.2 («Уникальное кодирование символов»)
  123. ^ Ван Wingen, Johan W (1999). «8. Расширение кода, ISO 2022 и 2375, ISO 4873 и 10367» . Наборы символов. Буквы, жетоны и коды . Терена.
  124. ECMA-43 (1991) , стр. 10-11, глава 10 («Определение версии и уровня»)
  125. ^ Lunde (2008) , стр. 253-255, глава 4 («Методы кодирования»), раздел «EUC по сравнению с кодировками ISO-2022».
  126. ^ IBM . «Архитектура представления символьных данных (CDRA)» . С. 157–162.
  127. ^ DICOM PS3.2 2016d - Соответствие; D.6.2 Наборы символов; D.6 Поддержка наборов символов
  128. ^ «Вариант DICOM ISO 2022» .
  129. ^ a b Сивонен, Анри (2018-12-17). «(НЕ ПРЕДСТАВЛЕННЫЙ ПРОЕКТ) Отсутствие генерации U + FFFD для содержимого ASCII-состояния нулевой длины между escape-последовательностями ISO-2022-JP» (PDF) .
  130. ^ https://bugzilla.mozilla.org/show_bug.cgi?id=935453
  131. ^ WHATWG Encoding Standard , глава 4.2 («Имена и метки»), привязка «замена»
  132. ^ Стандарт кодирования WHATWG , раздел 14.1 («замена»)
  133. ^ Дэвис, Марк; Suignard, Мишель (2014-09-19). «3.6.2 Некоторые выходные данные для всех входов» . Технический отчет Unicode № 36: Вопросы безопасности Unicode (редакция 15) . Консорциум Unicode.

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

  • ARIB (2008). ARIB STD-B24: Спецификация кодирования и передачи данных для цифрового вещания (PDF) (стандарт ARIB). 5.2-E1. 1 . Архивировано (PDF) из оригинала 10.07.2017 . Проверено 10 июля 2017 .
  • ECMA (1980). ECMA-35: Расширение набора 7-битных кодированных символов (PDF) (Стандарт ECMA) (2-е изд.).
  • ECMA (1994). ECMA-35: Структура кода символов и методы расширения (PDF) (Стандарт ECMA) (6-е изд.).
  • ECMA (1985). ECMA-43: Структура и правила набора 8-битных кодированных символов (PDF) (Стандарт ECMA) (2-е изд.).
  • ECMA (1991). ECMA-43: Структура и правила набора 8-битных кодированных символов (PDF) (Стандарт ECMA) (3-е изд.).
  • ECMA (2000). ECMA-144: 8-битные однобайтовые графические наборы символов: латинский алфавит № 6 (PDF) (стандарт ECMA) (3-е изд.).
  • Европейский вещательный союз (1997). ETS 300 706: Расширенная спецификация телетекста (PDF) (Европейские стандарты электросвязи). ETSI .
  • ISO / IEC JTC 1 / SC 2 (2003). ISO / IEC 2375: 2003: Информационные технологии - Процедура регистрации управляющих последовательностей и кодированных наборов символов . ISO .
  • ISO / IEC JTC 1 / SC 2 (12 февраля 1998 г.). ISO / IEC FDIS 8859-10: Информационные технологии - 8-битные однобайтовые наборы графических символов - Часть 10: Латинский алфавит № 6 (PDF) (окончательный проект международного стандарта).
  • ISO / IEC JTC 1 / SC 2 (2017). ISO / IEC 10646: Информационные технологии - Универсальный набор кодированных символов (UCS) (стандарт ISO) (5-е изд.). ISO .
  • ISO-IR: Международный регистр наборов кодированных символов ISO / IEC для использования с escape-последовательностями (PDF) (индекс реестра). ITSCJ / IPSJ .
  • ван Кестерен, Энн . Стандарт кодирования WHATWG (WHATWG Living Standard). WHATWG .

Процитированные зарегистрированные наборы кодов [ править ]

  • ISO / TC 97 / SC 2 (1975-12-01). ISO-IR-1: Набор управляющих символов стандарта ISO 646 (PDF) . ITSCJ / IPSJ .
  • Sveriges Standardiseringskommission (1975-12-01). ISO-IR-7: NATS Control set для передачи газетного текста (PDF) . ITSCJ / IPSJ .
  • Японский комитет промышленных стандартов (1975-12-01). ISO-IR-14: Набор символов японского римского алфавита (PDF) . ITSCJ / IPSJ .
  • IPTC (1976-03-25). ISO-IR-26: Комплект управления для передачи газетного текста (PDF) . ITSCJ / IPSJ .
  • ISO / TC 97 / SC 2 (1977-10-15). ISO-IR-36: набор управляющих символов ISO 646, в котором IS4 заменен на Single Shift для G2 (SS2) (PDF) . ITSCJ / IPSJ .
  • ISO / TC97 / SC2 / WG-7 ; ECMA (1 августа 1985 г.). ISO-IR-104: Минимальный C0 установлен для ISO 4873 (PDF) . ITSCJ / IPSJ .
  • ISO / TC97 / SC2 / WG-7 ; ECMA (1 августа 1985 г.). ISO-IR-105: Минимальный набор C1 для ISO 4873 (PDF) . ITSCJ / IPSJ .
  • МСЭ (1 августа 1985 г.). ISO-IR-106: Основной набор функций управления Teletex (PDF) . ITSCJ / IPSJ .
  • Řad pro normalizaci a měřeni (1987-07-31). ISO-IR-140: Набор управляющих символов C0 стандарта ISO 646 с заменой EM на SS2 (PDF) . ITSCJ / IPSJ .
  • Корейское бюро стандартов (1988-10-01). ISO-IR-149: корейский набор графических символов для обмена информацией (KS C 5601: 1987) (PDF) . ITSCJ / IPSJ .
  • ИСО / МЭК / JTC1 / SC2 / WG3 (1990-04-16). ISO-IR-155: Базовый набор коробочных чертежей (PDF) . ITSCJ / IPSJ .
  • CCITT (13 июля 1992 г.). ISO-IR-164: Дополнительный набор графических символов для иврита (PDF) . ITSCJ / IPSJ .
  • ECMA (1996-04-22). ISO-IR-192: Формат преобразования UCS (UTF-8), уровень реализации 3, без стандартного возврата (PDF) . ITSCJ / IPSJ .
  • ECMA (1996-04-22). ISO-IR-195: Формат преобразования UCS (UTF-16), уровень реализации 3, без стандартного возврата (PDF) . ITSCJ / IPSJ .
  • ECMA (1996-04-22). ISO-IR-196: Формат преобразования UCS (UTF-8) со стандартным возвратом (PDF) . ITSCJ / IPSJ .
  • Национальное управление по стандартам Ирландии (1999-12-07). ISO-IR-208: Набор символов в кодировке Огам для обмена информацией (PDF) . ITSCJ / IPSJ .

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

  • Murai, J .; Crispin, M .; ван дер Поэль, Э. (1993). «RFC 1468: Японская кодировка символов для Интернет-сообщений» . Запросы на комментарии . IETF . DOI : 10.17487 / rfc1468 .
  • Охта, М .; Ханда, К. (1993). «RFC 1554: ISO-2022-JP-2: многоязычное расширение ISO-2022-JP» . Запросы на комментарии . IETF . DOI : 10.17487 / rfc1554 .
  • Choi, U .; Chon, K .; Парк, Х. (1993). «RFC 1557: корейская кодировка символов для Интернет-сообщений» . Запросы на комментарии . IETF . DOI : 10.17487 / rfc1557 .
  • Чжу, HF .; Hu, DY .; Wang, ZG .; Kao, TC .; Чанг, WCH .; Криспин, М. (1996). «RFC 1922: Кодировка китайских символов для Интернет-сообщений» . Запросы на комментарии . IETF . DOI : 10.17487 / rfc1922 .
  • Тамару, К. (1997). «RFC 2237: Японская кодировка символов для Интернет-сообщений» . Запросы на комментарии . IETF . DOI : 10.17487 / rfc2237 .

Процитированы другие опубликованные работы [ править ]

  • Лунде, Кен (2008). CJKV Обработка информации (2-е изд.). O'Reilly Media . ISBN 9780596514471.CS1 maint: ref duplicates default (link)

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

  • Лунде, Кен (1998). CJKV Обработка информации . Кембридж, Массачусетс: O'Reilly & Associates . ISBN 1-56592-224-7.CS1 maint: ref duplicates default (link)

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

  • ИСО / МЭК 2022: 1994
  • ИСО / МЭК 2022: 1994 / Кор 1: 1999
  • ECMA-35 , эквивалент ISO / IEC 2022 и свободно загружаемый.
  • Международный регистр наборов кодированных символов для использования с escape-последовательностями , полный список назначенных наборов символов и их escape-последовательностей
  • История кодов символов в Северной Америке, Европе и Восточной Азии с 1999 г., ред. 2004 г.
  • Кен Лунд «s CJK.INF : документ о кодирующая китайском, японском и корейском языках (CJK) языков, в том числе обсуждение различных вариантов ISO / IEC 2022.