Unicode , формально Стандарт Unicode , [примечание 1] — это стандарт кодирования текста , поддерживаемый Консорциумом Unicode , предназначенный для поддержки использования текста, написанного во всех основных системах письма мира . Версия 15.1 стандарта [A] определяет149 813 символов [3] и 161 шрифт, используемый в различных обычных, литературных, академических и технических контекстах.
Многие распространенные символы, включая цифры, знаки препинания и другие символы, унифицированы в рамках стандарта и не рассматриваются как специфичные для какой-либо конкретной системы письма. Unicode кодирует тысячи эмодзи , и Консорциум постоянно занимается их разработкой в рамках стандарта. [4] Более того, широкое распространение Unicode во многом стало причиной первоначальной популяризации эмодзи за пределами Японии . В конечном итоге Unicode способен кодировать более 1,1 миллиона символов.
Unicode в значительной степени вытеснил предыдущую среду с множеством несовместимых наборов символов , каждый из которых использовался в разных регионах и на разных компьютерных архитектурах. Юникод используется для кодирования подавляющего большинства текста в Интернете, включая большинство веб-страниц , и соответствующая поддержка Юникод стала обычным явлением при разработке современного программного обеспечения.
Репертуар символов Юникода синхронизирован с ISO/IEC 10646 , каждый из которых полностью идентичен друг другу. Однако стандарт Unicode — это больше, чем просто набор символов, в котором назначаются символы. В помощь разработчикам и дизайнерам стандарт также предоставляет диаграммы и справочные данные, а также приложения, объясняющие концепции, относящиеся к различным сценариям, и дающие рекомендации по их реализации. Темы, охватываемые этими приложениями, включают нормализацию символов , композицию и декомпозицию символов , сопоставление и направленность . [5]
Текст Unicode обрабатывается и сохраняется в виде двоичных данных с использованием одной из нескольких кодировок , которые определяют, как преобразовать абстрактные коды стандарта для символов в последовательности байтов. Сам стандарт Unicode определяет три кодировки: UTF-8 , UTF-16 и UTF-32 , хотя существует и несколько других. Из них UTF-8 с большим отрывом используется наиболее широко, отчасти из-за его обратной совместимости с ASCII .
Первоначально Unicode был разработан с намерением преодолеть ограничения, присутствующие во всех текстовых кодировках, разработанных до этого момента: каждая кодировка использовалась для использования в своем собственном контексте, но без особых ожиданий совместимости с какой-либо другой. Действительно, любые две выбранные кодировки часто оказывались совершенно неработоспособными при совместном использовании: текст, закодированный в одной, интерпретировался другой как мусорные символы . Большинство кодировок были разработаны только для облегчения взаимодействия между несколькими сценариями - часто в первую очередь между данным сценарием и латинскими символами - а не между большим количеством сценариев и не для того, чтобы все поддерживаемые сценарии обрабатывались единообразно.
Философия, лежащая в основе Unicode, направлена на кодирование основных символов — графем и графемоподобных единиц — а не графических различий, рассматриваемых как простые варианты глифов , которые вместо этого лучше всего обрабатываются с помощью шрифта , использования разметки или каких-либо других средств. В особенно сложных случаях, таких как трактовка орфографических вариантов ханьских иероглифов , существуют значительные разногласия относительно того, какие различия оправдывают их собственные кодировки, а какие являются лишь графическими вариантами других иероглифов.
На самом абстрактном уровне Unicode присваивает каждому символу уникальный номер, называемый кодовой точкой . Многие вопросы визуального представления, включая размер, форму и стиль, должны решаться на усмотрение программного обеспечения, фактически отображающего текст, например веб-браузера или текстового процессора . Однако, отчасти с целью стимулирования быстрого внедрения, простота этой исходной модели со временем стала несколько более сложной, и в ходе разработки стандарта были сделаны различные прагматические уступки.
Первые 256 кодовых точек соответствуют стандарту ISO/IEC 8859-1 с целью упростить преобразование текста, уже написанного западноевропейскими алфавитами. Чтобы сохранить различия, сделанные различными устаревшими кодировками, и, следовательно, обеспечить преобразование между ними и Unicode без какой-либо потери информации, многим символам, почти идентичным другим , как по внешнему виду, так и по назначению, были присвоены отдельные кодовые точки. Например, блок «Формы половинной и полной ширины» включает в себя полную семантическую копию латинского алфавита, поскольку устаревшие кодировки CJK содержали символы как «полной ширины» (соответствующие ширине символов CJK), так и «полуширинные» (соответствующие обычному латинскому алфавиту).
Премия Unicode Bulldog Award вручается людям, оказавшим влияние на развитие Unicode, в число ее лауреатов входят Тацуо Кобаяши , Томас Майло, Рузбе Пурнадер , Кен Лунде и Майкл Эверсон . [6]
Истоки Unicode можно проследить до 1980-х годов, когда группа людей была связана со стандартом кодировки символов Xerox ( XCCS). [7] В 1987 году сотрудник Xerox Джо Беккер вместе с сотрудниками Apple Ли Коллинзом и Марком Дэвисом начали исследовать практические аспекты создания универсального набора символов. [8] При дополнительном вкладе Питера Фенвика и Дэйва Опстада , [7] Беккер опубликовал в августе 1988 года проект предложения по «международной/многоязычной системе кодирования текстовых символов, предварительно названной Unicode». Он пояснил, что «название «Юникод» призвано означать уникальную, унифицированную, универсальную кодировку». [7]
В этом документе, озаглавленном Unicode 88 , Беккер обрисовал схему с использованием 16-битных символов: [7]
Юникод предназначен для удовлетворения потребности в работоспособной и надежной кодировке мирового текста. Юникод можно грубо описать как «широкий ASCII », расширенный до 16 бит, чтобы охватить символы всех живых языков мира. В правильно спроектированном проекте 16 бит на символ более чем достаточно для этой цели.
Это проектное решение было принято на основе предположения, что только сценарии и символы «современного» использования потребуют кодирования: [7]
Unicode отдает более высокий приоритет обеспечению полезности в будущем, чем сохранению прошлых древностей. Юникод нацелен в первую очередь на символы, опубликованные в современном тексте (например, в объединении всех газет и журналов, напечатанных в мире в 1988 году), число которых, несомненно, намного меньше 2 14 = 16 384. Помимо этих современных символов, все остальные могут быть определены как устаревшие или редкие; они лучше подходят для регистрации для частного использования, чем для перегрузки общедоступного списка вообще полезного Unicode.
В начале 1989 года рабочая группа Unicode расширилась, включив в нее Кена Уистлера и Майка Кернагана из Metaphor, Карен Смит-Йошимура и Джоан Алипранд из Research Libraries Group , а также Гленна Райта из Sun Microsystems . В 1990 году к группе также присоединились Мишель Суйнар и Асмус Фрейтаг из Microsoft и Рик Макгоуэн из NeXT . К концу 1990 года большая часть работы по переназначению существующих стандартов была завершена, и окончательный обзорный проект Unicode был готов.
Консорциум Unicode был зарегистрирован в Калифорнии 3 января 1991 года [9] , а в октябре того же года был опубликован первый том Стандарта Unicode . Второй том, в который теперь добавлены иероглифы Хань, был опубликован в июне 1992 года.
В 1996 году в Unicode 2.0 был реализован механизм суррогатных символов, так что Unicode больше не ограничивался 16 битами. Это увеличило кодовое пространство Unicode до более чем миллиона кодовых точек, что позволило кодировать многие исторические письменности, такие как египетские иероглифы , а также тысячи редко используемых или устаревших символов, включение которых в стандарт не предполагалось. Среди этих символов есть различные редко используемые символы CJK, многие из которых в основном используются в именах собственных, что делает их гораздо более необходимыми для универсального кодирования, чем предполагала исходная архитектура Unicode. [10]
Версия 1.0 спецификации Microsoft TrueType, опубликованная в 1992 году, использовала имя «Apple Unicode» вместо «Unicode» для идентификатора платформы в таблице имен.
Консорциум Unicode — это некоммерческая организация, которая координирует развитие Unicode. Полноправными членами являются большинство основных компаний, занимающихся компьютерным программным обеспечением и оборудованием (и некоторые другие), проявляющие интерес к стандартам обработки текста, включая Adobe , Apple , Google , IBM , Meta (ранее Facebook), Microsoft , Netflix и SAP . [11]
На протяжении многих лет несколько стран или правительственных учреждений были членами Консорциума Unicode. В настоящее время только Министерство пожертвований и по делам религии (Оман) является полноправным членом с правом голоса. [11]
Консорциум ставит перед собой амбициозную цель - в конечном итоге заменить существующие схемы кодировки символов на Unicode и его стандартные схемы формата преобразования Unicode (UTF), поскольку многие из существующих схем ограничены по размеру и объему и несовместимы с многоязычными средами.
В настоящее время Unicode охватывает большинство основных систем письма, используемых сегодня. [12] [ нужен лучший источник ]
По состоянию на 2024 год в последнюю версию Юникода включен в [обновлять]общей сложности 161 алфавит [13] (охватывающий алфавиты , абугиды и слоговые письма ), хотя все еще существуют скрипты, которые еще не закодированы, особенно те, которые в основном используются в исторических, литургических и слоговых письмах. академические контексты. Происходят и дальнейшие дополнения символов к уже закодированным сценариям, а также символов, в частности для математики и музыки (в виде нот и ритмических символов).
Комитет по дорожной карте Unicode ( Майкл Эверсон , Рик Макгоуэн, Кен Уистлер, В.С. Умамахесваран) [14] поддерживает список сценариев, которые являются кандидатами или потенциальными кандидатами на кодирование, а также их предварительные назначения кодовых блоков на странице дорожной карты Unicode [15] Unicode. Сайт консорциума . Для некоторых сценариев, включенных в «Дорожную карту», таких как чжурчжэньский и киданьский большой сценарий , были сделаны предложения по кодированию, и они проходят процесс утверждения. По другим сценариям, таким как Mayan (кроме чисел) и Rongorongo , предложений пока не поступало, и они ждут согласия по репертуару персонажей и других деталей от участвующих сообществ пользователей.
Некоторые современные изобретенные сценарии, которые еще не включены в Unicode (например, Tengwar ) или которые не подходят для включения в Unicode из-за отсутствия реального использования (например, Klingon ), перечислены в реестре Unicode ConScript вместе с неофициальными но широко используемые присвоения кодов зон частного использования .
Существует также инициатива по созданию средневековых шрифтов Unicode, ориентированная на специальные латинские средневековые символы. Часть этих предложений уже включена в Unicode.
Инициатива по кодированию сценариев, [16] проект, реализуемый Деборой Андерсон из Калифорнийского университета в Беркли, был основан в 2002 году с целью финансирования предложений по сценариям, еще не закодированным в стандарте. В последние годы этот проект стал основным источником предлагаемых дополнений к стандарту. [17]
Консорциум Unicode вместе с ISO разработал общий репертуар после первой публикации Стандарта Unicode : Unicode и универсальный набор кодированных символов (UCS) ISO используют идентичные имена символов и кодовые точки. Однако версии Unicode отличаются от своих эквивалентов ISO по двум важным аспектам.
Хотя UCS представляет собой простую карту символов, Unicode определяет правила, алгоритмы и свойства, необходимые для обеспечения совместимости между различными платформами и языками. Таким образом, стандарт Unicode включает дополнительную информацию, охватывающую такие глубокие темы, как побитовое кодирование, сопоставление и рендеринг. Он также предоставляет полный каталог свойств символов, в том числе тех, которые необходимы для поддержки двунаправленного текста , а также визуальные диаграммы и наборы справочных данных для помощи разработчикам. Ранее «Стандарт Юникод» продавался в печатном виде, содержащем полную базовую спецификацию, стандартные приложения, [примечание 2] и таблицы кодов. Однако версия 5.0, опубликованная в 2006 году, была последней версией, напечатанной таким образом. Начиная с версии 5.2, можно приобрести только базовую спецификацию, опубликованную в мягкой обложке для печати по запросу. [18] Полный текст, с другой стороны, публикуется в виде бесплатного PDF-файла на веб-сайте Unicode.
Практическая причина использования этого метода публикации подчеркивает второе существенное различие между UCS и Unicode — частоту выпуска обновленных версий и добавления новых символов. Стандарт Unicode регулярно выпускает ежегодные расширенные версии, иногда в течение календарного года выпускалось более одной версии, а в редких случаях запланированный выпуск приходилось откладывать. Например, в апреле 2020 года, через месяц после публикации версии 13.0, Консорциум Unicode объявил, что изменил предполагаемую дату выпуска версии 14.0, перенеся ее на шесть месяцев назад, на сентябрь 2021 года, из-за пандемии COVID-19 .
Последняя версия Unicode 15.1 была выпущена 12 сентября 2023 года. Это незначительное обновление версии 15.0, выпущенной 13 сентября 2022 года, в котором добавлено в общей сложности 4489 новых символов, включая два новых сценария, расширение CJK Unified. Блок иероглифов и множественные дополнения к существующим блокам. Было добавлено 33 новых смайлика, таких как символ « беспроводной связи » (сети) и дополнительные цветные сердечки. [19] [20]
На данный момент опубликованы следующие версии стандарта Unicode . Версии обновлений, которые не включают никаких изменений в репертуаре персонажей, обозначаются третьим номером (например, «версия 4.0.1») и опускаются в таблице ниже. [21]
Консорциум Unicode обычно выпускает новую версию стандарта Unicode один раз в год, а иногда и два раза в год. Версию 16.0, следующую основную версию, планируется опубликовать в 2024 году. Предполагается, что она будет включать шесть новых алфавитов ( Тодхри , Сунувар , Гурунг Кхема , Кират Рай , Гарай и Ол Онал ), дополнительные бирманские цифры для алфавитов Шан и Мон. , дополнительные символы для устаревших компьютеров и как минимум шесть новых смайлов. [56] [57]
Стандарт Unicode определяет кодовое пространство : [58] последовательность целых чисел, называемых кодовыми точками [59], охватывающую интервал , обозначенный в соответствии со стандартом как U+0000 – U+10FFFF . [60] Кодовое пространство представляет собой систематическое, независимое от архитектуры представление стандарта Unicode ; Фактический текст обрабатывается как двоичные данные с помощью одной из нескольких кодировок Unicode, например UTF-8 .
В этой нормативной записи двухсимвольный префикс U+всегда предшествует написанной кодовой точке [61] , а сами кодовые точки записываются как шестнадцатеричные числа. Всегда записываются не менее четырех шестнадцатеричных цифр, при необходимости перед ними добавляются ведущие нули . Например, кодовая точка U+00F7 ÷ ЗНАК ДЕЛЕНИЯ дополняется двумя ведущими нулями, а U+13254 𓉔 ЕГИПЕТСКИЙ ИЕРОГЛИФ O004 ( 
) не дополняется. [62]
Всего их 2 20 + (2 16 − 2 11 ) =1 112 064 действительных кодовых точки в кодовом пространстве. (Это число возникает из-за ограничений кодировки символов UTF-16 , которая может кодировать 2 16 кодовых точек в диапазоне от U+0000 до U+FFFF, за исключением 2 11 кодовых точек в диапазоне от U+D800 до U+DFFF. , которые используются в качестве суррогатных пар для кодирования 2 20 кодовых точек в диапазоне от U+10000 до U+10FFFF .)
Кодовое пространство Юникода разделено на 17 плоскостей , пронумерованных от 0 до 16. Плоскость 0 — это базовая многоязычная плоскость (BMP), содержащая наиболее часто используемые символы. Доступ ко всем кодовым точкам в BMP осуществляется как одна кодовая единица в кодировке UTF-16 и может быть закодирована одним, двумя или тремя байтами в UTF-8. Кодовые точки в плоскостях с 1 по 16 ( дополнительные плоскости ) доступны как суррогатные пары в UTF-16 и кодируются четырьмя байтами в UTF-8 .
Внутри каждой плоскости символы распределяются внутри именованных блоков связанных символов. Размер блока всегда кратен 16 и часто кратен 128, но в остальном он произволен. Символы, необходимые для данного сценария, могут быть распределены по нескольким различным, потенциально непересекающимся блокам внутри кодового пространства.
Каждой кодовой точке присваивается классификация, указанная в качестве свойства «Общая категория » кодовой точки . Здесь на самом верхнем уровне кодовые точки относятся к одной из следующих категорий: буква, знак, цифра, пунктуация, символ, разделитель или другое. В каждой категории каждая кодовая точка затем подразделяется на подкатегории. В большинстве случаев для адекватного описания всех характеристик любой кодовой точки необходимо использовать другие свойства.
The 1024 точки в диапазоне U+D800 – U+DBFF известны как кодовые точки с высоким суррогатным кодом, а кодовые точки в диапазоне U+DC00 – U+DFFF (1024 кодовых точки) известны как кодовые точки с низким суррогатным кодом. Кодовая точка с высоким суррогатным кодом, за которой следует кодовая точка с низким уровнем суррогатного кода, образует суррогатную пару в UTF-16 для представления кодовых точек, превышающих U+FFFF . В принципе, эти кодовые точки нельзя использовать иначе, хотя на практике это правило часто игнорируется, особенно если не используется UTF-16.
Небольшой набор кодовых точек гарантированно никогда не будет присвоен персонажам, хотя третьи стороны могут использовать их самостоятельно по своему усмотрению. Всего таких несимволов 66 : U+FDD0 – U+FDEF и две последние кодовые точки в каждой из 17 плоскостей (например, U+FFFE , U+FFFF , U+1FFFE , U+1FFFF , ..., U+ 10FFFE , U+10FFFF ). Набор несимволов стабилен, и никакие новые несимволы никогда не будут определены. [63] Как и в случае с суррогатами, правило, согласно которому их нельзя использовать, часто игнорируется, хотя операция обозначения порядка байтов предполагает, что U+FFFE никогда не будет первой кодовой точкой в тексте. Исключение суррогатных и неперсонажных листьевДля использования доступно 1 111 998 кодовых точек.
Кодовые точки частного использования считаются назначенными, но они намеренно не имеют интерпретации, определенной Стандартом Unicode [64], так что любой обмен такими кодовыми точками требует независимого соглашения между отправителем и получателем относительно их интерпретации. В кодовом пространстве Unicode есть три области частного использования:
Графические символы — это те, которые определены стандартом Unicode как имеющие определенную семантику, либо имеющие видимую форму глифа , либо представляющие видимое пространство. Начиная с Unicode 15.1, существуют149 641 графический символ.
Символы формата — это символы, которые не имеют видимого внешнего вида, но могут влиять на внешний вид или поведение соседних символов. Например, U+200C ZERO WIDTH NON-JOINER и U+200D ZERO WIDTH JOINER могут использоваться для изменения поведения формирования соседних символов по умолчанию (например, для запрета лигатур или запроса формирования лигатуры). В Юникоде 15.1 имеется 172 символа формата.
65 кодовых точек, диапазоны U+0000 – U+001F и U+007F – U+009F , зарезервированы как коды управления , соответствующие кодам управления C0 и C1, как определено в ISO/IEC 6429 . U+0089 LINE TABULATION , U+008A LINE FEED и U+000D CARRIAGE RETURN широко используются в текстах, использующих Unicode. В результате явления, известного как моджибаке , кодовые точки C1 неправильно декодируются в соответствии с кодовой страницей Windows-1252 , ранее широко используемой в контекстах Западной Европы.
Вместе графические символы, символы формата, управляющего кода и символы частного использования называются назначенными символами . Зарезервированные кодовые точки — это те кодовые точки, которые действительны и доступны для использования, но еще не назначены. Начиная с Unicode 15.1, существуют824 652 зарезервированных кодовых точки.
Набор графических и форматных символов, определенных в Юникоде, не соответствует напрямую репертуару абстрактных символов, представленных в Юникоде. Юникод кодирует символы, связывая абстрактный символ с определенной кодовой точкой. [65] Однако не все абстрактные символы кодируются как один символ Юникода, а некоторые абстрактные символы могут быть представлены в Юникоде последовательностью из двух или более символов. Например, латинская строчная буква «i» с огонеком , точкой над ней и острым ударением , необходимая в литовском языке , представлена последовательностью символов U+012F ; U + 0307 ; U + 0301 . Unicode поддерживает список последовательностей символов с уникальными именами для абстрактных символов, которые не закодированы напрямую в Unicode. [66]
Все назначенные персонажи имеют уникальное и неизменяемое имя, по которому они идентифицируются. Эта неизменность гарантируется начиная с версии 2.0 стандарта Unicode в соответствии с политикой стабильности имен. [63] В случаях, когда имя серьезно дефектно и вводит в заблуждение или содержит серьезную опечатку, может быть определен формальный псевдоним, который приложениям рекомендуется использовать вместо официального имени персонажа. Например, U+A015 ꀕ YI SYLLABLE WU имеет формальный псевдоним YI SYLLABLE ITERATION MARK , а U+FE18 ︘ ФОРМА ПРЕДСТАВЛЕНИЯ ДЛЯ ВЕРТИКАЛЬНОГО ПРАВОГО БЕЛОГО ЛЕНТИКУЛЯРНОГО БЮСТГЕЛЯ KC ET ( sic ) имеет формальный псевдоним ПРЕЗЕНТАЦИОННАЯ ФОРМА ДЛЯ ВЕРТИКАЛЬНОГО ПРАВОГО БЕЛОГО ЛЕНТИКУЛЯРНОГО БЮСТГАЛЬЦА CK ЭТ . [67]
Unicode включает механизм изменения символов, который значительно расширяет поддерживаемый набор глифов. Сюда относится использование комбинации диакритических знаков , которые могут быть добавлены пользователем после основного символа. К одному и тому же символу можно одновременно применять несколько комбинированных диакритических знаков. Юникод также содержит заранее составленные версии большинства комбинаций букв и диакритических знаков, используемых при обычном использовании. Они упрощают преобразование в устаревшие кодировки и обратно и позволяют приложениям использовать Unicode в качестве внутреннего текстового формата без необходимости реализации объединения символов. Например, éв Юникоде может быть представлено как U+0065 e ЛАТИНСКАЯ СТРОЧНАЯ БУКВА E, за которой следует U+0301 ◌́ КОМБИНИРОВАНИЕ ОСТРОГО АКЦЕНТА ), и, что эквивалентно, как заранее составленный символ U+00E9 é ЛАТИНСКАЯ СТРОЧНАЯ БУКВА E С ОСТРЫМ . Таким образом, пользователи часто имеют несколько эквивалентных способов кодирования одного и того же символа. Механизм канонической эквивалентности в стандарте Unicode обеспечивает практическую взаимозаменяемость этих эквивалентных кодировок.
Примером этого является корейский алфавит хангыль : Unicode предоставляет механизм для составления слогов хангыль из их отдельных подкомпонентов хангыль Джамо . Однако оно также обеспечивает11 172 комбинации предсложных слогов, составленных из самого распространенного джамо.
Символы CJK в настоящее время имеют коды только для несоставных радикалов и заранее составленных форм. Большинство символов хань были либо намеренно составлены из более простых орфографических элементов, называемых радикалами , либо реконструированы как композиции из них, поэтому в принципе Unicode мог бы обеспечить их композицию, как это произошло с хангылем. Хотя это могло бы значительно сократить количество необходимых кодовых точек, а также позволить алгоритмический синтез множества произвольных новых символов, сложность этимологии символов и апостериорный характер радикальных систем добавляют огромную сложность предложению. Действительно, попытки разработать кодировки CJK на основе составления радикалов столкнулись с трудностями, связанными с тем фактом, что китайские иероглифы не разлагаются так просто и регулярно, как хангыль.
Блоку CJK Radicals Supplement присвоен диапазон U+2E80 – U+2EFF , а радикалам Канси присвоены U+2F00 – U+2FDF . Блок последовательностей идеографического описания охватывает диапазон U+2FF0 – U+2FFB , но стандарт Unicode предостерегает от использования его символов в качестве альтернативного представления символов, закодированных в другом месте:
Этот процесс отличается от формального кодирования идеограммы. Канонического описания незакодированных иероглифов не существует; описанным иероглифам не приписана семантика; для описанных иероглифов не определена эквивалентность. Концептуально идеографические описания больше похожи на английскую фразу «е» с острым ударением», чем на последовательность символов <U+0065, U+0301>.
Многие сценарии, в том числе арабский и деванагари , имеют особые орфографические правила, которые требуют объединения определенных комбинаций букв в специальные лигатурные формы . Правила, регулирующие формирование лигатур, могут быть довольно сложными и требуют специальных технологий формирования шрифтов, таких как ACE (арабская каллиграфическая машина от DecoType в 1980-х годах, которая использовалась для создания всех арабских примеров в печатных изданиях The Unicode Standard ), что стало доказательством концепции OpenType (от Adobe и Microsoft), Graphite ( от SIL International ) или AAT (от Apple).
В шрифты также встроены инструкции, сообщающие операционной системе, как правильно выводить различные последовательности символов. Простое решение для размещения комбинированных знаков или диакритических знаков — это присвоение знакам нулевой ширины и размещение самого глифа слева или справа от левого бокового подшипника (в зависимости от направления письма, в котором они предназначены для использования). Метка, обработанная таким образом, появится поверх любого символа, предшествующего ей, но не изменит свое положение относительно ширины или высоты базового глифа; это может быть визуально неудобно и может перекрывать некоторые глифы. Реальное наложение невозможно, но в ограниченных случаях его можно аппроксимировать (например, тайские верхние гласные и знаки тона могут изначально находиться на разной высоте). Как правило, этот подход эффективен только для моноширинных шрифтов, но может использоваться в качестве запасного метода рендеринга, когда более сложные методы не работают.
Несколько подмножеств Unicode стандартизированы: Microsoft Windows, начиная с Windows NT 4.0, поддерживает WGL-4 с 657 символами, который, как считается, поддерживает все современные европейские языки, использующие латинский, греческий или кириллический алфавит. Другие стандартизированные подмножества Unicode включают многоязычные европейские подмножества: [69] MES-1 (только латиница, 335 символов), MES-2 (1062 латинских, греческих и кириллических символов) [70] и MES-3A и MES-3B. (два больших подмножества здесь не показаны). MES-2 включает в себя все символы MES-1 и WGL-4.
Стандарт DIN 91379 [71] определяет подмножество букв Юникода, специальных символов, а также последовательностей букв и диакритических знаков, чтобы обеспечить правильное представление имен и упростить обмен данными в Европе. Этот стандарт поддерживает все официальные языки всех стран Европейского Союза, а также языки немецких меньшинств и официальные языки Исландии, Лихтенштейна, Норвегии и Швейцарии. Для возможности транслитерации имен в других системах письма на латиницу согласно соответствующим стандартам ISO предусмотрены все необходимые комбинации основных букв и диакритических знаков.
Программное обеспечение рендеринга, которое не может правильно обработать символ Юникода, часто отображает его как открытый прямоугольник или как U + FFFD , чтобы указать положение нераспознанного символа. Некоторые системы предприняли попытки предоставить больше информации о таких персонажах. Шрифт Last Resort от Apple отобразит заменяющий глиф, указывающий диапазон символов в Юникоде, а резервный шрифт Юникода от SIL International отобразит поле, показывающее шестнадцатеричное скалярное значение символа.
Было определено несколько механизмов для хранения серии кодовых точек в виде серии байтов.
Юникод определяет два метода сопоставления: кодировки формата преобразования Юникода (UTF) и кодировки универсального набора кодированных символов (UCS). Кодировка отображает (возможно, подмножество) диапазон кодовых точек Юникода в последовательности значений в некотором диапазоне фиксированного размера, называемом кодовыми единицами . Все кодировки UTF сопоставляют кодовые точки с уникальной последовательностью байтов. [72] Цифры в названиях кодировок указывают количество битов на единицу кода (для кодировок UTF) или количество байтов на единицу кода (для кодировок UCS и UTF-1 ). UTF-8 и UTF-16 — наиболее часто используемые кодировки. UCS-2 — устаревшее подмножество UTF-16; UCS-4 и UTF-32 функционально эквивалентны.
Кодировки UTF включают в себя:
UTF-8 использует от одного до четырех байтов на кодовую точку и, будучи компактным для латинских сценариев и совместимым с ASCII, обеспечивает де-факто стандартную кодировку для обмена текстом Unicode. Он используется FreeBSD и последними дистрибутивами Linux в качестве прямой замены устаревших кодировок при общей обработке текста.
Кодировки UCS-2 и UTF-16 определяют знак порядка байтов (BOM) Unicode для использования в начале текстовых файлов, который может использоваться для определения порядка байтов (или определения порядка байтов ). Спецификация, закодированная как U+FEFF BYTE ORDER MARK , обладает важным свойством однозначности при переупорядочении байтов, независимо от используемой кодировки Unicode; U+FFFE (результат замены байтов U+FEFF ) не соответствует допустимому символу, а U+FEFF в местах, отличных от начала текста, передает неразрывный пробел нулевой ширины (символ без внешнего вида и никакого эффекта, кроме предотвращения образования лигатур ).
Тот же символ, преобразованный в UTF-8, становится последовательностью байтов EF BB BF. Стандарт Unicode позволяет спецификации «может служить подписью для текста в кодировке UTF-8, где набор символов не помечен». [73] Некоторые разработчики программного обеспечения приняли его для других кодировок, включая 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 и SCSU — схемы сжатия Unicode. В первоапрельском RFC 2005 года указаны две пародийные кодировки UTF: UTF-9 и UTF-18 .
Юникод в форме UTF-8 является наиболее распространенной кодировкой во Всемирной паутине с 2008 года. [74] Он имеет почти универсальное распространение, и большая часть контента, отличного от UTF-8, встречается в других кодировках Unicode. , например UTF-16 . По состоянию на 2024 год [обновлять]на UTF-8 приходится в среднем 97,8% всех веб-страниц (и 987 из 1000 веб-страниц с самым высоким рейтингом). [75] Хотя на многих страницах для отображения контента используются только символы ASCII , UTF-8 был разработан с использованием 8-битного ASCII в качестве подмножества, и сейчас почти ни один веб-сайт не заявляет, что использует только ASCII вместо UTF-8. [76] Более трети отслеживаемых языков на 100% используют UTF-8.
Все интернет-протоколы, поддерживаемые Инженерной группой Интернета , например FTP , [77] требуют поддержки UTF-8 с момента публикации RFC 2277 в 1998 году, в котором указано, что все протоколы IETF «ДОЛЖНЫ иметь возможность использовать кодировку UTF-8». . [78]
Юникод стал доминирующей схемой внутренней обработки и хранения текста. Хотя большая часть текста по-прежнему хранится в устаревших кодировках, Unicode используется почти исключительно для создания новых систем обработки информации. Первые пользователи, как правило, использовали UCS-2 (двухбайтовый устаревший предшественник UTF-16 фиксированной длины), а затем перешли на UTF-16 (текущий стандарт переменной длины), поскольку это был наименее разрушительный способ добавить поддержку символы, отличные от BMP. Наиболее известной такой системой является Windows NT (и ее потомки 2000 , XP , Vista , 7 , 8 , 10 и 11 ), которая использует UTF-16 в качестве единственной внутренней кодировки символов. Среды байт-кода Java и .NET, macOS и KDE также используют его для внутреннего представления. Частичную поддержку Unicode можно установить в Windows 9x через Microsoft Layer for Unicode .
UTF-8 (первоначально разработанный для Plan 9 ) [79] стал основной кодировкой памяти в большинстве Unix-подобных операционных систем (хотя другие также используются некоторыми библиотеками), поскольку он является относительно простой заменой традиционных расширенных наборов символов ASCII . UTF-8 также является наиболее распространенной кодировкой Unicode, используемой в HTML- документах во Всемирной паутине .
Многоязычные механизмы рендеринга текста, использующие Unicode, включают Uniscribe и DirectWrite для Microsoft Windows, ATSUI и Core Text для macOS, а также Pango для GTK+ и рабочего стола GNOME .
Поскольку раскладки клавиатуры не могут иметь простые комбинации клавиш для всех символов, некоторые операционные системы предоставляют альтернативные методы ввода, которые обеспечивают доступ ко всему набору символов.
ISO/IEC 14755 , [80] , который стандартизирует методы ввода символов Юникода из их кодовых точек, определяет несколько методов. Существует базовый метод , в котором за начальной последовательностью следует шестнадцатеричное представление кодовой точки и конечная последовательность . Также указан метод ввода с выбором экрана , при котором символы перечислены в таблице на экране, например, в программе карты символов.
Онлайн-инструменты для поиска кодовой точки известного символа включают Unicode Lookup [81] Джонатана Хедли и Shapecatcher [82] Бенджамина Милда. При поиске в Юникоде вводится ключ поиска (например, «дроби»), и возвращается список соответствующих символов с их кодовыми точками. В Shapecatcher, на основе контекста Shape , персонаж рисуется в рамке, и возвращается список символов, аппроксимирующих рисунок, с их кодовыми точками.
MIME определяет два разных механизма кодирования символов, отличных от ASCII, в электронной почте, в зависимости от того, находятся ли символы в заголовках электронной почты (например, «Тема:») или в текстовом теле сообщения; в обоих случаях идентифицируется исходный набор символов, а также кодировка передачи. Для передачи по электронной почте в формате Unicode рекомендуется использовать набор символов UTF-8 и кодировку передачи Base64 или Quoted-printable , в зависимости от того, состоит ли большая часть сообщения из символов ASCII . Детали двух разных механизмов указаны в стандартах MIME и обычно скрыты от пользователей почтового программного обеспечения.
IETF определил [83] [84] структуру интернационализированной электронной почты с использованием UTF-8 и обновил [85] [86] [87] [88] несколько протоколов в соответствии с этой структурой.
Внедрение Unicode в электронной почте происходит очень медленно. [ нужна цитация ] Некоторый восточноазиатский текст все еще кодируется в таких кодировках, как ISO-2022 , а некоторые устройства, такие как мобильные телефоны, [ нужна цитация ] все еще не могут правильно обрабатывать данные Unicode. Однако поддержка улучшается. Многие крупные провайдеры бесплатной почты, такие как Yahoo! Mail , Gmail и Outlook.com поддерживают его.
Во всех рекомендациях W3C в качестве набора символов документа используется Юникод, начиная с HTML 4.0. Веб-браузеры уже много лет поддерживают Unicode, особенно UTF-8. Раньше возникали проблемы с отображением, возникающие в основном из-за проблем, связанных со шрифтами ; например, версия Microsoft Internet Explorer 6 и более ранние версии не отображали многие кодовые точки, если явно не было указано использовать шрифт, который их содержит. [89]
Хотя правила синтаксиса могут влиять на порядок, в котором разрешено появление символов, документы XML (включая XHTML ) по определению [90] содержат символы из большинства кодовых точек Unicode, за исключением:
Символы HTML проявляются либо непосредственно в виде байтов в соответствии с кодировкой документа, если кодировка их поддерживает, либо пользователи могут записывать их в виде числовых ссылок на символы на основе кодовой точки символа в Юникоде. Например, ссылки Δ, Й, ק, م, ๗, あ, 叶, 葉и 말(или те же числовые значения, выраженные в шестнадцатеричном формате, с &#xпрефиксом в качестве префикса) должны отображаться во всех браузерах как Δ, Й, ק, م, ๗, あ, 叶, 葉. и 말.
При указании URI , например URL-адресов в HTTP- запросах, символы, отличные от ASCII, должны быть закодированы в процентах .
Unicode в принципе не занимается шрифтами как таковыми , рассматривая их как вариант реализации. [91] Любой символ может иметь множество аллографов , от более распространенных жирных, курсивных и базовых букв до сложных декоративных стилей. Шрифт является «совместимым с Unicode», если к глифам шрифта можно получить доступ с помощью кодовых точек, определенных в стандарте Unicode . [92] Стандарт не определяет минимальное количество символов, которые должны быть включены в шрифт; некоторые шрифты имеют довольно небольшой репертуар.
Бесплатные и розничные шрифты на основе Unicode широко доступны, поскольку TrueType и OpenType поддерживают Unicode (и формат веб-открытых шрифтов (WOFF и WOFF2 ) основан на них). Эти форматы шрифтов сопоставляют кодовые точки Unicode с глифами, но файлы шрифтов OpenType и TrueType ограничены 65 535 глифами. Файлы коллекций предоставляют механизм «режим пробела» для преодоления этого ограничения в одном файле шрифта. (Однако каждый шрифт в коллекции по-прежнему имеет ограничение в 65 535.) Файл коллекции TrueType обычно имеет расширение «.ttc».
На рынке существуют тысячи шрифтов , но менее дюжины шрифтов, иногда называемых шрифтами «пан-Юникода», пытаются поддерживать большую часть набора символов Юникода. Вместо этого шрифты на основе Юникода обычно ориентированы на поддержку только базового ASCII и определенных сценариев или наборов символов или символов. Несколько причин оправдывают этот подход: приложениям и документам редко требуется отображать символы более чем одной или двух систем письма; шрифты, как правило, требуют ресурсов в вычислительной среде; а операционные системы и приложения демонстрируют возрастающий интеллект в отношении получения информации о глифах из отдельных файлов шрифтов по мере необходимости, т. е. замены шрифта . Более того, разработка согласованного набора инструкций рендеринга для десятков тысяч глифов представляет собой монументальную задачу; такое предприятие проходит точку убывающей отдачи для большинства шрифтов.
Unicode частично решает проблему новой строки , возникающую при попытке прочитать текстовый файл на разных платформах. Юникод определяет большое количество символов , которые соответствующие приложения должны распознавать как ограничители строк.
Что касается новой строки, в Unicode представлены U+2028 LINE SEPARATOR и U+2029 PARAGRAPH SEPARATOR . Это была попытка предоставить решение Unicode для семантического кодирования абзацев и строк, потенциально заменив все различные платформенные решения. При этом Unicode действительно позволяет обойти исторические решения, зависящие от платформы. Тем не менее, лишь немногие решения Unicode, если таковые имеются, приняли эти разделители строк и абзацев Unicode в качестве единственных канонических символов окончания строки. Однако общий подход к решению этой проблемы заключается в нормализации новой строки. Это достигается с помощью текстовой системы Cocoa в Mac OS X, а также с помощью рекомендаций W3C XML и HTML. В этом подходе каждый возможный символ новой строки преобразуется внутри в общий символ новой строки (какой именно из них не имеет особого значения, поскольку это внутренняя операция только для рендеринга). Другими словами, текстовая система может правильно интерпретировать символ как новую строку, независимо от фактической кодировки ввода.
Группе идеографических исследований (IRG) поручено консультировать Консорциум и ISO по вопросам унификации Хань, или Унихан, особенно по дальнейшему добавлению в репертуар унифицированных и совместимых иероглифов CJK. В состав IRG входят эксперты из каждого региона, где исторически использовались китайские иероглифы . Однако, несмотря на обсуждения в комитете, объединение Хань неизменно оставалось одним из наиболее спорных аспектов стандарта Unicode с момента создания проекта. [93]
Существующие стандарты набора символов, такие как японский JIS X 0208 (закодированный с помощью Shift JIS ), определяют критерии унификации, то есть правила определения того, когда вариант китайского иероглифа следует считать разницей в почерке/шрифте (и, следовательно, унифицированным), а не разницей в написании ( кодироваться отдельно). Модель символов Unicode для символов CJK была основана на критериях унификации, используемых в JIS X 0208, а также на критериях, разработанных Ассоциацией общего китайского кода в Китае. [94] Из-за принципа стандарта кодирования семантических, а не стилистических вариантов, Unicode подвергся критике за то, что он не присваивал кодовые точки определенным редким и архаичным вариантам кандзи , что, возможно, усложняло обработку древних и необычных японских имен. Поскольку особое внимание уделяется китайскому, японскому и корейскому языкам, имеющим много общих символов, ханьское объединение также иногда воспринимается как обращение к этим трем как к одному и тому же. [95]
Существуют менее часто используемые альтернативные кодировки, часто предшествующие Unicode, с моделями символов, отличающимися от этой парадигмы, направленные на сохранение различных стилистических различий между региональными и / или нестандартными формами символов. Одним из примеров является код TRON, который некоторые пользователи предпочитают для обработки исторических японских текстов, но он не получил широкого распространения среди японской общественности. Другим примером является кодировка CCCII, принятая библиотечными системами Гонконга , Тайваня и США . У них есть свои недостатки в общем использовании, что приводит к тому, что кодировка Big5 (введенная в 1984 году, через четыре года после CCCII) стала более распространенной, чем CCCII, за пределами библиотечных систем. [96] Хотя работа Apple, основанная на тезаурусе CJK Research Libraries Group , который использовался для поддержки варианта EACC CCCII, была одним из прямых предшественников набора Unihan Unicode , Unicode принял модель унификации в стиле JIS. [94]
Самая ранняя версия Unicode имела репертуар менее 21 000 символов хань, в основном ограниченный теми, которые относительно распространены в современном использовании. Начиная с версии 15.1, стандарт теперь кодирует более 97 000 символов хань, и продолжается работа по добавлению еще тысяч — в основном исторических и диалектных вариантов символов, используемых во всей синосфере .
Современные шрифты позволяют решить некоторые практические проблемы изображения единых ханьских символов с помощью различных региональных графических представлений. Таблица OpenType 'locl' позволяет средству визуализации выбирать разные глифы для каждой кодовой точки на основе языкового стандарта текста. [97] Последовательности вариантов Юникода также могут обеспечивать внутритекстовые аннотации для желаемого выбора глифа; для этого требуется регистрация конкретного варианта в базе данных идеографических вариаций .
Если соответствующие глифы для символов одного и того же алфавита различаются только курсивом, Unicode в целом унифицировал их, как это можно увидеть при сравнении набора из семи символов курсива, обычно встречающихся в русском, традиционном болгарском, македонском и Сербский текст справа означает, что различия отображаются с помощью технологии интеллектуальных шрифтов или изменения шрифтов вручную. Используется тот же метод OpenType «locl». [98]
Юникод был разработан для обеспечения двустороннего преобразования формата «кодовая точка за кодовой точкой» в любую ранее существовавшую кодировку символов и обратно, чтобы текстовые файлы в старых наборах символов можно было преобразовать в Юникод, а затем обратно и получить тот же файл. без использования контекстно-зависимой интерпретации. Это означает, что в Юникоде существуют противоречивые устаревшие архитектуры, такие как сочетание диакритических знаков и заранее составленных символов , что дает более одного метода представления некоторого текста. Это наиболее ярко выражено в трех различных формах кодировки корейского хангыля . Начиная с версии 3.0, любые заранее составленные символы, которые могут быть представлены комбинированной последовательностью уже существующих символов, больше не могут быть добавлены в стандарт, чтобы сохранить совместимость программного обеспечения, использующего разные версии Unicode.
Между символами существующих устаревших наборов символов и символами Юникода необходимо обеспечить инъективные сопоставления, чтобы облегчить преобразование в Юникод и обеспечить совместимость с устаревшим программным обеспечением. Отсутствие согласованности в различных сопоставлениях между более ранними японскими кодировками, такими как Shift-JIS или EUC-JP и Unicode, привело к несоответствию двустороннего преобразования формата , особенно сопоставлению символа JIS X 0208 '～' (1-33, WAVE DASH). , широко используемый в устаревших данных баз данных, либо на U+FF5E～FULLWIDTH TILDE (в Microsoft Windows ), либо на U+301C〜WAVE DASH (другие поставщики). [99]
Некоторые японские программисты возражали против Unicode, поскольку он требует от них разделения использования U+005C \ REVERSE SOLIDUS (обратная косая черта) и U+00A5 ¥ YEN SIGN , который был сопоставлен с 0x5C в JIS X 0201, и существует много устаревшего кода. с этим использованием. [100] (Эта кодировка также заменяет тильду '~' 0x7E на макрон '¯', теперь 0xAF.) Разделение этих символов существует в ISO 8859-1 задолго до Unicode.
Индийским сценариям , таким как тамильский и деванагари, выделено только 128 кодовых точек, что соответствует стандарту ISCII . Правильная отрисовка индийского текста в Юникоде требует преобразования сохраненных символов логического порядка в визуальный порядок и формирования лигатур (также известных как конъюнкты) из компонентов. Некоторые местные ученые выступали за присвоение этим лигатурам кодовых точек Юникода, что противоречит практике других систем письма, хотя Юникод содержит некоторые арабские и другие лигатуры только в целях обратной совместимости. [101] [102] [103] Кодирование любых новых лигатур в Юникоде не произойдет, отчасти потому, что набор лигатур зависит от шрифта, а Юникод — это кодировка, независимая от вариантов шрифта. Такая же проблема возникла с тибетским письмом в 2003 году, когда Управление по стандартизации Китая предложило закодировать 956 заранее составленных тибетских слогов, [104] , но они были отклонены для кодирования соответствующим комитетом ISO ( ISO/IEC JTC 1/SC 2 ). [105]
Поддержка тайского алфавита подвергалась критике за порядок расположения тайских символов. Гласные เ, แ, โ, ใ, ไ, которые пишутся слева от предыдущей согласной, располагаются в визуальном, а не фонетическом порядке, в отличие от представлений других индийских алфавитов в Юникоде. Это осложнение связано с тем, что Unicode унаследовал тайский промышленный стандарт 620 , который работал таким же образом и был способом, которым тайский язык всегда писался на клавиатуре. Эта проблема с упорядочением немного усложняет процесс сопоставления Юникода, требуя поиска в таблице для изменения порядка тайских символов для сопоставления. [95] Даже если бы Unicode принял кодировку в соответствии с порядком произнесения, все равно было бы проблематично сопоставлять слова в словарном порядке. Например, слово แสดง [sa dɛːŋ] «выполнять» начинается с группы согласных «สด» (с присущей гласной согласным «ส»), гласная แ- в устной речи идет после ด, но в словаре, слово сопоставляется так, как оно написано, с гласной, следующей за ส.
Символы с диакритическими знаками обычно могут быть представлены либо как один заранее составленный символ, либо как разложенная последовательность базовой буквы плюс один или несколько знаков без пробелов. Например, ḗ (предварительная е с макроном и акутом выше) и ḗ (е, за которым следует комбинированный макрон выше и комбинированный акут выше) должны отображаться одинаково, оба появляются как е с макроном (◌̄) и акутом (◌ ́), но на практике их внешний вид может различаться в зависимости от того, какой механизм рендеринга и шрифты используются для отображения символов. Точно так же точки , необходимые при латинизации индийского языка , часто расставляются неправильно. [ нужна цитация ] Символы Юникода, которые сопоставляются с предварительно составленными глифами, можно использовать во многих случаях, что позволяет избежать проблемы, но если заранее составленный символ не был закодирован, проблема часто может быть решена с помощью специального шрифта Юникода, такого как Charis SIL , который использует Технологии Graphite , OpenType («gsub») или AAT для расширенных функций рендеринга.
Стандарт Unicode наложил правила, призванные гарантировать стабильность. [106] В зависимости от строгости правила изменение может быть запрещено или разрешено. Например, «имя», присвоенное кодовой точке, не может и не будет меняться. Но свойство «script» является более гибким по собственным правилам Unicode. В версии 2.0 Unicode изменил многие «имена» кодовых точек по сравнению с версией 1. В то же время Unicode заявил, что с этого момента присвоенное кодовой точке имя никогда не будет меняться. Это означает, что когда ошибки публикуются, эти ошибки невозможно исправить, даже если они тривиальны (как это произошло в одном случае с написанием BRAKCET вместо BRACKET в имени персонажа). В 2006 году был впервые опубликован список аномалий в именах персонажей, и по состоянию на июнь 2021 года было выявлено 104 символа с выявленными проблемами, [107] например:
Хотя Unicode определяет указатель (имя) сценария как « Phags_Pa », к именам символов этого сценария добавляется дефис: U+A840 ꡀ PHAGS-PA LETTER KA . [110] [111] Однако это не аномалия, а правило: в обозначениях шрифтов дефисы заменяются подчеркиваниями. [110]
В Unicode имеется большое количество гомоглифов , многие из которых очень похожи или идентичны буквам ASCII. Их замена может привести к тому, что идентификатор или URL-адрес будет выглядеть правильно, но будет вести в другое место, чем ожидалось. [112] Кроме того, гомоглифы также можно использовать для манипулирования выходными данными систем обработки естественного языка (NLP) . [113] Для смягчения последствий необходимо запретить использование этих символов, отобразить их по-разному или потребовать, чтобы они разрешались в один и тот же идентификатор; [114] Все это сложно из-за огромного и постоянно меняющегося набора персонажей. [115] [116]
В 2021 году два исследователя, один из Кембриджского университета , а другой из Эдинбургского университета , выпустили рекомендации по безопасности, в которых они утверждают, что метки BiDi могут использоваться для того, чтобы заставить большие участки кода делать что-то, отличное от того, чем они кажутся. делать. Проблема получила название « Источник трояна ». [117] В ответ редакторы кода начали выделять метки, указывающие на принудительное изменение направления текста. [118]
2.2 Исходное поле
В 1978 году первоначальное предложение о наборе «Универсальных знаков» было сделано
Бобом Бельвиллем
из
Xerox PARC
. Многие люди внесли свои идеи в разработку новой конструкции кодирования. Начиная с 1980 года, эти усилия превратились в
стандарт кодировки символов Xerox
(XCCS) настоящего автора, многоязычную кодировку, которая поддерживается Xerox в качестве внутреннего корпоративного стандарта с 1982 года благодаря усилиям Эда Смуры, Рона Пеллара и других. .
Юникод возник в результате восьмилетнего опыта работы с XCCS. Его фундаментальные отличия от XCCS были предложены Питером Фенвиком и Дэйвом Опстадом (чистые 16-битные коды) и
Ли Коллинзом
(унификация идеографических символов). Unicode сохраняет многие особенности XCCS, полезность которых была доказана на протяжении многих лет в продуктах международной линии связи многоязычных систем.
Выберите этот формат развертывания, если ваша система поддерживает переменные шрифты и вы предпочитаете использовать только один язык, но вам также требуется полный охват символов или возможность помечать текст языковыми тегами для использования глифов, подходящих для других языков (для этого требуется приложение, поддерживающее языковые теги и функция GSUB OpenType 'locl').
СМИ из Commons
Учебники из Wikibooks