Модзибаке ( яп .文字化け; IPA: [mod͡ʑibake] , «преобразование символов») — искажённый или бессвязный текст, являющийся результатом декодирования текста с использованием непреднамеренной кодировки символов . [1] Результатом является систематическая замена символов совершенно не связанными с ними, часто из другой системы письма .
Это отображение может включать общий символ замены ("�") в местах, где двоичное представление считается недействительным. Замена может также включать несколько последовательных символов, как показано в одной кодировке, когда тот же двоичный код составляет один символ в другой кодировке. Это происходит либо из-за разной кодировки постоянной длины (как в азиатских 16-битных кодировках против европейских 8-битных кодировок), либо из-за использования кодировок переменной длины (в частности, UTF-8 и UTF-16 ).
Неудачная визуализация глифов из-за отсутствия шрифтов или отсутствия глифов в шрифте — это другая проблема, которую не следует путать с mojibake. Симптомы этой неудачной визуализации включают блоки с кодовой точкой , отображаемой в шестнадцатеричном формате , или с использованием универсального символа замены. Важно, что эти замены являются допустимыми и являются результатом правильной обработки ошибок программным обеспечением.
Для корректного воспроизведения исходного закодированного текста необходимо сохранить соответствие между закодированными данными и понятием их кодировки (т. е. исходные и целевые стандарты кодировки должны быть одинаковыми). Поскольку mojibake является примером несоответствия между ними, этого можно добиться, манипулируя самими данными или просто переименовывая их.
Mojibake часто встречается с текстовыми данными, которые были помечены неправильной кодировкой; они могут быть даже не помечены вообще, но перемещены между компьютерами с разными кодировками по умолчанию. Основным источником проблем являются протоколы связи , которые полагаются на настройки на каждом компьютере, а не на отправку или хранение метаданных вместе с данными.
Различия в настройках по умолчанию между компьютерами частично обусловлены различным развертыванием Unicode среди семейств операционных систем , а частично специализацией устаревших кодировок для различных систем письма человеческих языков. В то время как дистрибутивы Linux в основном перешли на UTF-8 в 2004 году, [2] Microsoft Windows обычно использует UTF-16 и иногда использует 8-битные кодовые страницы для текстовых файлов на разных языках.
Для некоторых систем письма , таких как японская , исторически использовалось несколько кодировок, из-за чего пользователи относительно часто видели моджибаке. Например, само слово моджибаке («文字化け»), хранящееся как EUC-JP, может неправильно отображаться как «ﾊｸｻ�ｽ､ｱ», «ﾊｸｻ嵂ｽ､ｱ» ( MS-932 ) или «ﾊｸｻ郾ｽ». ､ｱ», если интерпретируется как Shift-JIS или как «Ê¸»ú²½¤±» в программном обеспечении, которое предполагает, что текст находится в кодировке Windows-1252 или ISO 8859-1 , обычно обозначаемой как Western или Western European . Это еще больше усугубляется, если задействованы другие локали: тот же текст, сохраненный в кодировке UTF-8, отображается как «譁�蟄怜喧縺�», если интерпретируется как Shift-JIS, как «æ–‡å—化ã '», если интерпретируется как Western или (например) как «鏂囧瓧鍖栥亼», если интерпретировать как нахождение в локали GBK (материковый Китай).
Если кодировка не указана, то программное обеспечение должно решить ее другими способами. В зависимости от типа программного обеспечения типичным решением является либо конфигурация, либо эвристика определения набора символов , оба из которых склонны к неправильному прогнозированию.
Кодировка текстовых файлов зависит от настроек локали , которые зависят от языка пользователя и марки операционной системы , среди прочих условий. Поэтому предполагаемая кодировка систематически неверна для файлов, которые поступают с компьютера с другими настройками или даже из другой локализованной части программного обеспечения в той же системе. Для Unicode одним из решений является использование метки порядка байтов , но многие анализаторы не допускают этого для исходного кода или другого машиночитаемого текста. Другое решение — хранить кодировку как метаданные в файловой системе; файловые системы, поддерживающие расширенные атрибуты файлов , могут хранить ее как user.charset. [3] Это также требует поддержки в программном обеспечении, которое хочет воспользоваться этим, но не мешает другому программному обеспечению.
Хотя некоторые кодировки легко обнаружить, например UTF-8, есть много таких, которые трудно различить (см. определение набора символов ). Например, веб-браузер может не различить страницу в кодировке EUC-JP и страницу в кодировке Shift-JIS, если кодировка не назначена явно с помощью заголовков HTTP, отправляемых вместе с документами, или с помощью метатегов документа , которые используются для замены отсутствующих заголовков HTTP, если сервер не может быть настроен на отправку правильных заголовков HTTP; см. кодировки символов в HTML .
Mojibake также возникает, когда неправильно указана кодировка. Это часто случается между похожими кодировками. Например, почтовый клиент Eudora для Windows был известен тем, что отправлял электронные письма, помеченные как ISO 8859-1 , которые на самом деле были Windows-1252 . [4] Windows-1252 содержит дополнительные печатные символы в диапазоне C1 (чаще всего встречаются изогнутые кавычки и дополнительные тире ), которые не отображались должным образом в программном обеспечении, соответствующем стандарту ISO; это особенно затрагивало программное обеспечение, работающее под управлением других операционных систем, таких как Unix .
Из кодировок, которые все еще широко используются, многие произошли от ASCII и добавления к нему; в результате эти кодировки частично совместимы друг с другом. Примерами этого являются Windows-1252 и ISO 8859-1. Таким образом, люди могут ошибочно принять расширенный набор кодировок, который они используют, за простой ASCII.
Когда есть слои протоколов, каждый из которых пытается указать кодировку на основе разной информации, наименее определенная информация может ввести получателя в заблуждение. Например, рассмотрим веб-сервер, обслуживающий статический файл HTML по HTTP. Набор символов может быть передан клиенту любым из 3 способов:
http-equivили charset) или encodingатрибут XML- декларации. Это кодировка, в которой автор намеревался сохранить конкретный файл.Гораздо более старое оборудование обычно разработано для поддержки только одного набора символов, и этот набор символов обычно не может быть изменен. Таблица символов, содержащаяся в прошивке дисплея, будет локализована для включения символов для страны, в которой будет продаваться устройство, и обычно таблица отличается от страны к стране. Таким образом, эти системы потенциально будут отображать mojibake при загрузке текста, сгенерированного в системе из другой страны. Аналогично, многие ранние операционные системы не поддерживают несколько форматов кодировки и, таким образом, будут отображать mojibake, если будут настроены на отображение нестандартного текста — например, ранние версии Microsoft Windows и Palm OS локализованы для каждой страны и будут поддерживать только стандарты кодировки, соответствующие стране, в которой будет продаваться локализованная версия, и будут отображать mojibake, если будет открыт файл, содержащий текст в формате кодировки, отличном от версии, для поддержки которой предназначена ОС.
Приложения, использующие UTF-8 в качестве кодировки по умолчанию, могут достичь большей степени взаимодействия благодаря ее широкому распространению и обратной совместимости с US-ASCII . UTF-8 также может быть напрямую распознана простым алгоритмом, поэтому хорошо написанное программное обеспечение должно быть способно избежать смешивания UTF-8 с другими кодировками.
Сложность разрешения случая mojibake варьируется в зависимости от приложения, в котором он возникает, и причин его возникновения. Два наиболее распространенных приложения, в которых может возникнуть mojibake, — это веб-браузеры и текстовые процессоры . Современные браузеры и текстовые процессоры часто поддерживают широкий спектр кодировок символов. Браузеры часто позволяют пользователю изменять настройки кодировки своего движка рендеринга на лету, в то время как текстовые процессоры позволяют пользователю выбирать подходящую кодировку при открытии файла. Пользователям может потребоваться некоторое количество проб и ошибок, чтобы найти правильную кодировку.
Проблема усложняется, когда она возникает в приложении, которое обычно не поддерживает широкий диапазон кодировок символов, например, в компьютерной игре, не поддерживающей Unicode. В этом случае пользователь должен изменить настройки кодировки операционной системы, чтобы они соответствовали настройкам игры. Однако изменение настроек кодировки на уровне всей системы также может вызвать Mojibake в уже существующих приложениях. В Windows XP или более поздних версиях пользователь также имеет возможность использовать Microsoft AppLocale , приложение, которое позволяет изменять настройки локали для каждого приложения. Тем не менее, изменение настроек кодировки операционной системы невозможно в более ранних операционных системах, таких как Windows 98 ; чтобы решить эту проблему в более ранних операционных системах, пользователю придется использовать сторонние приложения для рендеринга шрифтов.
Mojibake в английских текстах обычно встречается в знаках препинания, таких как длинное тире (—), короткое тире (–) и фигурные кавычки («,”,','), но редко в тексте символов, поскольку большинство кодировок согласуются с ASCII в кодировке английского алфавита . Например, знак фунта £ будет отображаться так, как £если бы он был закодирован отправителем как UTF-8 , но интерпретирован получателем как одна из западноевропейских кодировок ( CP1252 или ISO 8859-1 ). Если итерировать с использованием CP1252, это может привести к £, £, £, £, и так далее.
Аналогично правая одинарная кавычка (') при кодировании в UTF-8 и декодировании с использованием Windows-1252 превращается в ’, ’, ’, и т. д.
В более ранние эпохи некоторые компьютеры имели кодировки, специфичные для поставщика, что вызывало несоответствие также и для английского текста. 8-битные компьютеры марки Commodore использовали кодировку PETSCII , особенно примечательную инвертированием верхнего и нижнего регистра по сравнению со стандартным ASCII . Принтеры PETSCII прекрасно работали на других компьютерах той эпохи, но инвертировали регистр всех букв. Мейнфреймы IBM использовали кодировку EBCDIC , которая вообще не соответствует ASCII.
Алфавиты северогерманских языков , каталонского , румынского , финского , французского , немецкого , итальянского , португальского и испанского являются расширениями латинского алфавита . Дополнительные символы, как правило, искажаются, делая тексты лишь слегка нечитаемыми с помощью mojibake:
... и их заглавные аналоги, если применимо.
Это языки, для которых использовался набор символов ISO 8859-1 (также известный как Latin 1 или Western ). Однако ISO 8859-1 устарел из-за двух конкурирующих стандартов: обратно совместимого Windows-1252 и слегка измененного ISO 8859-15 . Оба добавляют знак евро € и французский œ, но в остальном любая путаница этих трех наборов символов не создает mojibake в этих языках. Кроме того, всегда можно с уверенностью интерпретировать ISO 8859-1 как Windows-1252, и довольно безопасно интерпретировать его как ISO 8859-15, в частности, в отношении знака евро, который заменяет редко используемый знак валюты (¤). Однако с появлением UTF-8 mojibake стал более распространенным в определенных сценариях, например, при обмене текстовыми файлами между компьютерами UNIX и Windows из-за несовместимости UTF-8 с Latin-1 и Windows-1252. Но UTF-8 может быть напрямую распознан простым алгоритмом, так что хорошо написанное программное обеспечение должно иметь возможность избегать смешивания UTF-8 с другими кодировками, поэтому это было наиболее распространено, когда у многих было программное обеспечение, не поддерживающее UTF-8. Большинство этих языков поддерживались кодировкой MS-DOS по умолчанию CP437 и другими машинными кодировками по умолчанию, за исключением ASCII, поэтому проблемы при покупке версии операционной системы были менее распространены. Однако Windows и MS-DOS несовместимы.
В шведском, норвежском, датском и немецком языках гласные редко повторяются, и обычно очевидно, когда один символ искажается, например, вторая буква в шведском слове kärlek («любовь»), когда оно закодировано в UTF-8, но декодировано в западном коде, что дает «kärlek», или für в немецком, которое становится «für». Таким образом, даже если читателю приходится угадывать исходную букву, почти все тексты остаются разборчивыми. С другой стороны, в финском языке часто используются повторяющиеся гласные в таких словах, как hääyö («брачная ночь»), что может сделать поврежденный текст очень трудным для чтения (например, hääyö отображается как «hääyö»). В исландском языке десять потенциально сбивающих с толку символов, а в фарерском — восемь, что делает многие слова практически совершенно непонятными при искажении (например, исландское þjóðlöð , «исключительное гостеприимство», отображается как «Ã¾jóðlöð»).
В немецком языке для обозначения этого явления используется общее название Buchstabensalat («буквенный салат»), в испанском — deformación (дословно «деформация»), а в португальском — desformatação (дословно «деформирование»).
Некоторые пользователи транслитерируют свои тексты при работе на компьютере, либо опуская проблемные диакритические знаки, либо используя замены диграфов (å → aa, ä/æ → ae, ö/ø → oe, ü → ue и т. д.). Таким образом, автор может написать «ueber» вместо «über», что является стандартной практикой в немецком языке, когда умлауты недоступны. Последняя практика, по-видимому, более приемлема в немецкой языковой сфере, чем в странах Северной Европы . Например, в норвежском языке диграфы связаны с архаичным датским языком и могут использоваться в шутку. Однако диграфы полезны в общении с другими частями мира. Например, у норвежского футболиста Уле Гуннара Сульшера на форме была написана фамилия «SOLSKJAER», когда он играл за «Манчестер Юнайтед» .
Артефакт UTF-8, ошибочно интерпретированный как ISO 8859-1 , « Ring meg nå », отображаемый как «Ring meg nÃ¥», был замечен в 2014 году в мошенничестве с SMS, нацеленном на Норвегию. [5]
Та же проблема возникает и в румынском языке, см. следующие примеры:
Пользователи языков Центральной и Восточной Европы также могут быть затронуты. Поскольку большинство компьютеров не были подключены к какой-либо сети в середине и конце 1980-х годов, для каждого языка с диакритическими знаками существовали разные кодировки символов (см. ISO/IEC 8859 и KOI-8 ), часто также различающиеся в зависимости от операционной системы.
В венгерском языке это явление называется betűszemét , что означает «буквенный мусор». Венгерский язык особенно восприимчив, поскольку содержит диакритические буквы á, é, í, ó, ú, ö, ü (все присутствуют в наборе символов Latin-1), а также два символа ő и ű, которых нет в Latin-1. Эти два символа можно правильно закодировать в Latin-2, Windows-1250 и Unicode. Однако до того, как Unicode стал распространенным в почтовых клиентах, электронные письма, содержащие венгерский текст, часто имели поврежденные буквы ő и ű, иногда до неузнаваемости. На поврежденное электронное письмо принято отвечать бессмысленной фразой «Árvíztűrő tükörfúrógép» (дословно «Защищенный от наводнений сверлильный станок для зеркал»), которая содержит все диакритические символы, используемые в венгерском языке.
До создания ISO 8859-2 в 1987 году пользователи различных вычислительных платформ использовали собственные кодировки символов , такие как AmigaPL на Amiga, Atari Club на Atari ST и Masovia, IBM CP852 , Mazovia и Windows CP1250 на IBM PC. Польские компании, продававшие ранние компьютеры с DOS, создали свои собственные взаимно несовместимые способы кодирования польских символов и просто перепрограммировали EPROM видеокарт (обычно CGA , EGA или Hercules ), чтобы предоставить аппаратные кодовые страницы с необходимыми глифами для польского языка — произвольно расположенными без привязки к тому, где их разместили другие продавцы компьютеров.
Ситуация начала улучшаться, когда под давлением академических и пользовательских групп ISO 8859-2 стал «интернет-стандартом» с ограниченной поддержкой программного обеспечения доминирующих поставщиков (сегодня в значительной степени замененного Unicode). Из-за многочисленных проблем, вызванных разнообразием кодировок, даже сегодня некоторые пользователи склонны называть польские диакритические символы krzaczki ( [ˈkʂät͜ʂ.ki] , дословно «маленькие кустики»).
Mojibake в разговорной речи называют кракозябры ( кракозя́бры [krɐkɐˈzʲæbrɪ̈] ) на русском языке , что было и остаётся сложным из-за нескольких систем кодирования кириллицы . [6] Советский Союз и ранняя Российская Федерация разработали кодировки KOI ( Код Обмена Информацией , что переводится как «Код для обмена информацией»). Это началось с 7-битной кодировки KOI7 только для кириллицы , основанной на ASCII, но с заменой латинских и некоторых других символов на кириллические буквы. Затем появилась 8-битная кодировка KOI8 , которая является расширением ASCII , которая кодирует только кириллические буквы с октетами с высоким набором бит, соответствующими 7-битным кодам из KOI7. Именно по этой причине текст KOI8, даже русский, остается частично читаемым после удаления восьмого бита, что считалось важным преимуществом в эпоху систем электронной почты, не поддерживающих 8BITMIME . Например, слова " Школа русского языка " ( shkola russkogo yazyka ), закодированные в KOI8 и прошедшие через процесс удаления высоких бит, в конечном итоге отображаются как "[KOLA RUSSKOGO qZYKA". В конечном итоге, KOI8 получил различные варианты для русского и болгарского ( KOI8-R ), украинского ( KOI8-U ), белорусского (KOI8-RU) и даже таджикского (KOI8-T) языков.
Между тем, на Западе кодовая страница 866 поддерживала украинский и белорусский языки , а также русский и болгарский в MS-DOS . Для Microsoft Windows кодовая страница 1251 добавила поддержку сербского и других славянских вариантов кириллицы .
Совсем недавно кодировка Unicode включала кодовые точки практически для всех символов всех языков, включая все символы кириллицы.
До появления Unicode необходимо было сопоставлять кодировку текста со шрифтом, использующим ту же систему кодировки; невыполнение этого требования приводило к нечитаемой тарабарщине , чей конкретный вид варьировался в зависимости от точной комбинации текста и кодировки шрифта. Например, попытка просмотреть кириллический текст, не входящий в Unicode, с помощью шрифта, ограниченного латинским алфавитом, или с помощью кодировки по умолчанию («западной»), обычно приводит к тексту, который почти полностью состоит из заглавных гласных с диакритическими знаками (например, KOI8 « Библиотека » ( biblioteka , library) становится «âÉÂÌÉÏÔÅËÁ», а «Школа русского языка» ( shkola russkogo yazyka , Russian-language school) становится «ûËÏÌÁ ÒÕÓÓËÏÇÏ ÑÚÙËÁ»). Использование кодовой страницы 1251 для просмотра текста в кодировке KOI8 или наоборот приводит к искажению текста, состоящего в основном из заглавных букв (KOI8 и кодовая страница 1251 имеют одну и ту же область ASCII, но в кодовой странице KOI8 заглавные буквы находятся в той области, где в кодовой странице 1251 — строчные, и наоборот).
В первые годы существования российского сектора Всемирной паутины были распространены как KOI8, так и кодовая страница 1251. Сейчас почти все веб-сайты используют Unicode, но по состоянию на ноябрь 2023 года, [update]по оценкам, 0,35% всех веб-страниц во всем мире — включая все языки — по-прежнему закодированы в кодовой странице 1251, в то время как менее 0,003% сайтов по-прежнему закодированы в KOI8-R. [7] [8] Хотя стандарт HTML включает возможность указывать кодировку для любой веб-страницы в ее источнике, [9] этим иногда пренебрегают, вынуждая пользователя вручную переключать кодировки в браузере.
На болгарском языке mojibake часто называют majmunica ( маймуница ), что означает «обезьяний [алфавит]». На сербском языке его называют đubre ( ђубре ), что означает « мусор ». В отличие от бывшего СССР, южные славяне никогда не использовали что-то вроде KOI8, а кодовая страница 1251 была доминирующей кириллической кодировкой до Unicode; поэтому эти языки испытывали меньше проблем с несовместимостью кодировок, чем русский. В 1980-х годах болгарские компьютеры использовали свою собственную кодировку MIK , которая внешне похожа на (хотя и несовместима) CP866.
Хорватский , боснийский , сербский (отделившиеся разновидности сербскохорватского языка) и словенский добавляют к основному латинскому алфавиту буквы š, đ, č, ć, ž и их заглавные аналоги Š, Đ, Č, Ć, Ž (только č/Č, š/Š и ž/Ž официально используются в словенском языке, хотя другие используются при необходимости, в основном в иностранных именах). Все эти буквы определены в Latin-2 и Windows-1250 , в то время как только некоторые (š, Š, ž, Ž, Đ) существуют в обычной ОС по умолчанию Windows-1252 и присутствуют там из-за некоторых других языков.
Хотя Mojibake может встречаться с любым из этих символов, буквы, не включенные в Windows-1252, гораздо более подвержены ошибкам. Таким образом, даже в наши дни "šđčćž ŠĐČĆŽ" часто отображается как "šðèæž ŠÐÈÆŽ", хотя ð, È и Æ никогда не используются в славянских языках.
Если ограничиться базовым ASCII (например, большинство имен пользователей), то распространенными заменами являются: š→s, đ→dj, č→c, ć→c, ž→z (заглавные формы аналогично, с Đ→Dj или Đ→DJ в зависимости от регистра слова). Все эти замены вносят двусмысленность, поэтому восстановление оригинала из такой формы обычно выполняется вручную, если это необходимо.
Кодировка Windows -1252 важна, поскольку английские версии операционной системы Windows являются наиболее распространенными, а не локализованными. [ необходима цитата ] Причины этого включают в себя относительно небольшой и фрагментированный рынок, рост стоимости высококачественной локализации, высокий уровень пиратства программного обеспечения (в свою очередь вызванный высокой стоимостью программного обеспечения по сравнению с доходом), что препятствует усилиям по локализации, и люди, предпочитающие английские версии Windows и другого программного обеспечения. [ необходима цитата ]
Стремление отличить хорватский язык от сербского, боснийский от хорватского и сербского, а теперь даже черногорский от трех других создает много проблем. Существует много разных локализаций, использующих разные стандарты и разного качества. Не существует общих переводов для огромного количества компьютерной терминологии, происходящей из английского языка. В конце концов, люди используют английские заимствованные слова («kompjuter» для «компьютер», «kompajlirati» для «компиляция» и т. д.), и если они не привыкли к переведенным терминам, они могут не понять, что должна делать та или иная опция в меню на основе переведенной фразы. Поэтому люди, которые понимают английский язык, а также те, кто привык к английской терминологии (а таких большинство, потому что английская терминология также в основном преподается в школах из-за этих проблем), регулярно выбирают оригинальные английские версии неспециализированного программного обеспечения.
При использовании кириллицы ( македонской и частично сербской ) проблема аналогична проблемам с другими кириллическими письменностями.
Более новые версии английской Windows позволяют изменять кодовую страницу (более старые версии требуют специальных английских версий с этой поддержкой), но эта настройка может быть и часто была установлена неправильно. Например, Windows 98 и Windows Me могут быть установлены на большинство не-справа налево однобайтовых кодовых страниц, включая 1250, но только во время установки.
Системы письма некоторых языков кавказского региона, включая письменности грузинского и армянского языков , могут производить моджибаке. Эта проблема особенно остра в случае ArmSCII или ARMSCII, набора устаревших кодировок символов для армянского алфавита, которые были заменены стандартами Unicode. ArmSCII не получил широкого распространения из-за отсутствия поддержки в компьютерной индустрии. Например, Microsoft Windows не поддерживает его.
Другой тип mojibake возникает, когда текст, закодированный в однобайтовой кодировке, ошибочно анализируется в многобайтовой кодировке, например, в одной из кодировок для восточноазиатских языков . При таком типе mojibake одновременно искажается более одного (обычно двух) символа. Например, если шведское слово kärlek закодировано в Windows-1252, но декодировано с помощью GBK, оно будет отображаться как "k鋜lek", где " är " анализируется как "鋜". По сравнению с приведенным выше mojibake, это сложнее читать, так как отсутствуют буквы, не связанные с проблемными å, ä или ö, и это особенно проблематично для коротких слов, начинающихся с å, ä или ö (например, "än" становится "鋘"). Поскольку объединены две буквы, mojibake также кажется более случайным (более 50 вариантов по сравнению с обычными тремя, не считая более редких заглавных). В некоторых редких случаях целая текстовая строка, включающая в себя шаблон определенной длины слов, например, предложение « Буш скрыл факты », может быть неверно истолкована.
На вьетнамском языке это явление называется chữ ma ( Hán–Nôm : 𡨸魔, «призрачные символы») или loạn mã (от китайского 乱码, luànmǎ ). Это может произойти, когда компьютер пытается декодировать текст, закодированный в UTF-8, как Windows-1258 , TCVN3 или VNI. Во Вьетнаме chữ ma обычно наблюдалось на компьютерах, работающих под управлением версий Windows до Vista, или на дешевых мобильных телефонах.
В Японии mojibake особенно проблематичен, поскольку существует множество различных кодировок японского текста. Наряду с кодировками Unicode (UTF-8 и UTF-16) существуют и другие стандартные кодировки, такие как Shift-JIS (машины Windows) и EUC-JP (системы UNIX). Даже по сей день mojibake часто встречается как японцам, так и неяпонцам при попытке запустить программное обеспечение, написанное для японского рынка.
В китайском языке то же самое явление называется Luàn mǎ ( пиньинь , упрощенный китайский 乱码, традиционный китайский 亂碼, что означает «хаотичный код») и может возникнуть, когда компьютеризированный текст закодирован в одной китайской кодировке символов , но отображается с использованием неправильной кодировки. Когда это происходит, часто можно исправить проблему, переключив кодировку символов без потери данных. Ситуация осложняется существованием нескольких используемых китайских систем кодировки символов, наиболее распространенными из которых являются: Unicode , Big5 и Guobiao (с несколькими обратно совместимыми версиями), а также возможностью кодирования китайских символов с использованием японской кодировки.
Сравнительно легко определить исходную кодировку, когда luànmǎ встречается в кодировках Guobiao:
Дополнительная проблема в китайском языке возникает, когда редкие или устаревшие символы, многие из которых все еще используются в личных именах или географических названиях, отсутствуют в некоторых кодировках. Примеры этого:
Газеты справлялись с отсутствующими персонажами разными способами, в том числе используя программное обеспечение для редактирования изображений, чтобы синтезировать их путем объединения других радикалов и персонажей; используя изображение личности (в случае имен людей) или просто заменяя омофоны в надежде, что читатели смогут сделать правильный вывод.
Похожий эффект может возникнуть в брахмических или индийских письменностях Южной Азии , используемых в таких индоарийских или индийских языках, как хиндустани (хинди-урду), бенгали , пенджаби , маратхи и других, даже если используемый набор символов правильно распознается приложением. Это происходит потому, что во многих индийских письменностях правила, по которым отдельные символы букв объединяются для создания символов для слогов, могут быть неправильно поняты компьютером, на котором отсутствует соответствующее программное обеспечение, даже если глифы для отдельных форм букв доступны.
Одним из примеров этого является старый логотип Wikipedia , который пытается показать символ, аналогичный «wi» (первый слог «Wikipedia») на каждом из многих фрагментов головоломки. Элемент головоломки, который должен был содержать символ деванагари для «wi», вместо этого отображал символ «wa», за которым следовал непарный модификатор гласной «i», легко узнаваемый как mojibake, сгенерированный компьютером, не настроенным на отображение индийского текста. [11] Логотип, переработанный в мае 2010 года, [ref]исправил эти ошибки.
Идея простого текста требует, чтобы операционная система предоставляла шрифт для отображения кодов Unicode. Этот шрифт отличается от ОС к ОС для сингала и делает орфографически неверные глифы для некоторых букв (слогов) во всех операционных системах. Например, «reph», краткая форма для «r», является диакритическим знаком, который обычно ставится поверх простой буквы. Однако неправильно ставить его поверх некоторых букв, таких как «ya» или «la» в определенных контекстах. Для санскритских слов или имен, унаследованных современными языками, таких как कार्य, IAST: kārya или आर्या, IAST: āryā , его склонны ставить поверх этих букв. Напротив, для похожих звуков в современных языках, которые вытекают из их специфических правил, он не ставится сверху, например, слово करणाऱ्या, IAST: karaṇāryā , основа общего слова करणारा/री, IAST: karaṇārā/rī , в языке маратхи . [12] Но это происходит в большинстве операционных систем. Это, по-видимому, ошибка внутреннего программирования шрифтов. В Mac OS и iOS сочетание muurdhaja l (темный l) и 'u', а также его длинная форма дают неправильные формы. [ необходима цитата ]
Некоторые индийские и производные от индийских письменности, в частности лаосская , официально не поддерживались Windows XP до выпуска Vista . [13] Однако различные сайты создали бесплатные для загрузки шрифты.
Из-за западных санкций [14] и позднего появления поддержки бирманского языка в компьютерах [15] [16] большая часть ранней бирманской локализации была доморощенной без международного сотрудничества. Преобладающим средством поддержки бирманского языка является шрифт Zawgyi , шрифт, который был создан как шрифт Unicode, но на самом деле был лишь частично совместим с Unicode. [16] В шрифте Zawgyi некоторые кодовые точки для бирманского письма были реализованы так, как указано в Unicode , но другие — нет. [17] Консорциум Unicode называет это специальными кодировками шрифтов . [18] С появлением мобильных телефонов поставщики мобильных устройств, такие как Samsung и Huawei, просто заменили системные шрифты, совместимые с Unicode, версиями Zawgyi. [15]
Из-за этих специальных кодировок сообщения между пользователями Zawgyi и Unicode будут отображаться как искаженный текст. Чтобы обойти эту проблему, производители контента будут публиковать сообщения как в Zawgyi, так и в Unicode. [19] Правительство Мьянмы назначило 1 октября 2019 года «Днем U» для официального перехода на Unicode. [14] Полный переход, как предполагалось, займет два года. [20]
В некоторых системах письма Африки незакодированный текст нечитаем. Тексты, которые могут производить моджибаке, включают тексты из Африканского Рога, такие как письмо геэз в Эфиопии и Эритрее , используемое для амхарского , тигре и других языков, и сомалийский язык , который использует алфавит османья . В Южной Африке алфавит мвангвего используется для записи языков Малави , а алфавит мандомбе был создан для Демократической Республики Конго , но они, как правило, не поддерживаются. Различные другие системы письма, родом из Западной Африки, представляют схожие проблемы, такие как алфавит нко , используемый для языков мандинго в Гвинее , и слоговое письмо ваи , используемое в Либерии .
Другим затронутым языком является арабский (см. ниже), текст на котором становится совершенно нечитаемым, если кодировки не совпадают.
В примерах в этой статье не используется настройка браузера UTF-8, поскольку UTF-8 легко распознается, поэтому, если браузер поддерживает UTF-8, он должен распознавать его автоматически и не пытаться интерпретировать что-либо другое как UTF-8.
"становится ", "и "так далее.1 октября — «День U», когда Мьянма официально примет новую систему.... Microsoft и Apple помогли другим странам стандартизироваться много лет назад, но западные санкции привели к тому, что Мьянма проиграла.
С выпуском пакета обновления 2 для Windows XP появилась поддержка сложных скриптов, что позволило Windows отображать совместимый с Unicode бирманский шрифт, такой как Myanmar1 (выпущенный в 2005 г.). ... Myazedi, BIT и позже Zawgyi ограничили проблему рендеринга, добавив дополнительные кодовые точки, зарезервированные для этнических языков Мьянмы. Перераспределение не только препятствует будущей поддержке этнических языков, но и приводит к системе набора текста, которая может быть запутанной и неэффективной даже для опытных пользователей. ... Huawei и Samsung, два самых популярных бренда смартфонов в Мьянме, мотивированы только захватом наибольшей доли рынка, что означает, что они поддерживают Zawgyi из коробки.
шрифты Unicode в Мьянме никогда не были общепринятыми, в отличие от частного и частично совместимого с Unicode шрифта Zawgyi. ... Unicode улучшит обработку естественного языка
«UTF-8» технически не применяется к специальным кодировкам шрифтов, таким как Zawgyi.
Это затрудняет общение на цифровых платформах, поскольку контент, написанный в Unicode, кажется пользователям Zawgyi искаженным и наоборот. ... Чтобы лучше охватить свою аудиторию, производители контента в Мьянме часто публикуют как Zawgyi, так и Unicode в одном посте, не говоря уже об английском или других языках.
Словарное определение термина mojibake в Викисловаре
Медиа, связанные с Mojibake на Wikimedia Commons