Введение в кодировки текста в Windows — искажение кодировки (mojibake), возникающее при интеграции с Linux

Искажение кодировки (mojibake) в Windows возникает не потому, что японский язык сложен. Почти всегда причина в том, что одна и та же последовательность байт была прочитана в другой кодировке, либо результат неверного чтения был сохранён уже в другой кодировке.

Особенно когда работа идёт на стыке Windows и Linux: на стороне Windows сохраняется сразу несколько контекстов — CP932, UTF-8, UTF-16, кодовая страница консоли, различия между версиями PowerShell, — тогда как на стороне Linux по умолчанию почти всегда действует предположение об UTF-8. В результате несовпадения предположений, которые раньше были незаметны, проявляются все разом.

Речь здесь не столько о сложности обработки японского языка, сколько о том, удалось ли согласовать, на каких предположениях обрабатываются байты. В этой статье мы разберём кодировки текста в Windows с точки зрения «почему возникает искажение», сделав акцент на практических моментах, где число инцидентов растёт при интеграции с Linux.

1. Что важно понять в первую очередь

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

• Искажение кодировки — это проблема не «символов», а «того, как была интерпретирована последовательность байт».
• В Windows сосуществуют мир Unicode и мир устаревших кодовых страниц (legacy code page), и даже на одной машине предположения различаются в зависимости от контекста.
• На стороне Linux сильно доминирует предположение об UTF-8, поэтому смешение с CP932 или UTF-16 со стороны Windows легко приводит к инцидентам.
• Следует различать стадию, когда искажено только отображение, и стадию, когда испорченное содержимое уже сохранено.
• Безопаснее выбирать UTF-8 как первый вариант для нового текста и сохранять существующие legacy-файлы как есть до явной задачи миграции.
• Кодировка файла, кодировка редактора, кодовая страница консоли и внутренний формат строк приложения — это разные вещи. Если их перепутать, расследование заходит в тупик.

Одной фразы «на Windows возникло искажение кодировки» недостаточно, чтобы определить причину. Как минимум нужно разделить, что именно из перечисленного ниже разошлось.

• Кодировка самого файла
• Кодировка на момент сохранения
• Интерпретация редактора
• Кодовая страница ввода/вывода консоли
• Внутренний формат строк приложения
• Локаль на стороне Linux и предполагаемая кодировка

2. Что такое искажение кодировки на самом деле

На самом деле суть искажения кодировки довольно проста.

1. Строка кодируется (encode) в какой-то кодировке в последовательность байт
2. Эта последовательность байт декодируется (decode) в какой-то кодировке обратно в строку
3. Если предположения encode и decode не совпадают, результат читается как другая строка

Например, если сохранить あ в UTF-8, получится следующая последовательность байт.

E3 81 82

Если прочитать эту последовательность байт как UTF-8, получится あ, а если в контексте CP932 — она будет выглядеть как какой-то другой набор символов вроде 縺�. Это и есть искажение кодировки.

Важно понимать: здесь произошло не «повреждение японского текста», а лишь расхождение в интерпретации одних и тех же байт.

2.1 Если искажено только отображение, восстановление ещё возможно

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

А вот что действительно опасно — следующая последовательность действий.

1. UTF-8-файл ошибочно читается как CP932
2. На экране это выглядит как 縺�
3. Видимая на экране строка сохраняется как есть
4. Исходные байты UTF-8 теряются

На этом этапе речь уже идёт не о простом искажении отображения, а о повреждении данных.

2.2 Ещё опаснее — сведение «непредставимых символов» к узкой кодовой странице

Ещё один типичный инцидент — преобразование строки Unicode в устаревшую кодовую страницу вроде CP932.

Например, если строка содержит символы, которых нет в целевой кодовой странице, происходит следующее:

• символ заменяется на ?
• появляется символ-заменитель �
• символ преобразуется в похожий, но другой
• преобразование завершается ошибкой

Этот инцидент нужно оценивать не только по признаку «читается / не читается», но и по тому, возвращается ли строка к исходному виду после обратного преобразования (round-trip). Однажды утраченный символ уже не восстановить, даже узнав впоследствии правильную кодировку.

3. Почему в Windows всё так запутано

Windows запутана не просто потому, что она старая. Дело в том, что мир Unicode и мир устаревших кодовых страниц до сих пор сосуществуют.

