Ошибка кодировки пример

Кракозя́бры (крякозя́бры) — бессмысленный с точки зрения читателя набор символов, чаще всего получаемый на компьютере в результате неправильного перекодирования осмысленного текста.

Чаще всего кракозябры образуются на выводе программ по причине неправильно настроенной кодировки символов, а также из-за использования неподходящего шрифта. Проблема может быть связана и непосредственно с браузером: например, в Google Chrome русская кодировка CP-866 отсутствует, а многие старые браузеры не умели читать в UTF-16.

Термин[править]

Жаргонизм «кракозябры» не имеет на сегодняшний день устоявшейся формы, существует множество вариаций произношения и написания этого слова: части крако-, кроко-, кряко-; -зябры, -зябли и другие могут встречаться в разных сочетаниях. Кроме того, данное явление может быть обозначено и другими словами, например:

• абракадабра
• бнопня
• зюки
• мусор
• иероглифы
• стриказяблик

Название «бнопня» (или, более точно, «бНОПНЯ») напрямую происходит от явления неправильной настройки кодировок в почтовых программах. Так выглядит слово «Вопрос», преобразованное из кодировки CP1251 в KOI8-R. По слову «бНОПНЯ» опытные пользователи сразу определяли новичков, задававших вопрос по настройке кодировки.

Этимология[править]

Происхождение слова неизвестно.

В народной этимологии приводится аналогия с детскими каракулями (гибрид крокодила и зебры), а также производное от английского глагола «to crack» — ломать, крушить.

Возможная связь: В польском детском научно-популярном журнале «Горизонты техники для детей», русскоязычная версия которого продавалась в СССР (№ 12 за 1979 год), был опубликован фантастический рассказ «КАИС» Гали и Лены Марьиных, 11 и 13 лет. В рассказе фигурирует форма инопланетной жизни «стреказябли».

В единственном числе «кракозябра» — вообще любой компьютерный символ, для которого в русском языке нет общеизвестного звука (а то и названия), например, значок @.

В других языках[править]

По-японски явление, аналогичное кракозябрам, называется модзибакэ (яп. 文字化け «искажённые символы»), а по-китайски — луаньма (кит. 乱码 «мешанина из знаков»). Болгары называют этот эффект маймуница («обезьянья азбука»), сербы — ђубре («мусор»), немцы — Buchstabensalat («салат из букв») и Krähenfüße («вороньи лапки»), поляки — krzaki («знаки китайского письма; помехи видные в телевизоре, когда нет сигнала», буквально «кусты»), в иврите джибриш(Шаблон:Hebrew).

История[править]

В 1980-е и 1990-е пользователи компьютеров и с 1990 г. — пользователи русскоязычной части интернета вынуждены были мириться с существованием нескольких конкурирующих кодировок кириллицы: основная — ГОСТ, альтернативная — DOS 866 (Unix KOI8-R, Windows CP-1251, ISO 8859-5), MacCyrillic. В результате неправильной конфигурации серверов и недостаточной совместимости тексты очень часто было невозможно прочесть. Получая сообщения по электронной почте или зайдя на веб-сайт, неопытные пользователи могли наткнуться на странные необычные символы вместо букв кириллицы.

Несмотря на всё более широкое распространение Юникода, феномен кракозябр иногда встречается и сегодня. Есть возможность получить неадекватные символы при использовании неправильных шрифтов при печати на принтере или фотонаборном автомате, неверно настроенной локали программы (когда вместо кодовой страницы CP1251 используется CP1252).

При использовании UTF-8 всё равно остаётся риск получить кракозябры при выводе текста по HTTP: если кодировка нигде не указана, RFC 2616 даёт значение по умолчанию — ISO-8859-1^[1].

Примеры[править]

Для примера использована панграмма (без кавычек): «Широкая электрификация южных губерний даст мощный толчок подъёму сельского хозяйства.».

Перекодировка[править]

