tr жалуется на «недопустимую последовательность байтов»

Я новичок в UNIX и использую «Командную строку Mac OS X» Кирка МакЭлхарна, чтобы научить себя некоторым командам.

Я пытаюсь использовать trи grepтак, чтобы я мог искать текстовые строки в обычном документе MS-Office Word.

$ tr '\r' '\n' < target-file | grep search-string

Но все, что он возвращает, это:

Illegal byte sequence.

robomechanoid:Position-Paper-Final-Draft robertjralph$ tr '\r' '\n' < Position-Paper-Final-Version.docx | grep DeCSS
tr: Illegal byte sequence
robomechanoid:Position-Paper-Final-Draft robertjralph$ 

Я фактически запустил ту же строку в сценарии, в котором я создал, viи он выполняет поиск правильно.

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

Компьютеры хранят данные в виде последовательности байтов . Текст - это последовательность символов. Существует несколько способов кодирования символов в виде байтов, называемых кодировками символов . Стандартной кодировкой символов де-факто в большинстве стран мира, особенно в OSX, является UTF-8 , которая является кодировкой для набора символов Unicode . Есть только 256 возможных байтов, но более миллиона возможных символов Unicode, поэтому большинство символов кодируются как несколько байтов. 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

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

Кстати, 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 из командной строки? Документ .docxWord на самом деле представляет собой 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

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

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