3.1 В Windows API сосуществуют линии Unicode и кодовых страниц

В Windows API есть две большие линии.

• Семейство W: wide character. Обрабатывает Unicode в виде UTF-16
• Семейство A: линия кодовых страниц, называемая ANSI

То есть в Windows изначально существуют оба пути: «обрабатывать как Unicode» и «обрабатывать через активную на тот момент кодовую страницу». Из-за этого даже на одной и той же Windows-машине предположения меняются в зависимости от того, через какой API или инструмент прошёл текст.

3.2 «Японский текст в Windows» — это не одна сущность

На практике в работе с японским текстом в Windows чаще всего путают следующие четыре варианта.

• CP932: часто встречается в устаревшем японском тексте Windows
• UTF-8: всё чаще встречается в новых текстовых ресурсах, вебе и кросс-платформенных сценариях
• UTF-16LE: до сих пор регулярно встречается в контексте инструментов и API Windows
• Кодовая страница консоли: отдельный слой, влияющий на ввод-вывод cmd.exe и некоторых консольных инструментов

Здесь важно понимать: выполнение chcp 65001 не превращает файлы в UTF-8. Изменение кодовой страницы консоли и то, какие байты содержит уже существующий файл, — разные вопросы.

Кстати, устаревший японский текст Windows часто небрежно называют «Shift_JIS», но на практике лучше держать в уме именно название CP932 — так разговор меньше расходится. Это как минимум явно указывает, что речь идёт о наследуемой японской кодировке, специфичной для Windows.

3.3 Имя файла и содержимое файла — разные вопросы

Когда в Windows японское имя файла отображается нормально, легко подумать: «значит, и с содержимым всё в порядке». Именно здесь кроется опасность.

• слой обработки пути / имени файла
• слой чтения содержимого файла
• слой отображения в консоли

Это три разных слоя.

Например, японский путь может обрабатываться без проблем, но если содержимое файла сохранено в CP932, а на стороне Linux читается как UTF-8, оно будет повреждено. И наоборот: даже если содержимое файла в UTF-8, при несовпадении кодовой страницы консоли будет искажено только отображение.

3.4 Значения по умолчанию в PowerShell и сопутствующих инструментах тоже не согласованы

Незаметный, но частый источник инцидентов в Windows — то, что при, казалось бы, одинаковой «записи текста» выходные байты различаются в зависимости от пути записи.

Особенно стоит обратить внимание на следующее.

• Windows PowerShell 5.1 не имеет согласованной кодировки по умолчанию
• Некоторые cmdlet и перенаправление вывода создают UTF-16LE
• В других путях используется активная кодовая страница ANSI
• Начиная с PowerShell 7 по умолчанию используется UTF-8 без BOM

То есть кодировка не определяется одной лишь фразой «текст, полученный из PowerShell». Нужно смотреть, какая версия, какой cmdlet и какой путь записи использовались.

4. Типичные инциденты при интеграции с Linux

Нередко бывает так, что нечто, кое-как работавшее в пределах одной Windows, ломается сразу, как только в дело вступает Linux. Причина проста: на стороне Linux сильно доминирует предположение об UTF-8.

4.1 Текст, сохранённый в Windows в CP932, Linux читает как UTF-8

Самый частый инцидент.

• устаревшее приложение Windows или старый процесс эксплуатации записывает CSV / TXT / log в CP932
• скрипты и инструменты на стороне Linux читают их с предположением UTF-8 согласно локали
• в результате возникает ошибка decode, � или бессмысленный набор символов

При этом инструмент на стороне Linux ни при чём — коренная причина в том, что у полученных байт не было договорённости о кодировке.

4.2 UTF-8 без BOM, созданный в Linux / VS Code, Windows принимает за ANSI

Бывает и обратная ситуация.

• в Linux или VS Code создаётся скрипт / конфигурация / текст в UTF-8 без BOM
• Windows PowerShell 5.1 или устаревший инструмент принимает файл без BOM за кодовую страницу ANSI
• повреждаются только строки, содержащие японский текст или другие не-ASCII символы

В этом обычно обвиняют UTF-8, но настоящая причина в том, что в цепочке присутствует читающая сторона, которая не может правильно определить UTF-8 без BOM.

4.3 Windows записывает UTF-16LE, а на стороне Linux это «не похоже на текст»

