Архив метки: unicode

Строки символов Unicode в Python 2 и Python 3

Винсент: Знаешь, что самое забавное в Европе?
Джулс: Что?
Винсент: Такие маленькие отличия. Там вроде все то же самое, что и здесь, но чуть-чуть отличается.

«Криминальное чтиво»

Как известно, ключевым отличием Python 3.x от Python 2.x является переориентация языка и стандартных библиотек со строк байтов на строки символов Unicode. Когда я решил повнимательнее посмотреть на это различие, пришлось копнуть вглубь и вширь, а результаты моих раскопок я оформил в статью, которую предлагаю вашему вниманию.

В Python 2В Python 3
строковый литерал получает тип strстроковый литерал получает тип str
тип str представляет собой строку байтовтип str представляет собой строку символов Unicode
для представления строки символов Unicode используется тип unicodeдля представления строки байтов используется тип bytes
для представления строки unicode в нужной кодировке используется метод unicode.encode(кодировка), возвращающий строку байтов strдля представления строки str в нужной кодировке используется метод str.encode(кодировка), возвращающий строку байтов bytes
для преобразования строки байтов str в строку unicode используется метод str.decode(кодировка), возвращающий строку unicodeдля преобразования строки байтов bytes в строку str используется метод bytes.decode(кодировка), возвращающий строку str
системная кодировка по умолчанию, она же кодировка исходных файлов по умолчанию, ASCIIсистемная кодировка по умолчанию, она же кодировка исходных файлов по умолчанию, UTF-8
при записи в файл строки по умолчанию преобразуются в системную кодировку по умолчаниюпри записи в файл строки по умолчанию преобразуются в кодировку, определяемую пользовательскими настройками
идентификаторы в программе содержат только символы ASCII, не могут использовать никаких других букв, кроме латинскихидентификаторы в программе содержат символы Unicode, могут использовать буквы других алфавитов, кроме латинского

Мои эксперименты я ставлю под ОС Windows 7 в стандартной консоли.

Для разминки, несколько манипуляций со строковыми литералами и переменными в Python 2:


>>> s = 'Hello'
>>> s
'Hello'
>>> type(s)

>>> u = s.decode('ascii')
>>> u
u'Hello'
>>> type(u)


И в Python 3:


>>> s = 'Hello'
>>> s
'Hello'
>>> type(s)

>>> b = s.encode('ascii')
>>> b
b'Hello'
>>> type(b)


Теперь посмотрим на кодировки, используемые в Python 2 и Python 3 по умолчанию:

  • Системная кодировка по умолчанию (system default encoding), возвращается функцией sys.getdefaultencoding(). Это кодировка исходных текстов Python по умолчанию, она же используется по умолчанию для кодирования и декодирования строк unicode.
  • Кодировки стандартных потоков ввода, вывода и ошибок — файловых объектов, атрибуты sys.stdin.encoding, sys.stdout.encoding и sys.stderr.encoding, соответственно. Строки символов Unicode, посылаемые в канал вывода, преобразуются в соответствующую кодировку (или в системную кодировку по умолчанию, если атрибут encoding is None).
  • Кодировка имен файлов в файловой системе, возвращается функцией sys.getfilesystemencoding(). Имена файлов, представленные в программе на Python как строки символов Unicode, преобразуются в эту кодировку для взаимодействия с файловой системой (или в системную кодировку по умолчанию, если sys.getfilesystemencoding() возвращает None).
  • Кодировка для текстовых данных, заданная пользовательскими настройками, возвращается функцией locale.getpreferredencoding(False).

Кодировки в Python 2:


>>> import sys, locale
>>> sys.getdefaultencoding()
'ascii'
>>> sys.stdin.encoding
'cp866'
>>> sys.stdout.encoding
'cp866'
>>> sys.stderr.encoding
'cp866'
>>> sys.getfilesystemencoding()
'mbcs'
>>> locale.getpreferredencoding(False)
'cp1251'

