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

Unicode - это стандарт информационных технологий для согласованного кодирования , представления и обработки текста, выраженного в большинстве мировых систем письма . Стандарт поддерживается Консорциумом Unicode , и по состоянию на март 2020 года он насчитывает в общей сложности 143859 символов с Unicode 13.0 (эти символы состоят из 143 696 графических символов и 163 символов формата), охватывающих 154 современных и исторических сценария , а также несколько наборы символов и смайлики . Репертуар символов стандарта Unicode синхронизирован с ISO / IEC 10646., каждый из которых является кодом для кода, идентичным другому.

Стандарт Unicode состоит из набора кодовых диаграмм для визуальной справки, метода кодирования и набора стандартных кодировок символов , набора файлов справочных данных и ряда связанных элементов, таких как свойства символов, правила нормализации , декомпозиции, сопоставления. , рендеринг и порядок отображения двунаправленного текста (для правильного отображения текста, содержащего сценарии с написанием справа налево , например арабский и иврит , и сценарии слева направо). [1]

Успех Unicode в унификации наборов символов привел к его широкому распространению и преимущественному использованию при интернационализации и локализации компьютерного программного обеспечения . Стандарт реализован во многих новейших технологиях, включая современные операционные системы , XML , Java (и другие языки программирования ) и .NET Framework .

Юникод может быть реализован с помощью различных кодировок символов. Стандарт Unicode определяет форматы преобразования Unicode (UTF) UTF-8 , UTF-16 и UTF-32 , а также несколько других кодировок. Чаще всего используются кодировки UTF-8, UTF-16 и UCS -2 (предшественник UTF-16 без полной поддержки Unicode); GB18030 стандартизирован в Китае и полностью реализует Unicode, но не является официальным стандартом Unicode.

UTF-8, доминирующая кодировка во всемирной паутине (используется более чем на 95% веб-сайтов по состоянию на 2020 год и до 100% для некоторых языков) [2], использует один байт [примечание 1] для первых 128 кодовых точек , и до 4 байтов для других символов. [3] Первые 128 кодовых точек Unicode представляют символы ASCII , что означает, что любой текст ASCII также является текстом UTF-8.

UCS-2 использует два байта (16  бит ) для каждого символа, но может кодировать только первые 65 536 кодовых точек , так называемую базовую многоязычную плоскость (BMP). С 1112 064 возможными кодовыми точками Unicode, соответствующими символам (см. Ниже ) на 17 плоскостях, и с более чем 143 000 кодовых точек, определенных с версии 13.0, UCS-2 может представлять только менее половины всех закодированных символов Unicode. Таким образом, UCS-2 устарел, хотя все еще широко используется в программном обеспечении. UTF-16 расширяет UCS-2, используя ту же 16-битную кодировку, что и UCS-2 для базовой многоязычной плоскости, и 4-байтовую кодировку для других плоскостей. Если он не содержит кодовых точек в зарезервированном диапазоне U + D800 – U + DFFF, [требуется пояснение ]текст UCS-2 является допустимым текстом UTF-16.

UTF-32 (также называемый UCS-4) использует четыре байта для кодирования любой заданной кодовой точки, но не обязательно любого заданного воспринимаемого пользователем символа (грубо говоря, графемы ), поскольку воспринимаемый пользователем символ может быть представлен графемой кластер (последовательность из нескольких кодовых точек). [4] Как и в UCS-2, количество байтов на кодовую точку фиксировано, что упрощает индексацию символов; но в отличие от UCS-2, UTF-32 может кодировать все кодовые точки Unicode. Однако, поскольку каждый символ использует четыре байта, UTF-32 занимает значительно больше места, чем другие кодировки, и широко не используется. Примеры UTF-32 также имеют переменную длину (как и все другие кодировки), хотя в другом смысле включают: « Деванагари кшикодируется 4 кодовыми точками [..] Флаговые эмодзи также являются кластерами графем и состоят из двух символов кодовых точек - например, флаг Японии " [5] и все" объединяющие последовательности символов являются графемами, но есть и другие последовательности кодовые точки, которые также есть; например \ r \ n равно единице " [6] [7] [8] [9]

Происхождение и развитие [ править ]

Unicode имеет явную цель преодолеть ограничения традиционных кодировок символов, таких как те, которые определены стандартом ISO / IEC 8859 , которые широко используются в различных странах мира, но остаются в значительной степени несовместимыми друг с другом. Многие традиционные кодировки символов имеют общую проблему в том, что они допускают двуязычную компьютерную обработку (обычно с использованием латинских символов и местного алфавита), но не многоязычную компьютерную обработку (компьютерную обработку произвольных сценариев, смешанных друг с другом).

Unicode, по сути, кодирует лежащие в основе символы - графемы и графемоподобные единицы - а не варианты глифов (визуализации) для таких символов. В случае китайских иероглифов это иногда приводит к разногласиям по поводу отличия основного символа от его вариантов глифов (см. Объединение Хань ).

При обработке текста Unicode обеспечивает уникальную кодовую точку - число , а не глиф - для каждого символа. Другими словами, Unicode представляет символ абстрактным образом и оставляет визуальную визуализацию (размер, форму, шрифт или стиль) другому программному обеспечению, например веб-браузеру или текстовому процессору . Однако эта простая цель усложняется из-за уступок, сделанных разработчиками Unicode в надежде способствовать более быстрому принятию Unicode.

Первые 256 кодовых точек были сделаны идентичными содержанию ISO / IEC 8859-1, чтобы упростить преобразование существующего западного текста. Многие практически идентичные символы кодировались несколько раз в разных кодовых точках, чтобы сохранить различия, используемые в устаревших кодировках, и, следовательно, обеспечить преобразование этих кодировок в Unicode (и обратно) без потери какой-либо информации. Например, раздел кодовых точек « полноширинные формы » включает в себя полную копию латинского алфавита, поскольку китайские, японские и корейские ( CJK ) шрифты содержат две версии этих букв: «полноширинные», соответствующие ширине символов CJK, и нормальная ширина. Для других примеров см. Повторяющиеся символы в Юникоде .

История [ править ]

Основываясь на опыте использования стандарта Xerox Character Code Standard (XCCS) с 1980 года [10], истоки Unicode восходят к 1987 году, когда Джо Беккер из Xerox с Ли Коллинзом и Марком Дэвисом из Apple начали исследовать практические аспекты создания универсального набора символов. . [11] С дополнительным вкладом Питера Фенвика и Дэйва Опстада [10] Джо Беккер опубликовал в августе 1988 года проект предложения по «международной / многоязычной системе кодирования текстовых символов, предварительно названной Unicode». Он пояснил, что «[t] его название« Unicode »предназначено для обозначения уникальной, унифицированной, универсальной кодировки». [10]

В этом документе, озаглавленном Unicode 88 , Беккер обрисовал в общих чертах модель 16-битных символов: [10]

Unicode предназначен для удовлетворения потребности в работоспособной и надежной кодировке мирового текста. Юникод можно грубо описать как «широкоформатный ASCII», который был расширен до 16 бит, чтобы охватить символы всех живых языков мира. В правильно спроектированном дизайне для этой цели более чем достаточно 16 бит на символ.

Его первоначальный 16-битный дизайн был основан на предположении, что нужно будет кодировать только те скрипты и символы, которые используются в современном мире: [10]

Unicode уделяет больше внимания обеспечению полезности для будущего, чем сохранению древностей прошлого. Unicode нацелен в первую очередь на символы, опубликованные в современном тексте (например, в объединении всех газет и журналов, напечатанных в мире в 1988 году), число которых, несомненно, намного меньше 2 14 = 16 384. Помимо этих современных символов, все остальные могут быть определены как устаревшие или редкие; они являются лучшими кандидатами для регистрации для частного использования, чем для чрезмерного заполнения общедоступного списка общепринятых юникодов.