Для восстановления текста (и для перекодировки) в POSIX-совместимых системах можно использовать утилиту iconv, например:
<syntaxhighlight lang=»bash»>
iconv -c -f cp1251 -t cp1252 source.txt > target.txt
</syntaxhighlight>
Если возможности применить iconv нет, следует открыть текстовый файл с неизвестной кодировкой с помощью любого популярного браузера, в котором доступно ручное указание кодировки (обычно: Вид — кодировка — … в верхнем меню, либо в контекстном меню). Позже, когда методом перебора удастся получить читаемый текст, его можно скопировать в текстовой редактор и сохранить в нужной кодировке. Также существует множество утилит, позволяющих ручное (с выбором пары кодировок) или автоматическое (вплоть до нескольких уровней глубины) перекодирование текста, например, для Windows: TotalRecode или «Штирлиц».

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

Другие искажения, связанные с перекодировкой[править]

Нередко бывает, что перекодировка осуществляется в правильном направлении, но сам перекодировщик работает не совсем корректно. Например, некоторые программы-перекодировщики преобразуют только базовые русские буквы, а все остальные символы оставляют на месте. В итоге при перекодировке KOI8-R → Windows-1251 буква ё превращается в Ј (сербская буква), значок градуса (°) превращается в њ и т. д. (такие тексты в изобилии встречаются в Интернете, достаточно поискать слова «всЈ» или «њС»).

