Ошибка RE: недопустимая последовательность байтов в Mac OS X

Я пытаюсь заменить строку в Makefile на Mac OS X для кросс-компиляции на iOS. Строка имеет двойные кавычки. Команда:

sed -i "" 's|"iphoneos-cross","llvm-gcc:-O3|"iphoneos-cross","clang:-Os|g' Configure

И ошибка:

sed: RE error: illegal byte sequence

Я пытался избежать двойных кавычек, запятых, тире и двоеточий без радости. Например:

sed -i "" 's|\"iphoneos-cross\"\,\"llvm-gcc\:\-O3|\"iphoneos-cross\"\,\"clang\:\-Os|g' Configure

У меня чертовски много времени на отладку проблемы. Кто-нибудь знает, как заставить sedпечатать позицию недопустимой последовательности байтов? Или кто-нибудь знает, что такое недопустимая последовательность байтов?

^{Пример команды, которая демонстрирует симптом: sed 's/./@/' <<<$'\xfc'терпит неудачу, потому что байт 0xfcне является допустимым символом UTF-8.
Обратите внимание, что, напротив, GNU sed (Linux, но также устанавливается на macOS) просто пропускает недействительный байт, не сообщая об ошибке.}

Использование ранее принятого ответа - вариант, если вы не против потерять поддержку своего истинного языка (если вы работаете в системе США и вам никогда не нужно иметь дело с иностранными символами, это может быть хорошо).

Однако тот же эффект можно получить Ad-Hoc для одной команды только :

LC_ALL=C sed -i "" 's|"iphoneos-cross","llvm-gcc:-O3|"iphoneos-cross","clang:-Os|g' Configure

Примечание: важен эффективный LC_CTYPE параметр C, поэтому LC_CTYPE=C sed ...он также обычно работает, но если LC_ALLон установлен (что-то иное, чем C), он переопределит отдельные LC_*переменные -категории, такие как LC_CTYPE. Таким образом, наиболее надежный подход заключается в установке LC_ALL.

Тем не менее, (фактически) настройки LC_CTYPEдля Cобрабатывают строки , как если бы каждый байт был свой характер ( не интерпретации , основанная на правилах кодирования выполняется), причем без учета для - многобайтового по требованию - UTF-8 , кодирующие , что OS X использует по умолчанию где иностранные символы имеют многобайтовые кодировки .

В двух словах: заходящих LC_CTYPEнаC причины оболочку и утилиты только распознавать основные английские буквы как буквы (те , в 7-битном диапазоне ASCII), так что иностранные гольцы. не будут рассматриваться как буквы , что приведет, например, к неудачному преобразованию в верхний / нижний регистр.

Опять же, это может быть хорошо, если вам не нужно сопоставлять многобайтовые символы, такие как é, и просто хотите пропустить такие символы .

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

Проблема в том, что кодировка входного файла не совпадает с кодировкой оболочки.
В частности, входной файл содержит символы, закодированные таким образом, который недопустим в UTF-8 (как @Klas Lindbäck заявил в комментарии) - вот что sedпытается сказать сообщение об ошибке invalid byte sequence.

Скорее всего, ваш входной файл использует однобайтовую 8-битную кодировку, например ISO-8859-1, часто используемую для кодирования "западноевропейских" языков.

Пример:

Буква с акцентом àимеет код Unicode 0xE0(224) - такой же, как и в ISO-8859-1. Однако из - за характера UTF-8 кодировке, этот единственный элемент кода представлен в виде 2 -х байт - 0xC3 0xA0, в то время как пытается передать один байт 0xE0 является недействительным в соответствии с UTF-8.

Вот демонстрация проблемы с использованием строки, voilàзакодированной как ISO-8859-1, с àпредставленным в виде одного байта (через строку bash в кавычках ANSI-C ( $'...'), которая используется \x{e0}для создания байта):

Обратите внимание, что эта sedкоманда по сути является no-op, которая просто пропускает ввод, но она нам нужна, чтобы вызвать ошибку:

  # -> 'illegal byte sequence': byte 0xE0 is not a valid char.
sed 's/.*/&/' <<<$'voil\x{e0}'