В начале 1989 года рабочая группа по Unicode расширилась, включив в нее Кена Уистлера и Майка Кернагана из Metaphor, Карен Смит-Йошимура и Джоан Алипранд из RLG и Гленна Райт из Sun Microsystems , а в 1990 году Мишеля Суиньяра и Асмуса Фрейтага из Microsoft и Рика Макгоуэна. из NeXT присоединились к группе. К концу 1990 года большая часть работы по сопоставлению существующих стандартов кодировки символов была завершена, и был готов окончательный проект обзора Unicode.

Консорциум Unicode был включен в Калифорнии 3 января 1991 года, [12] , а в октябре 1991 года, первый объем стандарта Unicode был опубликован. Второй том, посвященный идеограммам Хань, был опубликован в июне 1992 года.

В 1996 году в Unicode 2.0 был реализован механизм суррогатных символов, так что Unicode больше не ограничивался 16 битами. Это увеличило кодовое пространство Unicode до более чем миллиона кодовых точек, что позволило кодировать многие исторические сценарии (например, египетские иероглифы ) и тысячи редко используемых или устаревших символов, которые, как предполагалось, не нуждались в кодировании. Среди символов, изначально не предназначенных для Unicode, редко используются кандзи или китайские иероглифы, многие из которых являются частью личных и географических названий, что делает их редко используемыми, но гораздо более важными, чем предполагалось в исходной архитектуре Unicode. [13]

Спецификация Microsoft TrueType версии 1.0 от 1992 года использовала имя Apple Unicode вместо Unicode для идентификатора платформы в таблице имен.

Консорциум Unicode [ править ]

Консорциум Unicode - это некоммерческая организация, координирующая разработку Unicode. Полноправные члены включают большинство основных производителей компьютерного программного обеспечения и оборудования, которые заинтересованы в стандартах обработки текста, включая Adobe , Apple , Facebook , Google , IBM , Microsoft , Netflix и SAP SE . [14]

На протяжении многих лет несколько стран или правительственных агентств были членами Консорциума Unicode. В настоящее время только Министерство по делам религий и пожертвований (Оман) является полноправным членом с правом голоса. [14]

Консорциум ставит амбициозную цель в конечном итоге заменить существующие схемы кодирования символов на Unicode и его стандартные схемы формата преобразования Unicode (UTF), поскольку многие из существующих схем ограничены по размеру и сфере и несовместимы с многоязычными средами.

Сценарии покрыты [ править ]

Многие современные приложения могут отображать значительную часть множества сценариев в Unicode , как показано на этом снимке экрана из приложения OpenOffice.org .

Unicode охватывает почти все скрипты ( системы письма ), которые используются в настоящее время. [15] [ неудавшаяся проверка ] [16]

В последнюю версию Unicode включено в общей сложности 154 скрипта (включая алфавиты , abugidas и слоговые словари ), хотя все еще есть скрипты, которые еще не закодированы, особенно те, которые в основном используются в историческом, литургическом и академическом контекстах. Также происходит дальнейшее добавление символов к уже закодированным сценариям, а также символов, в частности для математики и музыки (в форме нот и ритмических символов).

Комитет по дорожной карте Unicode ( Майкл Эверсон , Рик Макгоуэн, Кен Уистлер, В. С. Умамахесваран [17] ) поддерживает список сценариев, которые являются кандидатами или потенциальными кандидатами для кодирования, и их предварительные назначения блоков кода на странице Unicode Roadmap веб-сайта Консорциума Unicode. . Для некоторых сценариев в дорожной карте, таких как небольшой сценарий чжурчжэней и кидань , были внесены предложения по кодированию, и они проходят процесс утверждения. Для других сценариев, таких как Mayan (кроме чисел) и Rongorongo, предложений еще не было, и они ждут согласия по репертуару персонажей и другим деталям от вовлеченных сообществ пользователей.

Некоторые современные придуманные сценарии, которые еще не были включены в Unicode (например, Tengwar ) или которые не могут быть включены в Unicode из-за отсутствия реального использования (например, Klingon ), перечислены в ConScript Unicode Registry вместе с неофициальными но широко используемые назначения кодов для частных областей использования .

Существует также Средневековая инициатива по шрифтам Unicode, ориентированная на особые латинские средневековые символы. Часть этих предложений уже включена в Unicode.

Encoding Initiative сценария , пробег проект Дебора Андерсон в Университете Калифорнии, Беркли был основан в 2002 году с целью финансирования предложений по алфавитов , еще не закодированных в стандарте. В последние годы этот проект стал основным источником предлагаемых дополнений к стандарту. [18]

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

Unicode разработан совместно с Международной организацией по стандартизации и имеет общий репертуар символов с ISO / IEC 10646 : универсальный набор символов. Юникод и ИСО / МЭК 10646 эквивалентны кодировке символов, но Стандарт Юникода содержит гораздо больше информации для разработчиков, подробно охватывая такие темы, как побитовое кодирование, сопоставление и рендеринг. Стандарт Unicode перечисляет множество свойств символов, включая те, которые необходимы для поддержки двунаправленного текста . В этих двух стандартах используется немного различающаяся терминология.

Консорциум Unicode впервые опубликовал Стандарт Unicode в 1991 году ( версия 1.0 ) и с тех пор регулярно публикует новые версии.

Последняя версия , и поэтому единственным допустимым, является версия 13.0 . Он был выпущен в марте 2020 года и полностью опубликован на веб-сайте консорциума.

В апреле 2020 года прогнозируемая версия 14.0 была отложена на шесть месяцев с ее первоначального выпуска в марте 2021 года из -за пандемии COVID-19 до сентября 2021 года [19]. Она добавит как минимум 5 новых скриптов, а также 37 новых символов эмодзи. . [20]

Последней версией как формальной и полной публикации книги (включая таблицы кодов) была версия 5.0 (2006 г.). Начиная с версии 5.2, основная спецификация стандарта публикуется в мягкой обложке для печати по запросу. [21] Полный текст каждой версии стандарта, включая основную спецификацию, стандартные приложения и таблицы кодов, находится в свободном доступе в формате PDF на веб-сайте Unicode.

К настоящему времени опубликованы следующие основные и второстепенные версии стандарта Unicode. Версии обновлений, которые не включают никаких изменений в репертуаре персонажей, обозначены третьим числом (например, «версия 4.0.1») и опущены в таблице ниже. [22]

  1. ^ Количество символов, перечисленных для каждой версии Unicode, представляет собой общее количество графических символов и символов формата (т. Е. Исключая символы частного использования , управляющие символы , несимволы и суррогатные кодовые точки ).

Архитектура и терминология [ править ]

Стандарт Unicode определяет codespace, [54] набор числовых значений в пределах от 0 до 10FFFF 16 , [55] называемые кодовые точки [56] и обозначается как U + 0000 до U + 10FFFF ( "+ U" плюс значение кода пункта в шестнадцатеричном формате с начальными нулями, если необходимо, чтобы получить как минимум четыре цифры, например , U + 00F7 для знака деления, ÷ против U + 13254 для египетского иероглифа, обозначающего тростниковое убежище или извилистую стену ( ) [57 ] ) соответственно. Из них 2 16 + 2 20определенных кодовых точек, кодовые точки от U + D800 до U + DFFF, которые используются для кодирования суррогатных пар в UTF-16 , зарезервированы стандартом и не могут использоваться для кодирования допустимых символов, в результате чего получается всего 2 16 - 2 11 + 2 20 = 1112064 возможные кодовые точки , соответствующие допустимых символов Unicode. Не все эти кодовые точки обязательно соответствуют видимым символам; некоторые, например, назначаются управляющим кодам, таким как возврат каретки .

Плоскости кода и блоки [ править ]

Кодовое пространство Unicode разделено на семнадцать плоскостей , пронумерованных от 0 до 16:

Все кодовые точки в BMP доступны как единая кодовая единица в кодировке UTF-16 и могут быть закодированы в один, два или три байта в UTF-8 . Кодовые точки в плоскостях с 1 по 16 ( дополнительные плоскости ) доступны как суррогатные пары в UTF-16 и кодируются в четырех байтах в UTF-8.

Внутри каждой плоскости персонажи распределяются внутри именованных блоков связанных символов. Хотя блоки имеют произвольный размер, они всегда кратны 16 кодовым точкам и часто кратны 128 кодовым точкам. Символы, необходимые для данного сценария, могут быть распределены по нескольким различным блокам.

