Символы ошибки кодировки

Как работают кодировки текста. Откуда появляются «кракозябры». Принципы кодирования. Обобщение и детальный разбор

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

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

О чем будет под катом: принцип работы одно байтовых кодировок (ASCII, Windows-1251 и т.д.), предпосылки появления Unicode, что такое Unicode, Unicode-кодировки UTF-8, UTF-16, их отличия, принципиальные особенности, совместимость и несовместимость разных кодировок, принципы кодирования символов, практический разбор кодирования и декодирования.

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

Предпосылки Unicode

Начать думаю стоит с того времени когда компьютеризация еще не была так сильно развита и только набирала обороты. Тогда разработчики и стандартизаторы еще не думали, что компьютеры и интернет наберут такую огромную популярность и распространенность. Собственно тогда то и возникла потребность в кодировке текста. В каком то же виде нужно было хранить буквы в компьютере, а он (компьютер) только единицы и нули понимает. Так была разработана одно-байтовая кодировка ASCII (скорее всего она не первая кодировка, но она наиболее распространенная и показательная, по этому ее будем считать за эталонную). Что она из себя представляет? Каждый символ в этой кодировке закодирован 8-ю битами. Несложно посчитать что исходя из этого кодировка может содержать 256 символов (восемь бит, нулей или единиц 2⁸=256).

Первые 7 бит (128 символов 2⁷=128) в этой кодировке были отданы под символы латинского алфавита, управляющие символы (такие как переносы строк, табуляция и т.д.) и грамматические символы. Остальные отводились под национальные языки. То есть получилось что первые 128 символов всегда одинаковые, а если хочешь закодировать свой родной язык пожалуйста, используй оставшуюся емкость. Собственно так и появился огромный зоопарк национальных кодировок. И теперь сами можете представить, вот например я находясь в России беру и создаю текстовый документ, у меня по умолчанию он создается в кодировке Windows-1251 (русская кодировка использующаяся в ОС Windows) и отсылаю его кому то, например в США. Даже то что мой собеседник знает русский язык, ему не поможет, потому что открыв мой документ на своем компьютере (в редакторе с дефолтной кодировкой той же самой ASCII) он увидит не русские буквы, а кракозябры. Если быть точнее, то те места в документе которые я напишу на английском отобразятся без проблем, потому что первые 128 символов кодировок Windows-1251 и ASCII одинаковые, но вот там где я написал русский текст, если он в своем редакторе не укажет правильную кодировку будут в виде кракозябр.

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

Небольшой практикум ASCII

Возможно покажется элементарщиной, но раз уж решил объяснять все и подробно, то это надо.

Вот таблица символов ASCII:

Тут имеем 3 колонки:

• номер символа в десятичном формате
• номер символа в шестнадцатиричном формате
• представление самого символа.

Итак, закодируем строку «ok» (англ.) в кодировке ASCII. Символ «o» (англ.) имеет позицию 111 в десятичном виде и 6F в шестнадцатиричном. Переведем это в двоичную систему — 01101111. Символ «k» (англ.) — позиция 107 в десятеричной и 6B в шестнадцатиричной, переводим в двоичную — 01101011. Итого строка «ok» закодированная в ASCII будет выглядеть так — 01101111 01101011. Процесс декодирования будет обратный. Берем по 8 бит, переводим их в 10-ичную кодировку, получаем номер символа, смотрим по таблице что это за символ.

Unicode

С предпосылками создания общей таблицы для всех в мире символов, разобрались. Теперь собственно, к самой таблице. Unicode — именно эта таблица и есть (это не кодировка, а именно таблица символов). Она состоит из 1 114 112 позиций. Большинство этих позиций пока не заполнены символами, так что вряд ли понадобится это пространство расширять.

Разделено это общее пространство на 17 блоков, по 65 536 символов в каждом. Каждый блок содержит свою группу символов. Нулевой блок — базовый, там собраны наиболее употребляемые символы всех современных алфавитов. Во втором блоке находятся символы вымерших языков. Есть два блока отведенные под частное использование. Большинство блоков пока не заполнены.

Итого емкость символов юникода составляет от 0 до 10FFFF (в шестнадцатиричном виде).

Записываются символы в шестнадцатиричном виде с приставкой «U+». Например первый базовый блок включает в себя символы от U+0000 до U+FFFF (от 0 до 65 535), а последний семнадцатый блок от U+100000 до U+10FFFF (от 1 048 576 до 1 114 111).

