TR жалуется на “Недопустимую последовательность байта”

Я полагаю, что ваша кодировка с локалей UTF-8, так что у вас будут проблемы с бинарными файлами. Просто переключитесь на C-локаль:

LC_ALL=C tr '\r' '\n' < target-file | LC_ALL=C grep search-string

grep является инструментом обработки текста. Он ожидает, что они будут представлены в виде текстовых файлов . Похоже, то же самое происходит и с tr на макросах (хотя предполагается, что tr поддерживает двоичные файлы).

Компьютеры хранят данные в виде последовательностей байт. Текст представляет собой последовательность символов. Существует несколько способов кодирования символов в виде байтов, называемых кодировками символов . Де-факто стандартной кодировкой символов в большинстве стран мира, особенно на OSX, является UTF-8, которая является кодировкой для набора символов Unicode. Возможен только 256 байт, но более миллиона символов Юникода, поэтому большинство символов кодируется как несколько байт. UTF-8 - это кодировка переменной длины: в зависимости от символа для кодирования может потребоваться от одного до четырех байт. Некоторые последовательности байтов не представляют символов в кодировке UTF-8. Поэтому существуют последовательности байтов, которые не являются действительными текстовыми файлами в кодировке UTF-8.

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

Документ Microsoft Word не является текстовым файлом: это документ обработки текстов. Форматы текстовых документов кодируют не только текст, но и форматирование, встроенные изображения и т. д. Формат Word, как и большинство форматов текстовых документов, не является текстовым файлом.

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

export LC_CTYPE=C
tr '\r' '\n' < target-file | grep search-string

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

Кстати, tr '\r' '\n' не очень полезная команда, если только у вас не осталось текстовых файлов с Mac OS 9 или старше. \r (возврат каретки) был новым разделителем строк в Mac OS до Mac OS X. Начиная с OSX, новым разделителем строк является \n (поток строк, стандарт unix), а текстовые файлы не содержат возврата каретки. Windows использует двухсимвольную последовательность CR-LF для представления разделения строк; tr -d '\r' преобразовывает текстовый файл Windows в текстовый файл Unix/Linux/OSX.

Как же искать в документе Word из командной строки? Документ Word на самом деле является .docx zip архивом zip архивом , содержащим несколько файлов, основные из которых находятся в XML.

unzip -l Position-Paper-Final-Version.docx

Mac OS X включает в себя утилиту zipgrep для поиска внутри zip-файлов.

zipgrep DeCSS Position-Paper-Final-Version.docx

Результат будет не очень читабельным, так как XML файлы в формате docx в основном состоят из одной огромной строки. Если вы хотите искать внутри основного текста документа, извлеките файл word/document.xml из архива. Обратите внимание, что помимо текста документа, этот файл содержит XML-разметку, которая представляет собой структуру документа. Вы можете немного помассировать XML разметку с помощью sed , чтобы разделить ее на управляемые строки.

unzip -p Position-Paper-Final-Version.docx word/document.xml |
sed -e 's/></>\n</g' |
grep DeCSS