Свойство General Category [ править ]

Каждая кодовая точка имеет одно свойство общей категории . Обозначены основные категории: буква, знак, число, пунктуация, символ, разделитель и прочее. Внутри этих категорий есть подразделения. В большинстве случаев для точного определения характеристик кодовой точки необходимо использовать другие свойства. Возможные общие категории:

Кодовые точки в диапазоне U + D800 – U + DBFF (1024 кодовых точки) называются кодовыми точками с высоким суррогатом , а кодовые точки в диапазоне U + DC00 – U + DFFF (1024 кодовых точки) называются низко-суррогатными. кодовые точки. Кодовая точка с высоким суррогатным кодом, за которой следует кодовая точка с низким суррогатным кодом, образуют суррогатную пару в UTF-16 для представления кодовых точек, превышающих U + FFFF. В противном случае эти кодовые точки нельзя использовать (на практике это правило часто игнорируется, особенно когда не используется UTF-16).

Гарантируется, что небольшой набор кодовых точек никогда не будет использоваться для кодирования символов, хотя приложения могут использовать эти кодовые точки для внутренних целей, если захотят. Всего шестьдесят шесть таких несимволов : U + FDD0 – U + FDEF и любая кодовая точка, оканчивающаяся значением FFFE или FFFF (т. Е. U + FFFE, U + FFFF, U + 1FFFE, U + 1FFFF, ... U + 10FFFE, U + 10FFFF). Набор несимволов стабилен, и никакие новые несимволы никогда не будут определены. [58] Как и суррогаты, правило, что они не могут использоваться, часто игнорируется, хотя операция метки порядка байтов предполагает, что U + FFFE никогда не будет первой кодовой точкой в ​​тексте.

Исключение суррогатов и несимволов оставляет доступными для использования 1111998 кодовых точек.

Кодовые точки частного использования считаются присвоенными символами, но они не имеют интерпретации, определенной стандартом Unicode [59], поэтому любой обмен такими символами требует соглашения между отправителем и получателем об их интерпретации. В кодовом пространстве Unicode есть три области частного использования:

  • Зона частного использования: U + E000 – U + F8FF (6 400 знаков),
  • Дополнительная область частного использования-A: U + F0000 – U + FFFFD (65 534 символа),
  • Дополнительная область частного использования-B: U + 100000 – U + 10FFFD (65 534 символа).

Графические символы - это символы, определенные Unicode для определенной семантики, которые либо имеют видимую форму глифа, либо представляют видимое пространство. В Unicode 13.0 имеется 143 696 графических символов.

Символы формата - это символы, которые не имеют видимого внешнего вида, но могут влиять на внешний вид или поведение соседних символов. Например, U + 200C ZERO WIDTH NON-JOINER и U + 200D ZERO WIDTH JOINER могут использоваться для изменения поведения по умолчанию при формировании соседних символов (например, для запрета лигатуры или запроса формирования лигатуры). Unicode 13.0 содержит 163 символа формата.

Шестьдесят пять кодовых точек (U + 0000 – U + 001F и U + 007F – U + 009F) зарезервированы как управляющие коды и соответствуют управляющим кодам C0 и C1, определенным в ISO / IEC 6429 . U + 0009 (табуляция), U + 000A (перевод строки) и U + 000D (возврат каретки) широко используются в текстах с кодировкой Unicode. На практике кодовые точки C1 часто неправильно переводятся ( моджибаке ) как устаревшие символы Windows-1252, используемые в некоторых английских и западноевропейских текстах.

Графические символы, символы формата, символы управляющего кода и символы частного использования известны вместе как назначенные символы . Зарезервированные кодовые точки - это те кодовые точки, которые доступны для использования, но еще не назначены. В Unicode 13.0 зарезервировано 830 606 кодовых точек.

Абстрактные персонажи [ править ]

Набор графических символов и символов формата, определенных Unicode, не соответствует непосредственно репертуару абстрактных символов, который может быть представлен в Unicode. Unicode кодирует символы, связывая абстрактный символ с определенной кодовой точкой. [60] Однако не все абстрактные символы кодируются как один символ Unicode, а некоторые абстрактные символы могут быть представлены в Unicode последовательностью из двух или более символов. Например, латинская строчная буква «i» с огонеком , точкой наверху и острым ударением , что требуется в литовском языке., представлен последовательностью символов U + 012F, U + 0307, ​​U + 0301. Unicode поддерживает список последовательностей символов с уникальными именами для абстрактных символов, которые напрямую не кодируются в Unicode. [61]

Все графические символы, символы формата и символы частного использования имеют уникальное и неизменное имя, по которому они могут быть идентифицированы. Эта неизменность гарантируется, начиная с версии Unicode 2.0, политикой стабильности имени. [58] В случаях, когда имя серьезно дефектно и вводит в заблуждение или содержит серьезную типографскую ошибку, может быть определен формальный псевдоним, и приложениям рекомендуется использовать формальный псевдоним вместо официального имени персонажа. Например, U + A015YI SYLLABLE WU имеет формальный псевдоним YI SYLLABLE ITERATION MARK , а U + FE18PRESENTATION FORM FOR VERTICAL RIGHT WHITE LENTICULAR BRA KC ET ( sic ) имеет формальный псевдоним ФОРМА ПРЕЗЕНТАЦИИ ДЛЯ ВЕРТИКАЛЬНОГО ПРАВОГО БЕЛОГО ЛЕНТИКУЛЯРНОГО БРЮКА CK ET . [62]

Готовые и составные персонажи [ править ]

Unicode включает механизм изменения символов, который значительно расширяет поддерживаемый репертуар глифов. Это касается использования комбинирования диакритических знаков, которые могут быть добавлены пользователем после основного символа. К одному и тому же символу можно одновременно применять несколько комбинированных диакритических знаков. Unicode также содержит предварительно составленные версии большинства буквенно-диакритических комбинаций при обычном использовании. Это упрощает преобразование в устаревшие кодировки и обратно и позволяет приложениям использовать Unicode в качестве внутреннего текстового формата без необходимости реализации комбинирования символов. Например, é можно представить в Юникоде как U + 0065 ( СТРОЧНАЯ ЛАТИНСКАЯ БУКВА E ), за которой следует U + 0301 ( ОБЪЕДИНЕНИЕ ОСТРОГО АКЦЕНТА), но его также можно представить как предварительно составленный символ U + 00E9 (СТРОЧНАЯ ЛАТИНСКАЯ БУКВА E С ОСТРЫМ ). Таким образом, во многих случаях у пользователей есть несколько способов кодирования одного и того же символа. Чтобы справиться с этим, Unicode предоставляет механизм канонической эквивалентности .

Примером этого является корейский алфавит хангыль . Unicode предоставляет механизм для составления слогов хангыль с их отдельными подкомпонентами, известного как хангыль джамо . Тем не менее, он также предоставляет 11 172 комбинации заранее составленных слогов, составленных из наиболее распространенных джамо.

В настоящее время символы CJK имеют коды только для их предварительно составленной формы. Тем не менее, большинство этих символов содержат более простые элементы (называемые радикалами ), поэтому в принципе Unicode мог бы их разложить, как это было с хангылем. Это значительно уменьшило бы количество требуемых кодовых точек, одновременно позволяя отображать практически все мыслимые символы (что могло бы устранить некоторые проблемы, вызванные объединением ханьцев ). Похожая идея используется некоторыми методами ввода , такими как Cangjie и Wubi . Однако попытки сделать это для кодировки символов натолкнулись на тот факт, что китайские иероглифы не разлагаются так просто и регулярно, как хангыль.

Набор радикалов был предоставлен в Unicode 3.0 (радикалы CJK между U + 2E80 и U + 2EFF, радикалы KangXi в U + 2F00 до U + 2FDF и символы идеографического описания от U + 2FF0 до U + 2FFB), но стандарт Unicode (глава 12.2 Unicode 5.2) предостерегает от использования последовательностей идеографических описаний в качестве альтернативного представления для ранее закодированных символов:

Этот процесс отличается от формального кодирования идеограммы. Нет канонического описания незакодированных идеографов; отсутствует семантика описываемых идеографов; для описанных идеографов не определена эквивалентность. Концептуально идеографические описания больше похожи на английскую фразу «an 'e' с острым ударением», чем на последовательность символов <U + 0065, U + 0301>.

Лигатуры [ править ]

Многие письменности, включая арабский и деванагари , имеют особые орфографические правила, требующие объединения определенных комбинаций букв в специальные лигатурные формы . Правила, регулирующие формирование лигатуры, могут быть довольно сложными, требуя специальных технологий формирования шрифтов, таких как ACE (Arabic Calligraphic Engine от DecoType в 1980-х годах и использовался для создания всех арабских примеров в печатных изданиях стандарта Unicode), что стало доказательством этого. концепции для OpenType (по Adobe и Microsoft), Graphite (по SIL International ) или АЯТ (Яблоко).

Инструкции также встроены в шрифты, чтобы сообщить операционной системекак правильно выводить разные последовательности символов. Простое решение для размещения комбинированных знаков или диакритических знаков - присвоить знакам нулевую ширину и разместить сам глиф слева или справа от левого подшипника (в зависимости от направления шрифта, с которым они предназначены для использования). Метка, обработанная таким образом, появится поверх любого предшествующего ей символа, но не изменит свое положение относительно ширины или высоты базового глифа; это может быть визуально неудобно и может перекрывать некоторые глифы. Настоящее наложение невозможно, но может быть приблизительно определено в некоторых случаях (например, тайские верхние гласные и тональные знаки могут быть просто на разной высоте для начала). Обычно этот подход эффективен только для моноширинных шрифтов, но может использоваться как резервный метод рендеринга, когда более сложные методы не работают.

Стандартизированные подмножества [ править ]

Некоторые подмножества Unicode стандартизированы: Microsoft Windows, начиная с Windows NT 4.0, поддерживает WGL-4 с 657 символами, который, как считается, поддерживает все современные европейские языки, использующие латинский, греческий или кириллический шрифт. Другие стандартизированные подмножества Unicode включают многоязычные европейские подмножества: [63]

MES-1 (только латинский алфавит, 335 символов), MES-2 (латинский, греческий и кириллица 1062 символа) [64] и MES-3A и MES-3B (два больших подмножества, здесь не показаны). Обратите внимание, что MES-2 включает каждый символ в MES-1 и WGL-4.

Программное обеспечение для визуализации, которое не может обработать символ Unicode должным образом, часто отображает его как открытый прямоугольник или « заменяющий символ » Unicode (U + FFFD, ), чтобы указать положение нераспознанного символа. Некоторые системы предприняли попытки предоставить больше информации о таких персонажах. Apple, шрифт Last Resort будет отображаться заменяющий символ , указывающий диапазон Unicode символа, и SIL International «s Unicode Запасной шрифт будет отображаться окно , показывающее скалярное значение шестнадцатеричного символа.

Отображение и кодирование [ править ]

Было указано несколько механизмов для хранения серии кодовых точек в виде серии байтов.

Unicode определяет два метода сопоставления: кодировки формата преобразования Unicode (UTF) и кодировки универсального кодированного набора символов (UCS). Кодирование отображает (возможно, подмножество) диапазон кодовых точек Unicode в последовательности значений в некотором диапазоне фиксированного размера, называемых кодовыми единицами . Код карты всех кодировок UTF указывает на уникальную последовательность байтов. [65] Числа в названиях кодировок указывают количество битов на единицу кода (для кодировок UTF) или количество байтов на единицу кода (для кодировок UCS и UTF-1). UTF-8 и UTF-16 - наиболее часто используемые кодировки. UCS-2 - устаревшее подмножество UTF-16; UCS-4 и UTF-32 функционально эквивалентны.

Кодировки UTF включают:

  • UTF-1 , устаревший предшественник UTF-8, максимизирует совместимость с ISO 2022 , больше не являющимся частью стандарта Unicode.
  • UTF-7 , устаревшая 7-битная кодировка, иногда используемая в электронной почте (не является частью стандарта Unicode , а задокументирована только как информационный RFC , т. Е. Не в Internet Standards Track)
  • UTF-8 , использует от одного до четырех байтов для каждой кодовой точки, максимизирует совместимость с ASCII
  • UTF-EBCDIC , аналогичен UTF-8, но разработан для совместимости с EBCDIC (не является частью стандарта Unicode )
  • UTF-16 , использует одну или две 16-битных кодовых единицы на кодовую точку, не может кодировать суррогаты
  • UTF-32 , использует одну 32-битную кодовую единицу на кодовую точку

UTF-8 использует от одного до четырех байтов на кодовую точку и, будучи компактным для латинских шрифтов и совместимым с ASCII, обеспечивает фактическую стандартную кодировку для обмена текстом Unicode. Он используется FreeBSD и последними дистрибутивами Linux в качестве прямой замены устаревших кодировок в общей обработке текста.

Кодировки UCS-2 и UTF-16 определяют метку порядка байтов Unicode (BOM) для использования в начале текстовых файлов, которая может использоваться для определения порядка байтов (или определения порядка байтов ). Спецификация, кодовая точка U + FEFF имеет важное свойство однозначности при изменении порядка байтов, независимо от используемой кодировки Unicode; U + FFFE (результат перестановки байтов U + FEFF) не соответствует допустимому символу, а U + FEFF в других местах, кроме начала текста, передает неразрывный пробел нулевой ширины (символ с никакого внешнего вида и никакого эффекта, кроме предотвращения образования лигатур ).

Тот же самый символ, преобразованный в UTF-8, становится последовательностью байтов EF BB BF. Стандарт Unicode допускает, что спецификация «может служить подписью для текста в кодировке UTF-8, если набор символов не отмечен». [66] Некоторые разработчики программного обеспечения приняли его для других кодировок, включая UTF-8, в попытке отличить UTF-8 от локальных 8-битных кодовых страниц . Однако RFC 3629 , стандарт UTF-8, рекомендует запретить метки порядка байтов в протоколах, использующих UTF-8, но обсуждает случаи, когда это может быть невозможно. Кроме того, большое ограничение на возможные шаблоны в UTF-8 (например, не может быть никаких одиночных байтов с установленным старшим битом) означает, что должна быть возможность отличить UTF-8 от других кодировок символов, не полагаясь на спецификацию.

В UTF-32 и UCS-4 одна 32-битная кодовая единица служит довольно прямым представлением кодовой точки любого символа (хотя порядок байтов, который варьируется на разных платформах, влияет на то, как кодовая единица проявляется как последовательность байтов). В других кодировках каждая кодовая точка может быть представлена ​​переменным количеством кодовых единиц. UTF-32 широко используется в качестве внутреннего представления текста в программах (в отличие от сохраненного или передаваемого текста), поскольку каждая операционная система Unix, которая использует компиляторы gcc для создания программного обеспечения, использует его как стандартную кодировку « широких символов ». Некоторые языки программирования, такие как Seed7 , используют UTF-32 в качестве внутреннего представления для строк и символов. Последние версии Pythonязык программирования (начиная с 2.2) также может быть настроен для использования UTF-32 в качестве представления строк Unicode, эффективно распространяя такое кодирование в программном обеспечении с высокоуровневым кодированием.

Punycode , другая форма кодирования, позволяет кодировать строки Unicode в ограниченный набор символов, поддерживаемый системой доменных имен (DNS) на основе ASCII . Кодировка используется как часть IDNA , которая представляет собой систему, позволяющую использовать интернационализированные доменные имена во всех скриптах, поддерживаемых Unicode. Ранее и теперь исторические предложения включают UTF-5 и UTF-6 .

GB18030 - это еще одна форма кодировки Unicode, разработанная Управлением по стандартизации Китая . Это официальный набор символов из Народной Республики Китай (КНР). BOCU-1 и ГТС являются схемами сжатия Unicode. В День первоапрельских RFC 2005 указано два пародийные UTF кодировки, UTF-9 и UTF-18 .

Принятие [ править ]

Операционные системы [ править ]

