Перенесли данные через архив и потеряли кириллицу в именах файлов

MAATRIX

Перенесли архив с проектом или бэкапом на новый сервер, распаковали — и вместо «Договор_Иванов.docx» на экране каша из символов вроде «Ð”Ð¾Ð³Ð¾Ð²Ð¾Ñ€_Иванов». Содержимое файлов не пострадало, но по именам работать нельзя: скрипты, которые ищут файлы по маске, падают, ссылки из базы на путь ломаются, человек не может найти нужный документ глазами. Разберём, почему это происходит именно с кириллицей и любыми другими не-ASCII символами, и как упаковывать и распаковывать архивы так, чтобы имена доезжали целыми.

Почему кириллица превращается в кракозябры

Имя файла на диске — это не текст в привычном смысле, а последовательность байт. Чтобы превратить её в буквы на экране, нужна кодировка — таблица соответствия между байтами и символами. Для латиницы и цифр (ASCII) эта таблица одна и та же практически везде уже несколько десятилетий, поэтому с английскими именами файлов проблем такого рода почти не бывает. А вот кириллицу разные системы исторически кодировали по-разному: cp866 в консоли старых Windows и DOS, cp1251 в графическом Windows, koi8-r в старых unix-системах, UTF-8 — универсальный стандарт, к которому в итоге пришли почти все современные системы.

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

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

ZIP: где именно живёт причина

Формат zip — самый частый источник этой проблемы, и у него длинная история. Изначально спецификация zip вообще не предполагала ничего, кроме DOS-совместимой кодовой страницы (обычно cp437 или, для кириллических систем, cp866) — о UTF-8 в момент создания формата речи не шло. Архиваторы под Windows десятилетиями паковали имена в cp866 (консольные утилиты) или cp1251 (графические программы вроде WinRAR старых версий), и никакой информации о том, какая именно кодировка использована, в архив не попадало — читающая программа должна была угадывать или использовать свою кодировку по умолчанию.

Позже в спецификацию zip добавили explicit-флаг: 11-й бит поля general purpose flag, который означает, что имя файла и комментарий закодированы в UTF-8 (в документации формата он называется language encoding flag, EFS). Это решает проблему в теории — если флаг выставлен, читающая программа точно знает, что перед ней UTF-8. На практике флаг помогает только когда обе стороны его поддерживают: архив создан новым архиватором, который сознательно ставит этот бит, и распаковывается программой, которая его читает. Старые архивы этого флага не имеют вообще, а часть инструментов до сих пор его игнорирует. Отсюда типичная ситуация: архив, упакованный когда-то на Windows-машине с русской консольной кодировкой, спокойно живёт годами, а при переносе на Linux-сервер вдруг «ломается» — хотя в самом архиве ничего не менялось. Похожая логика встречается и при более широкой миграции с Windows Server на Linux: часть проблем там не про совместимость софта, а про то, что данные изначально жили в другой системе кодировок.

TAR и TAR.GZ: та же болезнь, другая механика

С tar ситуация ещё проще и одновременно суровее: классический формат tar вообще не хранит никакой информации о кодировке имени файла. Он просто записывает имя как последовательность байт фиксированной длины в заголовке записи — без пометки, что это за кодировка. Программа, которая создаёт tar, кодирует имя в той кодировке, что действует в системе на момент запуска (обычно это определяется локалью — переменной окружения LANG или LC_ALL), и точно так же программа, которая читает tar, интерпретирует байты имени в своей текущей локали. Если локали источника и приёмника не совпадают — снова кракозябры, причём даже без какого-либо флага, который в принципе мог бы это предотвратить: механизма для явного указания кодировки в базовом формате tar просто нет.

Частичное решение появилось с расширением POSIX pax: pax-формат умеет хранить дополнительные заголовки записей произвольной длины, в том числе явно записывать имя файла в UTF-8 как расширенный атрибут независимо от ограничений базового формата. GNU tar и bsdtar (libarchive) при определённых условиях используют pax-заголовки автоматически. Но и это не панацея: то, что окажется в pax-заголовке как «UTF-8 имя», всё равно зависит от того, что упаковщик посчитал правильной интерпретацией байт в момент упаковки. Если система с самого начала работала в неправильной локали, в архив попадёт неправильно интерпретированное имя, просто уже помеченное как UTF-8 — проблема на входе не решается автоматически, решается только надёжность передачи уже распознанного.

Сравнение: как разные форматы обращаются с именами

Из таблицы виден практический вывод: если вы выбираете формат архива под задачу переноса данных с не-ASCII именами файлов между разными системами, форматы со встроенной поддержкой Unicode в самом контейнере (7z, современный rar) избавляют от проблемы на уровне архитектуры формата, а не полагаются на совпадение настроек локали на обеих сторонах.

