7.2. codecs – Реестр кодеков и базовые классы¶codecs – Codec registry and base classes

7.2.1. Базовые классы кодеков¶Codec Base Classes

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

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

7.2.2. Кодировки и Unicode¶Encodings and Unicode

Строки внутренне хранятся как последовательности кодовых точек в диапазоне 0x0-0x10FFFF. (См. PEP 393 для подробностей реализации.) Когда строковый объект используется вне CPU и памяти, порядок байт (endianness) и то, как эти массивы хранятся в виде байтов, становится важным. Как и для других кодеков, сериализация строки в последовательность байтов называется кодированием, а восстановление строки из последовательности байтов – декодированием. Существует множество различных кодеков текстовой сериализации, которые в совокупности называются текстовыми кодировками.

Простейшая текстовая кодировка (называемая 'latin-1' или 'iso-8859-1') сопоставляет кодовые точки 0-255 байтам 0x0-0xff, что означает, что строковый объект, содержащий кодовые точки выше U+00FF, не может быть закодирован этим кодеком. Попытка вызовет UnicodeEncodeError, который выглядит следующим образом (хотя детали сообщения об ошибке могут отличаться): UnicodeEncodeError: 'latin-1' codec can't encode character '\u1234' in position 3: ordinal not in range(256).

Существует ещё одна группа кодировок (так называемые charmap-кодировки), которые выбирают другое подмножество всех кодовых точек Unicode и определяют, как эти кодовые точки сопоставляются байтам 0x0-0xff. Чтобы увидеть, как это делается, просто откройте, например, encodings/cp1252.py (кодировку, которая в основном используется в Windows). Там есть строковая константа из 256 символов, показывающая, какой символ сопоставляется какому значению байта.

Все эти кодировки могут закодировать только 256 из 1114112 кодовых точек, определённых в Unicode. Простой и прямой способ сохранить каждую кодовую точку Unicode – хранить каждую кодовую точку в виде четырёх последовательных байтов. Есть две возможности: хранить байты в порядке big endian или little endian. Эти две кодировки называются UTF-32-BE и UTF-32-LE соответственно. Их недостаток в том, что если, например, использовать UTF-32-BE на little endian-машине, придётся постоянно менять порядок байтов при кодировании и декодировании. UTF-32 избегает этой проблемы: байты всегда будут в естественном порядке байтов. Однако когда эти байты читаются CPU с другим порядком байтов, байты всё же придётся переставлять. Чтобы иметь возможность определить порядок байтов последовательности байтов UTF-16 или UTF-32, существует так называемый BOM (Byte Order Mark – метка порядка байтов). Это символ Unicode U+FEFF. Этот символ может быть добавлен в начало каждой последовательности байтов UTF-16 или UTF-32. Версия этого символа с переставленными байтами (0xFFFE) является недопустимым символом, который не может встречаться в тексте Unicode. Поэтому когда первый символ в последовательности байтов UTF-16 или UTF-32 оказывается U+FFFE, байты необходимо переставить при декодировании. К сожалению, символ U+FEFF имел второе назначение как ZERO WIDTH NO-BREAK SPACE: символ без ширины, не допускающий разрыва слова. Его можно использовать, например, для подсказок алгоритму лигатур. Начиная с Unicode 4.0 использование U+FEFF в качестве ZERO WIDTH NO-BREAK SPACE устарело (эту роль взял на себя U+2060 (WORD JOINER)). Тем не менее программное обеспечение Unicode всё ещё должно уметь обрабатывать U+FEFF в обеих ролях: как BOM он является средством определения расположения закодированных байтов и исчезает после декодирования последовательности байтов в строку; как ZERO WIDTH NO-BREAK SPACE это обычный символ, который декодируется как любой другой.

Существует ещё одна кодировка, способная кодировать весь диапазон символов Unicode: UTF-8. UTF-8 – это 8-битная кодировка, а это значит, что в UTF-8 нет проблем с порядком байтов. Каждый байт в последовательности UTF-8 состоит из двух частей: битов маркера (самые старшие биты) и битов полезной нагрузки. Биты маркера представляют собой последовательность от нуля до четырёх битов 1, за которой следует бит 0. Символы Unicode кодируются следующим образом (где x – биты полезной нагрузки, которые при объединении дают символ Unicode):

Младший значащий бит символа Unicode – это самый правый бит x.

Поскольку UTF-8 – это 8-битная кодировка, BOM не требуется, и любой символ U+FEFF в декодированной строке (даже если это первый символ) трактуется как ZERO WIDTH NO-BREAK SPACE.