Чтобы просто игнорировать проблему , LCTYPE=Cможно использовать вышеуказанный подход:

  # No error, bytes are passed through ('á' will render as '?', though).
LC_CTYPE=C sed 's/.*/&/' <<<$'voil\x{e0}'

Если вы хотите определить, какие части ввода вызывают проблему , попробуйте следующее:

  # Convert bytes in the 8-bit range (high bit set) to hex. representation.
  # -> 'voil\x{e0}'
iconv -f ASCII --byte-subst='\x{%02x}' <<<$'voil\x{e0}'

Вывод покажет вам все байты с установленным старшим битом (байты, которые превышают 7-битный диапазон ASCII) в шестнадцатеричной форме. (Тем не менее, обратите внимание, что это также включает в себя правильно закодированные многобайтовые последовательности UTF-8 - для более точной идентификации байтов invalid-in-UTF-8 потребуется более сложный подход.)

Выполнение кодирования преобразований по требованию :

Стандартная утилита iconvможет использоваться для преобразования в ( -t) и / или из ( -f) кодировок; iconv -lперечисляет все поддерживаемые.

Примеры:

Преобразование FROM ISO-8859-1в действующую кодировку в оболочке (на основе LC_CTYPE, которая UTF-8по умолчанию -base), основываясь на приведенном выше примере:

  # Converts to UTF-8; output renders correctly as 'voilà'
sed 's/.*/&/' <<<"$(iconv -f ISO-8859-1 <<<$'voil\x{e0}')"

Обратите внимание, что это преобразование позволяет вам правильно сопоставлять иностранные символы :

  # Correctly matches 'à' and replaces it with 'ü': -> 'voilü'
sed 's/à/ü/' <<<"$(iconv -f ISO-8859-1 <<<$'voil\x{e0}')"

Чтобы преобразовать ввод BACK ISO-8859-1после обработки, просто передайте результат в другую iconvкоманду:

sed 's/à/ü/' <<<"$(iconv -f ISO-8859-1 <<<$'voil\x{e0}')" | iconv -t ISO-8859-1

Добавьте следующие строки в ваш ~/.bash_profileили ~/.zshrcфайл (ы).

export LC_CTYPE=C 
export LANG=C

Мой обходной путь использовал Perl:

find . -type f -print0 | xargs -0 perl -pi -e 's/was/now/g'

Ответ mklement0 великолепен, но у меня есть небольшие хитрости.

Кажется хорошей идеей явно указать bashкодировку при использовании iconv. Кроме того, нам следует добавить метку порядка байтов ( даже если стандарт Юникода не рекомендует этого ), потому что между UTF-8 и ASCII могут быть допустимые путаницы без метки порядка байтов . К сожалению, iconvне предшествует метке порядка байтов, когда вы явно указываете порядковый номер ( UTF-16BEили UTF-16LE), поэтому нам нужно использовать UTF-16, который использует платформенно-зависимый порядковый номер, а затем использовать file --mime-encodingдля обнаружения истинного iconvиспользованного порядкового номера .

(Я пишу все мои кодировки в верхнем регистре, потому что, когда вы перечисляете все iconvподдерживаемые кодировки iconv -l, все они в верхнем регистре.)

# Find out MY_FILE's encoding
# We'll convert back to this at the end
FILE_ENCODING="$( file --brief --mime-encoding MY_FILE )"
# Find out bash's encoding, with which we should encode
# MY_FILE so sed doesn't fail with 
# sed: RE error: illegal byte sequence
BASH_ENCODING="$( locale charmap | tr [:lower:] [:upper:] )"
# Convert to UTF-16 (unknown endianness) so iconv ensures
# we have a byte-order mark
iconv -f "$FILE_ENCODING" -t UTF-16 MY_FILE > MY_FILE.utf16_encoding
# Whether we're using UTF-16BE or UTF-16LE
UTF16_ENCODING="$( file --brief --mime-encoding MY_FILE.utf16_encoding )"
# Now we can use MY_FILE.bash_encoding with sed
iconv -f "$UTF16_ENCODING" -t "$BASH_ENCODING" MY_FILE.utf16_encoding > MY_FILE.bash_encoding
# sed!
sed 's/.*/&/' MY_FILE.bash_encoding > MY_FILE_SEDDED.bash_encoding
# now convert MY_FILE_SEDDED.bash_encoding back to its original encoding
iconv -f "$BASH_ENCODING" -t "$FILE_ENCODING" MY_FILE_SEDDED.bash_encoding > MY_FILE_SEDDED
# Now MY_FILE_SEDDED has been processed by sed, and is in the same encoding as MY_FILE

