В этом квартале мне поручили создать одну конкретную функцию — средство импорта списков контактов для файлов CSV и других типов, которое будет сохранять их в наших текущих моделях контактов.

Для базовой версии импортера я использовал свой личный список контактов Google csv. Это оказался отличный выбор, потому что он содержит реальные контакты и данные. Следовательно, я столкнулся с проблемой, которая имеет глубокие корни, а именно символы и кодировки, отличные от ascii.

Впервые я столкнулся с проблемой, когда мой французский контакт по имени Дебора был импортирован. Как видите, возникает следующая ошибка:

Failed to submit message: u"UnicodeDecodeError: 'ascii' codec can't decode byte 0xe9 in position 1: ordinal not in range(128)"

Ресурсы

Я решил провести небольшое исследование и наткнулся на эти два отличных ресурса:

Прагматичный Юникод: http://nedbatchelder.com/text/unipain.html

Юникод в Python, полностью демистифицированный: https://www.youtube.com/watch?v=cecJ9o5GGmw

История

Я повторю некоторые из основных моментов, которые я почерпнул из них. Во-первых, компьютеры оперируют байтами, а не символами. Все, что хранится и передается, — это байты. То, что мы передаем, для нас бессмысленно. Поэтому было создано символьное представление байтов, ASCII (Американский стандартный код для обмена информацией).

Это хорошо сработало для американцев, так как весь наш алфавит умещается в пределах 128 символов. Однако другие языки могут содержать более 128 символов, и в результате люди начали создавать разные наборы символов для следующих 128 символов. Так родились наборы символов, такие как ISO Latin-1.

Имейте в виду, что все это все еще передается и хранится в байтах. Это означает, что любой код в диапазоне от 128 до 256 может иметь другое значение в зависимости от набора символов, в котором он должен быть закодирован.

В этом суть проблемы, с которой я столкнулся в связи с буквой é в Деборе.

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

Разрешение(?)

Наиболее ценным выводом из двух вышеприведенных видео было решение проблемы путем создания «бутерброда с юникодом». кодируйте его только тогда, когда он покидает вашу систему. Все, что находится посередине, должно быть в формате Unicode, что позволит вашему приложению работать с согласованным форматом.

Однако проблема все еще в том, что вы можете не знать кодировку символов, поступающих в вашу систему, так как же вы их декодируете? Может быть, принудительно использовать строгий тип кодирования при импорте, хотя это ограничивает пользователя. Мое временное решение — запустить пару вложенных блоков try для декодирования по разным наборам символов. Тем не менее, я продолжу исследования и найду более надежное решение для Деборы.

Первоначально опубликовано на newtonry.tumblr.com.