Кодировки в Python 3:


>>> import sys, locale
>>> sys.getdefaultencoding()
'utf-8'
>>> sys.stdin.encoding
'cp866'
>>> sys.stdout.encoding
'cp866'
>>> sys.stderr.encoding
'cp866'
>>> sys.getfilesystemencoding()
'mbcs'
>>> locale.getpreferredencoding(False)
'cp1251'

Как видим, системной кодировкой по умолчанию для Pyt
hon 2 является ascii, а для Python 3 — utf-8. И это единственное обнаруженное различие.

Нам, русским, очень «повезло» с обилием кириллических кодировок в Windows. Работая в консоли Windows, по умолчанию мы имеем дело с кириллической кодировкой cp866. Работая с текстовым файлом в Блокноте, по умолчанию мы работаем в кириллической кодировке cp1251. Имена файлов, использующие русские символы, в файловой системе Windows представлены в кодировке mbcs (multi-byte character set), — это двухбайтовая кодировка, которая позволяет представить подмножество символов Unicode (UTF-16?).

Вооружившись знанием об используемых по умолчанию кодировках, попробуем в интерактивном режиме Pyhton вводить и выводить строки, включающие нелатинские символы.

Фрагмент интерактивного сеанса Python 2:


>>> u = u'Привет world'
>>> type(u)

>>> u
u'u041fu0440u0438u0432u0435u0442 world'
>>> print u, u.encode('cp866')
Привет world Привет world

Что я только что сделал?

Команды вводятся через стандартный входной поток, использующий кодировку cp866 (sys.stdin.encoding). Таким образом, в первом предложении присваивания литерал u'Привет world' преобразуется в строку unicode из кодировки cp866 и полученная строка unicode присваивается переменной u. Далее я проверил тип и значение переменной u и увидел, что русские буквы представлены двухбайтовыми кодами Unicode. Наконец, предложение print посылает в стандартный выходной поток данную строку unicode и строку str, полученную преобразованием строки u в кодировку cp866. Результат вывода обеих строк одинаков, поскольку строка unicode неявно преобразуется при выводе в стандартый выходной поток в кодировку cp866 (sys.stdout.encoding).

В Python 3 получим такой результат (предлагаю интерпретировать его самостоятельно):


>>> s = 'Привет world'
>>> type(s)

>>> s
'Привет world'
>>> print(s, s.encode('cp866'))
Привет world b'x8fxe0xa8xa2xa5xe2 world'

Идем дальше.

В Python 2 для использования в скриптах не-ASCII символов нужно явно указывать кодировку исходного файла, поскольку системная кодировка по умолчанию, ascii, подразумевает использование в файле только символов ASCII. А в Python 3 исходный файл по умолчанию содержит символы Unicode в кодировке utf-8, что позволяет использовать в нем практически любые символы без явного указания кодировки.

Файл hello.py в кодировке UTF-8 для Python 2:


# -*- coding: utf-8 -*-

s = u'Привет world!'
print type(s), s, s.encode('cp866')

Выполню его в консоли Windows:


C:_sandbox> c:Python27python.exe hello.py
Привет world! Привет world!

Файл hello3.py в кодировке UTF-8 для Python 3:


# нас устраивает кодировка по умолчанию utf-8

s = 'Привет world!'
print(type(s), s, s.encode('cp866'))

Выполню его в консоли Windows:


C:_sandbox> c:Python33python.exe hello3.py
Привет world! b'x8fxe0xa8xa2xa5xe2 world!'

Разница с работой скрипта hello.py в том, что теперь к кодировке стандартного потока вывода приводится значение типа str, и строка байтов bytes не интерпретируется как строка читабельных символов.

Следующий скрипт helloname.py демонстрирует ввод и вывод кириллических символов в Python 2, используя для их хранения строки unicode:


# -*- coding: utf-8 -*-