Инструменты и явная работа с кодировкой

Практический подход к упаковке — выбирать инструменты, у которых поддержка Unicode в именах файлов не опциональная надстройка, а часть формата или явно управляемая настройка:

• 7-Zip / p7zip — формат 7z хранит имена в Unicode внутри контейнера, поэтому при упаковке и распаковке на разных ОС с разными локалями (Windows и Linux, например) кириллица обычно не ломается — кодировка не берётся «из воздуха» системной локали, а записана в самом архиве.
• Info-ZIP (unzip/zip) современных версий по умолчанию при создании zip в UTF-8-окружении старается выставлять EFS-флаг и умеет его читать при распаковке. Для чтения legacy-архивов, где флага нет и имена записаны в старой DOS/Windows-кодировке, у unzip есть возможность явно задать кодировку исходных имён при извлечении вместо использования локали приёмника — синтаксис опции отличался между релизами, сверьтесь с man unzip вашей версии.
• bsdtar (libarchive) на Linux в UTF-8-локали в целом ведёт себя предсказуемее классического GNU tar при работе с pax-заголовками, но итоговый результат всё равно зависит от локали, в которой архив был создан.
• Перед упаковкой архива для передачи между системами проверьте локаль текущей системы командой locale (или echo $LANG) — если она не UTF-8, велик шанс, что архиватор запишет имена не в той кодировке, которую ожидает получатель.

Общее практическое правило: если данные с кириллическими (или любыми не-ASCII) именами файлов переносятся между системами, у которых вы не уверены на 100% в одинаковой локали — предпочтительнее формат с встроенной поддержкой Unicode в именах (7z, современный rar), а не классический zip или голый tar без pax.

Если имена уже испорчены — что делать без пересборки архива

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

Практический инструмент для этого — convmv, который умеет массово перекодировать имена файлов из одной кодировки в другую:

# сначала — «сухой прогон» без флага --notest,
# покажет, что получится, но ничего не изменит
convmv -f cp1251 -t utf8 -r ./povrezhdennaya_papka

# если результат выглядит правильно — применяем реально
convmv -f cp1251 -t utf8 -r --notest ./povrezhdennaya_papka

Ключевой момент — не угадывать исходную кодировку с первой попытки вслепую, а проверять результат dry-run перед --notest: если после перекодирования кракозябры не исчезли, а превратились в другую кашу, значит исходная кодировка указана неверно, и стоит попробовать следующего кандидата (обычно перебирают cp866, cp1251, koi8-r — в зависимости от системы и инструмента, которым архив создавался изначально). Запускать convmv дважды подряд с --notest на одних и тех же файлах, ориентируясь на предположения, а не на проверенный dry-run — верный способ окончательно запутать имена.

Если оригинальные имена файлов зафиксированы где-то ещё — в списке файлов из системы-источника, в базе данных, которая на них ссылается, в сопроводительной описи — надёжнее сверяться с этим источником истины, а не восстанавливать имена по догадке о кодировке: перекодирование даёт правильный результат, только если исходная кодировка угадана верно, а на глаз это не всегда очевидно, особенно для коротких имён.

Проверяйте имена сразу после распаковки, а не постфактум

Главная практическая ошибка — считать распаковку завершённой, если архиватор не выдал ошибок. Отсутствие ошибки распаковки ничего не говорит о корректности кодировки имён: архиватор молча запишет файл под кракозябренным именем и завершится с нулевым кодом возврата, потому что с его точки зрения всё прошло штатно — он записал те байты, которые у него были.

Практический чек-лист сразу после распаковки, до того как данные попадут в продакшн-процесс или скрипт автоматизации:

• Откройте распакованную директорию и визуально пробегитесь по списку файлов — кракозябры видно сразу, специальных инструментов для первой проверки не требуется.
• Проверьте локаль терминала, из которого смотрите на список: locale должна показывать UTF-8, иначе даже корректно записанные UTF-8-имена будут отображаться неправильно, и вы ошибочно решите, что проблема в архиве, хотя она в отображении.
• Для автоматизированной проверки на сервере (скрипт деплоя, распаковывающий архивы из внешнего источника) добавьте шаг валидации: пройтись по именам файлов и убедиться, что каждое декодируется как UTF-8 без ошибок — большинство языков дают такую проверку одной строкой.
• Если распаковка — часть пайплайна без участия человека, не давайте процессу молча продолжать с испорченными именами: остановите пайплайн с понятной ошибкой, чем потом выяснять, почему часть файлов «пропала» — на деле она просто лежит под нечитаемым именем.
• Сверяйте не только то, что все файлы физически распаковались (количество и размер совпадают), но и что сама миграция или перенос прошли успешно по содержательному критерию — открываемости и читаемости имён, а не только по коду возврата команды.

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

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