Это тоже случается довольно часто.

• часть вывода Windows PowerShell 5.1 или устаревший инструмент записывают UTF-16LE
• текстовые инструменты на стороне Linux ожидают однобайтовый поток UTF-8
• в результате получается «похожий на бинарный текст» с большим числом NUL-байт

Сам UTF-16LE не плох. Но во многих случаях он плохо сочетается с предположением о прямой передаче в инструменты обработки текста Linux.

4.4 Трение возникает и из-за наличия или отсутствия BOM

BOM — не сама кодировка, но на практике он ощутимо влияет на работу.

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

Особенно в случае UTF-8: даже если формально это один и тот же UTF-8, байты с BOM и без BOM — это разные вещи. Одной фразы «перешли на UTF-8» для правила эксплуатации недостаточно — решена лишь половина вопроса.

4.5 Доверие тому, что показывает консоль, сбивает с толку

При работе на стыке Windows и Linux есть ещё одна опасная точка — консоль.

• у консоли Windows есть кодовые страницы ввода и вывода
• терминал на стороне Linux чаще всего работает с предположением о локали UTF-8
• при прохождении через WSL, SSH, контейнеры и CI число путей отображения растёт

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

4.6 Типичные инциденты в виде таблицы

5. Расследование искажения кодировки ведём по этим четырём вопросам

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

5.1 Что представляют собой исходные байты

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

• Это UTF-8?
• UTF-8 с BOM?
• CP932?
• UTF-16LE?
• Не был ли файл где-то по пути пересохранён и превращён в нечто иное?

5.2 Кто и с каким предположением записал файл первым

Далее нужно определить «первого автора записи».

• Устаревшее приложение Windows?
• PowerShell 5.1 или 7?
• Скрипт Linux?
• VS Code?
• Экспорт из Excel?
• Какое-то промежуточное ПО / batch / CI?

Пока это остаётся неясным, определение кодировки превращается в лотерею.

5.3 Кто и с каким предположением читает файл сейчас

Важен не только автор записи, но и предположение читающей стороны.

• Автоопределяет ли редактор кодировку?
• Смотрит ли PowerShell на BOM?
• Обрабатывает ли сторона Linux файл как UTF-8 согласно локали?
• Использует ли библиотека кодировку по умолчанию?
• Явно ли указаны Encoding.UTF8 или cp932?

Искажение кодировки почти всегда возникает именно здесь.

5.4 Было ли уже сохранено неверно прочитанное содержимое

Наконец, нужно проверить, остановился ли ущерб на стадии отображения.

• Остаются ли байты исходными?
• Не сохранил ли кто-то содержимое, выглядящее искажённым?
• Не попали ли ? или � в diff?
• Не был ли весь текст переписан в другой кодировке?

Если ответить на эти четыре вопроса, причина, как правило, становится видна.

6. Правила эксплуатации, снижающие число инцидентов

Далее — практическая часть. В проектах на стыке Windows и Linux заблаговременное определение следующих правил заметно снижает число инцидентов.

6.1 Для новых файлов UTF-8 — первый выбор

Для новых текстовых файлов разумно в первую очередь выбирать UTF-8. Но останавливаться на этом нельзя — нужно решить и вопрос с BOM.

Рекомендуемый способ решения:

• Текст, который в основном читается на стороне Linux: по умолчанию UTF-8 без BOM
• Скрипты, читаемые устаревшими инструментами Windows или Windows PowerShell 5.1: явно указывать наличие BOM исходя из требований получателя
• Если есть чёткий получатель, которому нужен UTF-16LE, зафиксировать это требование в спецификации

Если написать только «унифицировано на UTF-8», позже возникнут споры из-за BOM.

6.2 Существующие legacy-файлы сохраняем как есть до явной задачи миграции

Если существующий файл в CP932, безопаснее не конвертировать его в UTF-8 заодно с повседневными исправлениями функциональности.

Безопасна следующая схема эксплуатации.

• Существующие файлы сохраняют исходные encoding / BOM / символы перевода строки
• Изменение кодировки выносится в отдельную задачу миграции
• Массовое преобразование выполняется только после проверки объектов конвертации, зоны воздействия и downstream-потребителей

Многие инциденты с искажением кодировки начинаются с благих намерений — «конвертировать в UTF-8 заодно».