Отлично теперь вместо зоопарка национальных кодировок, у нас есть всеобъемлющая таблица, в которой зашифрованы все символы которые нам могут пригодиться. Но тут тоже есть свои недостатки. Если раньше каждый символ был закодирован одним байтом, то теперь он может быть закодирован разным количеством байтов. Например для кодирования всех символов английского алфавита по прежнему достаточно одного байта например тот же символ «o» (англ.) имеет в юникоде номер U+006F, то есть тот же самый номер как и в ASCII — 6F в шестнадцатиричной и 111 в десятеричной. А вот для кодирования символа «U+103D5» (это древнеперсидская цифра сто) — 103D5 в шестнадцатиричной и 66 517 в десятеричной, тут нам потребуется уже три байта.

Решить эту проблему уже должны юникод-кодировки, такие как UTF-8 и UTF-16. Далее речь пойдет про них.

UTF-8

UTF-8 является юникод-кодировкой переменной длинны, с помощью которой можно представить любой символ юникода.

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

Немного отступлю от темы, надо написать про совместимость ASCII и UTF

То что латинские символы и основные управляющие конструкции, такие как переносы строк, табуляции и т.д. закодированы одним байтом делает utf-кодировки совместимыми с кодировками ASCII. То есть фактически латиница и управляющие конструкции находятся на тех же самых местах как в ASCII, так и в UTF, и то что закодированы они и там и там одним байтом и обеспечивает эту совместимость.

Давайте возьмем символ «o»(англ.) из примера про ASCII выше. Помним что в таблице ASCII символов он находится на 111 позиции, в битовом виде это будет 01101111. В таблице юникода этот символ — U+006F что в битовом виде тоже будет 01101111. И теперь так, как UTF — это кодировка переменной длины, то в ней этот символ будет закодирован одним байтом. То есть представление данного символа в обеих кодировках будет одинаково. И так для всего диапазона символов от 0 до 128. То есть если ваш документ состоит из английского текста то вы не заметите разницы если откроете его и в кодировке UTF-8 и UTF-16 и ASCII (прим. в UTF-16 такие символы все равно будут закодированы двумя байтами, по этому вы не увидите разницы, если ваш редактор будет игнорировать нулевые байты), и так до момента пока вы не начнете работать с национальным алфавитом.

Сравним на практике как будет выглядеть фраза «Hello мир» в трех разных кодировках: Windows-1251 (русская кодировка), ISO-8859-1 (кодировка западно-европейских языков), UTF-8 (юникод-кодировка). Суть данного примера состоит в том что фраза написана на двух языках. Посмотрим как она будет выглядеть в разных кодировках.

В кодировке ISO-8859-1 нет таких символов «м», «и» и «р».

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

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

01001000 01100101 01101100 01101100 01101111 00100000 11101100 11101000 11110000
Отлично, вот это и есть фраза «Hello мир» в кодировке Windows-1251.

Теперь представим что вы имеете файл с текстом, но не знаете в какой кодировке этот текст. Вы предполагаете что он в кодировке ISO-8859-1 и открываете его в своем редакторе в этой кодировке. Как сказано выше с частью символов все в порядке, они есть в этой кодировке, и даже находятся на тех же местах, но вот с символами из слова «мир» все сложнее. Этих символов в этой кодировке нет, а на их местах в кодировке ISO-8859-1 находятся совершенно другие символы. А конкретно «м» — позиция 236, «и» — 232. «р» — 240. И на этих позициях в кодировке ISO-8859-1 находятся следующие символы позиция 236 — символ «ì», 232 — «è», 240 — «ð»

Значит фраза «Hello мир» закодированная в Windows-1251 и открытая в кодировке ISO-8859-1 будет выглядеть так: «Hello ìèð». Вот и получается что эти две кодировки совместимы лишь частично, и корректно перекодировать строку из одной кодировке в другую не получится, потому что там просто напросто нет таких символов.

Тут и будут необходимы юникод-кодировки, а конкретно в данном случае рассмотрим UTF-8. То что символы в ней могут быть закодированы разным количеством байтов от 1 до 4 мы уже выяснили. Теперь стоит сказать что с помощью UTF могут быть закодированы не только 256 символов, как в двух предыдущих, а вобще все символы юникода

Работает она следующим образом. Первый бит каждого байта кодирующего символ отвечает не за сам символ, а за определение байта. То есть например если ведущий (первый) бит нулевой, то это значит что для кодирования символа используется всего один байт. Что и обеспечивает совместимость с ASCII. Если внимательно посмотрите на таблицу символов ASCII то увидите что первые 128 символов (английский алфавит, управляющие символы и знаки препинания) если их привести к двоичному виду, все начинаются с нулевого бита (будьте внимательны, если будете переводить символы в двоичную систему с помощью например онлайн конвертера, то первый нулевой ведущий бит может быть отброшен, что может сбить с толку).

01001000 — первый бит ноль, значит 1 байт кодирует 1 символ -> «H»