Юникод стал доминирующей схемой для внутренней обработки и хранения текста. Хотя большая часть текста по-прежнему хранится в устаревших кодировках, Unicode используется почти исключительно для создания новых систем обработки информации. Ранние последователи, как правило, использовали UCS-2 (двухбайтовый прекурсор фиксированной ширины для UTF-16), а затем перешли на UTF-16 (текущий стандарт переменной ширины), поскольку это был наименее разрушительный способ добавить поддержку не -BMP символы. Самая известная такая система - Windows NT (и ее потомки, Windows 2000 , Windows XP , Windows Vista , Windows 7 , Windows 8 и Windows 10), который использует UTF-16 в качестве единственной внутренней кодировки символов. Java и .NET байткод среда, MacOS и KDE также использовать его для внутреннего представления. Частичная поддержка Unicode может быть установлена ​​в Windows 9x через Microsoft Layer for Unicode .

UTF-8 (первоначально разработанный для Plan 9 ) [67] стал основной кодировкой хранилища в большинстве Unix-подобных операционных систем (хотя другие также используются некоторыми библиотеками), поскольку это относительно простая замена традиционных расширенных наборов символов ASCII . UTF-8 также является наиболее распространенной кодировкой Unicode, используемой в документах HTML во всемирной паутине .

Многоязычные механизмы визуализации текста, использующие Unicode, включают Uniscribe и DirectWrite для Microsoft Windows, ATSUI и Core Text для macOS, а также Pango для GTK + и рабочего стола GNOME .

Способы ввода [ править ]

Поскольку в раскладках клавиатуры не может быть простых комбинаций клавиш для всех символов, некоторые операционные системы предоставляют альтернативные методы ввода, позволяющие получить доступ ко всему репертуару.

ISO / IEC 14755 , [68], который стандартизирует методы ввода символов Unicode из их кодовых точек, определяет несколько методов. Существует метод Basic , в котором за начальной последовательностью следует шестнадцатеричное представление кодовой точки и конечной последовательности . Также указан метод ввода с выбором экрана , когда символы перечислены в таблице на экране, например, в программе сопоставления символов.

Онлайн-инструменты для поиска кодовой точки для известного символа включают Unicode Lookup [69] Джонатана Хедли и Shapecatcher [70] Бенджамина Милде. В Unicode Lookup вводится ключ поиска (например, «дроби»), и возвращается список соответствующих символов с их кодовыми точками. В Shapecatcher, на основе контекста формы , персонаж рисует в поле, и возвращается список символов, приближенных к рисунку, с их кодовыми точками.

Электронная почта [ редактировать ]

MIME определяет два разных механизма для кодирования не-ASCII символов в электронной почте , в зависимости от того, находятся ли эти символы в заголовках электронной почты (например, «Тема:») или в тексте сообщения; в обоих случаях идентифицируется исходный набор символов, а также кодировка передачи. Для передачи по электронной почте Unicode рекомендуется использовать набор символов UTF-8 и кодировку передачи Base64 или Quoted-printable , в зависимости от того, состоит ли большая часть сообщения из символов ASCII . Детали двух различных механизмов указаны в стандартах MIME и обычно скрыты от пользователей почтового программного обеспечения.

Принятие Unicode в электронной почте происходит очень медленно. Некоторый восточноазиатский текст по-прежнему закодирован в кодировках, таких как ISO-2022 , а некоторые устройства, такие как мобильные телефоны, по-прежнему не могут правильно обрабатывать данные Unicode. Однако поддержка улучшается. Многие крупные поставщики бесплатной почты, такие как Yahoo , Google ( Gmail ) и Microsoft ( Outlook.com ), поддерживают его.

Интернет [ править ]

Все рекомендации W3C использовали Unicode в качестве набора символов документа, начиная с HTML 4.0. Веб-браузеры уже много лет поддерживают Unicode, особенно UTF-8. Раньше возникали проблемы с отображением, возникающие в основном из-за проблем со шрифтами ; например, версии Microsoft Internet Explorer версии 6 и старше не отображали много кодовых точек, если явно не было указано использовать шрифт, который их содержит. [71]

Хотя правила синтаксиса могут влиять на порядок, в котором разрешены символы, документы XML (включая XHTML ) по определению [72] содержат символы из большинства кодовых точек Unicode, за исключением:

  • большинство управляющих кодов C0 ,
  • постоянно неназначенные кодовые точки D800 – DFFF,
  • FFFE или FFFF.

Символы HTML проявляются либо непосредственно как байты в соответствии с кодировкой документа, если кодировка их поддерживает, либо пользователи могут записывать их как числовые ссылки на символы на основе кодовой точки Unicode символа. Так , например, ссылки &#916;, &#1049;, &#1511;, &#1605;, &#3671;, &#12354;, &#21494;, &#33865;, и &#47568;(или одни и те же числовые значения , выраженные в шестнадцатеричной системе , с в &#xкачестве префикса) должны отображаться во всех браузерах как Δ, Й, ק, م, 7,あ,叶,葉, и 말.

При указании URI , например, в качестве URL-адресов в HTTP- запросах, символы, отличные от ASCII, должны быть закодированы в процентах .

Шрифты [ править ]

Unicode в принципе не имеет отношения к шрифтам как таковым , рассматривая их как варианты реализации. [73] У любого данного символа может быть много аллографов , от более распространенных жирных, курсивных и базовых букв до сложных декоративных стилей. Шрифт является «совместимым с Unicode», если к глифам в шрифте можно получить доступ с помощью кодовых точек, определенных в стандарте Unicode. [74] Стандарт не определяет минимальное количество символов, которое должно быть включено в шрифт; у некоторых шрифтов довольно небольшой репертуар.

Бесплатные и розничные шрифты на основе Unicode широко доступны, поскольку TrueType и OpenType поддерживают Unicode. Эти форматы шрифтов сопоставляют кодовые точки Unicode с глифами, но шрифт TrueType ограничен 65 535 глифами.

На рынке существуют тысячи шрифтов , но менее дюжины шрифтов - иногда называемых «пан-Unicode» шрифтами - пытаются поддерживать большую часть репертуара символов Unicode. Вместо этого шрифты на основе Unicode обычно ориентированы на поддержку только базового ASCII и определенных сценариев или наборов символов или символов. Такой подход оправдан несколькими причинами: приложениям и документам редко требуется отображать символы из более чем одной или двух систем письма; шрифты обычно требуют ресурсов в вычислительной среде; а операционные системы и приложения демонстрируют растущий интеллект в отношении получения информации о глифах из отдельных файлов шрифтов по мере необходимости, т. е. подстановки шрифтов.. Более того, разработка последовательного набора инструкций по рендерингу для десятков тысяч глифов представляет собой грандиозную задачу; такое предприятие проходит точку убывающей отдачи от большинства шрифтов.

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

Unicode частично решает проблему новой строки, которая возникает при попытке прочитать текстовый файл на разных платформах. Unicode определяет большое количество символов, которые соответствующие приложения должны распознавать как терминаторы строки.

Что касается новой строки, Unicode представил U + 2028 LINE SEPARATOR и U + 2029 PARAGRAPH SEPARATOR. . Это была попытка предоставить решение Unicode для семантического кодирования абзацев и строк, потенциально заменяющее все различные решения платформы. При этом Unicode действительно позволяет обойти исторически сложившиеся решения, зависящие от платформы. Тем не менее, немногие, если вообще какие-либо решения Unicode приняли эти разделители строк и абзацев Unicode в качестве единственных канонических символов окончания строки. Однако общий подход к решению этой проблемы - нормализация новой строки. Это достигается с помощью текстовой системы Какао в Mac OS X, а также с помощью рекомендаций W3C XML и HTML. В этом подходе каждый возможный символ новой строки внутренне преобразуется в общий символ новой строки (который на самом деле не имеет значения, поскольку это внутренняя операция только для рендеринга). Другими словами, текстовая система может правильно обрабатывать символ как новую строку,независимо от фактической кодировки ввода.

Проблемы [ править ]

Философская критика и критика полноты [ править ]

