Кодировка юникод что это
Юникод для чайников
Сам я не очень люблю заголовки вроде «Покемоны в собственном соку для чайников\кастрюль\сковородок», но это кажется именно тот случай — говорить будем о базовых вещах, работа с которыми довольно часто приводить к купе набитых шишек и уйме потерянного времени вокруг вопроса — «Почему же оно не работает?». Если вы до сих пор боитесь и\или не понимаете Юникода — прошу под кат.
Зачем?
Главный вопрос новичка, который встречается с впечатляющим количеством кодировок и на первый взгляд запутанными механизмами работы с ними (например, в Python 2.x). Краткий ответ — потому что так сложилось 🙂
Кодировкой, кто не знает, называют способ представления в памяти компьютера (читай — в нулях-единицах\числах) цифр, буков и всех остальных знаков. Например, пробел представляется как 0b100000 (в двоичной), 32 (в десятичной) или 0x20 (в шестнадцатеричной системе счисления).
Так вот, когда-то памяти было совсем немного и всем компьютерам было достаточно 7 бит для представления всех нужных символов (цифры, строчный\прописной латинский алфавит, куча знаков и так называемые управляемые символы — все возможные 127 номеров были кому-то отданы). Кодировка в это время была одна — ASCII. Шло время, все были счастливы, а кто не был счастлив (читай — кому не хватало знака «©» или родной буквы «щ») — использовали оставшиеся 128 знаков на свое усмотрение, то есть создавали новые кодировки. Так появились и ISO-8859-1, и наши (то есть кириличные) cp1251 и KOI8. Вместе с ними появилась и проблема интерпретации байтов типа 0b1******* (то есть символов\чисел от 128 и до 255) — например, 0b11011111 в кодировке cp1251 это наша родная «Я», в тоже время в кодировке ISO-8859-1 это греческая немецкая Eszett (подсказывает Moonrise) «ß». Ожидаемо, сетевая коммуникация и просто обмен файлами между разными компьютерами превратились в чёрт-знает-что, несмотря на то, что заголовки типа ‘Content-Encoding’ в HTTP протоколе, email-письмах и HTML-страницах немного спасали ситуацию.
В этот момент собрались светлые умы и предложили новый стандарт — Unicode. Это именно стандарт, а не кодировка — сам по себе Юникод не определяет, как символы будут сохранятся на жестком диске или передаваться по сети. Он лишь определяет связь между символом и некоторым числом, а формат, согласно с которым эти числа будут превращаться в байты, определяется Юникод-кодировками (например, UTF-8 или UTF-16). На данный момент в Юникод-стандарте есть немного более 100 тысяч символов, тогда как UTF-16 позволяет поддерживать более одного миллиона (UTF-8 — и того больше).
Ближе к делу!
Естественно, есть поддержка Юникода и в Пайтоне. Но, к сожалению, только в Python 3 все строки стали юникодом, и новичкам приходиться убиваться об ошибки типа:
Давайте разберемся, но по порядку.
Зачем кто-то использует Юникод?
Почему мой любимый html-парсер возвращает Юникод? Пусть возвращает обычную строку, а я там уже с ней разберусь! Верно? Не совсем. Хотя каждый из существующих в Юникоде символов и можно (наверное) представить в некоторой однобайтовой кодировке (ISO-8859-1, cp1251 и другие называют однобайтовыми, поскольку любой символ они кодируют ровно в один байт), но что делать если в строке должны быть символы с разных кодировок? Присваивать отдельную кодировку каждому символу? Нет, конечно, надо использовать Юникод.
Зачем нам новый тип «unicode»?
Вот мы и добрались до самого интересного. Что такое строка в Python 2.x? Это просто байты. Просто бинарные данные, которые могут быть чем-угодно. На самом деле, когда мы пишем что-нибудь вроде:интерпретатор не создает переменную, которая содержит первые четыре буквы латинского алфавита, но только последовательность с четырёх байт, и латинские буквы здесь используются исключительно для обозначения именно этого значения байта. То есть ‘a’ здесь просто синоним для написания ‘\x61’, и ни чуточку больше. Например:
И ответ на вопрос — зачем нам «unicode» уже более очевиден — нужен тип, который будет представятся символами, а не байтами.
Хорошо, я понял чем есть строка. Тогда что такое Юникод в Пайтоне?
«type unicode» — это прежде всего абстракция, которая реализует идею Юникода (набор символов и связанных с ними чисел). Объект типа «unicode» — это уже не последовательность байт, но последовательность собственно символов без какого либо представления о том, как эти символы эффективно сохранить в памяти компьютера. Если хотите — это более высокой уровень абстракции, чем байтовый строки (именно так в Python 3 называют обычные строки, которые используются в Python 2.6).
Как пользоваться Юникодом?
Как из юникод-строки получить обычную? Закодировать её:
Алгоритм кодирования естественно обратный приведенному выше.
Не кодируется 🙁
Разберем примеры с начала статьи. Как работает конкатенация строки и юникод-строки? Простая строка должна быть превращена в юникод-строку, и поскольку интерпретатор не знает кодировки, от использует кодировку по умолчанию — ascii. Если этой кодировке не удастся декодировать строку, получим некрасивую ошибку. В таком случае нам нужно самим привести строку к юникод-строке, используя правильную кодировку:
«UnicodeDecodeError» обычно есть свидетельством того, что нужно декодировать строку в юникод, используя правильную кодировку.
Теперь использование «str» и юникод-строк. Не используйте «str» и юникод строки 🙂 В «str» нет возможности указать кодировку, соответственно кодировка по умолчанию будет использоваться всегда и любые символы > 128 будут приводить к ошибке. Используйте метод «encode»:
«UnicodeEncodeError» — знак того, что нам нужно указать правильную кодировку во время превращения юникод-строки в обычную (или использовать второй параметр ‘ignore’\’replace’\’xmlcharrefreplace’ в методе «encode»).
Хочу ещё!
Хорошо, используем бабу-ягу из примера выше ещё раз:
Есть ещё способ использования «u»» для представления, например, кириллицы, и при этом не указывать кодировку или нечитабельные юникод-поинты (то есть «u’\u1234’»). Способ не совсем удобный, но интересный — использовать unicode entity codes:
Ну и вроде всё. Основные советы — не путать «encode»\«decode» и понимать различия между байтами и символами.
Python 3
Здесь без кода, ибо опыта нет. Свидетели утверждают, что там всё значительно проще и веселее. Кто возьмется на кошках продемонстрировать различия между здесь (Python 2.x) и там (Python 3.x) — респект и уважуха.
Полезно
Раз уж мы о кодировках, порекомендую ресурс, который время-от-времени помогает побороть кракозябры — http://2cyr.com/decode/?lang=ru.
Unicode HOWTO — официальный документ о том где, как и зачем Юникод в Python 2.x.
Спасибо за внимание. Буду благодарен за замечания в приват.
Юникод: необходимый практический минимум для каждого разработчика
Юникод — это очень большой и сложный мир, ведь стандарт позволяет ни много ни мало представлять и работать в компьютере со всеми основными письменностями мира. Некоторые системы письма существуют уже более тысячи лет, причём многие из них развивались почти независимо друг от друга в разных уголках мира. Люди так много всего придумали и оно зачастую настолько непохоже друг на друга, что объединить всё это в единый стандарт было крайне непростой и амбициозной задачей.
Чтобы по-настоящему разобраться с Юникодом нужно хотя бы поверхностно представлять себе особенности всех письменностей, с которыми позволяет работать стандарт. Но так ли это нужно каждому разработчику? Мы скажем, что нет. Для использования Юникода в большинстве повседневных задач, достаточно владеть разумным минимумом сведений, а дальше углубляться в стандарт по мере необходимости.
В статье мы расскажем об основных принципах Юникода и осветим те важные практические вопросы, с которыми разработчики непременно столкнутся в своей повседневной работе.
Зачем понадобился Юникод?
До появления Юникода, почти повсеместно использовались однобайтные кодировки, в которых граница между самими символами, их представлением в памяти компьютера и отображением на экране была довольно условной. Если вы работали с тем или иным национальным языком, то в вашей системе были установлены соответствующие шрифты-кодировки, которые позволяли отрисовывать байты с диска на экране таким образом, чтобы они представляли смысл для пользователя.
Если вы распечатывали на принтере текстовый файл и на бумажной странице видели набор непонятных кракозябр, это означало, что в печатающее устройство не загружены соответствующие шрифты и оно интерпретирует байты не так, как вам бы этого хотелось.
У такого подхода в целом и однобайтовых кодировок в частности был ряд существенных недостатков:
Основные принципы Юникода
Все мы прекрасно понимаем, что компьютер ни о каких идеальных сущностях знать не знает, а оперирует битами и байтами. Но компьютерные системы пока создают люди, а не машины, и для нас с вами иногда бывает удобнее оперировать умозрительными концепциями, а затем уже переходить от абстрактного к конкретному.
Важно! Одним из центральных принципов в философии Юникода является чёткое разграничение между символами, их представлением в компьютере и их отображением на устройстве вывода.
Вводится понятие абстрактного юникод-символа, существующего исключительно в виде умозрительной концепции и договорённости между людьми, закреплённой стандартом. Каждому юникод-символу поставлено в соответствие неотрицательное целое число, именуемое его кодовой позицией (code point).
Так, например, юникод-символ U+041F — это заглавная кириллическая буква П. Существует несколько возможностей представления данного символа в памяти компьютера, ровно как и несколько тысяч способов отображения его на экране монитора. Но при этом П, оно и в Африке будет П или U+041F.
Это хорошо нам знакомая инкапсуляция или отделение интерфейса от реализации — концепция, отлично зарекомендовавшая себя в программировании.
Получается, что руководствуясь стандартом, любой текст можно закодировать в виде последовательности юникод-символов
записать на листочке, упаковать в конверт и переслать в любой конец Земли. Если там знают о существовании Юникода, то текст будет воспринят ими ровно так же, как и нами с вами. У них не будет ни малейших сомнений, что предпоследний символ — это именно кириллическая строчная е (U+0435), а не скажем латинская маленькая e (U+0065). Обратите внимание, что мы ни слова не сказали о байтовом представлении.
Хотя юникод-символы и называются символами, они далеко не всегда соответствуют символу в традиционно-наивном понимании, например букве, цифре, пунктуационному знаку или иероглифу. (Подробнее смотри под спойлером.)
Что такое символ, чем отличается графемный кластер (читай: воспринимаемое как единое целое изображение символа) от юникод-символа и от кодового кванта мы расскажем в следующий раз.
Кодовое пространство Юникода
Кодовое пространство Юникода состоит из 1 114 112 кодовых позиций в диапазоне от 0 до 10FFFF. Из них к девятой версии стандарта значения присвоены лишь 128 237. Часть пространства зарезервирована для частного использования и консорциум Юникода обещает никогда не присваивать значения позициям из этих специальный областей.
Ради удобства всё пространство поделено на 17 плоскостей (сейчас задействовано шесть их них). До недавнего времени было принято говорить, что скорее всего вам придётся столкнуться только с базовой многоязыковой плоскостью (Basic Multilingual Plane, BMP), включающей в себя юникод-символы от U+0000 до U+FFFF. (Забегая немного вперёд: символы из BMP представляются в UTF-16 двумя байтами, а не четырьмя). В 2016 году этот тезис уже вызывает сомнения. Так, например, популярные символы Эмодзи вполне могут встретиться в пользовательском сообщении и нужно уметь их корректно обрабатывать.
Кодировки
Если мы хотим переслать текст через Интернет, то нам потребуется закодировать последовательность юникод-символов в виде последовательности байтов.
Стандарт Юникода включает в себя описание ряда юникод-кодировок, например UTF-8 и UTF-16BE/UTF-16LE, которые позволяют кодировать всё пространство кодовых позиций. Конвертация между этими кодировками может свободно осуществляться без потерь информации.
Также никто не отменял однобайтные кодировки, но они позволяют закодировать свой индивидуальный и очень узкий кусочек юникод-спектра — 256 или менее кодовых позиций. Для таких кодировок существуют и доступны всем желающим таблицы, где каждому значению единственного байта сопоставлен юникод-символ (см. например CP1251.TXT). Несмотря на ограничения, однобайтные кодировки оказываются весьма практичными, если речь идёт о работе с большим массивом моноязыковой текстовой информации.
Из юникод-кодировок самой распространённой в Интернете является UTF-8 (она завоевала пальму первенства в 2008 году), главным образом благодаря её экономичности и прозрачной совместимости с семибитной ASCII. Латинские и служебные символы, основные знаки препинания и цифры — т.е. все символы семибитной ASCII — кодируются в UTF-8 одним байтом, тем же, что и в ASCII. Символы многих основных письменностей, не считая некоторых более редких иероглифических знаков, представлены в ней двумя или тремя байтами. Самая большая из определённых стандартом кодовых позиций — 10FFFF — кодируется четырьмя байтами.
Обратите внимание, что UTF-8 — это кодировка с переменной длиной кода. Каждый юникод-символ в ней представляется последовательностью кодовых квантов с минимальной длиной в один квант. Число 8 означает битовую длину кодового кванта (code unit) — 8 бит. Для семейства кодировок UTF-16 размер кодового кванта составляет, соответственно, 16 бит. Для UTF-32 — 32 бита.
Если вы пересылаете по сети HTML-страницу с кириллическим текстом, то UTF-8 может дать весьма ощутимый выигрыш, т.к. вся разметка, а также JavaScript и CSS блоки будут эффективно кодироваться одним байтом. К примеру главная страница Хабра в UTF-8 занимает 139Кб, а в UTF-16 уже 256Кб. Для сравнения, если использовать win-1251 с потерей возможности сохранять некоторые символы, то размер, по сравнению с UTF-8, сократится всего на 11Кб до 128Кб.
Для хранения строковой информации в приложениях часто используются 16-битные юникод-кодировки в силу их простоты, а так же того факта, что символы основных мировых систем письма кодируются одним шестнадцатибитовым квантом. Так, например, Java для внутреннего представления строк успешно применяет UTF-16. Операционная система Windows внутри себя также использует UTF-16.
В любом случае, пока мы остаёмся в пространстве Юникода, не так уж и важно, как хранится строковая информация в рамках отдельного приложения. Если внутренний формат хранения позволяет корректно кодировать все миллион с лишним кодовых позиций и на границе приложения, например при чтении из файла или копировании в буфер обмена, не происходит потерь информации, то всё хорошо.
Для корректной интерпретации текста, прочитанного с диска или из сетевого сокета, необходимо сначала определить его кодировку. Это делается либо с использованием метаинформации, предоставленной пользователем, записанной в тексте или рядом с ним, либо определяется эвристически.
В сухом остатке
Информации много и имеет смысл привести краткую выжимку всего, что было написано выше:
Краткое замечание про кодирование
С термином кодирование может произойти некоторая путаница. В рамках Юникода кодирование происходит дважды. Первый раз кодируется набор символов Юникода (character set), в том смысле, что каждому юникод-символу ставится с соответствие кодовая позиция. В рамках этого процесса набор символов Юникода превращается в кодированный набор символов (coded character set). Второй раз последовательность юникод-символов преобразуется в строку байтов и этот процесс также называется кодирование.
В англоязычной терминологии существуют два разных глагола to code и to encode, но даже носители языка зачастую в них путаются. К тому же термин набор символов (character set или charset) используется в качестве синонима к термину кодированный набор символов (coded character set).
Всё это мы говорим к тому, что имеет смысл обращать внимание на контекст и различать ситуации, когда речь идёт о кодовой позиции абстрактного юникод-символа и когда речь идёт о его байтовом представлении.
Юникод
Юникод — это мировой стандарт кодировки символов. Система использует Юникод исключительно для обработки символов и строк. Подробное описание всех аспектов Юникода см. в стандарте Юникода.
По сравнению с более старыми механизмами обработки символьных и строковых данных, Юникод упрощает локализацию программного обеспечения и улучшает обработку многоязычного текста. Используя Юникод для представления символьных и строковых данных в приложениях, можно включить возможности универсального обмена данными для глобального маркетинга, используя один двоичный файл для каждого возможного кода символа. Юникод выполняет следующие действия:
Юникод поддерживает множество сценариев, используемых в разных языках мира, а также большое количество технических символов и специальных символов, используемых при публикации. Поддерживаются следующие сценарии: латиница, Греческий, кириллица, иврит, арабский, деванагари, тайский, Таиланд, хангыль, хирагана и катакана. В число поддерживаемых языков входят, но не ограничено, немецкий, французский, английский, Греческий, Русский, иврит, арабский, хинди, тайский, китайский, корейский и японский. В настоящее время Юникод может представлять подавляющее большинство символов в современных компьютерах по всему миру, а также обновляться, чтобы сделать его еще более полным.
Набор символов Юникода включает множество Объединенных символов, например U + 0308 («ё»), объединяющий диересис или умляут. Юникод часто представляет один и тот же глиф в форме «», состоящей из «», или «», разделенной «». Например, составной формой «Ä» является одиночная кодовая точка Юникода «Ä» (U + 00C4), а ее настоящую форма — «A» + «ё» (U + 0041 U + 0308). В Юникоде не определена составная форма для каждого глифа. Например, вьетнамский символ «o» в нижнем регистре с циркумфлексом и тильдой («ỗ») представлен в виде U + 006F U + 0302 U + 0303 (o + циркумфлексом + тильда). Более подробное обсуждение сочетаний символов и связанных с ними проблем см. в разделе Использование нормализации Юникода для представления строк.
Для обеспечения совместимости с 8-и 7-разрядными средами Юникод также можно кодировать как UTF-8 и UTF-7 соответственно. хотя функции с поддержкой юникода в Windows используют utf-16, также можно работать с данными, закодированными в utf-8 или utf-7, которые поддерживаются в Windows виде кодовых страницнабора многобайтовых символов.
новые Windows приложения должны использовать UTF-16 в качестве внутреннего представления данных. Windows также предоставляет обширную поддержку для кодовых страниц, и смешанное использование в одном приложении возможно. Даже новые приложения на основе Юникода иногда приходится работать с кодовыми страницами. Причины этого описаны в разделе кодовые страницы.
Приложение может использовать функции MultiByteToWideChar и WideCharToMultiByte для преобразования между строками на основе кодовых страниц и строк Юникода. Несмотря на то, что их имена относятся к «многобайтовой», эти функции хорошо работают с кодовыми страницами однобайтовых кодировок (SBCS), двухбайтовых кодировок (DBCS) и многобайтовой кодировки (MBCS).
как правило, Windows приложение должно использовать внутреннюю кодировку UTF-16, преобразуя его только как часть «тонкого слоя» через интерфейс, который должен использовать другой формат. Этот метод защищает от потери и повреждения данных. Каждая кодовая страница поддерживает разные символы, но ни одна из них не поддерживает полный спектр символов, предоставляемых в Юникоде. Большинство кодовых страниц поддерживают различные подмножества, которые кодируются по-разному. Кодовые страницы для UTF-8 и UTF-7 являются исключением, так как они поддерживают полный набор символов Юникода, а преобразование между этими кодировками и UTF-16 — без потерь.
Данные, преобразованные непосредственно из кодировки, используемой одной кодовой страницей, в кодировку, используемую другим кодом, могут быть повреждены, так как одно и то же значение данных на разных кодовых страницах может кодировать другой символ. Даже если приложение преобразуется как можно ближе к интерфейсу, необходимо тщательно обдумать Диапазон обрабатываемых данных.
Данные, преобразованные из Юникода в кодовую страницу, подвергаются потери данных, поскольку данная кодовая страница может не представлять каждый символ, используемый в этих данных в Юникоде. Поэтому обратите внимание, что WideCharToMultiByte может потерять некоторые данные, если Целевая кодовая страница не может представлять все символы в строке Юникода.
При модернизации устаревших приложений на основе кодовых страниц для использования Юникода можно использовать универсальные функции и текстовый макрос для поддержки одного набора источников, из которого компилируются две версии приложения. одна версия поддерживает юникод, а другая — с Windows кодовыми страницами. используя этот механизм, можно преобразовать даже очень крупные приложения из Windows кодовые страницы в юникод, сохраняя источники приложений, которые могут быть скомпилированы, построены и протестированы на всех этапах преобразования. Дополнительные сведения см. в разделе соглашения для прототипов функций.
В символах и строках Юникода используются типы данных, отличные от тех, которые используются для символов и строк на основе кодовой страницы. Вместе с набором макросов и соглашений об именовании это различие снижает вероятность случайного смешивания двух типов символьных данных. Он упрощает проверку типов компилятора, чтобы обеспечить использование только значений параметров Юникода с функциями, ожидающими строки в Юникоде.
Национальная библиотека им. Н. Э. Баумана
Bauman National Library
Персональные инструменты
Unicode
Юникод (англ. Unicode ) — стандарт кодирования символов, позволяющий представить знаки почти всех письменных языков. Стандарт предложен в 1991 году некоммерческой организацией «Консорциум Юникода». Применение этого стандарта позволяет закодировать очень большое число символов из разных письменностей: в документах Unicode могут соседствовать китайские иероглифы, математические символы, буквы греческого алфавита, латиницы и кириллицы, при этом становится ненужным переключение кодовых страниц.
Стандарт состоит из двух основных разделов: универсальный набор символов (UCS, universal character set) и семейство кодировок (UTF, Unicode transformation format). Универсальный набор символов задаёт однозначное соответствие символов кодам — элементам кодового пространства, представляющим неотрицательные целые числа. Семейство кодировок определяет машинное представление последовательности кодов UCS.
Коды в стандарте Юникод разделены на несколько областей. Область с кодами от U+0000 до U+007F содержит символы набора ASCII с соответствующими кодами. Далее расположены области знаков различных письменностей, знаки пунктуации и технические символы. Часть кодов зарезервирована для использования в будущем. Под символы кириллицы выделены области знаков с кодами от U+0400 до U+052F, от U+2DE0 до U+2DFF, от U+A640 до U+A69F.
Содержание
Предпосылки создания и развитие Юникода
К концу 1980-х годов стандартом стали 8-битные символы. При этом существовало множество разных 8-битных кодировок, и постоянно появлялись всё новые. Это объяснялось как постоянным расширением круга поддерживаемых языков, так и стремлением создать кодировку, частично совместимую с какой-нибудь другой (характерный пример — появление альтернативной кодировки для русского языка, обусловленное эксплуатацией западных программ, созданных для кодировки CP437). В результате появилось несколько проблем:
Проблема «кракозябр» — проблема отображения документов в неправильной кодировке. Проблему можно было решить либо последовательным внедрением методов указания используемой кодировки, либо внедрением единой (общей) для всех кодировки.
Проблема ограниченности набора символов. Проблему можно было решить либо переключением шрифтов внутри документа, либо внедрением «широкой» кодировки. Переключение шрифтов издавна практиковалось в текстовых процессорах, причём часто использовались шрифты с нестандартной кодировкой, т.н. «dingbat fonts». В итоге при попытке переноса документа в другую систему все нестандартные символы превращались в «кракозябры».
Проблема преобразования одной кодировки в другую. Проблему можно было решить либо составлением таблиц перекодировки для каждой пары кодировок, либо использованием промежуточного преобразования в третью кодировку, включающую все символы всех кодировок.
Проблема дублирования шрифтов. Для каждой кодировки создавался свой шрифт, даже если наборы символов в кодировках совпадали частично или полностью. Проблему можно было решить путём создания «больших» шрифтов, из которых впоследствии выбирались бы нужные для данной кодировки символы. Однако это требовало создания единого реестра символов, чтобы определять, чему что соответствует.
Была признана необходимость создания единой «широкой» кодировки. Кодировки с переменной длиной символа, широко использующиеся в Восточной Азии, были признаны слишком сложными в использовании, поэтому было решено использовать символы фиксированной ширины. Использование 32-битных символов казалось слишком расточительным, поэтому было решено использовать 16-битные.
В дальнейшем, однако, было принято решение кодировать все символы и в связи с этим значительно расширить кодовую область. Одновременно с этим, коды символов стали рассматриваться не как 16-битные значения, а как абстрактные числа, которые в компьютере могут представляться множеством разных способов.
Поскольку в ряде компьютерных систем (например, Windows NT) фиксированные 16-битные символы уже использовались в качестве кодировки по умолчанию, было решено все наиболее важные знаки кодировать только в пределах первых 65 536 позиций (так называемая англ. basic multilingual plane, BMP ). Остальное пространство используется для «дополнительных символов»: систем письма вымерших языков или очень редко используемых китайских иероглифов, математических и музыкальных символов.
Для совместимости со старыми 16-битными системами была изобретена система UTF-16, где первые 65 536 позиций, за исключением позиций из интервала U+D800…U+DFFF, отображаются непосредственно как 16-битные числа, а остальные представляются в виде «суррогатных пар» (первый элемент пары из области U+D800…U+DBFF, второй элемент пары из области U+DC00…U+DFFF). Для суррогатных пар была использована часть кодового пространства (2048 позиций), отведённого «для частного использования».
Поскольку в UTF-16 можно отобразить только 2 20 +2 16 −2048 (1 112 064) символов, то это число и было выбрано в качестве окончательной величины кодового пространства Юникода (диапазон кодов: 0x000000-0x10FFFF).
Хотя кодовая область Юникода была расширена за пределы 2 16 уже в версии 2.0, первые символы в «верхней» области были размещены только в версии 3.1.
Роль этой кодировки в веб-секторе постоянно растёт. На начало 2010 доля веб-сайтов, использующих Юникод, составила около 50 %.
Версии Юникода
Работа по доработке стандарта продолжается. Новые версии выпускаются по мере изменения и пополнения таблиц символов. Параллельно выпускаются новые документы ISO/IEC 10646.
Первый стандарт выпущен в 1991 году, последний — в 2016, следующий ожидается летом 2017 года. Стандарты версий 1.0—5.0 публиковались как книги, и имеют ISBN. Номер версии стандарта составлен из трёх цифр (например, «4.0.1»). Третью цифру меняют при внесении в стандарт небольших изменений, не добавляющих новых символов.
| Номер версии | Дата публикации | ISBN книги | Издание ISO/IEC 10646 | Количество письменностей | Количество символов | Изменения |
|---|---|---|---|---|---|---|
| 1.0.0 | Октябрь 1991 | ISBN 0-201-56788-1 (Vol.1) | 24 | 7161 | Изначально таблицы Юникода содержали символы следующих письменностей: арабское письмо, армянское письмо, бенгальское письмо, чжуиньское письмо, кириллица, деванагари, грузинское письмо, греческое и коптское письмо, гуджарати, гурмукхи, хангыль, еврейское письмо, хирагана, каннада, Катакана, лаосское письмо, латинское письмо, малаялам, ория, тамильское письмо, телугу, тайское письмо и тибетское письмо | |
| 1.0.1 | Июнь 1992 | ISBN 0-201-60845-6 (Vol.2) | 25 | 28 359 | Добавлено 20 902 идеограммы китайского, японского и корейского письма | |
| 1.1 | Июнь 1993 | ISO/IEC 10646-1:1993 | 24 | 34 233 | Добавлено более 4306 слогов хангыля, дополнивших уже имеющиеся в таблицах 2350 символов. Удалены символы тибетского письма | |
| 2.0 | Июль 1996 | ISBN 0-201-48345-9 | ISO/IEC 10646-1:1993 и Amendments 5, 6, 7 | 25 | 38 950 | Удалены добавленные ранее слоги хангыля, и добавлены 11 172 новых слога хангыля с новыми кодами. Возвращены удалённые ранее символы тибетского письма; символы получили новые коды и были размещены в разных таблицах. Введён механизм суррогатных символов. Выделено место для плоскостей (англ. planes) 15 и 16 |
| 2.1 | Май 1998 | ISO/IEC 10646-1:1993, Amendments 5, 6, 7, два символа из Amendment 18 | 25 | 38 952 | Добавлен символ евро | |
| 3.0 | Сентябрь 1999 | ISBN 0-201-61633-5 | ISO/IEC 10646-1:2000 | 38 | 49 259 | Добавлены символы следующих письменностей: письмо чероки, эфиопское письмо, кхмерское письмо, монгольские письменности, бирманское письмо, огамическое письмо, руны, сингальское письмо, сирийское письмо, тана, канадское слоговое письмо и письмо и, а также символы шрифта Брайля |
| 3.1 | Март 2001 | ISO/IEC 10646-1:2000 |
Кодовое пространство
Хотя формы записи UTF-8 и UTF-32 позволяют кодировать до 2 31 (2 147 483 648) кодовых позиций, было принято решение использовать лишь 1 112 064 для совместимости с UTF-16. Впрочем, даже и этого на текущий момент более чем достаточно — в версии 6.0 используется чуть менее 110 000 кодовых позиций (109 242 графических и 273 прочих символа).
Кодовое пространство разбито на 17 плоскостей по 2 16 (65 536) символов. Нулевая плоскость называется базовой и содержит символы наиболее употребительных письменностей. Остальные плоскости — дополнительные. Первая плоскость используется в основном для исторических письменностей, вторая — для редко используемых иероглифов китайского письма (ККЯ), третья зарезервирована для архаичных китайских иероглифов. Плоскости 15 и 16 выделены для частного употребления. Для обозначения символов Unicode используется запись вида «U+xxxx» (для кодов 0…FFFF), или «U+xxxxx» (для кодов 10000…FFFFF), или «U+xxxxxx» (для кодов 100000…10FFFF), где xxx — шестнадцатеричные цифры. Например, символ «я» (U+044F) имеет код 044F16= 110310.
| Плоскости Юникода | ||
|---|---|---|
| Плоскость | Название | Диапазон символов |
| 0 | Базовая многоязыковая плоскость (Basic multilingual plane, BMP) | U+0000…U+FFFF |
| 1 | Дополнительная многоязыковая плоскость (Supplementary multilingual plane, SMP) | U+10000…U+1FFFF |
| 2 | Дополнительная иероглифическая плоскость (Supplementary ideographic plane, SIP) | U+20000…U+2FFFF |
| 3 | Третичная иероглифическая плоскость (Tertiary ideographic plane, TIP) | U+30000…U+3FFFF |
| 4—13 | не используются | U+40000…U+DFFFF |
| 14 | Дополнительная плоскость особого назначения (Supplementary special-purpose plane, SSP) | U+E0000…U+EFFFF |
| 15—16 | Дополнительные области для частного использования (Supplementary private use area, SPUA-A/B) | U+F0000…U+10FFFF |
Система кодирования
Универсальная система кодирования (Юникод) представляет собой набор графических символов и способ их кодирования для компьютерной обработки текстовых данных.
Графические символы — это символы, имеющие видимое изображение. Графическим символам противопоставляются управляющие символы и символы форматирования.
Графические символы включают в себя следующие группы:
Юникод — это система для линейного представления текста. Символы, имеющие дополнительные над- или подстрочные элементы, могут быть представлены в виде построенной по определённым правилам последовательности кодов (составной вариант, composite character) или в виде единого символа (монолитный вариант, precomposed character). На данный момент (2014) считается, что все буквы крупных письменностей в Юникод внесены, и если символ доступен в составном варианте, дублировать его в монолитном виде не нужно.
Политика консорциума
Консорциум не создаёт нового, а констатирует сложившийся порядок вещей. Например, картинки «эмодзи» были добавлены потому, что японские операторы мобильной связи широко их использовали. Для этого добавление символа проходит через сложный процесс. И, например, символ российского рубля прошёл его за три месяца просто потому, что получил официальный статус.
Товарные знаки кодируют только в порядке исключения. Так, в Юникоде нет флага Windows или яблока Apple.
Как только символ появился в кодировке, он никогда не сдвинется и не исчезнет. Если же потребуется изменить порядок символов, это делается не переменой позиций, а национальным порядком сортировки. Есть и другие, более тонкие гарантии стабильности — например, не будут меняться таблицы нормализации.
Объединение и дублирование символов
Один и тот же символ может иметь несколько форм; в Юникод эти формы входят одной кодовой позицией:
С другой стороны, если исторически в шрифтах были две разных кодовых позиции, они остаются разными и в Юникоде. Строчная греческая сигма имеет две формы, и у них разные позиции. Буква расширенной латиницы Å (A с кружком) и знак ангстрема Å, греческая буква μ и обозначение приставки «микро-» µ — разные символы.
Конечно же, похожие символы в неродственных письменностях ставятся в разные кодовые позиции. Например, буква А в латинице,кириллице,греческом и чероки — разные символы.
Крайне редко один и тот же символ ставится в две разные кодовые позиции для упрощения обработки текста. Математический штрих и такой же штрих для индикации мягкости звуков — разные символы, второй считается буквой.
Алгоритмы нормализации
Поскольку одни и те же символы можно представить различными кодами, сравнение строк байт за байтом становится невозможным. Алгоритмы нормализации (англ. normalization forms ) решают эту проблему, выполняя приведение текста к определённому стандартному виду. Приведение осуществляется путём замены символов на эквивалентные с использованием таблиц и правил. «Декомпозицией» называется замена (разложение) одного символа на несколько составляющих символов, а «композицией», наоборот, — замена (соединение) нескольких составляющих символов на один символ.
В стандарте Юникода определены 4 алгоритма нормализации текста: NFD, NFC, NFKD и NFKC.
NFD,англ. normalization form D («D» от англ. decomposition ), форма нормализации D — каноническая декомпозиция — алгоритм, согласно которому выполняется рекурсивная замена монолитных символов (англ. precomposed characters) на несколько составных (англ. composite characters ) в соответствии с таблицами декомпозиции.
| → |
|
| |||||||
| → |
|
|
| |||||||||
| → |
|
|
| |||||||||||
| → |
|
|
| |||||||||||||
NFC, англ. normalization form C («C» от англ. composition ), форма нормализации C — алгоритм, согласно которому последовательно выполняются каноническая декомпозиция и каноническая композиция. Сначала каноническая декомпозиция (алгоритм NFD) приводит текст к форме D. Затем каноническая композиция — операция, обратная NFD, обрабатывает текст от начала к концу с учётом следующих правил:
|
| → |
| |||||||
NFKD, англ. normalization form KD , форма нормализации KD — совместимая декомпозиция — алгоритм, согласно которому последовательно выполняются каноническая декомпозиция и замены символов текста по таблицам совместимой декомпозиции. Таблицы совместимой декомпозиции предусматривают замену на почти эквивалентные символов:
| → |
| |||||
| → |
| |||||
| → |
| |||||
| → |
| |||||
| → |
| |||||
| → |
| |||||||||
| → |
| |||||||
NFKC, англ. normalization form KC , форма нормализации KC — алгоритм, согласно которому последовательно выполняются совместимая декомпозиция (алгоритм NFKD) и каноническая композиция (алгоритм NFC). Примеры:
| Исходный текст | NFD | NFC | NFKD | NFKC | ||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|
|
|
| ||||||||||||||||||||||
|
|
|
|
| ||||||||||||||||||||||
|
|
|
|
| ||||||||||||||||||||||
|
|
|
|
| ||||||||||||||||||||||
|
|
|
|
| ||||||||||||||||||||||
|
|
|
|
| ||||||||||||||||||||||
|
|
|
|
| ||||||||||||||||||||||
|
|
|
|
| ||||||||||||||||||||||
|
|
|
|
| ||||||||||||||||||||||
Представленные символы
Юникод включает практически все современные письменности, в том числе:
С академическими целями добавлены многие исторические письменности, в том числе: германские руны, древнетюркские руны, древнегреческая письменность, египетские иероглифы, клинопись, письменность майя, этрусский алфавит.
В Юникоде представлен широкий набор математических и музыкальных символов, а также пиктограмм.
В Юникод принципиально не включаются государственные флаги, логотипы компаний и продуктов, хотя они и встречаются в шрифтах (например, логотип Apple в кодировке MacRoman (0xF0) или логотип Windows в шрифте Wingdings (0xFF)). В юникодовских шрифтах логотипы должны размещаться только в области пользовательских символов.
Проблемы Юникода
В Юникоде английское «a» и польское «a» — один и тот же символ. Точно так же одним и тем же символом (но отличающимся от «a» латинского) считаются русское «а» и сербское «а». Такой принцип кодирования не универсален; по-видимому, решения «на все случаи жизни» вообще не может существовать.
Некоторые недостатки связаны не с самим Юникодом, а с возможностями обработчиков текста.
Некоторые редкие системы письма всё ещё не представлены должным образом в Юникоде. Изображение «длинных» надстрочных символов, простирающихся над несколькими буквами, как, например, в церковнославянском языке, пока не реализовано.