01100101 — первый бит ноль, значит 1 байт кодирует 1 символ -> «e»

Если первый бит не нулевой то символ кодируется несколькими байтами.

Для двухбайтовых символов первые три бита должны быть такие — 110

11010000 10111100 — в начале 110, значит 2 байта кодируют 1 символ. Второй байт в таком случае всегда начинается с 10. Итого отбрасываем управляющие биты (начальные, которые выделены красным и зеленым) и берем все оставшиеся (10000111100), переводим их в шестнадцатиричный вид (043С) -> U+043C в юникоде равно символ «м».

для трех-байтовых символов в первом байте ведущие биты — 1110

11101000 10000111 101010101 — суммируем все кроме управляющих битов и получаем что в 16-ричной равно 103В5, U+103D5 — древнеперситдская цифра сто (10000001111010101)

для четырех-байтовых символов в первом байте ведущие биты — 11110

11110100 10001111 10111111 10111111 — U+10FFFF это последний допустимый символ в таблице юникода (100001111111111111111)

Теперь, при желании, можем записать нашу фразу в кодировке UTF-8.

UTF-16

UTF-16 также является кодировкой переменной длинны. Главное ее отличие от UTF-8 состоит в том что структурной единицей в ней является не один а два байта. То есть в кодировке UTF-16 любой символ юникода может быть закодирован либо двумя, либо четырьмя байтами. Давайте для понятности в дальнейшем пару таких байтов я буду называть кодовой парой. Исходя из этого любой символ юникода в кодировке UTF-16 может быть закодирован либо одной кодовой парой, либо двумя.

Начнем с символов которые кодируются одной кодовой парой. Легко посчитать что таких символов может быть 65 535 (2в16), что полностью совпадает с базовым блоком юникода. Все символы находящиеся в этом блоке юникода в кодировке UTF-16 будут закодированы одной кодовой парой (двумя байтами), тут все просто.

символ «o» (латиница) — 00000000 01101111
символ «M» (кириллица) — 00000100 00011100

Теперь рассмотрим символы за пределами базового юникод диапазона. Для их кодирования потребуется уже две кодовые пары (4 байта). И механизм их кодирования немного сложнее, давайте по порядку.

Для начала введем понятия суррогатной пары. Суррогатная пара — это две кодовые пары используемые для кодирования одного символа (итого 4 байта). Для таких суррогатных пар в таблице юникода отведен специальный диапазон от D800 до DFFF. Это значит, что при преобразовании кодовой пары из байтового вида в шестнадцатиричный вы получаете число из этого диапазона, то перед вами не самостоятельный символ, а суррогатная пара.

Чтобы закодировать символ из диапазона 10000 — 10FFFF (то есть символ для которого нужно использовать более одной кодовой пары) нужно:

1. из кода символа вычесть 10000(шестнадцатиричное) (это наименьшее число из диапазона 10000 — 10FFFF)
2. в результате первого пункта будет получено число не больше FFFFF, занимающее до 20 бит
3. ведущие 10 бит из полученного числа суммируются с D800 (начало диапазона суррогатных пар в юникоде)
4. следующие 10 бит суммируются с DC00 (тоже число из диапазона суррогатных пар)
5. после этого получатся 2 суррогатные пары по 16 бит, первые 6 бит в каждой такой паре отвечают за определение того что это суррогат,
6. десятый бит в каждом суррогате отвечает за его порядок если это 1 то это первый суррогат, если 0, то второй

Разберем это на практике, думаю станет понятнее.

Для примера зашифруем символ, а потом расшифруем. Возьмем древнеперсидскую цифру сто (U+103D5):

1. 103D5 — 10000 = 3D5
2. 3D5 = 0000000000 1111010101 (ведущие 10 бит получились нулевые приведем это к шестнадцатиричному числу, получим 0 (первые десять), 3D5 (вторые десять))
3. 0 + D800 = D800 (1101100000000000) первые 6 бит определяют что число из диапазона суррогатных пар десятый бит (справа) нулевой, значит это первый суррогат
4. 3D5 + DC00 = DFD5 (1101111111010101) первые 6 бит определяют что число из диапазона суррогатных пар десятый бит (справа) единица, значит это второй суррогат
5. итого данный символ в UTF-16 — 1101100000000000 1101111111010101

Теперь наоборот раскодируем. Допустим что у нас есть вот такой код — 1101100000100010 1101111010001000:

1. переведем в шестнадцатиричный вид = D822 DE88 (оба значения из диапазона суррогатных пар, значит перед нами суррогатная пара)
2. 1101100000100010 — десятый бит (справа) нулевой, значит первый суррогат
3. 1101111010001000 — десятый бит (справа) единица, значит второй суррогат
4. отбрасываем по 6 бит отвечающих за определение суррогата, получим 0000100010 1010001000 (8A88)
5. прибавляем 10000 (меньшее число суррогатного диапазона) 8A88 + 10000 = 18A88
6. смотрим в таблице юникода символ U+18A88 = Tangut Component-649. Компоненты тангутского письма.

Спасибо тем кто смог дочитать до конца, надеюсь было полезно и не очень занудно.

Вот некоторые интересные ссылки по данной теме:
habr.com/ru/post/158895 — полезные общие сведения по кодировкам
habr.com/ru/post/312642 — про юникод
unicode-table.com/ru — сама таблица юникод символов

Ну и собственно куда же без нее
ru.wikipedia.org/wiki/%D0%AE%D0%BD%D0%B8%D0%BA%D0%BE%D0%B4 — юникод
ru.wikipedia.org/wiki/ASCII — ASCII
ru.wikipedia.org/wiki/UTF-8 — UTF-8
ru.wikipedia.org/wiki/UTF-16 — UTF-16

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

Чаще всего кракозябры образуются на выводе программ по причине неправильно настроенной кодировки символов, а также из-за использования неподходящего шрифта. Проблема может быть связана и непосредственно с браузером: например, в 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].

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

• Буква зю

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

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

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

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

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

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

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

В 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].

[править] Эквивалентные варианты

Жаргонизм не имеет на сегодняшний день устоявшейся формы. Существуют множество конкурирующих вариаций. Вот некоторые из них:

• абракадабра
• абраказябры
• балиберда
• бнопня
• боржоми ^{[источник не указан 370 дней]}
• ёгрики
• зюквы
• зюки
• калябушки
• каракули ^{[источник не указан 370 дней]}
• квакозябры
• козюбрики
• козяблики
• козябры
• кракозябли
• кракозяблы
• кракосямбы
• крокозяблики
• крокозяблы
• крокозябры
• крюкозяблы
• крюкозябры
• крякозяблики
• крякозябры
• птичий язык

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

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

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

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

Для восстановления текста (и для перекодировки) в POSIX-совместимых системах можно использовать утилиту iconv, например:

iconv -c -f cp1251 -t cp1252 source.txt > target.txt

Если возможности применить iconv нет, следует открыть текстовый файл с неизвестной кодировкой с помощью любого популярного браузера, в котором доступно ручное указание кодировки (обычно: Вид — кодировка — … в верхнем меню, либо в контекстном меню). Позже, когда методом перебора удастся получить читаемый текст, его можно скопировать в текстовой редактор и сохранить в нужной кодировке. Также существует множество утилит, позволяющих ручное (с выбором пары кодировок) или автоматическое (вплоть до нескольких уровней глубины) перекодирование текста, например, для Windows, TotalRecode или «Штирлиц».

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

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

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

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

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

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

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

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

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

• Буква зю

[править] Примечания

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

• Почтовый декодер
• Универсальный декодер кириллицы 
• Онлайн декодер 

Материал из Seo Wiki — Поисковая Оптимизация и Программирование

Перейти к: навигация, поиск

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

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

Происходит от слова «крокозябра», которое, в свою очередь, является синонимом выражения «детские каракули».. По-японски явление, аналогичное крокозябрам, называется модзибакэ (яп. 文字化け), а по-китайски — луаньма (кит. 乱码 «мешанина из знаков»). Болгары называют этот эффект маймуница («обезьяница»), а сербы — ђубре («мусор»).

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

История

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

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

Примеры

Примечания

Перекодировка

Для восстановления текста (вообще для перекодировки) можно использовать утилиту iconv, например:

$ iconv -f cp1251 -t cp1252 source.txt > target.txt

Если при открытии текстовых файлов вы получаете кракозябру, попробуйте открыть его с помощью любого браузера, в котором доступно ручное указание кодировки (обычно: Вид — кодировка — … в верхнем меню, либо в контекстном меню). Если после этого получается текст из одной строки без деления на абзацы, можно в контекстном меню выбрать Исходный текст (View Source), в начале страницы прописать <PRE> и сохранить.

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

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

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

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

Ссылки

• Почтовый декодер Студии Артемия Лебедева
• Универсальный декодер кириллицы — Онлайн-перекодировщик текста крякозябры на кириллице.

ar:موجيباكي

de:Zeichensalat
el:Mojibake
en:Mojibake
eo:Moĝibako
es:Mojibake
fr:Mojibake
gl:Mojibake
it:Mojibake
ja:文字化け
ksh:Bochstabesallaat
pt:Mojibake
simple:Mojibake
sv:Mojibake
ur:عجیب محارف
zh:亂碼

→