Унификация хань (идентификация форм в восточноазиатских языках, которые можно рассматривать как стилистические вариации одного и того же исторического персонажа) стала одним из самых спорных аспектов Unicode, несмотря на присутствие большинства экспертов из всех трех регионов в Группа идеографических исследований (IRG), которая консультирует Консорциум и ISO по дополнениям к репертуару и по объединению ханьцев. [75]

Unicode подвергся критике за то, что он не может отдельно кодировать старые и альтернативные формы кандзи, что, по мнению критиков, усложняет обработку древних японских и необычных японских имен. Часто это происходит из-за того, что Unicode кодирует символы, а не глифы (визуальные представления основного символа, которые часто меняются от одного языка к другому). Объединение глифов приводит к пониманию того, что объединяются сами языки, а не только базовое представление символов. [76] [ требуется разъяснение ]Было предпринято несколько попыток создать альтернативные кодировки, которые сохраняли стилистические различия между китайскими, японскими и корейскими иероглифами в противовес политике Юникода по унификации ханьцев. Примером одного из них является TRON (хотя он не получил широкого распространения в Японии, есть некоторые пользователи, которым необходимо обрабатывать исторические японские тексты и отдавать им предпочтение).

Хотя репертуар из менее чем 21 000 символов хань в самой ранней версии Unicode был в значительной степени ограничен символами, широко используемыми в современном мире, Unicode теперь включает более 92 000 символов хань, и продолжается работа по добавлению еще тысяч исторических и диалектных символов, используемых в Китае. Япония, Корея, Тайвань и Вьетнам.

Современная технология шрифтов предоставляет средства для решения практической проблемы необходимости изобразить унифицированный символ хань в терминах набора альтернативных представлений глифов в форме последовательностей вариантов Unicode . Например, расширенные типографические таблицы OpenType позволяют выбрать одно из ряда альтернативных представлений глифов при выполнении процесса преобразования символа в глиф. В этом случае информация может быть предоставлена ​​в виде обычного текста, чтобы указать, какую альтернативную форму символа выбрать.

Различные кириллические символы с курсивом и без него

Если разница в соответствующих глифах для двух символов в одном и том же скрипте различается только курсивом, Unicode, как правило, унифицировал их, как видно из сравнения между русскими (обозначенными как стандартные) и сербскими символами справа, что означает, что различия отображается с помощью технологии интеллектуальных шрифтов или вручную изменяя шрифты.

Сопоставление с устаревшими наборами символов [ править ]

Unicode был разработан, чтобы обеспечить преобразование формата туда и обратно по кодовым точкам в любые ранее существовавшие кодировки символов и обратно, чтобы текстовые файлы в более старых наборах символов можно было преобразовать в Unicode, а затем вернуться и вернуть тот же файл, без использования контекстно-зависимой интерпретации. Это означает, что несовместимые устаревшие архитектуры, такие как сочетание диакритических знаков и предварительно составленных символов , существуют в Unicode, что дает более одного метода представления некоторого текста. Это наиболее ярко выражено в трех различных формах кодировки корейского хангыля.. Начиная с версии 3.0, любые предварительно составленные символы, которые могут быть представлены последовательностью комбинирования уже существующих символов, больше не могут быть добавлены к стандарту, чтобы сохранить взаимодействие между программным обеспечением, использующим разные версии Unicode.

Между символами в существующих устаревших наборах символов и символами в Unicode должны быть обеспечены инъективные сопоставления, чтобы облегчить преобразование в Unicode и обеспечить взаимодействие с устаревшим программным обеспечением. Отсутствие согласованности в различных сопоставлениях между более ранними японскими кодировками, такими как Shift-JIS или EUC-JP и Unicode, привело к несоответствию преобразования формата туда и обратно , в частности, отображение символа JIS X 0208 '~' (1-33, WAVE DASH) , активно используется в устаревших данных базы данных, либо U + FF5EFULLWIDTH TILDE (в Microsoft Windows ), либо U + 301CWAVE DASH (другие поставщики). [77]

Некоторые японские программисты возражали против Unicode, потому что он требует, чтобы они разделяли использование U + 005C \ REVERSE SOLIDUS (обратная косая черта) и U + 00A5 ¥ YEN SIGN , который был сопоставлен с 0x5C в JIS X 0201, и существует много устаревшего кода. с этим использованием. [78] (Эта кодировка также заменяет тильду '~' 0x7E на макрон '¯', теперь 0xAF.) Разделение этих символов существует в ISO 8859-1 , задолго до появления Unicode.

Индийские скрипты [ править ]

Индийским шрифтам, таким как тамильский и деванагари , выделено только 128 кодовых точек, что соответствует стандарту ISCII . Правильная визуализация индийского текста Unicode требует преобразования сохраненных символов логического порядка в визуальный порядок и формирования лигатур (или конъюнктов) из компонентов. Некоторые местные ученые выступали за присвоение кодовых точек Unicode этим лигатурам, что противоречит практике других систем письма, хотя Unicode содержит некоторые арабские и другие лигатуры только для целей обратной совместимости. [79] [80] [81]Кодирование любых новых лигатур в Unicode не произойдет, отчасти потому, что набор лигатур зависит от шрифта, а Unicode - это кодировка, не зависящая от вариантов шрифта. Такая же проблема возникла для тибетского письма в 2003 году, когда Управление по стандартизации Китая предложило кодировать 956 предварительно составленных тибетских слогов [82], но они были отклонены для кодирования соответствующим комитетом ISO ( ISO / IEC JTC 1 / SC 2 ). [83]

Поддержка тайского алфавита подверглась критике за упорядочение тайских символов. Гласные เ, แ, โ, ใ, ไ, которые пишутся слева от предшествующей согласной, находятся в визуальном порядке, а не в фонетическом порядке, в отличие от представлений Unicode в других индийских алфавитах. Эта сложность связана с тем, что Unicode унаследовал Тайский промышленный стандарт 620 , который работал таким же образом и был способом, которым тайский язык всегда был написан на клавиатуре. Эта проблема упорядочения немного усложняет процесс сопоставления Unicode, требуя поиска в таблице для изменения порядка тайских символов для сопоставления. [76] Даже если бы Unicode принял кодирование в соответствии с порядком произнесения, все равно было бы проблематично сопоставить слова в порядке словаря. Например, слово แสดง [sa dɛːŋ] «выполнять» начинается с группы согласных «สด» (с присущей гласной для согласного «ส»), гласная แ - в устном порядке идет после ด, но в словаре это слово выглядит следующим образом: сопоставлены так, как написано, с гласной после.

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

Символы с диакритическими знаками обычно могут быть представлены либо как один предварительно составленный символ, либо как разложенная последовательность базовой буквы плюс один или несколько знаков без пробелов. Например, ḗ (предварительно составленный e с макроном и акромом выше) и ḗ (e, за которым следует объединение макрона выше и сочетание акта выше) должны отображаться одинаково, оба появляются как e с макроном и акцентом , но на практике их внешний вид может варьироваться в зависимости от того, какой механизм визуализации и шрифты используются для отображения символов. Точно так же, underdots , по мере необходимости в латинизации из Indic , часто будет неправильно размещен. [ необходима цитата ]. Символы Юникода, которые сопоставляются с предварительно составленными глифами, могут использоваться во многих случаях, что позволяет избежать проблемы, но если предварительно составленный символ не был закодирован, проблема часто может быть решена с помощью специального шрифта Unicode, такого как Charis SIL, который использует Graphite , OpenType или Технологии AAT для расширенных функций рендеринга.

Аномалии [ править ]

