codecs — Реестр кодеков и базовые классы¶

Базовые классы кодеков¶

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

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

>>> 'German ß, ♬'.encode(encoding='ascii', errors='backslashreplace')
b'German \\xdf, \\u266c'
>>> 'German ß, ♬'.encode(encoding='ascii', errors='xmlcharrefreplace')
b'German ß, ♬'

Кодировки и Unicode¶

Строки хранятся внутри системы в виде последовательностей кодовых точек в диапазоне U+0000–U+10FFFF. (Более подробную информацию о реализации смотрите в разделе PEP 393). Как только строковый объект используется за пределами процессора и памяти, возникает проблема с порядковыми номерами и тем, как эти массивы хранятся в виде байтов. Как и в случае с другими кодеками, преобразование строки в последовательность байтов называется «кодированием», а воссоздание строки из последовательности байтов называется «декодированием». Существует множество различных кодеков для сериализации текста, которые в совокупности называются text encodings.

Простейшая текстовая кодировка (называемая '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 - это сохранить каждую кодовую точку в виде четырех последовательных байт. Есть две возможности: хранить байты в порядке возрастания или в порядке убывания. Эти две кодировки называются UTF-32-BE и UTF-32-LE соответственно. Их недостаток заключается в том, что если, например, вы используете UTF-32-BE на машине с малым порядком порядковых номеров, вам всегда придется менять местами байты при кодировании и декодировании. UTF-32 позволяет избежать этой проблемы: байты всегда будут иметь естественный порядок порядковых номеров. Однако, когда эти байты считываются процессором с другим порядковым номером, байты должны быть заменены местами. Чтобы можно было определить последовательность байтов UTF-16 или UTF-32, существует так называемая спецификация («Метка порядка байтов»). Это символ Юникода U+FEFF. Этот символ может добавляться перед каждой последовательностью байтов UTF-16 или UTF-32. Версия этого символа с заменой байтов (0xFFFE) является недопустимым символом, который может не отображаться в тексте в Юникоде. Таким образом, когда первый символ в последовательности байтов 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 в обеих ролях: как спецификация, это устройство для определения структуры хранилища закодированных байтов, и оно исчезает, как только последовательность байтов декодируется в строку; как ZERO WIDTH NO-BREAK SPACE это обычный символ, который будет расшифрован, как и любой другой.

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

Младшим разрядом символа Unicode является крайний правый бит x.

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

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

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

ДВУХУГОЛЬНАЯ КАВЫЧКА, УКАЗЫВАЮЩАЯ ВПРАВО

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

в iso-8859-1), это увеличивает вероятность того, что кодировка utf-8-sig может быть правильно угадана по последовательности байтов. Таким образом, здесь спецификация используется не для определения порядка байтов, используемого для генерации последовательности байтов, а в качестве подписи, которая помогает угадать кодировку. При кодировании кодек utf-8-sig запишет в файл 0xef, 0xbb, 0xbf в качестве первых трех байт. При декодировании utf-8-sig эти три байта будут пропущены, если они отображаются как первые три байта в файле. В UTF-8 использование спецификации не рекомендуется и, как правило, его следует избегать.

Стандартные кодировки¶

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

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

• набор кодов ISO 8859

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

• кодовая страница IBM EBCDIC

• кодовая страница IBM PC, совместимая с ASCII

Специфичные для Python кодировки¶

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

encodings.idna — Интернационализированные доменные имена в приложениях¶

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

Если вам нужен стандарт IDNA 2008 от RFC 5891 и RFC 5895, используйте сторонний idna module.

Эти 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, разделяя входную строку на метки на основе символов-разделителей, определенных в section 3.1 of RFC 3490, и преобразуя каждую метку в ACE по мере необходимости, и наоборот, разделяя входную строку байтов в метки на основе разделителя . и преобразуя все найденные метки ACE в unicode. Кроме того, модуль socket прозрачно преобразует имена хостов в кодировке Unicode в ACE, так что приложениям не нужно беспокоиться о преобразовании имен хостов самим, когда они передают их в модуль socket. Кроме того, модули, которые имеют имена хостов в качестве функциональных параметров, такие как http.client и ftplib, принимают имена хостов в Юникоде (http.client затем также прозрачно отправляют имя хоста IDNA в Host). поле, если оно вообще отправляет это поле).

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

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

encodings.idna.nameprep(label)¶

Возвращает версию label с заданным именем. В настоящее время в реализации используются строки запроса, поэтому AllowUnassigned равно true.

encodings.idna.ToASCII(label)¶

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

encodings.idna.ToUnicode(label)¶

Преобразуйте метку в Юникод, как указано в RFC 3490.

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

Этот модуль реализует кодовую страницу ANSI (CP_ACP).

encodings.utf_8_sig — Кодек UTF-8 с подписью спецификации¶

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