Без внешней информации невозможно надёжно определить, какая кодировка использовалась для кодирования строки. Любая charmap-кодировка может декодировать любую случайную последовательность байтов. Однако с UTF-8 это невозможно, так как последовательности байтов UTF-8 имеют структуру, не допускающую произвольные байтовые последовательности. Чтобы повысить надёжность обнаружения кодировки UTF-8, Microsoft изобрела вариант UTF-8 (который Python 2.5 называет "utf-8-sig") для своей программы Notepad: перед тем, как любой символ Unicode будет записан в файл, записывается BOM в кодировке UTF-8 (который выглядит как последовательность байтов: 0xef, 0xbb, 0xbf). Поскольку маловероятно, что какой-либо файл в charmap-кодировке начинается с этих байтовых значений (которые, например, отображаются в

ЛАТИНСКАЯ СТРОЧНАЯ БУКВА I С ДИЭРЕЗИСОМ

ПРАВАЯ ДВОЙНАЯ УГЛОВАЯ КАВЫЧКА

ПЕРЕВЁРНУТЫЙ ВОПРОСИТЕЛЬНЫЙ ЗНАК

in iso-8859-1), this increases the probability that a utf-8-sig encoding can be correctly guessed from the byte sequence. So here the BOM is not used to be able to determine the byte order used for generating the byte sequence, but as a signature that helps in guessing the encoding. On encoding the utf-8-sig codec will write 0xef, 0xbb, 0xbf as the first three bytes to the file. On decoding utf-8-sig will skip those three bytes if they appear as the first three bytes in the file. In UTF-8, the use of the BOM is discouraged and should generally be avoided.

7.2.3. Стандартные кодировки¶Standard Encodings

Python поставляется с рядом встроенных кодеков, реализованных либо как функции на C, либо с помощью словарей в качестве таблиц отображения. В следующей таблице перечислены кодеки по именам, вместе с несколькими распространёнными псевдонимами и языками, для которых эта кодировка, вероятно, используется. Ни список псевдонимов, ни список языков не является исчерпывающим. Обратите внимание, что варианты написания, отличающиеся только регистром или использующие дефис вместо подчёркивания, также являются допустимыми псевдонимами; поэтому, например, 'utf-8' является допустимым псевдонимом для кодека 'utf_8'.

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

• набор символов ISO 8859
• кодовая страница Microsoft Windows, обычно полученная из набора символов 8859, но заменяющая управляющие символы дополнительными графическими символами
• кодовая страница IBM EBCDIC
• кодовая страница IBM PC, совместимая с ASCII

7.2.4. Кодировки, специфичные для Python¶Python Specific Encodings

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

7.2.5. encodings.idna – Интернационализированные доменные имена в приложениях¶encodings.idna – Internationalized Domain Names in Applications

Этот модуль реализует RFC 3490 (Интернационализированные доменные имена в приложениях) и RFC 3492 (Nameprep: профиль Stringprep для интернационализированных доменных имен (IDN)). Он основан на кодировке punycode и stringprep.

Вместе эти RFC определяют протокол для поддержки не-ASCII символов в доменных именах. Доменное имя, содержащее не-ASCII символы (такое как www.Alliancefrançaise.nu), преобразуется в ASCII-совместимую кодировку (ACE, например, www.xn--alliancefranaise-npb.nu). Затем форма ACE доменного имени используется везде, где протокол не допускает произвольные символы, например, в DNS-запросах, полях HTTP Host и т.д. Это преобразование выполняется в приложении; по возможности незаметно для пользователя: приложение должно прозрачно преобразовывать метки Unicode-доменов в IDNA при передаче и обратно преобразовывать метки ACE в Unicode перед отображением пользователю.

Python поддерживает это преобразование несколькими способами: кодек idna выполняет преобразование между Unicode и ACE, разделяя входную строку на метки на основе символов-разделителей, определенных в разделе 3.1 (1) документа RFC 3490, и преобразуя каждую метку в ACE по мере необходимости, и, наоборот, разделяя входную байтовую строку на метки на основе разделителя . и преобразуя любые найденные метки ACE в Unicode. Кроме того, модуль socket прозрачно преобразует Unicode-имена хостов в ACE, так что приложениям не нужно беспокоиться о преобразовании имен хостов при передаче их в модуль socket. Вдобавок, модули, которые принимают имена хостов в качестве параметров функций, такие как http.client и ftplib, принимают Unicode-имена хостов (при этом http.client также прозрачно отправляет IDNA-имя хоста в поле Host, если вообще отправляет это поле).

При получении имён хостов из сети (например, при обратном поиске имени) автоматическое преобразование в Unicode не выполняется: приложения, желающие отобразить такие имена хостов пользователю, должны декодировать их в Unicode.

Модуль encodings.idna также реализует процедуру nameprep, которая выполняет определенные нормализации имен хостов для достижения нечувствительности к регистру интернационализированных доменных имен и унификации похожих символов. Функции nameprep можно использовать напрямую при желании.

encodings.idna.nameprep(label)¶

Return the nameprepped version of label. The implementation currently assumes query strings, so AllowUnassigned is true.

encodings.idna.ToASCII(label)¶

Преобразует метку в ASCII, как указано в RFC 3490. Параметр UseSTD3ASCIIRules предполагается равным false.

encodings.idna.ToUnicode(label)¶

Преобразует метку в Unicode, как указано в RFC 3490.

7.2.6. encodings.mbcs – Кодовая страница Windows ANSI¶encodings.mbcs – Windows ANSI codepage

Кодирует операнд в соответствии с кодовой страницей ANSI (CP_ACP).

Доступность: только Windows.

7.2.7. encodings.utf_8_sig – Кодек UTF-8 с сигнатурой BOM¶encodings.utf_8_sig – UTF-8 codec with BOM signature

Этот модуль реализует вариант кодека UTF-8: при кодировании префикс UTF-8 BOM будет добавлен перед байтами, закодированными в UTF-8. Для кодировщика с состоянием это делается только один раз (при первой записи в байтовый поток). При декодировании необязательный UTF-8 BOM в начале данных будет пропущен.