import sys

def uraw_input(prompt):
return unicode(raw_input(prompt.encode(sys.stdout.encoding)), sys.stdin.encoding)

name = uraw_input(u'Привет! Ваше имя? ')
print u'Привет, %s!' % name

Выполню скрипт в консоли Windows:


C:_devGOLD>c:Python27python.exe helloname.py
Привет! Ваше имя? Андрей
Привет, Андрей!

Посмотрим теперь, что происходит при записи строк символов Unicode в файл. Если в Python 2 явно не преобразовывать выводимые в файл строки unicode в строки str с нужной кодировкой, то получим ошибку.


# -*- coding: UTF-8 -*-

with open('hello.txt', 'w') as f:
print 'File encoding:', f.encoding
f.write(u'Привет world!')

Выполню скрипт в консоли Windows:


C:_sandbox> c:Python27python.exe hellofile.py
File encoding: None
Traceback (most recent call last):
File "hellofile.py", line 5, in
f.write(u'╨Я╤А╨╕╨▓╨╡╤В world!')
UnicodeEncodeError: 'ascii' codec can't encode characters in position 0-5: ordinal not in range(128)

При записи в файл Python 2 пытается преобразовать строку unicode в системную кодировку по умолчанию, ascii, поскольку атрибут encoding открытого нами файла имеет значение None. В кодировке ascii нельзя представить кириллические символы, из-за чего и возникает ошибка.

Во избежание ошибок, при записи строк
unicode
в файл нужно явно приводить их к желаемой кодировке:


# -*- coding: UTF-8 -*-

with open('hello.txt', 'w') as f:
print 'File encoding:', f.encoding
f.write(u'Привет world!'.encode('cp866'))

Выполню исправленный скрипт в консоли Windows:


C:_sandbox> c:Python27python.exe hellofile.py
File encoding: None

C:_sandbox> type hello.txt
Привет world!

Аналогичный эксперимент с Python 3 показывает, что строки пишутся в файл в кодировке, определяемой локалью пользователя!


with open('hello3.txt', 'w') as f:
print('File encoding:', f.encoding)
f.write('Привет world!')

Выполняю скрипт в консоли Windows:


C:_sandbox> c:Python33python.exe hellofile3.py
File encoding: cp1251

Выше мы видели, что на русифицированной Windows функция locale.getpreferredencoding(False) возвращает 'cp1251'. Именно с этой кодировкой открывается новый файл по умолчанию, и, как следствие, к ней приводятся строки, записываемые в этот файл.

С кодировкой файла cp1251 запись в него смешанной латино-кириллической строки проходит на ура, а вот попытка записи кандзи вместе с кириллицей приводит к уже знакомой нам ошибке:


with open('hello31.txt', 'w') as f:
print('File encoding:', f.encoding)
f.write('Привет 世界!')

Выполняю скрипт в консоли Windows:


C:_sandbox> c:Python33python.exe hellofile31.py
File encoding: cp1251
Traceback (most recent call last):
File "hellofile31.py", line 3, in
f.write('Привет u4e16u754c!')
File "c:Python33libencodingscp1251.py", line 19, in encode
return codecs.charmap_encode(input,self.errors,encoding_table)[0]
UnicodeEncodeError: 'charmap' codec can't encode characters in position 7-8: character maps to

Кодировка cp1251 не кодирует кандзи!

Хорошая новость в том, что в Python 3, в отличие от Python 2, при открытии файла можно явно указать кодировку файла. В эту кодировку и будут преобразовываться строки str при записи в файл; из этой кодировки будут преобразовываться в str читаемые из файла строки байтов.

Укажу явно кодировку открываемых файлов в скрипте hello32.py:


with open('hello31.txt', 'w', encoding='utf-8') as f:
print('File encoding:', f.encoding)
f.write('Привет world!')