Другой вариант искажений связан с тем, что в целевой кодировке могут отсутствовать символы, имеющиеся в исходной кодировке. В этом случае отсутствующие символы могут просто выбрасываться, заменяться на символ-заменитель (часто знак вопроса — ?, иногда �) или же заменяться на похожие символы из ASCII (например, знак минуса (U+2212, −) может заменяться на простой дефис (U+002D, -), буква š может заменяться на s и т. д. В случае простого текста такие потери информации неизбежны, однако, если преобразованию подвергается файл HTML или XML, то корректным преобразованием будет замена отсутствующих в целевой кодировке символов на соответствующие мнемоники HTML: например, знак минуса должен заменяться на − или − буква š должна заменяться на š или š и т. д.

В культуре[править]

В 1997 г. московское издательство «АРГО-РИСК» выпустило сборник рассказов «Проблемы с кодировкой» (составитель Д. Кузьмин), в котором «все тексты напечатаны не поддающимимся прочтению наборами букв или иных знаков, возникающими обыкновенно при конвертировании текста из одной компьютерной программы в другую как следствие некорректной перекодировки»; в книгу вошли рассказы Николая Байтова, Вячеслава Курицына, Владимира Тучкова, Игоря Жукова, Максима Скворцова и Данилы Давыдова^[4]. По мнению Д. Суховей, таким «акционным» жестом издатели, вероятно, стремились привлечь внимание к новым эффектам, возникающими в результате „компьютеризации“ литературы^[5].

См. также[править]

• Буква зю

Источники[править]

Ссылки[править]

• Почтовый декодер Студии Артемия Лебедева

Время на прочтение
9 мин

Количество просмотров 58K

Зачем эта статья?

Об обработке текстов на естественном языке сейчас знают все. Все хоть раз пробовали задавать вопрос Сири или Алисе, пользовались Grammarly (это не реклама), пробовали генераторы стихов, текстов… или просто вводили запрос в Google. Да, вот так просто. На самом деле Google понимает, что вы от него хотите, благодаря штукам, которые умеют обрабатывать и анализировать естественную речь в вашем запросе.

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

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

Обратите внимание на следующий запрос:

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

Конечно, уже есть много готовых инструментов, которые довольно неплохо справляются с обработкой текстов и могут делать разные крутые вещи, но я не об этом хочу вам поведать. Я не буду рассказывать про nltk, стемминг, лемматизацию и т.п. Я хочу опуститься на несколько ступенек ниже и обсудить некоторые тонкости кодировок, байтов, их обработки.

Откуда взялась статья?

Одним из важных составляющих в области ИИ является обработка текстов на естественном языке. В процессе изучения данной тематики я начал задавать себе вопросы, которые в конечном итоге привели меня к изучению кодировок, представлению текстов в памяти, как они преобразуются, приводятся к нормальной форме. Я плохо понимал эту тему в начале, потребовалось немало времени и мозгового ресурса, чтобы понять, принять и запомнить некоторые вещи. Написанием данной статьи я хочу облегчить жизнь людям, которые столкнутся с необходимостью чтения и обработки текстов на Python и самому закрепить изученное. А некоторыми полезными поинтами своего изучения я постараюсь поделиться в данной статье.

Важная ремарка: я не являюсь специалистом в области обработки текстов. Изложенный материал является результатом исключительно любительского изучения.

Проблема чтения файлов

Допустим, у нас есть файл с текстом. Нам нужно этот текст прочитать. Казалось бы, пиши себе такой вот скрипт для чтения из файла да и радуйся:

with open("some_text.txt", "r") as file:
    content = file.read()

print(content)

В файле содержится вот такое вот изречение:

pitón

что переводится с испанского как питон. Однако консоль OC Windows 10 покажет нам немного другой результат:

C:myhabrTextsInPython> python .script1.py
pitón

Сейчас мы разберёмся, что именно пошло не так и по какой причине.

Кодировка

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

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

with open("simple_text.txt", "r") as file:
    text = file.read()
print(text)

Посмотрим на результат:

C:myhabrTextsInPython> python .script2.py
ÿþ<♦8♦@♦

Очень интересно, ничего непонятно. По умолчанию Python использует кодировку utf-8, но видимо запись в файл происходила не с её помощью. Здесь нам придёт на помощь дополнительный параметр функции open — параметр encoding, который позволяет указать конкретную кодировку, в которой следует прочитать файл (или записывать в него). Попробуем перебрать несколько кодировок и найти подходящую.

codecs = ["cp1252", "cp437", "utf-16be", "utf-16"]

for codec in codecs:
    with open("simple_text.txt", "r", encoding=codec) as file:
        text = file.read()
    print(codec.rjust(12), "|", text)

Результат:

C:myhabrTextsInPython> python .script3.py
      cp1252 | ÿþ<8@
       cp437 |  ■<8@
    utf-16be | 㰄㠄䀄
      utf-16 | мир

Разные кодировки расшифровывают байты из файла по-разному, то есть разным кодовым позициям могут соотвествовать разные символы. Пример примитивный, несложно догадаться, что истинная кодировка файла — это utf-16.

Важный поинт: при записи и чтении из файлов следует указывать конкретную кодировку, это позволит избежать путаницы в дальнейшем.

Ошибки, связанные с кодировками

При возникновении ошибки, связанной с кодировками, интерпретатор выдаст одно из следующих исключений:

• UnicodeError. Это общее исключение для ошибок кодировки.

• UnicodeDecodeError. Данное исключение возбуждается, если встречается кодовая позиция, которая отсутствует в кодировке.

• UnicodeEncodeError. А это исключение возбуждается, когда символ, который необходимо закодировать, незнаком для кодировки.

Попытка выполнения вот такого кода (в файле всё ещё содержится испанский питон):

with open("some_text.txt", "r", encoding="ascii") as file:
    file.read()

даст нам следующий результат:

UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 3: ordinal not in range(128)

Кодировка ASCII не поддерживает никакой алфавит, кроме английского. Поэтому декодирование символа «ó» вызывает у ASCII сложности. Однако Python всемогущ и есть механизм, который позволяет обработать ошибки кодировок. Это дополнительный параметр методов encode и decode — параметр errors. Он может принимать следующие значения:

Для обеих функций:

Только для метода encode:

Также отдельно выделены значения surrogatepass и surrogateescape.

Приведём пример использования таких обработчиков:

>>> text = "pitón"
>>> text.encode("ascii", errors="ignore")
b'pitn'
>>> text.encode("ascii", errors="replace")
b'pit?n'
>>> text.encode("ascii", errors="xmlcharrefreplace")
b'pitón'
>>> text.encode("ascii", errors="backslashreplace")
b'pit\xf3n'
>>> text.encode("ascii", errors="namereplace")
b'pit\N{LATIN SMALL LETTER O WITH ACUTE}n'

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

Cворачивание регистра

Сворачивание регистра — это попытка унифицировать текст любого представления к канонической форме. Например, приведение всего текста в нижний регистр. Также над текстом производятся некоторые преобразования (например, немецкая «эсцет» — «ß» — преобразуется в «ss»). В Python 3.3 появился метод str.casefold(), который как раз выполняет сворачивание регистра. Если текст содержит только символы кодировки latin1, результат применения этого метода будет аналогичен методу str.lower().

И по классике приведём пример:

>>> text = "Die größte Stadt der Welt liegt in China"
>>> text.casefold()
'die grösste stadt der welt liegt in china'

В результате применённый метод не только привёл весь текст к нижнему регистру, но и преобразовал специфический немецкий символ.

Важный поинт: привести текст можно не только методом str.lower(), но и методом str.casefold(), который может выполнить дополнительные преобразования текста.

Нормализация

Нормализация — это полноценное приведение текста к единому представлению.

Чтобы обозначить важность нормализации, приведём простой пример:

letter1 = "µ"
letter2 = "μ"

Внешне два этих символа выглядят абсолютно одинаково. Однако если мы попытаемся вывести имена этих символов, как их видит интерпретатор Python’a, результат нас порядком удивит.

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

import unicodedata

letter1 = "µ"
letter2 = "μ"
print(unicodedata.name(letter1))
print(unicodedata.name(letter2))

Результат выполнения данного кода:

C:myhabrTextsInPython> python .script7.py
MICRO SIGN
GREEK SMALL LETTER MU

Итак, интерпретатор Python’a видит эти символы как два разных, но в стандарте Unicode они имеют одинаковое отображение.Такие символы называют каноническими эквивалентами. Приложения будут считать два этих символа одинаковыми, но не интерпретатор.

Посмотрим на ещё один пример:

>>> s1 = 'café'
>>> s2 = 'cafeu0301'
>>> s1, s2
('café', 'café')
>>> s1 == s2
False
>>> len(s1), len(s2)
(4, 5)

Данные символы также будут являться каноническими эквивалентами. Из примера мы видим, что символ «é» в стандарте Unicodeможет быть представлен двумя способами, которые к тому же имеют разную длину. Символ «é» может быть представлен одним или двумя байтами.

Решением таких конфликтов занимается нормализация. Она реализована в Python в функции unicodedata.normalize.Первым аргумент является так называемая форма нормализации — нормализации строк Unicode, которые позволяют определить, эквивалентны ли какие-либо две строки Unicode друг другу. Всего предлагается четыре формы:

Разберём каждую форму немного подробнее.

• NFC

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

>>> unicodedata.normalize("NFC", s1), unicodedata.normalize("NFC", s2)
('café', 'café')
>>> len(unicodedata.normalize("NFC", s1)), len(unicodedata.normalize("NFC", s2))
(4, 4)
>>> unicodedata.normalize("NFC", s1) == unicodedata.normalize("NFC", s2)
True
>>> len(unicodedata.normalize("NFC", s1)) == len(unicodedata.normalize("NFC", s2))
True

Итак, нормализация обеих строк внешне их не изменила, однако длина строки s2 стала равной 4 (т.е. на один байт меньше). Была произведена композиция байтов eu0301, которые являлись отображением «é». Данная последовательность была заменена на минимальное представление символа, т.е. теперь представление этого символа для интерпретатора выглядит как в строке s1. Как результат, мы видим, что длина нормализованных строк стала равной, и сами строки также стали равны.

• NFD

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

>>> unicodedata.normalize("NFD", s1), unicodedata.normalize("NFD", s2)
('café', 'café')
>>> len(unicodedata.normalize("NFD", s1)), len(unicodedata.normalize("NFD", s2))
(5, 5)
>>> unicodedata.normalize("NFD", s1) == unicodedata.normalize("NFD", s2)
True
>>> len(unicodedata.normalize("NFD", s1)) == len(unicodedata.normalize("NFD", s2))
True

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

На данном этапе настал момент ввести понятие символа совместимости. Символы совместимости (compatibility characters) были введены в Unicode ради совместимости с другими стандартами, в частности, стандарты, которые предшествовали Unicode. Это означает, что некоторые символы могут встречаться в стандарте несколько раз. Мы уже могли наблюдать это явление в начале этого раздела на примере с символом «мю». Он считается символом совместимости.

• NFKC и NFKD

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

Немного модифицируем наш пример из начала раздела. Выведем кодовые позиции символов до и после нормализации:

import unicodedata

letter1 = "µ"
letter2 = "μ"
print("Before normalizing:", ord(letter1), ord(letter2))
letter1 = unicodedata.normalize("NFKC", letter1)
letter2 = unicodedata.normalize("NFKC", letter2)
print("After normalizing:", ord(letter1), ord(letter2))

И результат выполнения кода:

Before normalizing: 181 956
After normalizing: 956 956

Итак, мы видим, что первый символ (который являлся знаком «микро») был заменён на греческую «мю», т.е. более предпочтительное представление символа. Таким образом, если необходимо, например, провести частотный анализ текста, формы нормализации, которые затрагивают символы совместимости, могут помочь с этим, приводя символы совместимости к единому представлению.

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

Дополнительные материалы: что использовалось в статье и что почитать по теме

«Fluent Python», Лучано Ромальо

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

Документация для Unicode на официальном сайте Python

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

Unicode® Standard Annex

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

Когда я только начинал изучать тему разработки сайтов, кракозябры были одной из моих постоянных проблем. Создал HTML-страницу — в браузере кракозябры, установил денвер и попробовал создать сайт на PHP — снова вместо букв кракозябры. Скачал иностранную тему, подключился к базе данных — та же проблема.

На своих сайтах я обычно использую UTF-8 (это такая кодировка текста, она ещё называется юникод), соответственно она будет присутствовать во всех примерах в этой статье.

1. UTF-8 без BOM

Начнём с самой простой проблемы. Вы создали какой-то HTML-файл, открыли его в браузере и получили:

Проблема актуальна в основном для пользователей Windows, на маке я с таким ни разу не сталкивался.

Решение проблемы зависит в основном от того, каким редактором вы пользуетесь. Для пользователей Windows я рекомендую бесплатный офигительный Notepad++.

Значит, открываем файл в Notepad++ и переходим в Кодировки > Преобразовать в UTF-8 без BOM. Вопрос — почему без BOM? Потому что с BOM у вас будут постоянно вставляться пустые символы (на самом деле они не пустые, у них тоже есть своя функция, но нам она в данном случае не нужна) куда не надо, а для PHP это уже критично.

2. Мета тег charset

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

Всё, что нам требуется, это вставить следующий код между тегами <head> сайта. Прежде всего проверьте, возможно этот метатег у вас уже присутствует. Если да, то посмотрите какое у него стоит значение параметра charset.

В темах WordPress обычно этот тег уже имеется по умолчанию и выглядит следующим образом:

<meta charset="<?php bloginfo('charset'); ?>" />

3. .htaccess

Если русские буквы до сих пор отображаются кракозябрами, тогда открываем ваш .htaccess, который лежит в корне сайта и вставляем туда с новой строки это:

4. Заголовки сервера через header()

Ещё один способ определения кодировки. На этот раз через PHP. На WordPress никогда не приходилось им пользоваться.

header('Content-Type: text/html; charset=utf-8');

Важно! Этот код должен вставляться до того, как будет что-либо выведено на странице сайта, иначе — ошибка.

5. Проблемы с последним символом при обрезке строки

На многих сайтах встречаются блоки с популярными записями, последними комментариями, отзывами и так далее. Обычно в таких обзорных блоках выводится часть записи/комментария/отзыва и кнопка «читать далее». Так вот, для того, чтобы вывести первые несколько предложений или первые несколько слов текста, используется функция PHP substr(). Конечно же в основном я имею ввиду англоязычные темы, которых так много в интернете. Даже если у этих тем есть локализация — то есть вроде бы она на русском — переведена админка, переведён практически весь сайт, но при этом мы встречаем такие вот косяки:

Как решить эту проблему?

Легко — всё что нам нужно, это найти функцию substr() в коде и поменять её на mb_substr().

Если после этого у вас полезут ошибки на сайт, то скорее всего multibyte-функции не поддерживаются вашим хостингом, первое, что вам следует сделать, это написать в супорт и спросить, нельзя ли их подключить на ваш аккаунт. Если нет, меняем хостинг, например на тот, которым пользуюсь я.

6. MySQL

У меня не раз бывало такое, что я подключался к MySQL, вытаскивал какие-нибудь данные, и при их выводе на сайте, текст отображался кракозябрами.

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

Для того, чтобы исправить это, после подключения к БД, делаем следующее:

mysql_query("SET NAMES 'UTF8'");

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