6.3 Рассматриваем кодировку как часть интерфейса

Для CSV, TXT, логов, конфигурационных файлов и простых протоколов интерфейсом является не только содержимое, но и сама кодировка.

Например, в спецификации стоит зафиксировать как минимум следующее.

• Какой из вариантов — UTF-8 / CP932 / UTF-16LE — используется в данном файле
• Если UTF-8, содержит ли файл BOM
• LF или CRLF используется для перевода строки
• Кто выступает producer, а кто consumer — Linux или Windows
• Не выполняет ли промежуточный batch или ETL повторное сохранение

Фраза «передаём как текст» спецификацией не является.

6.4 Не доверяем значениям по умолчанию — при записи указываем кодировку явно

И в коде, и в скриптах безопаснее указывать кодировку явно.

Опасны следующие ходы мысли.

• Сохранять со значениями по умолчанию
• Полагать, что «наверное, всё будет нормально», ориентируясь на ОС
• Думать, что раз в консоли читается, значит и с файлом всё в порядке
• Полагаться на то, что есть автоопределение, значит всё будет хорошо

Значения по умолчанию обычно различаются между Windows и Linux, PowerShell 5.1 и 7, редакторами и рантаймами. Если не указывать кодировку явно, легко оказаться в ситуации, когда всё просто случайно работает.

6.5 Проверяем консоль и файл раздельно

Незаметное, но действенное правило.

• Проверка отображения в консоли
• Проверка повторным открытием файла

Эти два действия нужно разделять.

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

6.6 Git не исправляет кодировку

Незаметный, но важный момент.

Git по своей сути лишь отслеживает байты. То есть повреждённые байты он так же добросовестно занесёт в историю как есть.

Поэтому, когда:

• ничего не менялось, но появился гигантский diff
• только строки с японским текстом дают загадочный diff
• изменилась только первая строка
• символ перевода строки и кодировка изменились одновременно

— в таких случаях раньше, чем менять содержимое, стоит заподозрить инцидент с перекодировкой (re-encoding).

7. Минимальный чек-лист

Приводим чек-лист, который стоит зафиксировать в первую очередь в проектах со смешением Windows и Linux.

7.1 Перед редактированием

• Какова текущая кодировка этого файла
• Есть ли BOM
• LF или CRLF используется для перевода строки
• Записаны ли 2–3 характерные строки с японским текстом
• Известно ли, кто выступает конечным consumer — сторона Linux или Windows

7.2 Во время редактирования

• Не выполняется ли запись, зависящая от кодировки по умолчанию
• Не выполняется ли сохранение с расчётом на автоопределение
• Не используются ли пути через PowerShell или перенаправление оболочки небрежно
• Не успокаиваетесь ли вы одним лишь тем, что «отображение читается»

7.3 После редактирования

• Проверено ли повторным открытием после сохранения
• Не искажены ли характерные строки ни на стороне Linux, ни на стороне Windows
• Не увеличилось ли число ? или � в diff
• Не повреждены ли только первая строка или первый столбец
• Не превратился ли diff в большое изменение из-за одного лишь BOM / перевода строки

7.4 Что стоит выполнять как задачу миграции

• Массовое преобразование CP932 → UTF-8
• Унификация политики BOM для UTF-8
• Инвентаризация скриптов, рассчитанных на PowerShell 5.1
• Документирование путей передачи текста через CI / контейнеры / WSL / SSH
• Унификация настроек сохранения в редакторах, форматтерах и batch-скриптах

8. Итог

Если описать проблему кодировок Windows одной фразой, суть в том, что мир Unicode и мир устаревших кодовых страниц до сих пор сосуществуют.

А число инцидентов растёт при интеграции с Linux потому, что сторона Linux почти всегда движется на предположении об UTF-8, и на этом фоне сразу проявляются CP932 и UTF-16 со стороны Windows, кодовая страница консоли и различия между версиями PowerShell.

Стоит запомнить следующие пять пунктов.

• Искажение кодировки — это расхождение в интерпретации байт
• Искажение отображения и повреждение данных — разные вещи
• В Windows нужно раздельно рассматривать слои файла, редактора, консоли и API
• Для текста, которым обмениваются с Linux, UTF-8 — первый выбор
• Преобразование существующих legacy-файлов нужно отделять от обычных доработок

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