with open('hello32.txt', 'w', encoding='utf-8') as f:
print('File encoding:', f.encoding)
f.write('Привет 世界!')

with open('hello31.txt', encoding='utf-8') as f:
print('File encoding:', f.encoding)
print(f.read())

Выполняю скрипт в консоли Windows:


C:_sandbox> c:Python33python.exe hellofile32.py
File encoding: utf-8
File encoding: utf-8
File encoding: utf-8
Привет world!

Как видим, скрипт пишет в файл и читает из файла строки в кодировке utf-8.

В заключение, экзотический пример кода. Вследствие того, что в Python 3 системной кодировкой по умолчанию является utf-8, в Python 3 можно использовать в идентификаторах не только латиницу, но и другие символы Unicode:


>>> def привет_5_раз(имя):
... for i in range(5):
... print('Привет,', имя)
...
>>> привет_5_раз('Медвет')
Привет, Медвет
Привет, Медвет
Привет, Медвет
Привет, Медвет
Привет, Медвет

Сопровождать такой код и вносить в него изменения интернациональной команде разработчиков будет проблематично!

Проделанные сравнительные эксперименты не дали мне достаточно оснований, чтобы решительно встать на одну из сторон в священной войне между защитниками Python 2 и энтузиастами Python 3 :). Хотя Unicode-ориентированность Python 3 и то, как это сказывается на прикладном программировании, мне нравится.

Автор: Andrei Trofimov
Дата публикации: 2014-07-10T17:55:00.000+11:00

Python 3: Импорт и юникод

Третий питон с рождения замечательно поддерживает юникод. Собственно говоря, это одна из самых заметных его особенностей.

Русские идентификаторы

Чуть меньше бросается в глаза тот факт, что идентификаторы тоже стали юникодными. Уважаемые читатели, если вы используете третий питон и недостаточно хорошо владеете английским — пишите по русски. Это выглядит гораздо лучше, чем убогое средство под названием «транслитерация». Оцените сами:

def функция(агрумент):
коэффициент = 5
return агрумент * коэффициент

Это на самом деле здорово!

Еще один не вполне очевидный момент: имена модулей тоже могут быть в юникоде:

from . import вспомогательный_модуль

Тоже выглядит неплохо, верно? Есть только одна небольшая проблема: это не всегда работает. Вернее, на Windows возможны неприятности. И не нужно заявлять, что вопросы, касающиеся самой популярной на сегодняшний день операционной системы — никого не волнуют. Подавляющее большинство разработчиков самого Питона Windows не используют — и тем не менее Питон обязан на ней работать, и работать хорошо.

Чтобы рассказать в чем вышла загвоздка — я должен немного погрузиться в детали.

Юникод в C API

В Python 2 немалая часть Python C API принимала char * там, где требовалась строка. Поскольку str и был последовательностью байт — сложностей не возникало.

При переносе кода на Python 3 нужно было с этим что-то делать: strстал юникодным типом, последовательностью символов.

Но в С нет удобного типа для unicode! Вернее, существует стандартный тип wchar_t, который обременен множеством проблем. Главные из них: в разных реализациях этот тип имеет различный размер: 16 бит для UCS-2 и 32 бита для UCS-4. К тому же Windows (о, снова она) не поддерживает UCS-2 в полной мере (UCS-4 не поддерживает совсем).

Хуже всего то, что на некоторых платформах этот wchar_t попросту не определен.

Таким образом, использовать wchar_t в Python C API нельзя.

Сам Питон вводит тип Py_UNICODE для этих целей. Но и тут не все гладко. Этот тип не входит в Limited API (PEP 384).

Кроме того, разработчики не хотели радикально заменить все char * на что-то другое.

Есть еще и вопрос практического удобства: ведь очень здорово писать

ret = PyObject_GetAttrString(obj, "attribute");

Для wchar_t все гораздо сложнее, далеко не все компиляторы поддерживают строковые юникодные константы.