Стандарт Unicode установил правила, призванные гарантировать стабильность. [84] В зависимости от строгости правила изменение может быть запрещено или разрешено. Например, «имя», данное кодовой точке, не может и не будет изменяться. Но свойство «скрипта» более гибкое по собственным правилам Unicode. В версии 2.0 Unicode изменил многие «имена» кодовых точек по сравнению с версией 1. В тот же момент Unicode заявил, что с этого момента присвоенное имя кодовой точке больше не будет меняться. Это означает, что, когда ошибки публикуются, эти ошибки не могут быть исправлены, даже если они тривиальны (как это произошло в одном случае с орфографической BRAKCET для BRACKETв имени персонажа). В 2006 году был впервые опубликован список аномалий в именах персонажей, и по состоянию на апрель 2017 года насчитывалось 94 символа с выявленными проблемами [85], например:

  • U + 2118 ЗАГЛАВНАЯ СТРАНИЦА P : Это маленькая буква. Капитал U + 1D4AB 𝒫 МАТЕМАТИЧЕСКОЕ SCRIPT КАПИТАЛ Р [86]
  • U + 034F ͏ COMBINING GRAPHEME JOINER : не объединяет графемы. [85]
  • U + A015 YI SYLLABLE WU : Это не слог Yi, а знак итерации Yi.
  • U + FE18 ПРЕЗЕНТАЦИОННАЯ ФОРМА ДЛЯ ВЕРТИКАЛЬНОГО ПРАВОГО БЕЛОГО ЛЕНТИКУЛЯРНОГО ТОРМОЗА : скоба написана неправильно. [87]

Орфографические ошибки устраняются с помощью псевдонимов и сокращений Unicode .

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

  • Сравнение кодировок Unicode
  • Культурные, политические и религиозные символы в Юникоде
  • Международные компоненты для Unicode (ICU), теперь как ICU- TC как часть Unicode
  • Список двоичных кодов
  • Список символов Юникода
  • Список ссылок на символьные сущности XML и HTML
  • Гарнитуры Unicode с открытым исходным кодом
  • Стандарты, относящиеся к Unicode
  • Символы Юникода
  • Универсальный набор кодированных символов
  • Lotus Multi-Byte Character Set (LMBCS), параллельная разработка с аналогичными намерениями