• Что представляют собой исходные байты
• Кто и как записал
• Кто и как прочитал
• Было ли уже сохранено

— картина заметно проясняется.

Кодировка текста — тема незаметная, но между Windows и Linux она представляет собой сам I/O-контракт. Не оставлять это без ясности — самая эффективная мера.

9. Источники

Windows / Microsoft

• [Code Pages - Win32 apps

  Microsoft Learn](https://learn.microsoft.com/en-us/windows/win32/intl/code-pages)

• [Code Page Identifiers - Win32 apps

  Microsoft Learn](https://learn.microsoft.com/en-us/windows/win32/intl/code-page-identifiers)

• [Unicode in the Windows API - Win32 apps

  Microsoft Learn](https://learn.microsoft.com/en-us/windows/win32/intl/unicode-in-the-windows-api)

• [Console Code Pages - Windows Console

  Microsoft Learn](https://learn.microsoft.com/en-us/windows/console/console-code-pages)

• [chcp

  Microsoft Learn](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/chcp)

• [Use UTF-8 code pages in Windows apps

  Microsoft Learn](https://learn.microsoft.com/en-us/windows/apps/design/globalizing/use-utf8-code-page)

PowerShell / VS Code

• [about_Character_Encoding

  Microsoft Learn](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_character_encoding)

• [Understanding file encoding in VS Code and PowerShell

  Microsoft Learn](https://learn.microsoft.com/en-us/powershell/scripting/dev-cross-plat/vscode/understanding-file-encoding)

GNU / Linux locale

• GNU gettext manual: Header Entry
• Debian Reference, Chapter 8. I18N and L10N

Похожие статьи

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

Связанные темы

Эти страницы показывают тему статьи в более широком контексте услуг и решений.

Услуги по этой теме

Статья напрямую связана со следующими услугами.

Частые вопросы

Вопросы, которые часто возникают при консультациях по теме статьи.

Что вызывает искажение кодировки (mojibake) в Windows?

Почти всегда причина в том, что одна и та же последовательность байт была прочитана в другой кодировке, либо результат неверного чтения был сохранён уже в третьей кодировке. Например, если байты (E3 81 82), полученные при сохранении символа «あ» в UTF-8, прочитать в контексте CP932, они превратятся в бессмысленный набор символов вроде «縺». Дело не в сложности японского языка — суть в том, что предположения при encode и decode не совпадают.

Можно ли восстановить файл с искажённой кодировкой?

Если исходная последовательность байт не изменилась, файл иногда можно восстановить, открыв его заново в правильной кодировке. Опасность в другом: если сохранить содержимое, которое выглядит искажённым из-за неверного чтения, — на этом этапе проблема перестаёт быть просто визуальным искажением и становится повреждением данных. Кроме того, если строку Unicode привести к узкой кодовой странице вроде CP932 и часть символов заменится на «?» или символ-заменитель, однажды утраченные символы уже не восстановить, даже узнав впоследствии правильную кодировку.

Превращает ли chcp 65001 файлы в UTF-8?

Нет. Изменение кодовой страницы консоли и то, какие байты содержит уже существующий файл, — это разные вопросы. В Windows кодировка самого файла, интерпретация редактора, кодовая страница ввода/вывода консоли и внутренний формат строк в приложении — это разные слои, и их нужно рассматривать по отдельности. Суждение вида «в консоли читается, значит и с файлом всё в порядке» легко ошибочно, поэтому проверку отображения в консоли и проверку повторным открытием файла стоит разделять.

Какие безопасные правила обмена текстом между Windows и Linux?

Для новых файлов в качестве первого варианта выбирать UTF-8 и заранее решить вопрос с BOM. Тексты, которые в основном читаются на стороне Linux, по умолчанию делать в UTF-8 без BOM, а если их читают legacy-инструменты вроде Windows PowerShell 5.1, явно указывать наличие или отсутствие BOM исходя из требований получателя. Существующие файлы в CP932 не стоит конвертировать заодно с повседневными доработками — это нужно выносить в отдельную явную задачу миграции. Кроме того, для CSV и логов сама кодировка является частью интерфейса, поэтому фиксация encoding, BOM и символа перевода строки в спецификации снижает число инцидентов.

Об авторе

Страница с профилем автора статьи.

Го Комура

Представитель KomuraSoft LLC

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