В свете вышеописанных причин Python C API продолжает использовать char *, считая, что эти строки имеют кодировку UTF-8 если явно не указано иное. Т.е. прототипы функций C API выглядят как:

PyObject *
PyImport_ImportModuleLevel(char *name, PyObject *globals,
PyObject *locals, PyObject *fromlist,
int level);

Это — импорт модуля с именем name, которое передается как UTF-8строка, аналог питоновской функции __import__.

И эта функция — лишь верхушка используемого механизма. В процессе импорта вызываются довольно много внутренних закрытых функций — и везде используются переменные вроде char *name в качестве имен модулей. В кодировке UTF-8, еще раз напомню.

А ведь имя модуля транслируется в путь к файлу! А кодировака файловой системы может отличаться от UTF-8. Счастливые пользователи Linux давно об этом забыли — в подавляющем большинстве систем по умолчанию как кодировка пользователя (переменная окружения LANG) так и файловой системы установлены в UTF-8 и проблем нет совсем. Но в общем случае это не всегда так.

Кодировки по умолчанию

Чуть-чуть о кодировках. Для определения используемых по умолчанию кодировок в питоне существуют три функции: sys.getdefaultencoding, sys.getfilesystemencoding и locale.getpreferredencoding.

  • sys.getdefaultencoding() — кодировка по умолчанию, используемая в питоновских исходниках. Для третьего питона всегда равна UTF-8. Это — та самая кодировка, которую можно перекрыть написав в начале файла

    # -*- encoding: utf-8 -*-
  • sys.getfilesystemencoding() — кодировка файловой системы. Например, для

    f = open('path/to/file', 'r')

    значение 'path/to/file' имеет тип str (юникод). Лежащая в основе функция из clib имеет прототип

    int open(const char *pathname, int flags, mode_t mode);

    Значит, 'path/to/file' должен быть преобразован в char *используя к
    одировку sys.getfilesystemencoding(). Конечно, в Python C API есть специальные функции для этого.

  • locale.getpreferredencoding() — предпочтительная для пользователя кодировка. Она устанавливается в региональных настройках и к файловой системе прямого отношения не имеет.

Теперь снова вспомним нашу горячо любимую Windows.

locale.getpreferredencoding() возвращает 'cp1251' — Windows настроена на русский язык. Кодировка для консоли (sys.stdout.encoding) другая, это 'cp866' — что добавляет сумбура в и без того запутанную проблему. Ну да ладно, не будем отвлекаться.

sys.getfilesystemencoding() возвращает 'mbcs'. И вот здесь начинаются основные чудеса. Обратите внимание, mbcs — это не cp1251. Равно как и не cp1252 или какая другая кодировка. mbcs — это нечто совершенно особенное!

Multibyte character set (кодировка MBCS)

При преобразовании mbcs -> unicode используется кодировка из locale.getpreferredencoding(), преобразование однозначное и проблем не вызывает.

Для обратного преобразования unicode -> mbcs тоже используется locale.getpreferredencoding() (cp1251 в нашем случае). Но cp1251 не может описать любой юникодный символ. А mbcs — хитрый и коварный. Если для символа не существует точного преобразования — используется ближайший похожий по начертанию.

Это непросто понять без примера. Давайте возьмем французское слово comédie и попробуем преобразовать его в mbcs, имея руский язык cp1251 в настройках по умолчанию.

Возьмем Python 3.1:

>>> b = b'comxc3xa9die'
>>> s = b.decode('utf8')
>>> s.encode('mbcs')
b'comedie'

Посмотрите, какая прелесть! Для символа é в русской раскладке cp1251 нет подходящего аналога. Но ведь английская буква e так похожа: нужно лишь убрать умляут (англ. umlaut, французы зовут этот знак accent aigu). Так и получили преобразование comédie -> comedie без единой ошибки.