Заметки [ править ]

  1. ^ Консорциум Unicode использует неоднозначный термин байт; Международная организация по стандартизации (ИСО), Международная электротехническая комиссия (МЭК) и Целевая группа Internet Engineering (IETF) использовать более конкретный термин октет в текущих документовсвязанных с Unicode.

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

  1. ^ «Стандарт Unicode: Техническое введение» . Проверено 16 марта 2010 .
  2. ^ «Обзор использования кодировок символов с разбивкой по рейтингам» . w3techs.com . Проверено 9 июня 2020 .
  3. ^ «Соответствие» (PDF) . Стандарт Юникода . Март 2020 . Проверено 15 марта 2020 .
  4. ^ "UAX # 29: Сегментация текста Unicode §3 Границы кластера графемы" . unicode.org . 2020-02-19 . Проверено 27 июня 2020 .
  5. ^ «Unicode - краткое введение (для опытных) • JavaScript для нетерпеливых программистов» . explooringjs.com . Проверено 14 июня 2020 .
  6. ^ «Введение в Unicode» . mathias.gaunard.com . Проверено 14 июня 2020 .
  7. ^ «Строки и символы - язык программирования Swift (Swift 5.2)» . docs.swift.org . Проверено 14 июня 2020 .
  8. ^ «Нарушение наших предположений Latin-1 - В погоне за ленью» . manishearth.github.io . Проверено 14 июня 2020 . Unicode не хотел иметь дело с добавлением новых флагов каждый раз, когда появляется новая страна или территория. Они также не хотят , чтобы попасть в хитром деле определения того , что страна является , например , при работе с спорными территориями. [..] В некоторых китайских системах, например, флаг Тайваня (🇹🇼) может не отображаться.
  9. ^ «Давайте перестанем приписывать смысл кодовым точкам - в погоне за ленью» . manishearth.github.io . Проверено 14 июня 2020 . Люди начинают подразумевать, что кодовые точки что-то значат и что O (1) индексация или нарезка границ кодовых точек - полезная операция.
  10. ^ a b c d e Беккер, Джозеф Д. (10 сентября 1998 г.) [29 августа 1988 г.]. «Юникод 88» (PDF) . unicode.org (переиздание к 10-летию). Консорциум Unicode . Архивировано (PDF) из оригинала 25 ноября 2016 года . Проверено 25 октября 2016 . В 1978 году Боб Белвилл из Xerox PARC сделал первоначальное предложение о наборе «Универсальных знаков» . Многие люди внесли свои идеи в разработку нового дизайна кодирования. Начиная с 1980 года, эти усилия превратились в Стандарт Xerox Character Code Standard. (XCCS) автора, многоязычная кодировка, которая поддерживается Xerox в качестве внутреннего корпоративного стандарта с 1982 года благодаря усилиям Эда Смуры, Рона Пеллара и других.
    Unicode возник в результате восьмилетнего опыта работы с XCCS. Его фундаментальные отличия от XCCS были предложены Питером Фенвиком и Дэйвом Опстадом (чистые 16-битные коды) и Ли Коллинзом (унификация идеографических символов). Unicode сохраняет многие функции XCCS, полезность которых была доказана годами в международных продуктах многоязычных систем связи.
  11. ^ "Краткое изложение" . Проверено 15 марта 2010 .
  12. ^ История выпуска Unicode и дат публикации на unicode.org. Проверено 28 февраля 2017 года.
  13. ^ Сирл, Стивен Дж. «Возвращение к Unicode» . Проверено 18 января 2013 .
  14. ^ a b «Члены Консорциума Unicode» . Проверено 4 января 2019 .
  15. ^ «Таблицы кодов символов» . Проверено 17 марта 2010 .
  16. ^ "Unicode FAQ" . Проверено 2 апреля 2020 .
  17. ^ «Дорожная карта к BMP» . Консорциум Unicode . Проверено 30 июля 2018 .
  18. ^ «Об инициативе по кодированию скриптов» . Консорциум Unicode . Проверено 4 июня 2012 .
  19. ^ «Unicode 14.0 отложен на 6 месяцев» . Проверено 5 мая 2020 .
  20. ^ «Юникод 14.0.0» . www.unicode.org . Проверено 10 февраля 2021 .
  21. ^ «Доступен Unicode 6.1 в мягкой обложке» . announcements_at_unicode.org . Проверено 30 мая 2012 .
  22. ^ «Нумерованные версии стандарта Unicode» . Проверено 21 июня 2016 .
  23. ^ а б в
    • «Юникод версии 1.0» . 1991 г.
    • "1.0.0 / UnicodeData.txt (реконструированный)" . 2004 . Проверено 16 марта 2010 .
  24. ^ a b «Данные Unicode 1.0.1» . Проверено 16 марта 2010 .
  25. ^ а б
    • «Unicode версии 1.1» .
    • «Данные Unicode 1995» . Проверено 16 марта 2010 .
  26. ^ а б
    • «Юникод версии 2.0.0» .
    • «Unicode Data-2.0.14» . Проверено 16 марта 2010 .
  27. ^ а б
    • «Unicode версии 2.1.0» .
    • «Unicode Data-2.1.2» . Проверено 16 марта 2010 .
  28. ^ "Unicode Data-3.0.0" . Проверено 16 марта 2010 .
  29. ^ "Unicode Data-3.1.0" . Проверено 16 марта 2010 .
  30. ^ "Unicode Data-3.2.0" . Проверено 16 марта 2010 .
  31. ^ "Unicode Data-4.0.0" . Проверено 16 марта 2010 .
  32. ^ "Unicode Data-4.1.0" . Проверено 16 марта 2010 .
  33. ^ "Данные Unicode 5.0.0" . Проверено 17 марта 2010 .
  34. ^ "Данные Unicode 5.1.0" . Проверено 17 марта 2010 .
  35. ^ «Данные Unicode 5.2.0» . Проверено 17 марта 2010 .
  36. ^ «Данные Unicode 6.0.0» . Проверено 11 октября 2010 .
  37. ^ «Данные Unicode 6.1.0» . Проверено 31 января 2012 .
  38. ^ «Данные Unicode 6.2.0» . Проверено 26 сентября 2012 .
  39. ^ «Данные Unicode 6.3.0» . Проверено 30 сентября 2013 .
  40. ^ «Данные Unicode 7.0.0» . Проверено 15 июня 2014 .
  41. ^ «Юникод 8.0.0» . Консорциум Unicode . Проверено 17 июня 2015 .
  42. ^ «Данные Unicode 8.0.0» . Проверено 17 июня 2015 .
  43. ^ «Юникод 9.0.0» . Консорциум Unicode . Проверено 21 июня 2016 .
  44. ^ «Данные Unicode 9.0.0» . Проверено 21 июня 2016 .
  45. ^ Лобао, Martim (2016-06-07). «Это два эмодзи, которые не были одобрены для Unicode 9, но которые Google все равно добавил в Android» . Android Police . Проверено 4 сентября 2016 .
  46. ^ «Юникод 10.0.0» . Консорциум Unicode . Проверено 20 июня 2017 .
  47. ^ «Стандарт Unicode, версия 11.0.0, приложение C» (PDF) . Консорциум Unicode . Проверено 11 июня 2018 .
  48. ^ «Объявление стандарта Unicode версии 11.0» . blog.unicode.org . Проверено 6 июня 2018 .
  49. ^ «Стандарт Unicode, версия 12.0.0, приложение C» (PDF) . Консорциум Unicode . Проверено 5 марта 2019 .
  50. ^ «Объявление стандарта Unicode версии 12.0» . blog.unicode.org . Проверено 5 марта 2019 .
  51. ^ «Версия 12.1 Unicode выпущена в поддержку эпохи Рейва» . blog.unicode.org . Проверено 7 мая 2019 .
  52. ^ а б
    • «Юникод 13.0.0» .
    • «Объявление стандарта Unicode версии 13.0» . blog.unicode.org . Проверено 11 марта 2020 .
  53. ^ «Стандарт Unicode, версия 13.0 - Приложение C основной спецификации» (PDF) . Консорциум Unicode . Проверено 11 марта 2020 .
  54. ^ «Глоссарий терминов Unicode» . Проверено 16 марта 2010 .
  55. ^ «3.4 Символы и кодировка». Стандарт Unicode, версия 13.0 (PDF) . 2019. стр. 19.
  56. ^ «2.4 Кодовые точки и символы». Стандартная версия Unicode 12.0 - основная спецификация (PDF) . 2019. стр. 29.
  57. ^ «Приложение A: Условные обозначения» (PDF) . Стандарт Юникода . Консорциум Unicode. Март 2020. В соответствии с маркированным списком , относящимся к Unicode в MOS: ALLCAPS , формальные имена Unicode в этом абзаце не используются.
  58. ^ a b «Политика стабильности кодировки символов Unicode» . Проверено 16 марта 2010 .
  59. ^ «Свойства» (PDF) . Проверено 15 марта 2020 .
  60. ^ "Модель кодировки символов Юникода" . Проверено 16 марта 2010 .
  61. ^ «Именованные последовательности Unicode» . Проверено 16 марта 2010 .
  62. ^ "Псевдонимы Юникода" . Проверено 16 марта 2010 .
  63. ^ CWA 13873: 2000 - Многоязычные европейские подмножества в ISO / IEC 10646-1 Соглашение о семинаре CEN 13873
  64. ^ Обоснование многоязычного европейского набора символов 2 (MES-2) , Маркус Кун , 1998
  65. ^ "UTF-8, UTF-16, UTF-32 и спецификация" . Unicode.org FAQ . Проверено 12 декабря 2016 .
  66. ^ Стандарт Unicode, версия 6.2 . Консорциум Unicode. 2013. с. 561. ISBN. 978-1-936213-08-5.
  67. ^ Пайк, Роб (2003-04-30). «История UTF-8» .
  68. ^ "ISO / IEC JTC1 / SC 18 / WG 9 N" (PDF) . Проверено 4 июня 2012 .
  69. ^ Хедли, Джонатан (2009). «Поиск в Юникоде» .
  70. ^ Milde, Бенджамин (2011). «Распознавание символов Юникода» .
  71. ^ Вуд, Алан. «Настройка Windows Internet Explorer 5, 5.5 и 6 для многоязычной поддержки и поддержки Unicode» . Алан Вуд . Проверено 4 июня 2012 .
  72. ^ «Расширяемый язык разметки (XML) 1.1 (второе издание)» . Проверено 1 ноября 2013 .
  73. ^ Бигелоу, Чарльз; Холмс, Крис (сентябрь 1993 г.). «Дизайн шрифта Unicode» (PDF) . Электронное издательство . VOL. 6 (3), 289–305: 292.
  74. ^ «Шрифты и клавиатуры» . Консорциум Unicode. 2017-06-28 . Проверено 13 октября 2019 .
  75. ^ Краткая история кодов символов , Стивен Дж. Сирл, первоначально написано в 1999 г. , последнее обновление - в 2004 г.
  76. ^ a b Тайная жизнь Unicode: взгляд на мягкую изнанку Unicode , Сюзанна Топпинг, 1 мая 2001 г. (Интернет-архив)
  77. ^ Вклад AFII о WAVE DASH , «Таблица символов Unicode для японского языка» . web.archive.org . 2011-04-22. Архивировано из оригинала на 2011-04-22.
  78. ^ ISO 646- * Проблема , раздел 4.4.3.5 Введение в I18n , Томохиро КУБОТА, 2001
  79. ^ "Арабские формы представления-A" (PDF) . Проверено 20 марта 2010 .
  80. ^ "Арабские формы представления-B" (PDF) . Проверено 20 марта 2010 .
  81. ^ "Алфавитные формы представления" (PDF) . Проверено 20 марта 2010 .
  82. ^ Китай (2002-12-02). «Предложение по кодированию тибетских символов BrdaRten для ISO / IEC 10646 в BMP» (PDF) .
  83. ^ VS Umamaheswaran (2003-11-07). «Резолюции заседания 44 РГ 2» (PDF) . Резолюция M44.20.
  84. ^ Политика стабильности Unicode
  85. ^ a b «Техническое примечание Unicode № 27: Известные аномалии в именах символов Unicode» . unicode.org . 2017-04-10.
  86. ^ Диаграмма Unicode: «на самом деле это каллиграфическая строчная буква p, несмотря на название»
  87. ^ "Ошибочное написание BRACKET в имени символа является известным дефектом"

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

  • Стандарт Unicode, версия 3.0 , Консорциум Unicode, Addison-Wesley Longman, Inc., апрель 2000 г. ISBN 0-201-61633-5 
  • Стандарт Unicode, версия 4.0 , Консорциум Unicode, Addison-Wesley Professional, 27 августа 2003 г. ISBN 0-321-18578-1 
  • Стандарт Unicode, версия 5.0, пятое издание , Консорциум Unicode , Addison-Wesley Professional, 27 октября 2006 г. ISBN 0-321-48091-0 
  • Джули Д. Аллен. Стандарт Unicode, версия 6.0 , Консорциум Unicode , Mountain View, 2011, ISBN 9781936213016 , ( [1] ). 
  • «Полное руководство по типографике» , Джеймс Феличи, Adobe Press; 1-е издание, 2002 г. ISBN 0-321-12730-7 
  • Юникод: Букварь , Тони Грэм, книги M&T, 2000. ISBN 0-7645-4625-2 . 
  • Демистификация Unicode: Практическое руководство программиста по стандарту кодирования , Ричард Гиллам, Addison-Wesley Professional; 1-е издание, 2002 г. ISBN 0-201-70052-2 
  • Unicode Explained , Юкка К. Корпела, O'Reilly; 1-е издание, 2006 г. ISBN 0-596-10121-X 
  • Яннис Хараламбус; Мартин Дюрст (2019). «Юникод с лингвистической точки зрения». В Хараламбусе, Яннис (ред.). Труды графемики XXI века, Брест 2018 . Брест: Издания Fluxus. С. 167–183. ISBN 978-2-9570549-1-6.

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

  • Официальный сайт · Официальный технический сайт  
  • Юникод в Керли
  • Ресурсы Unicode Алана Вуда  - содержат списки текстовых процессоров с поддержкой Unicode; шрифты и символы сгруппированы по типу; символы представлены списками, а не сетками.
  • Резервный шрифт Unicode BMP  - отображает значение Unicode любого символа в документе, в том числе в области частного использования, а не сам глиф.