Почему grep не находит совпадения в SQL-файле и как это исправить

Вы запускаете grep “S” DB_Local_Backup.sql, но результат пуст – хотя явно видите букву “S” при открытии файла. Ситуация кажется парадоксальной, особенно если файл весит несколько гигабайтов. Но причина здесь не в размере данных, а в особенностях кодировки текста. Расскажу, как это исправить, и заодно объясню, почему такие ошибки случаются даже у опытных пользователей.

Почему grep не видит текст: кодировка и «невидимые» символы

Когда файл создаётся в SQL Server Management Studio (SSMS) по умолчанию, он сохраняется в формате UTF-16 Little-endian с меткой BOM (Byte Order Mark). Это двухбайтовая кодировка, где каждый символ представлен двумя байтами. Например, латинская “S” в UTF-16LE будет записана как последовательность 53 00 (в шестнадцатеричном виде), а не как 53 в привычной однобайтовой кодировке ASCII или UTF-8.

Пример содержимого файла в hex-редакторе:

00000000  ff fe 55 00 53 00 45 00  20 00 5b 00 43 00 65 00  |..U.S.E. .[.C.e.|

Здесь:

– ff fe – BOM для UTF-16LE;
– 55 00 – символ “U”;
– 53 00 – символ “S”.

Классический grep ожидает однобайтовые символы и не учитывает специфику UTF-16. Поэтому при поиске “S” (53 в ASCII) он пропускает двухбайтовые последовательности 53 00, воспринимая их как S + нулевой байт.

4 рабочих способа найти текст в UTF-16 файле

Способ 1: Использовать grep с опцией –binary-files=text
Добавьте флаг, который заставляет grep обрабатывать бинарные файлы как текстовые:

grep --binary-files=text "S" DB_Local_Backup_20250311.sql

Если это не сработает, попробуйте явно указать кодировку через iconv:

Способ 2: Конвертировать файл в UTF-8
Утилита iconv преобразует кодировку «на лету»:

iconv -f UTF-16LE -t UTF-8 DB_Local_Backup_20250311.sql | grep "S"

Пояснение параметров:

– -f UTF-16LE – исходная кодировка (Little-endian);
– -t UTF-8 – целевая кодировка.

Способ 3: Поиск через Perl
Perl лучше работает с разными кодировками:

perl -ne 'print if /S/' DB_Local_Backup_20250311.sql

Ключ -n обрабатывает файл построчно, -e выполняет код в кавычках.

Способ 4: Изменить настройки экспорта в SQL Server
Чтобы избежать проблем в будущем, сохраняйте файлы в однобайтовой кодировке:

1. В SSMS перейдите в Tools → Options → Environment → Documents.
2. В разделе “Save documents as” выберите ANSI вместо Unicode.
3. Пересохраните файл.

Детали, которые стоит учесть

Проверка кодировки файла. Перед работой с файлом выполните:

file DB_Local_Backup_20250311.sql

Результат вроде “Little-endian UTF-16 Unicode text” подтвердит проблему.

BOM (Byte Order Mark). Метка FF FE в начале файла помогает программам определить кодировку, но иногда мешает обработке. Если хотите её удалить, используйте:

tail -c +3 DB_Local_Backup.sql > NewFile.sql

Совместимость между Windows и WSL. Файлы, созданные в Windows, часто используют CRLF (перенос строки rn), тогда как в Linux – LF (n). Для grep это не критично, но если планируете редактировать файл в WSL, конвертируйте переносы:

dos2unix DB_Local_Backup.sql

Почему не стоит игнорировать кодировки

Проблема с grep – лишь верхушка айсберга. Скрипты в UTF-16 могут некорректно обрабатываться:

– При импорте в другие СУБД;
– В редакторах без поддержки Unicode;
– При передаче между системами (например, из Windows в Linux через FTP без указания бинарного режима).

Если вы часто работаете с SQL-дампом в WSL, добавьте в свой workflow автоматическую конвертацию. Например, создайте алиас в ~/.bashrc:

alias grepsql='iconv -f UTF-16LE -t UTF-8 DB_Local_Backup.sql | grep '

И напоследок: если ни один метод не сработал, проверьте, нет ли в файле непечатаемых символов или нестандартных разделителей. Команда hd (hexdump) поможет увидеть «сырые» байты:

head -n 1 DB_Local_Backup.sql | hd -C

Теперь вы знаете, как обходить подводные камни с кодировками. Держите эти команды под рукой – они пригодятся не только для SQL-файлов, но и при работе с данными из Excel, 1C и других Windows-ориентированных систем.