А теперь представьте, что это — имя файла. Результат будет следующим: файл на диске есть, и так как в Windows файловая система юникодная, имя файла будет записано правильно, по французски. Но преобразование unicode -> mbcs даст несколько другое имя, которого на диске нет.

В результате получается изумительная по своей красоте ситуация:

f = open('comédie', 'r')

будет говорить, что файла нет — а на самом деле вот же он, красавец!

Справедливости ради нужно упомянуть, что в Python 3.2 поведение mbcsнемного поменялось, и 'comédie'.encode('mbcs') вызовет UnicodeEncodeError. Дело в том, что mbcs стал использовать режим strict по умолчанию. Чтобы повторить функциональность 3.1 следует указывать режим replace: 'comédie'.encode('mbcs', 'replace')

Юникодная файловая система

С mbcs мы разобрались и выяснили, что для работы с файловой системой эта кодировка в общем случае непригодна. Т.е. если я буду использовать русские имена файлов на русской Windows — всё будет хорошо. Но открыть этот файл у американца или голландца не выйдет. Что же делать?

В Windows помимо open есть еще и функция

FILE *_wfopen(const wchar_t *filename, const wchar_t *mode);

которая принимает wchar_t * и позволяет использовать оригинальное юникодное имя файла без всяких преобразований. Существует целый набор, начинающийся с _w — на все случаи жизни.

Значит, нужно делать следующее: для Windows использовать юникодные версии функций работы с файлами, а для всех остальных операционных систем применять .encode(sys.getfilesystemencoding()).

Реализация модуля io начиная с версии 3.1 так и поступает.

И снова импорт русских названий

Всё отлично за одним маленьким исключением — механизм импорта не использует io! Исторически сложилось так, что имя импортируемого модуля довольно быстро преобразовывается в sys.getfilesystemencoding() (с возможными ошибками и потерями, о которых я писал выше) и в таком виде пронизывает весь очень непростой и громоздкий код, чтобы попасть в функции стандартной библиотеки C.

Добавьте к этому довольно большой объем платформозависимого кода (на Маке все работает совсем не так, как на Linux) и проблему обратной совместимости (даже после объявления части API устаревшей она должна поддерживаться как минимум в двух следующих выпусках) — и вы сможете представить сложность и объемность задачи.

Так вот, после трехлетнего труда (с небольшими перерывами, естественно — это же добровольный некоммерческий Open Source) Victor Stinner завершил требуемое нелегкое преобразование. Дов
ольно незаметный, но очень важный шаг!

Файловые пути стали храниться в PyObject* (на самом деле это, конечно, strPyUnicodeObject), работающая с ними часть C APIимеет суффикс Object. Например:

PyObject *
PyImport_ImportModuleLevelObject(PyObject *name, PyObject *globals,
PyObject *locals, PyObject *fromlist,
int level);

Сравните с PyImport_ImportModuleLevel. Все функции из старого APIстали тонкими обертками над новыми вариантами. Так, PyImport_ImportModuleLevel создает PyObject из name и вызывает PyImport_ImportModuleLevelObject.

Эти старые функции оставлены для сохранения обратной совместимости, сам Питон их уже не использует.

Если быть честным, именно Windows поддержка чуть-чуть не готова — но до выхода Python 3.3 еще очень много времени. Достаточно, чтобы закончить работу и навести полный порядок.

Заключение

Я написал этот довольно длинный текст преследуя несколько целей:

  • Пожалуй, главная из них — показать, насколько порой незначительные внешне изменения способны перевернуть внутреннюю реализацию, и как нелегко их проделать не сломав того, что уже отлично работает пятнадцать лет.

  • Вторая — продемонстрировать, как работают кодировки применительно к файловой системе.

  • Третья — напомнить, что можно использовать русские буквы в идентификаторах. Комментарии излишни.

  • И, наконец, очень хотелось отметить завершение отлично выполненной работы, которая делает Питон немного лучше.

Автор: Andrew Svetlov