Unicode , официально The Unicode Standard , [примечание 1] — стандарт кодирования текста , поддерживаемый Unicode Consortium , разработанный для поддержки использования текста во всех мировых системах письма , которые могут быть оцифрованы. Версия 16.0 стандарта [A] определяет154 998 символов и 168 сценариев [3], используемых в различных повседневных, литературных, академических и технических контекстах.
Многие общие символы, включая цифры, знаки препинания и другие символы, унифицированы в стандарте и не рассматриваются как специфичные для какой-либо конкретной системы письма. Unicode кодирует 3790 эмодзи , и его дальнейшее развитие проводится Консорциумом как часть стандарта. [4] Более того, широкое принятие Unicode во многом способствовало первоначальной популяризации эмодзи за пределами Японии. В конечном итоге Unicode способен кодировать более 1,1 миллиона символов.
Unicode в значительной степени вытеснил предыдущую среду множества несовместимых наборов символов , каждый из которых использовался в разных локалях и на разных компьютерных архитектурах. Unicode используется для кодирования подавляющего большинства текстов в Интернете, включая большинство веб-страниц , и соответствующая поддержка Unicode стала общепринятым соображением в современной разработке программного обеспечения.
Репертуар символов 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 без потери информации, многим символам, почти идентичным другим , как по внешнему виду, так и по предполагаемой функции, были даны различные кодовые точки. Например, блок Halfwidth и Fullwidth Forms охватывает полный семантический дубликат латинского алфавита, поскольку устаревшие кодировки CJK содержали как символы "fullwidth" (соответствующие ширине символов CJK), так и символы "halfwidth" (соответствующие обычной латинице).
Премия Unicode Bulldog Award присуждается людям, оказавшим влияние на развитие Unicode, среди лауреатов — Тацуо Кобаяши , Томас Мило, Рузбех Пурнадер , Кен Лунде и Майкл Эверсон . [6]
Истоки Unicode можно проследить до 1980-х годов, до группы людей, связанных со Стандартом кодирования символов Xerox ( XCCS). [7] В 1987 году сотрудник Xerox Джо Беккер вместе с сотрудниками Apple Ли Коллинзом и Марком Дэвисом начали исследовать практические аспекты создания универсального набора символов. [8] При дополнительном участии Питера Фенвика и Дэйва Опстада [7] Беккер опубликовал проект предложения по «международной/многоязычной системе кодирования текстовых символов в августе 1988 года, предварительно названной Unicode». Он объяснил, что «название „Unicode“ призвано предполагать уникальную, унифицированную, универсальную кодировку». [7]
В этом документе, озаглавленном Unicode 88 , Беккер изложил схему с использованием 16-битных символов: [7]
Unicode призван удовлетворить потребность в работоспособной, надежной мировой кодировке текста. Unicode можно грубо описать как "широкоформатный ASCII ", который был растянут до 16 бит, чтобы охватить символы всех живых языков мира. В правильно спроектированном дизайне 16 бит на символ более чем достаточно для этой цели.
Это проектное решение было принято на основе предположения, что кодирование потребуется только для сценариев и символов в «современном» использовании: [7]
Unicode отдает приоритет обеспечению полезности для будущего, а не сохранению древностей прошлого. Unicode нацелен в первую очередь на символы, опубликованные в современном тексте (например, в объединении всех газет и журналов, напечатанных в мире в 1988 году), число которых, несомненно, намного меньше 2 14 = 16 384. За пределами этих современных символов все остальные могут быть определены как устаревшие или редкие; они являются лучшими кандидатами для регистрации в частном порядке, чем для переполнения публичного списка общеполезных символов Unicode.
В начале 1989 года рабочая группа Unicode расширилась, включив в себя Кена Уистлера и Майка Кернагана из Metaphor, Карен Смит-Йошимуру и Джоан Алипранд из Research Libraries Group , а также Гленна Райта из Sun Microsystems . В 1990 году к группе также присоединились Мишель Сюиньяр и Асмус Фрейтаг из Microsoft и Рик Макгоуэн из NeXT . К концу 1990 года большая часть работы по перераспределению существующих стандартов была завершена, и был готов окончательный черновик обзора Unicode.
Консорциум Unicode был зарегистрирован в Калифорнии 3 января 1991 года, [9] и первый том The Unicode Standard был опубликован в октябре того же года. Второй том, теперь уже с идеограммами Хан, был опубликован в июне 1992 года.
В 1996 году в Unicode 2.0 был реализован механизм суррогатных символов, так что Unicode больше не был ограничен 16 битами. Это увеличило кодовое пространство Unicode до более чем миллиона кодовых точек, что позволило кодировать многие исторические письменности, такие как египетские иероглифы , и тысячи редко используемых или устаревших символов, которые не были предусмотрены для включения в стандарт. Среди этих символов есть различные редко используемые символы CJK — многие из них в основном используются в именах собственных, что делает их гораздо более необходимыми для универсального кодирования, чем предполагала исходная архитектура Unicode. [10]
В версии 1.0 спецификации TrueType компании Microsoft, опубликованной в 1992 году, для идентификатора платформы в таблице имен использовалось название «Apple Unicode» вместо «Unicode».
Консорциум Unicode — некоммерческая организация, которая координирует разработку Unicode. Полноправными членами являются большинство основных компаний, занимающихся программным обеспечением и оборудованием (и несколько других), которые проявляют интерес к стандартам обработки текста, в том числе Adobe , Apple , Google , IBM , Meta (ранее Facebook), Microsoft , Netflix и SAP . [11]
На протяжении многих лет несколько стран или правительственных учреждений были членами Консорциума Unicode. В настоящее время только Министерство пожертвований и религиозных дел (Оман) является полноправным членом с правом голоса. [11]
Консорциум ставит перед собой амбициозную цель — в конечном итоге заменить существующие схемы кодирования символов на Unicode и его стандартные схемы формата преобразования Unicode (UTF), поскольку многие из существующих схем ограничены по размеру и области применения и несовместимы с многоязычными средами.
В настоящее время Unicode охватывает большинство основных систем письма , используемых сегодня. [12] [ необходим лучший источник ]
По состоянию на 2024 год в последнюю версию Unicode (включая алфавиты , абугиды и слоговые азбуки ) включено в [обновлять]общей сложности 168 письменностей [13] , хотя все еще есть письменности, которые еще не закодированы, особенно те, которые в основном используются в исторических, литургических и академических контекстах. Также происходят дальнейшие добавления символов к уже закодированным письменностям, а также символов, в частности для математики и музыки (в виде нот и ритмических символов).
Комитет по дорожной карте Unicode ( Майкл Эверсон , Рик Макгоуэн, Кен Уистлер, В.С. Умамахесваран) [14] ведет список письменностей, которые являются кандидатами или потенциальными кандидатами на кодирование, и их предварительные назначения блоков кода на странице «Дорожная карта Unicode» [15] веб-сайта Консорциума Unicode . Для некоторых письменностей в «Дорожной карте», таких как чжурчжэньское и киданьское большое письмо , были сделаны предложения по кодированию, и они проходят процесс утверждения. Для других письменностей, таких как нумидийское и ронго-ронго , пока не сделано никаких предложений, и они ждут соглашения о репертуаре символов и других деталях от заинтересованных сообществ пользователей.
Некоторые современные письменности, которые еще не включены в Unicode (например, тенгвар ) или которые не соответствуют требованиям для включения в Unicode из-за отсутствия реального использования (например, клингонский ), перечислены в реестре ConScript Unicode , наряду с неофициальными, но широко используемыми кодами назначений для областей частного использования .
Также существует Medieval Unicode Font Initiative, ориентированная на специальные латинские средневековые символы. Часть этих предложений уже включена в Unicode.
Инициатива по кодированию сценариев [16] , проект, которым руководит Дебора Андерсон в Калифорнийском университете в Беркли, была основана в 2002 году с целью финансирования предложений по сценариям, еще не закодированным в стандарте. В последние годы проект стал основным источником предлагаемых дополнений к стандарту. [17]
Консорциум Unicode совместно с ISO разработали общий репертуар после первоначальной публикации The Unicode Standard : Unicode и Универсальный набор кодированных символов (UCS) ISO используют идентичные имена символов и кодовые точки. Однако версии Unicode отличаются от своих эквивалентов ISO двумя существенными способами.
В то время как UCS представляет собой простую таблицу символов, Unicode определяет правила, алгоритмы и свойства, необходимые для достижения взаимодействия между различными платформами и языками. Таким образом, The Unicode Standard включает в себя больше информации, охватывающей такие глубокие темы, как побитовое кодирование, сопоставление и рендеринг. Он также предоставляет полный каталог свойств символов, включая те, которые необходимы для поддержки двунаправленного текста , а также визуальные диаграммы и справочные наборы данных для помощи разработчикам. Ранее The Unicode Standard продавался в виде печатного тома, содержащего полную основную спецификацию, стандартные приложения [примечание 2] и кодовые таблицы. Однако версия 5.0, опубликованная в 2006 году, была последней версией, напечатанной таким образом. Начиная с версии 5.2, можно приобрести только основную спецификацию, опубликованную в виде издания в мягкой обложке с возможностью печати по требованию. [18] Полный текст, с другой стороны, опубликован в виде бесплатного PDF-файла на веб-сайте Unicode.
Практическая причина этого метода публикации подчеркивает второе существенное различие между UCS и Unicode — частоту, с которой выпускаются обновленные версии и добавляются новые символы. Стандарт Unicode регулярно выпускал ежегодные расширенные версии, иногда с выпуском более одной версии в календарном году и в редких случаях, когда запланированный выпуск приходилось откладывать. Например, в апреле 2020 года, через месяц после публикации версии 13.0, Консорциум Unicode объявил, что они изменили предполагаемую дату выпуска версии 14.0, отодвинув ее на шесть месяцев назад, на сентябрь 2021 года из-за пандемии COVID-19 .
Последняя версия Unicode 16.0 была выпущена 10 сентября 2024 года. Она добавила 5185 символов и семь новых письменностей: Гарай , Гурунг Кхема , Кират Рай , Ол Онал , Сунувар , Тодхри и Тулу-Тигалари . [19]
На данный момент опубликованы следующие версии The Unicode Standard . Версии обновлений, не вносящие никаких изменений в набор символов, обозначаются третьей цифрой (например, «версия 4.0.1») и опущены в таблице ниже. [20]
Консорциум Unicode обычно выпускает новую версию The Unicode Standard раз в год. Версия 17.0, следующая основная версия, по прогнозам, будет включать 4301 новых унифицированных символов CJK . [57] [58]
Стандарт Unicode определяет кодовое пространство : [59] последовательность целых чисел, называемых кодовыми точками [60] в диапазоне от 0 до1 114 111 , обозначенный в соответствии со стандартом как U+0000 – U+10FFFF . [61] Кодовое пространство является систематическим, независимо от архитектуры представлением стандарта Unicode ; фактический текст обрабатывается как двоичные данные с помощью одной из нескольких кодировок Unicode, например UTF-8 .
В этой нормативной нотации двухсимвольный префикс U+всегда предшествует написанной кодовой точке, [62] а сами кодовые точки записываются как шестнадцатеричные числа. Всегда записываются по крайней мере четыре шестнадцатеричные цифры с ведущими нулями, добавляемыми по мере необходимости. Например, кодовая точка U+00F7 ÷ ЗНАК ДЕЛЕНИЯ дополняется двумя ведущими нулями, но U+13254 𓉔 ЕГИПЕТСКИЙ ИЕРОГЛИФ O004 ( 
) не дополнен. [63]
Всего 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 .)
Кодовое пространство Unicode разделено на 17 плоскостей , пронумерованных от 0 до 16. Плоскость 0 — это базовая многоязычная плоскость (BMP), содержащая наиболее часто используемые символы. Все кодовые точки в BMP доступны как одна кодовая единица в кодировке UTF-16 и могут быть закодированы одним, двумя или тремя байтами в UTF-8. Кодовые точки в плоскостях с 1 по 16 ( дополнительные плоскости ) доступны как суррогатные пары в UTF-16 и кодируются четырьмя байтами в UTF-8 .
В каждой плоскости символы размещаются в именованных блоках связанных символов. Размер блока всегда кратен 16 и часто кратен 128, но в остальном произволен. Символы, требуемые для данного сценария, могут быть распределены по нескольким различным, потенциально разобщенным блокам в кодовом пространстве.
Каждой кодовой точке назначается классификация, указанная как свойство общей категории кодовой точки . Здесь, на самом верхнем уровне кодовые точки категоризируются как одна из букв, знаков, чисел, знаков препинания, символов, разделителей или других. В каждой категории каждая кодовая точка затем далее подразделяется на подкатегории. В большинстве случаев для адекватного описания всех характеристик любой заданной кодовой точки должны использоваться другие свойства.
The1024 точки в диапазоне 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 ). Набор несимволов стабилен, и никакие новые несимволы никогда не будут определены. [64] Как и в случае с суррогатами, правило, согласно которому их нельзя использовать, часто игнорируется, хотя работа метки порядка байтов предполагает, что U+FFFE никогда не будет первой кодовой точкой в тексте. Исключение суррогатов и несимволов оставляет1 111 998 кодовых точек доступны для использования.
Частные кодовые точки считаются назначенными, но они намеренно не имеют интерпретации, указанной в Стандарте Unicode [65] , так что любой обмен такими кодовыми точками требует независимого соглашения между отправителем и получателем относительно их интерпретации. В кодовом пространстве Unicode есть три области частного использования:
Графические символы — это те, которые определены Стандартом Unicode как имеющие определенную семантику, либо имеющие видимую форму глифа , либо представляющие видимое пространство. Начиная с Unicode 16.0, есть154 826 графических символов.
Символы формата — это символы, которые не имеют видимого вида, но могут влиять на вид или поведение соседних символов. Например, U+200C ZERO WIDTH NON-JOINER и U+200D ZERO WIDTH JOINER могут использоваться для изменения поведения формирования по умолчанию соседних символов (например, для запрета лигатур или запроса формирования лигатур). В Unicode 16.0 имеется 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. В явлении, известном как mojibake , кодовые точки C1 неправильно декодируются в соответствии с кодовой страницей Windows-1252 , ранее широко использовавшейся в западноевропейских контекстах.
Вместе графические, форматные, управляющие коды и символы частного использования совместно называются назначенными символами . Зарезервированные кодовые точки — это те кодовые точки, которые действительны и доступны для использования, но еще не назначены. Начиная с Unicode 15.1, есть819 467 зарезервированных кодовых точек.
Набор графических и форматных символов, определенных Unicode, не соответствует напрямую репертуару абстрактных символов, представляемых в Unicode. Unicode кодирует символы, связывая абстрактный символ с определенной кодовой точкой. [66] Однако не все абстрактные символы кодируются как один символ Unicode, и некоторые абстрактные символы могут быть представлены в Unicode последовательностью из двух или более символов. Например, латинская строчная буква «i» с огонёком , точкой над и острым ударением , которая требуется в литовском языке , представлена последовательностью символов U+012F ; U+0307 ; U+0301 . Unicode поддерживает список уникально именованных последовательностей символов для абстрактных символов, которые напрямую не кодируются в Unicode. [67]
Все назначенные символы имеют уникальное и неизменяемое имя, по которому они идентифицируются. Эта неизменяемость гарантируется с версии 2.0 Стандарта Unicode его политикой стабильности имен. [64] В случаях, когда имя является серьезно дефектным и вводящим в заблуждение или имеет серьезную типографскую ошибку, может быть определен формальный псевдоним , который приложениям рекомендуется использовать вместо официального имени символа. Например, U+A015 ꀕ YI SYLLABLE WU имеет формальный псевдоним YI SYLLABLE ITeration MARK , а U+FE18 ︘ ФОРМА ПРЕДСТАВЛЕНИЯ ВЕРТИКАЛЬНОЙ ПРАВОЙ БЕЛОЙ ДВУХСТОРОННЕЙ СКОБКИ ( sic ) имеет формальный псевдоним ФОРМА ПРЕДСТАВЛЕНИЯ ВЕРТИКАЛЬНОЙ ПРАВОЙ БЕЛОЙ ДВУХСТОРОННЕЙ СКОБКИ ET . [68]
Unicode включает механизм изменения символов, который значительно расширяет поддерживаемый репертуар глифов. Это охватывает использование комбинированных диакритических знаков , которые могут быть добавлены после базового символа пользователем. Несколько комбинированных диакритических знаков могут быть одновременно применены к одному и тому же символу. Unicode также содержит предварительно составленные версии большинства комбинаций букв/диакритических знаков в обычном использовании. Это упрощает преобразование в устаревшие кодировки и из них и позволяет приложениям использовать 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 , а радикалы Kangxi назначены диапазону U+2F00 – U+2FDF . Блок Ideographic Description Sequences охватывает диапазон U+2FF0 – U+2FFB , но стандарт Unicode предостерегает от использования его символов в качестве альтернативного представления для символов, закодированных в другом месте:
Этот процесс отличается от формального кодирования идеограммы. Не существует канонического описания незакодированных идеограмм; не существует семантики, назначенной описанным идеограммам; не существует эквивалентности, определенной для описанных идеограмм. Концептуально идеографические описания больше похожи на английскую фразу "e с острым ударением на ней", чем на последовательность символов <U+0065, U+0301>.
Многие письменности, включая арабскую и деванагари , имеют специальные орфографические правила, которые требуют объединения определенных комбинаций буквенных форм в специальные лигатурные формы . Правила, регулирующие формирование лигатуры, могут быть довольно сложными, требуя специальных технологий формирования письменности, таких как ACE (Arabic Calligraphic Engine от DecoType в 1980-х годах, использовавшийся для создания всех арабских примеров в печатных изданиях The Unicode Standard ), который стал доказательством концепции OpenType (от Adobe и Microsoft), Graphite (от SIL International ) или AAT (от Apple).
В шрифты также встроены инструкции, сообщающие операционной системе, как правильно выводить различные последовательности символов. Простым решением для размещения комбинационных знаков или диакритических знаков является назначение знакам ширины, равной нулю, и размещение самого глифа слева или справа от левого бокового выступа (в зависимости от направления письма, с которым они предназначены). Обработанный таким образом знак будет отображаться над любым предшествующим ему символом, но не будет корректировать свое положение относительно ширины или высоты базового глифа; это может быть визуально неуклюже и может перекрывать некоторые глифы. Реальное наложение невозможно, но может быть приближено в ограниченных случаях (например, тайские верхние комбинационные гласные и знаки тона могут просто изначально находиться на разной высоте). Как правило, этот подход эффективен только в моноширинных шрифтах, но может использоваться как резервный метод рендеринга, когда более сложные методы не срабатывают.
Несколько подмножеств Unicode стандартизированы: Microsoft Windows, начиная с Windows NT 4.0, поддерживает WGL-4 с 657 символами, который, как считается, поддерживает все современные европейские языки, использующие латинский, греческий или кириллический алфавит. Другие стандартизированные подмножества Unicode включают многоязычные европейские подмножества: [70] MES-1 (только латинский алфавит; 335 символов), MES-2 (латинский, греческий и кириллический; 1062 символа) [71] и MES-3A & MES-3B (два больших подмножества, здесь не показаны). MES-2 включает каждый символ в MES-1 и WGL-4.
Стандарт DIN 91379 [72] определяет подмножество букв Unicode, специальных символов и последовательностей букв и диакритических знаков, чтобы обеспечить правильное представление имен и упростить обмен данными в Европе. Этот стандарт поддерживает все официальные языки всех стран Европейского Союза, а также немецкие языки меньшинств и официальные языки Исландии, Лихтенштейна, Норвегии и Швейцарии. Чтобы обеспечить транслитерацию имен в других системах письма в латинский алфавит согласно соответствующим стандартам ISO, предоставляются все необходимые комбинации базовых букв и диакритических знаков.
Программное обеспечение для рендеринга, которое не может правильно обработать символ Unicode, часто отображает его как открытый прямоугольник или как U+FFFD, чтобы указать положение нераспознанного символа. Некоторые системы предприняли попытки предоставить больше информации о таких символах. Шрифт Last Resort от Apple отобразит заменяющий глиф, указывающий диапазон Unicode символа, а резервный шрифт Unicode от SIL International отобразит поле, показывающее шестнадцатеричное скалярное значение символа.
Было определено несколько механизмов для хранения серии кодовых точек в виде серии байтов.
Unicode определяет два метода отображения: кодировки Unicode Transformation Format (UTF) и кодировки Universal Coded Character Set (UCS). Кодировка сопоставляет (возможно, подмножество) диапазон кодовых точек Unicode с последовательностями значений в некотором диапазоне фиксированного размера, называемых единицами кода . Все кодировки UTF сопоставляют точки кода с уникальной последовательностью байтов. [73] Числа в названиях кодировок указывают количество бит на единицу кода (для кодировок UTF) или количество байт на единицу кода (для кодировок UCS и UTF-1 ). Наиболее часто используемые кодировки — UTF-8 и UTF-16. UCS-2 — устаревший подмножество UTF-16; UCS-4 и UTF-32 функционально эквивалентны.
Кодировки UTF включают в себя:
UTF-8 использует от одного до четырех 8-битных блоков ( байтов ) на кодовую точку и, будучи компактным для латинских алфавитов и совместимым с ASCII, обеспечивает фактический стандарт кодировки для обмена текстом Unicode. Он используется FreeBSD и большинством последних дистрибутивов Linux в качестве прямой замены устаревших кодировок в общей обработке текста.
Кодировки UCS-2 и UTF-16 определяют метку порядка байтов Unicode (BOM) для использования в начале текстовых файлов, которая может использоваться для определения порядка байтов (или определения порядка байтов ). BOM, закодированная как U+FEFF ZERO WIDTH NO-BREAK SPACE , имеет важное свойство однозначности при переупорядочивании байтов, независимо от используемой кодировки Unicode; U+FFFE (результат перестановки байтов U+FEFF ) не соответствует допустимому символу, а U+FEFF в местах, отличных от начала текста, передает неразрывный пробел нулевой ширины.
Тот же символ, преобразованный в UTF-8, становится последовательностью байтов EF BB BF. Стандарт Unicode позволяет BOM «служить подписью для текста в кодировке UTF-8, где набор символов не отмечен». [74] Некоторые разработчики программного обеспечения приняли его для других кодировок, включая UTF-8, в попытке отличить UTF-8 от локальных 8-битных кодовых страниц . Однако RFC 3629, стандарт UTF-8, рекомендует запретить метки порядка байтов в протоколах, использующих UTF-8, но обсуждает случаи, когда это может быть невозможно. Кроме того, большое ограничение на возможные шаблоны в UTF-8 (например, не может быть никаких одиноких байтов с установленным старшим битом) означает, что должно быть возможно отличить UTF-8 от других кодировок символов, не полагаясь на BOM.
В 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 .
Unicode в форме UTF-8 является наиболее распространенной кодировкой для Всемирной паутины с 2008 года. [75] Она получила почти всеобщее распространение, и большая часть контента, отличного от UTF-8, находится в других кодировках Unicode, например, UTF-16 . По состоянию на 2024 год [обновлять], UTF-8 составляет в среднем 98,3% всех веб-страниц (и 983 из 1000 самых высоко оцененных веб-страниц). [76] Хотя многие страницы используют только символы ASCII для отображения контента, UTF-8 был разработан с 8-битным ASCII в качестве подмножества, и почти ни один веб-сайт теперь не заявляет, что их кодировка — только ASCII вместо UTF-8. [77] Более трети отслеживаемых языков имеют 100% использование UTF-8.
Все интернет-протоколы, поддерживаемые Internet Engineering Task Force , например FTP , [78] требуют поддержки UTF-8 с момента публикации RFC 2277 в 1998 году, в котором указано, что все протоколы IETF «ДОЛЖНЫ иметь возможность использовать кодировку UTF-8». [79]
Unicode стал доминирующей схемой для внутренней обработки и хранения текста. Хотя большая часть текста все еще хранится в устаревших кодировках, 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 для Unicode .
UTF-8 (первоначально разработанная для Plan 9 ) [80] стала основной кодировкой хранения в большинстве Unix-подобных операционных систем (хотя другие также используются некоторыми библиотеками), поскольку она является относительно простой заменой традиционных расширенных наборов символов ASCII. UTF-8 также является наиболее распространенной кодировкой Unicode, используемой в HTML- документах во Всемирной паутине .
Многоязычные движки рендеринга текста, использующие Unicode, включают Uniscribe и DirectWrite для Microsoft Windows, ATSUI и Core Text для macOS, а также Pango для GTK+ и рабочего стола GNOME .
Поскольку раскладки клавиатуры не могут содержать простых комбинаций клавиш для всех символов, некоторые операционные системы предоставляют альтернативные методы ввода, которые обеспечивают доступ ко всему репертуару.
ISO/IEC 14755 , [81] который стандартизирует методы ввода символов Unicode из их кодовых точек, определяет несколько методов. Существует базовый метод , где за начальной последовательностью следует шестнадцатеричное представление кодовой точки и конечная последовательность . Также указан метод ввода с выбором экрана , где символы перечислены в таблице на экране, например, с помощью программы карты символов.
Онлайн-инструменты для поиска кодовой точки для известного символа включают Unicode Lookup [82] Джонатана Хедли и Shapecatcher [83] Бенджамина Милде. В Unicode Lookup вводится ключ поиска (например, «дроби»), и возвращается список соответствующих символов с их кодовыми точками. В Shapecatcher, на основе Shape context , рисуется символ в поле, и возвращается список символов, приблизительно соответствующих рисунку, с их кодовыми точками.
MIME определяет два различных механизма кодирования не-ASCII-символов в электронной почте в зависимости от того, находятся ли символы в заголовках электронной почты (например, «Тема:») или в текстовом теле сообщения; в обоих случаях идентифицируется исходный набор символов, а также кодировка передачи. Для передачи электронной почты в формате Unicode рекомендуются набор символов UTF-8 и кодировка передачи Base64 или Quoted-printable в зависимости от того, состоит ли большая часть сообщения из символов ASCII . Подробности двух различных механизмов указаны в стандартах MIME и, как правило, скрыты от пользователей программного обеспечения электронной почты.
IETF определила [84] [85] структуру для интернационализированной электронной почты с использованием UTF-8 и обновила [86] [87] [88] [89] несколько протоколов в соответствии с этой структурой.
Внедрение Unicode в электронную почту происходит очень медленно. [ требуется цитата ] Некоторые восточноазиатские тексты по-прежнему кодируются в таких кодировках, как ISO-2022 , а некоторые устройства, такие как мобильные телефоны, [ требуется цитата ] по-прежнему не могут правильно обрабатывать данные Unicode. Однако поддержка улучшается. Многие основные поставщики бесплатной почты, такие как Yahoo! Mail , Gmail и Outlook.com, поддерживают его.
Все рекомендации W3C использовали Unicode в качестве набора символов документа , начиная с HTML 4.0. Веб-браузеры поддерживали Unicode, особенно UTF-8, в течение многих лет. Раньше были проблемы с отображением, вызванные в основном проблемами, связанными со шрифтами ; например, версии Microsoft Internet Explorer v6 и более ранние не отображали многие кодовые точки, если явно не было указано использовать шрифт, содержащий их. [90]
Хотя правила синтаксиса могут влиять на порядок, в котором символы разрешены, документы XML (включая XHTML ) по определению [91] содержат символы большинства кодовых точек Unicode, за исключением:
Символы HTML отображаются либо напрямую как байты в соответствии с кодировкой документа, если кодировка их поддерживает, либо пользователи могут записывать их как числовые ссылки на символы на основе кодовой точки символа Unicode. Например, ссылки Δ, Й, ק, م, ๗, あ, , 叶, 葉и 말(или те же числовые значения, выраженные в шестнадцатеричном формате с &#xпрефиксом ) должны отображаться во всех браузерах как Δ, Й, ק ,م, ๗, あ, 叶, 葉 и 말.
При указании URI , например, в качестве URL-адресов в HTTP- запросах, символы, не входящие в набор ASCII, должны быть закодированы с помощью процентов .
Unicode в принципе не касается шрифтов как таковых , рассматривая их как варианты реализации. [92] Любой заданный символ может иметь множество аллографов , от более распространенных жирных, курсивных и базовых буквенных форм до сложных декоративных стилей. Шрифт является «совместимым с Unicode», если к глифам в шрифте можно получить доступ с помощью кодовых точек, определенных в The Unicode Standard . [93] Стандарт не определяет минимальное количество символов, которые должны быть включены в шрифт; некоторые шрифты имеют довольно небольшой репертуар.
Бесплатные и розничные шрифты на основе Unicode широко доступны, поскольку TrueType и OpenType поддерживают Unicode (и Web Open Font Format (WOFF и WOFF2 ) основаны на них). Эти форматы шрифтов сопоставляют кодовые точки Unicode с глифами, но файлы шрифтов OpenType и TrueType ограничены 65 535 глифами. Файлы коллекций предоставляют механизм «gap mode» для преодоления этого ограничения в одном файле шрифта. (Однако каждый шрифт в коллекции по-прежнему имеет ограничение в 65 535.) Файл коллекции TrueType обычно имеет расширение файла «.ttc».
На рынке существуют тысячи шрифтов , но менее дюжины шрифтов — иногда описываемых как шрифты «общего Юникода» — пытаются поддерживать большую часть репертуара символов Юникода. Вместо этого шрифты на основе Юникода обычно фокусируются на поддержке только базового ASCII и определенных сценариев или наборов символов или символов. Несколько причин оправдывают такой подход: приложениям и документам редко требуется отображать символы из более чем одной или двух систем письма; шрифты, как правило, требуют ресурсов в вычислительных средах; а операционные системы и приложения демонстрируют все большую интеллектуальность в отношении получения информации о глифах из отдельных файлов шрифтов по мере необходимости, т. е. замены шрифтов . Более того, разработка согласованного набора инструкций по отображению для десятков тысяч глифов представляет собой монументальную задачу; такое предприятие проходит точку убывающей отдачи для большинства шрифтов.
Unicode частично решает проблему новой строки , которая возникает при попытке прочитать текстовый файл на разных платформах. Unicode определяет большое количество символов , которые соответствующие приложения должны распознавать как символы конца строки.
Что касается новой строки, Unicode представил U+2028 LINE SEPARATOR и U+2029 PARAGRAPH SEPARATOR . Это была попытка предоставить решение Unicode для семантического кодирования абзацев и строк, потенциально заменяя все различные решения платформы. При этом Unicode действительно предоставляет способ обойти исторические решения, зависящие от платформы. Тем не менее, немногие решения Unicode приняли эти разделители строк и абзацев Unicode в качестве единственных канонических символов окончания строки. Однако распространенный подход к решению этой проблемы заключается в нормализации новой строки. Это достигается с помощью текстовой системы Cocoa в macOS , а также с помощью рекомендаций W3C XML и HTML. При таком подходе каждый возможный символ новой строки преобразуется внутренне в общий символ новой строки (какой именно, на самом деле не имеет значения, поскольку это внутренняя операция, предназначенная только для рендеринга). Другими словами, текстовая система может правильно обрабатывать символ как новую строку, независимо от фактической кодировки ввода.
Группа идеографических исследований (IRG) занимается консультированием Консорциума и ISO относительно унификации Хань, или Unihan, особенно дальнейшего добавления унифицированных и совместимых идеограмм CJK в репертуар. IRG состоит из экспертов из каждого региона, который исторически использовал китайские иероглифы . Однако, несмотря на обсуждения в комитете, унификация Хань неизменно является одним из наиболее спорных аспектов Стандарта Unicode с момента зарождения проекта. [94]
Существующие стандарты набора символов, такие как японский JIS X 0208 (закодированный Shift JIS ), определили критерии унификации, то есть правила для определения того, когда вариант китайского иероглифа следует считать различием почерка/шрифта (и, таким образом, унифицировать), а не различием в написании (кодировать отдельно). Модель символов Unicode для символов CJK была основана на критериях унификации, используемых JIS X 0208, а также на критериях, разработанных Ассоциацией по единому китайскому коду в Китае. [95] Из-за принципа стандарта кодирования семантических, а не стилистических вариантов, Unicode подвергся критике за то, что не назначал кодовые точки определенным редким и архаичным вариантам кандзи , что могло усложнить обработку древних и необычных японских имен. Поскольку он делает особый акцент на том, что китайский, японский и корейский языки имеют много общих символов, объединение Хань также иногда воспринимается как рассмотрение этих трех как одного и того же. [96]
Существуют менее часто используемые альтернативные кодировки, часто предшествующие Unicode, с моделями символов, отличающимися от этой парадигмы, направленными на сохранение различных стилистических различий между региональными и/или нестандартными формами символов. Одним из примеров является код TRON, который предпочитают некоторые пользователи для обработки исторического японского текста, хотя и не широко распространен среди японской общественности. Другим примером является кодировка CCCII, принятая библиотечными системами в Гонконге , Тайване и Соединенных Штатах . Они имеют свои собственные недостатки в общем использовании, что привело к тому, что кодировка Big5 (введенная в 1984 году, через четыре года после CCCII) стала более распространенной, чем CCCII, за пределами библиотечных систем. [97] Хотя работа в Apple, основанная на тезаурусе CJK группы Research Libraries Group , который использовался для поддержки варианта EACC CCCII, была одним из прямых предшественников набора Unihan Unicode , Unicode принял модель унификации в стиле JIS. [95]
Самая ранняя версия Unicode имела репертуар менее чем из 21 000 символов Хан, в основном ограниченный теми, которые находятся в относительно распространенном современном использовании. По состоянию на версию 16.0, стандарт теперь кодирует более 97 000 символов Хан, и работа продолжается, чтобы добавить еще тысячи — в основном исторические и диалектные варианты символов, используемые во всей Синосфере .
Современные шрифты предоставляют средства для решения некоторых практических проблем при изображении унифицированных символов Хан с различными региональными графическими представлениями. Таблица OpenType 'locl' позволяет визуализатору выбирать другой глиф для каждой кодовой точки на основе локали текста. [98] Последовательности вариаций Unicode также могут предоставлять внутритекстовые аннотации для желаемого выбора глифа; для этого требуется регистрация конкретного варианта в базе данных идеографических вариаций .
Если соответствующие глифы для символов в одном и том же сценарии отличаются только курсивом, Unicode в целом унифицирует их, как можно увидеть в сравнении набора из семи курсивных глифов символов, которые обычно появляются в русских, традиционных болгарских, македонских и сербских текстах справа, что означает, что различия отображаются с помощью технологии интеллектуальных шрифтов или ручного изменения шрифтов. Используется та же техника OpenType 'locl'. [99]
Для использования в турецком алфавите и азербайджанском алфавите Unicode включает отдельную строчную букву I без точки (ı) и заглавную букву I с точкой ( İ ). Однако обычные буквы ASCII используются для строчной буквы I с точкой и заглавной буквы I без точки , что соответствует тому, как они обрабатываются в более раннем стандарте ISO 8859-9 . Таким образом, сравнения без учета регистра для этих языков должны использовать другие правила, чем сравнения без учета регистра для других языков, использующих латиницу. [100]
Напротив, исландский eth (ð) , перечеркнутая D (đ) и ретрофлексная D (ɖ) , которые обычно [примечание 4] выглядят одинаково в верхнем регистре (Đ), подвергаются противоположной обработке и кодируются отдельно в обоих регистрах (в отличие от более раннего ISO 6937 , который унифицирует заглавные формы). Хотя это позволяет проводить сравнение без учета регистра без необходимости знать язык текста, этот подход также имеет проблемы, требуя мер безопасности, связанных с атаками на омоглифы . [101]
Сохранит ли строчная буква I свое название при применении диакритического знака, также зависит от местных соглашений.
В Unicode имеется большое количество омоглифов , многие из которых выглядят очень похожими или идентичными буквам ASCII. Замена их может сделать идентификатор или URL-адрес, который выглядит правильным, но ведет в другое место, чем ожидалось. [102] Кроме того, омоглифы также могут использоваться для манипулирования выводом систем обработки естественного языка (NLP) . [103] Для смягчения требуется запретить эти символы, отображать их по-разному или требовать, чтобы они разрешались в один и тот же идентификатор; [104] все это усложняется из-за огромного и постоянно меняющегося набора символов. [105] [106]
В 2021 году два исследователя, один из Кембриджского университета , а другой из Эдинбургского университета , выпустили рекомендацию по безопасности , в которой они утверждают, что метки BiDi могут использоваться для того, чтобы заставить большие разделы кода делать что-то отличное от того, что они, по-видимому, делают. Проблема была названа « Trojan Source ». [107] В ответ на это редакторы кода начали выделять метки, чтобы обозначить принудительное изменение направления текста. [108]
Unicode был разработан для обеспечения преобразования формата «код-точка-за-код-точкой» в любые уже существующие кодировки символов и из них, так что текстовые файлы в старых наборах символов можно преобразовать в Unicode, а затем обратно и получить тот же файл, не используя контекстно-зависимую интерпретацию. Это означало, что несовместимые устаревшие архитектуры, такие как объединение диакритических знаков и предварительно составленных символов , существуют в Unicode, предоставляя более одного метода представления некоторого текста. Это наиболее выражено в трех различных формах кодировки для корейского хангыля . Начиная с версии 3.0, любые предварительно составленные символы, которые могут быть представлены объединенной последовательностью уже существующих символов, больше не могут быть добавлены в стандарт для сохранения взаимодействия между программным обеспечением, использующим разные версии Unicode.
Необходимо обеспечить инъективные отображения между символами в существующих устаревших наборах символов и символами в Unicode для упрощения преобразования в Unicode и обеспечения взаимодействия с устаревшим программным обеспечением. Отсутствие согласованности в различных отображениях между ранними японскими кодировками, такими как Shift-JIS или EUC-JP , и Unicode привело к несоответствиям преобразования форматов в обе стороны , в частности, отображение символа JIS X 0208 '～' (1-33, WAVE DASH), широко используемого в устаревших данных базы данных, либо в U+FF5E～FULLWIDTH TILDE (в Microsoft Windows ), либо в U+301C〜WAVE DASH (другие поставщики). [109]
Некоторые японские программисты возражали против Unicode, поскольку он требует от них разделять использование U+005C \ REVERSE SOLIDUS (обратная косая черта) и U+00A5 ¥ YEN SIGN , который был сопоставлен с 0x5C в JIS X 0201, и существует много устаревшего кода с таким использованием. [110] (Эта кодировка также заменяет тильду '~' 0x7E на макрон '¯', теперь 0xAF.) Разделение этих символов существует в ISO 8859-1 задолго до Unicode.
Индийским письменностям, таким как тамильский и деванагари , выделено всего 128 кодовых точек, что соответствует стандарту ISCII . Корректная визуализация индийского текста Unicode требует преобразования сохраненных логических символов в визуальный порядок и формирования лигатур (также известных как конъюнкты) из компонентов. Некоторые местные ученые выступали за назначение кодовых точек Unicode этим лигатурам, идя вразрез с практикой для других систем письма, хотя Unicode содержит некоторые арабские и другие лигатуры только для целей обратной совместимости. [111] [112] [113] Кодирование любых новых лигатур в Unicode не произойдет, отчасти потому, что набор лигатур зависит от шрифта, а Unicode — это кодировка, независимая от вариаций шрифта. Аналогичная проблема возникла в 2003 году с тибетским письмом , когда Управление по стандартизации Китая предложило кодировать 956 предварительно составленных тибетских слогов, [114] но они были отклонены соответствующим комитетом ISO ( ISO/IEC JTC 1/SC 2 ) для кодирования. [115]
Поддержка тайского алфавита подверглась критике за порядок тайских символов. Гласные เ, แ, โ, ใ, ไ, которые пишутся слева от предыдущей согласной, находятся в визуальном порядке, а не в фонетическом, в отличие от представлений Unicode других индийских письменностей. Это осложнение связано с тем, что Unicode унаследовал тайский промышленный стандарт 620 , который работал таким же образом и был способом, которым тайский язык всегда писался на клавиатурах. Эта проблема с порядком немного усложняет процесс сортировки Unicode, требуя поиска в таблице для переупорядочивания тайских символов для сортировки. [96] Даже если бы Unicode принял кодировку в соответствии с устным порядком, было бы проблематично сортировать слова в словарном порядке. Например, слово แสดง [sa dɛːŋ] «исполнять» начинается с согласного «สด» (с присущей ему гласной для согласного «ส»), гласная แ- в устной речи будет стоять после ด, но в словаре слово сопоставляется так, как оно пишется, с гласной после ส.
Символы с диакритическими знаками обычно могут быть представлены либо как один предварительный составной символ, либо как разложенная последовательность базовой буквы плюс один или несколько нераздельных знаков. Например, ḗ (предварительный составной e с макроном и акутом сверху) и ḗ (e, за которым следует объединяющий макрон сверху и объединяющий акут сверху) должны отображаться одинаково, оба отображаются как e с макроном (◌̄) и акутом (◌́), но на практике их внешний вид может различаться в зависимости от того, какой движок рендеринга и шрифты используются для отображения символов. Аналогично, нижние точки , необходимые при латинизации индийских языков , часто будут размещаться неправильно. [ необходима цитата ] Символы Unicode, которые сопоставляются с предварительно составленными глифами, могут использоваться во многих случаях, что позволяет избежать этой проблемы, но если предварительно составленный символ не был закодирован, проблему часто можно решить с помощью специального шрифта Unicode, такого как Charis SIL , который использует технологии Graphite , OpenType («gsub») или AAT для расширенных функций рендеринга.
Стандарт Unicode установил правила, призванные гарантировать стабильность. [116] В зависимости от строгости правила изменение может быть запрещено или разрешено. Например, «имя», присвоенное кодовой точке, не может и не будет меняться. Но свойство «скрипт» является более гибким, согласно собственным правилам Unicode. В версии 2.0 Unicode изменил многие «имена» кодовых точек с версии 1. В то же время Unicode заявил, что с этого момента присвоенное кодовой точке имя никогда не изменится. Это подразумевает, что когда ошибки публикуются, эти ошибки не могут быть исправлены, даже если они незначительны (как это произошло в одном случае с написанием BRAKCET вместо BRACKET в имени символа). В 2006 году был впервые опубликован список аномалий в именах символов, и по состоянию на июнь 2021 года было 104 символа с выявленными проблемами, [117] например:
Хотя Unicode определяет обозначение (имя) письменности как « Phags_Pa », в именах символов этой письменности добавляется дефис: U+A840 ꡀ PHAGS-PA LETTER KA . [120] [121] Однако это не аномалия, а правило: дефисы заменяются подчеркиваниями в обозначениях письменности. [120]
В 1978 году первоначальное предложение о наборе "универсальных знаков" было сделано
Бобом Белвиллем
в
Xerox PARC
. Многие люди внесли свои идеи в разработку нового дизайна кодировки. Начиная с 1980 года эти усилия переросли в
Xerox Character Code Standard
(XCCS) настоящего автора, многоязычную кодировку, которая поддерживается Xerox в качестве внутреннего корпоративного стандарта с 1982 года усилиями Эда Смуры, Рона Пеллара и других.
Unicode возник в результате восьмилетнего опыта работы с XCCS. Его фундаментальные отличия от XCCS были предложены Питером Фенвиком и Дейвом Опстадом (чистые 16-битные коды) и
Ли Коллинзом
(идеографическая унификация символов). Unicode сохраняет многие особенности XCCS, полезность которых была доказана годами в международной линии многоязычных системных продуктов связи.
Выберите этот формат развертывания, если ваша система поддерживает переменные шрифты и вы предпочитаете использовать только один язык, но также хотите иметь полный охват символов или возможность добавлять в текст языковые теги для использования глифов, подходящих для других языков (для этого требуется приложение, поддерживающее языковые теги и функцию OpenType 'locl' GSUB).
Медиа из Commons
Учебники из Wikibooks