что такое unicode и каковы его перспективы
Юникод: необходимый практический минимум для каждого разработчика
Юникод — это очень большой и сложный мир, ведь стандарт позволяет ни много ни мало представлять и работать в компьютере со всеми основными письменностями мира. Некоторые системы письма существуют уже более тысячи лет, причём многие из них развивались почти независимо друг от друга в разных уголках мира. Люди так много всего придумали и оно зачастую настолько непохоже друг на друга, что объединить всё это в единый стандарт было крайне непростой и амбициозной задачей.
Чтобы по-настоящему разобраться с Юникодом нужно хотя бы поверхностно представлять себе особенности всех письменностей, с которыми позволяет работать стандарт. Но так ли это нужно каждому разработчику? Мы скажем, что нет. Для использования Юникода в большинстве повседневных задач, достаточно владеть разумным минимумом сведений, а дальше углубляться в стандарт по мере необходимости.
В статье мы расскажем об основных принципах Юникода и осветим те важные практические вопросы, с которыми разработчики непременно столкнутся в своей повседневной работе.
Зачем понадобился Юникод?
До появления Юникода, почти повсеместно использовались однобайтные кодировки, в которых граница между самими символами, их представлением в памяти компьютера и отображением на экране была довольно условной. Если вы работали с тем или иным национальным языком, то в вашей системе были установлены соответствующие шрифты-кодировки, которые позволяли отрисовывать байты с диска на экране таким образом, чтобы они представляли смысл для пользователя.
Если вы распечатывали на принтере текстовый файл и на бумажной странице видели набор непонятных кракозябр, это означало, что в печатающее устройство не загружены соответствующие шрифты и оно интерпретирует байты не так, как вам бы этого хотелось.
У такого подхода в целом и однобайтовых кодировок в частности был ряд существенных недостатков:
Основные принципы Юникода
Все мы прекрасно понимаем, что компьютер ни о каких идеальных сущностях знать не знает, а оперирует битами и байтами. Но компьютерные системы пока создают люди, а не машины, и для нас с вами иногда бывает удобнее оперировать умозрительными концепциями, а затем уже переходить от абстрактного к конкретному.
Важно! Одним из центральных принципов в философии Юникода является чёткое разграничение между символами, их представлением в компьютере и их отображением на устройстве вывода.
Вводится понятие абстрактного юникод-символа, существующего исключительно в виде умозрительной концепции и договорённости между людьми, закреплённой стандартом. Каждому юникод-символу поставлено в соответствие неотрицательное целое число, именуемое его кодовой позицией (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).
Всё это мы говорим к тому, что имеет смысл обращать внимание на контекст и различать ситуации, когда речь идёт о кодовой позиции абстрактного юникод-символа и когда речь идёт о его байтовом представлении.
Unicode: как человечество пришло к международному стандарту кодирования символов
Уверена, что большинство читателей хоть немного знакомы с терминами «Unicode» и «UTF-8». Но все ли знают, что именно стоит за ними? По сути они относятся к стандартам кодирования символов, также известным как наборы символов. Концепция появилась во времена оптического телеграфа, а не в компьютерную эру, как можно было подумать. Еще в 18 веке существовала потребность в быстрой передаче информации на большие расстояния, для чего использовались так называемые телеграфные коды. Информация кодировалась с помощью оптических, электронных и других средств.
В течение сотен лет, прошедших с момента изобретения первого телеграфного кода, не было никаких реальных попыток международной стандартизации таких схем кодирования. Даже первые десятилетия эры телетайпов и домашних компьютеров мало что изменили. Несмотря на то, что EBCDIC (8-битная кодировка символов IBM, продемонстрированная на перфокарте в заглавной иллюстрации) и ASCII немного улучшили ситуацию, способа кодировать растущую коллекцию символов без значительных затрат памяти все еще не было.
Развитие Юникода началось в конце 1980-х годов, когда рост обмена цифровой информацией во всем мире сделал потребность в единой системе кодирования более насущной. В наши дни Юникод позволяет нам использовать единую схему кодирования для всего — от базового английского текста и традиционного китайского, вьетнамского, даже майянского языков до пиктограмм, которые мы привыкли называть «эмодзи».
От кода к графикам
Еще в эпоху Римской империи было хорошо известно, что быстрая передача информации имеет значение. В течение долгого времени это означало наличие гонцов на лошадях, которые доставляли сообщения на большие расстояния, или их эквивалента. Как улучшить систему доставки информации, придумали еще в 4 веке до нашей эры — так появились водяной телеграф и система сигнальных огней. Но действительно эффективной передача данные на большие расстояния стала лишь в 18 веке.
Об оптическом телеграфе, также называемом «семафоре», мы уже писали в статье об истории оптической связи. Он состоял из ряда ретрансляционных станций, каждая из которых была оборудована системой поворотных стрелок, используемой для отображения символов телеграфного кода. Система братьев Шапп, которая использовалась французскими войсками между 1795 и 1850-ми годами, была основана на деревянной перекладине с двумя подвижными концами (рычагами), каждый из которых мог перемещаться в одно из семи положений. Вместе с четырьмя позициями для перекладины семафор в теории мог обозначить 196 символов (4x7x7). На практике число сокращалось до 92-94 позиций.
Французский оптический телеграфный код братьев Шапп, 1809 год
Система семафоров использовалась не столько для прямого кодирования символов, сколько для обозначения определенных строк в кодовой книге. Метод подразумевал, что по нескольким кодовым сигналам можно было расшифровать все сообщение. Это ускоряло передачу и делало бессмысленным перехват сообщений.
Улучшение производительности
Затем оптический телеграф был заменен электрическим. Это означало, что времена, когда кодировки фиксировались людьми, наблюдающими за ближайшей релейной вышкой, прошли. С двумя телеграфными устройствами, соединенными металлическим проводом, инструментом для передачи информации стал электрический ток. Это изменение привело к появлению новых кодов электрического телеграфа, а код Морзе в итоге стал международным стандартом (за исключением США, которые продолжали использовать американский код Морзе за пределами радиотелеграфии) с момента его изобретения в Германии в 1848 году.
Международный код Морзе имеет преимущество перед американским аналогом: в нем используется больше тире, чем точек. Такой подход снижает скорость передачи, но улучшает прием сообщения на другом конце линии. Это было необходимо, когда длинные сообщения передавались по многокилометровым проводам операторами разного уровня подготовки.
По мере развития технологий ручной телеграф был заменен на Западе автоматическим. В нем использовался 5-битный код Бодо, а также производный от него код Мюррея (последний основывался на использовании бумажной ленты, в которой пробивались отверстия). Система Мюррея позволяла заранее подготовить ленту с сообщениями, а затем загрузить ее в устройство для чтения, чтобы сообщение передалось автоматически. Код Бодо лег в основу международного телеграфного алфавита версии 1 (ITA 1), а модифицированный код Бодо-Мюррея лег в основу ITA 2, которая использовалась вплоть до 1960-х годов.
К 1960-м годам ограничение в 5 бит на символ уже не требовалось, что привело к развитию 7-битного ASCII в США и таких стандартов, как JIS X 0201 (для японских символов катакана) в Азии. В сочетании с телетайпами, которые тогда широко использовались, это позволяло передавать довольно сложные сообщения, включающие символы верхнего и нижнего регистров.
Полный набор символов 7-битного ASCII
В течение 1970-х и начала 1980-х годов ограничений 7- и 8-битных кодировок, таких как расширенный ASCII (например, ISO 8859-1 или Latin 1), было достаточно для основных домашних компьютеров и офисных нужд. Несмотря на это, потребность в улучшении была очевидна, поскольку общие задачи, такие как обмен цифровыми документами и текстом, часто приводили к хаосу из-за множества кодировок ISO 8859. Первый шаг был сделан в 1991 году — появился 16-битный Unicode 1.0.
Развитие 16-битных кодировок
Удивительно, что всего в 16 битах Unicode удалось охватить не только все западные системы письма, но и многие китайские иероглифы и множество специальных символов, используемых, например, в математике. С 16 битами, допускающими до 65 536 кодовых точек, Unicode 1.0 легко вмещал 7 129 символов. Но к моменту появления Unicode 3.1 в 2001 году он содержал не менее 94 140 символов.
Сейчас, в своей 13 версии, Unicode содержит в общей сложности 143 859 символов, не считая управляющих. Изначально Unicode предполагалось использовать только для кодирования систем записи, которые применяются в настоящее время. Но к релизу Unicode 2.0 в 1996 году стало понятно, что эту цель следует переосмыслить, чтобы кодировать даже редкие и исторические символы. Чтобы достичь этого без обязательной 32-битной кодировки каждого символа, Unicode изменился: он позволил не только кодировать символы напрямую, но и использовать их компоненты, или графемы.
Концепция в чем-то похожа на векторные изображения, где не указывается каждый пиксель, а вместо этого описываются элементы, составляющие рисунок. В результате кодировка Unicode Transformation Format 8 (UTF-8) поддерживает 2 31 кодовую точку, при этом для большинства символов в текущем наборе символов Unicode обычно требуется один-два байта.
Unicode на любой вкус и цвет
На данный момент довольно много людей, вероятно, сбиты с толку из-за различных терминов, которые используются, когда дело доходит до Unicode. Поэтому здесь важно отметить, что Unicode относится к стандарту, а различные Unicode Transformation Format являются его реализациями. UCS-2 и USC-4 — это более старые 2- и 4-байтовые реализации Unicode, при этом UCS-4 идентичен UTF-32, а UCS-2 заменяем UTF-16.
Обзор базовой многоязычной плоскости Unicode, первой плоскости Unicode практически со всеми современными языками
UTF-32, как следует из названия, кодирует каждый символ в четырех байтах. Это немного расточительно, зато абсолютно предсказуемо. Тот же UTF-8 символ может кодировать символ в диапазоне от одного до четырех байтов. В случае с UTF-32 определение количества символов в строке — это простая арифметика: взять все количество байтов и поделить на четыре. Это привело к появлению компиляторов и некоторых языков, например Python, позволяющих использовать UTF-32 для представления строк Unicode.
Однако из всех форматов Unicode наиболее популярным на сегодняшний день является UTF-8. Этому во многом способствовала всемирная сеть Интернет, где большинство веб-сайтов обслуживают свои HTML-документы в кодировке UTF-8. Из-за компоновки различных плоскостей кодовых точек в UTF-8, Western и многие другие распространенные системы записи умещаются в пределах двух байтов. Если сравнивать со старыми кодировками ISO 8859 и Shift JIS, фактически тот же текст в UTF-8 не занимает больше места, чем раньше.
От оптических башен до интернета
Времена конных гонцов, ретрансляционных вышек и небольших телеграфных станций прошли. Коммуникационные технологии сильно развились. Даже те дни, когда телетайпы были обычным явлением в офисах, вспоминаются с трудом. Однако на каждом этапе развития истории человечеству было необходимость кодировать, хранить и передавать информацию. И это привело нас к тому, что теперь мы можем мгновенно передавать сообщение по всему миру в системе символов, которую можно декодировать независимо от того, где вы находитесь.
Для тех, кому довелось переключаться между кодировками ISO 8859 в почтовых клиентах и веб-браузерах, чтобы получить что-то, похожее на исходное текстовое сообщение, поддержка Unicode стала благословением. Я могу понять этих людей. Когда 7-битный ASCII (или EBCDIC) был безальтернативной технологией, иногда приходилось тратить часы, разбираясь в символьной путанице цифрового документа, полученного из европейского или американского офиса.
Даже если Unicode не лишен проблем, трудно не испытывать благодарности, сравнивая его с тем, что было раньше. Вот они, 30 лет существования Unicode.
Юникод для чайников
Сам я не очень люблю заголовки вроде «Покемоны в собственном соку для чайников\кастрюль\сковородок», но это кажется именно тот случай — говорить будем о базовых вещах, работа с которыми довольно часто приводить к купе набитых шишек и уйме потерянного времени вокруг вопроса — «Почему же оно не работает?». Если вы до сих пор боитесь и\или не понимаете Юникода — прошу под кат.
Зачем?
Главный вопрос новичка, который встречается с впечатляющим количеством кодировок и на первый взгляд запутанными механизмами работы с ними (например, в 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.
Спасибо за внимание. Буду благодарен за замечания в приват.