Вы просто должны передать команду iconv перед командой sed . Например, с вводом file.txt:

iconv -f ISO-8859-1 -t UTF8-MAC file.txt | Sed 's / что-то / àéèêçùû / g' | .....

Опция -f - это кодовый набор from, а опция -t - преобразование кодового набора в.

Позаботьтесь о случае, веб - страницы , как правило , показывают , что в нижнем регистре , как <кодировка = ISO-8859-1" /> и Iconv верхнего регистра. У вас есть список Iconv поддерживаемых кодировок в вас система с командой Iconv -l

UTF8-MAC - это современный OS Mac кодовый набор для конвертации.

Кто-нибудь знает, как заставить sed напечатать положение недопустимой последовательности байтов? Или кто-нибудь знает, что такое недопустимая последовательность байтов?

$ uname -a
Darwin Adams-iMac 18.7.0 Darwin Kernel Version 18.7.0: Tue Aug 20 16:57:14 PDT 2019; root:xnu-4903.271.2~2/RELEASE_X86_64 x86_64

Я получил часть способа ответить на вышесказанное, просто используя tr .

У меня есть файл .csv, который является выпиской по кредитной карте, и я пытаюсь импортировать его в Gnucash. Я живу в Швейцарии, поэтому мне приходится иметь дело с такими словами, как Цюрих. Подозреваю, что Gnucash не любит "" в числовых полях, я решил просто заменить все

; ;

с участием

;;

Поехали:

$ head -3 Auswertungen.csv | tail -1 | sed -e 's/; ;/;;/g'
sed: RE error: illegal byte sequence

Я использовал od, чтобы пролить свет: обратите внимание на 374 на полпути вниз по этому выводу od -c

$ head -3 Auswertungen.csv | tail -1 | od -c
0000000    1   6   8   7       9   6   1   9       7   1   2   2   ;   5
0000020    4   6   8       8   7   X   X       X   X   X   X       2   6
0000040    6   0   ;   M   Y       N   A   M   E       I   S   X   ;   1
0000060    4   .   0   2   .   2   0   1   9   ;   9   5   5   2       -
0000100        M   i   t   a   r   b   e   i   t   e   r   r   e   s   t
0000120                Z 374   r   i   c   h                            
0000140    C   H   E   ;   R   e   s   t   a   u   r   a   n   t   s   ,
0000160        B   a   r   s   ;   6   .   2   0   ;   C   H   F   ;    
0000200    ;   C   H   F   ;   6   .   2   0   ;       ;   1   5   .   0
0000220    2   .   2   0   1   9  \n                                    
0000227

Тогда я подумал, что мог бы попытаться убедить tr заменить 374 на любой правильный байт-код. Итак, сначала я попробовал что-то простое, которое не сработало, но побочным эффектом показало, где находится проблемный байт:

$ head -3 Auswertungen.csv | tail -1 | tr . .  ; echo
tr: Illegal byte sequence
1687 9619 7122;5468 87XX XXXX 2660;MY NAME ISX;14.02.2019;9552 - Mitarbeiterrest   Z

Вы можете увидеть Tr поручительств в 374 символа.

Использование Perl, кажется, позволяет избежать этой проблемы.

$ head -3 Auswertungen.csv | tail -1 | perl -pne 's/; ;/;;/g'
1687 9619 7122;5468 87XX XXXX 2660;ADAM NEALIS;14.02.2019;9552 - Mitarbeiterrest   Z?rich       CHE;Restaurants, Bars;6.20;CHF;;CHF;6.20;;15.02.2019

Мой обходной путь использовал гну sed. Работал нормально для моих целей.