Erreur RE: séquence d'octets illégale sous Mac OS X

J'essaie de remplacer une chaîne dans un Makefile sur Mac OS X pour une compilation croisée vers iOS. La chaîne contient des guillemets doubles. La commande est:

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

Et l'erreur est:

sed: RE error: illegal byte sequence

J'ai essayé d'échapper aux guillemets, virgules, tirets et deux-points sans joie. Par exemple:

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

Je passe beaucoup de temps à déboguer le problème. Quelqu'un sait-il comment sedimprimer la position de la séquence d'octets illégale? Ou est-ce que quelqu'un sait quelle est la séquence d'octets illégale?

^{Un exemple de commande qui présente le symptôme: sed 's/./@/' <<<$'\xfc'échoue, car l'octet 0xfcn'est pas un caractère UTF-8 valide.
Notez que, en revanche, GNU sed (Linux, mais également installable sur macOS) passe simplement l'octet invalide, sans signaler d'erreur.}

L'utilisation de la réponse précédemment acceptée est une option si cela ne vous dérange pas de perdre la prise en charge de votre véritable locale (si vous êtes sur un système américain et que vous n'avez jamais besoin de gérer des caractères étrangers, cela peut être bien.)

Cependant, le même effet peut être obtenu ad hoc pour une seule commande uniquement :

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

Remarque: Ce qui compte, c'est un réglage efficace LC_CTYPE de C, donc LC_CTYPE=C sed ...cela fonctionnerait normalement aussi, mais s'il LC_ALLse trouve être défini (sur autre chose que C), il remplacera les LC_*variables de catégorie individuelles telles que LC_CTYPE. Ainsi, l'approche la plus robuste est de définir LC_ALL.

Cependant, le réglage (effectivement) LC_CTYPEsur Ctraite les chaînes comme si chaque octet était son propre caractère ( aucune interprétation basée sur des règles de codage n'est effectuée), sans égard pour le codage UTF-8 multi-octets à la demande qu'OS X utilise par défaut , où les caractères étrangers ont des encodages multi - octets .

En un mot: le réglage LC_CTYPEsurC fait que le shell et les utilitaires ne reconnaissent que les lettres anglaises de base comme des lettres (celles de la plage ASCII 7 bits), de sorte que les caractères étrangers. ne seront pas traités comme des lettres , ce qui entraînera, par exemple, l'échec des conversions majuscules / minuscules.

Encore une fois, cela peut convenir si vous n'avez pas besoin de faire correspondre des caractères codés sur plusieurs octets tels que é, et que vous souhaitez simplement passer ces caractères .

Si cela est insuffisant et / ou si vous souhaitez comprendre la cause de l'erreur d'origine (y compris déterminer quels octets d'entrée ont causé le problème) et effectuer des conversions de codage à la demande, lisez la suite ci-dessous.

Le problème est que le codage du fichier d'entrée ne correspond pas à celui du shell.
Plus précisément, le fichier d'entrée contient des caractères encodés d'une manière qui n'est pas valide en UTF-8 (comme @Klas Lindbäck l'a déclaré dans un commentaire) - c'est ce que le sedmessage d'erreur essaie de dire invalid byte sequence.

Très probablement, votre fichier d'entrée utilise un codage 8 bits à un octet tel que ISO-8859-1, fréquemment utilisé pour coder les langues «d'Europe occidentale».

Exemple:

La lettre accentuée àa un point de code Unicode 0xE0(224) - le même que dans ISO-8859-1. Cependant, en raison de la nature du codage UTF-8 , ce point de code unique est représenté par 2 octets - 0xC3 0xA0, alors que tenter de passer l' octet unique 0xE0 est invalide sous UTF-8.

Voici une démonstration du problème en utilisant la chaîne voilàcodée comme ISO-8859-1, avec le àreprésenté comme un octet (via une chaîne bash entre guillemets ANSI-C ( $'...') qui utilise \x{e0}pour créer l'octet):

Notez que la sedcommande est effectivement un no-op qui passe simplement l'entrée, mais nous en avons besoin pour provoquer l'erreur:

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

Pour ignorer simplement le problème , l' LCTYPE=Capproche ci-dessus peut être utilisée:

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

Si vous souhaitez déterminer quelles parties de l'entrée sont à l'origine du problème , essayez ce qui suit:

  # 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}'

La sortie vous montrera tous les octets qui ont le bit haut défini (octets qui dépassent la plage ASCII 7 bits) sous forme hexadécimale. (Notez, cependant, que cela inclut également les séquences multioctets UTF-8 correctement codées - une approche plus sophistiquée serait nécessaire pour identifier spécifiquement les octets non valides en UTF-8.)

Effectuer des conversions d'encodage à la demande :

L'utilitaire standard iconvpeut être utilisé pour convertir des encodages en ( -t) et / ou à partir de ( -f); iconv -lrépertorie tous ceux pris en charge.

Exemples:

Convertissez FROM ISO-8859-1en encodage en vigueur dans le shell (basé sur LC_CTYPE, qui est UTF-8basé par défaut), en vous basant sur l'exemple ci-dessus:

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

Notez que cette conversion vous permet de faire correspondre correctement les caractères étrangers :

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

Pour convertir l'entrée BACK en ISO-8859-1après traitement, dirigez simplement le résultat vers une autre iconvcommande:

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

Ajoutez les lignes suivantes à vos fichiers ~/.bash_profileou ~/.zshrc.

export LC_CTYPE=C 
export LANG=C

Ma solution de contournement utilisait Perl:

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

La réponse de mklement0 est excellente, mais j'ai quelques petits ajustements.

Il semble judicieux de spécifier explicitement bashle codage de lors de l 'utilisation iconv. De plus, nous devrions ajouter une marque d'ordre d'octet ( même si le standard Unicode ne le recommande pas ) car il peut y avoir des confusions légitimes entre UTF-8 et ASCII sans marque d'ordre d'octet . Malheureusement, iconvne ajoute pas de marque d'ordre d'octet lorsque vous spécifiez explicitement une endianness ( UTF-16BEou UTF-16LE), nous devons donc utiliser UTF-16, qui utilise l'endianness spécifique à la plate-forme, puis l'utiliser file --mime-encodingpour découvrir la vraie endianness iconvutilisée.

(Je mets tous mes encodages en majuscules car lorsque vous listez tous iconvles encodages pris en charge par, iconv -lils sont tous en majuscules.)

# 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

Vous devez simplement diriger une commande iconv avant la commande sed . Ex avec entrée file.txt:

iconv -f ISO-8859-1 -t UTF8-MAC fichier.txt | sed 's / quelque chose / àéèêçùû / g' | .....

L' option -f est le jeu de codes 'from' et l'option -t est la conversion du jeu de codes 'vers'.

Faites attention à la casse, les pages Web affichent généralement des minuscules comme ça <charset = iso-8859-1 "/> et iconv utilise des majuscules. Vous avez une liste des jeux de codes pris en charge par iconv dans votre système avec la commande iconv -l

UTF8-MAC est un jeu de codes OS Mac moderne pour la conversion.

Est-ce que quelqu'un sait comment obtenir sed pour afficher la position de la séquence d'octets illégale? Ou est-ce que quelqu'un sait quelle est la séquence d'octets illégale?

$ 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

J'ai fait une partie du chemin pour répondre à ce qui précède simplement en utilisant tr .

J'ai un fichier .csv qui est un relevé de carte de crédit et j'essaye de l'importer dans Gnucash. Je suis basé en Suisse et je dois donc composer avec des mots comme Zürich. Suspectant que Gnucash n'aime pas "" dans les champs numériques, je décide de tout simplement remplacer

; ;

avec

;;

Voici:

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

J'ai utilisé od pour faire la lumière: notez le 374 à mi-chemin de cette sortie 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

Ensuite, j'ai pensé que je pourrais essayer de persuader tr de remplacer 374 par quel que soit le code d'octet correct. Alors j'ai d'abord essayé quelque chose de simple, qui n'a pas fonctionné, mais qui a eu pour effet secondaire de me montrer où se trouvait l'octet gênant:

$ 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

Vous pouvez voir tr bails au caractère 374.

L'utilisation de perl semble éviter ce problème

$ 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

Ma solution de contournement utilisait gnu sed. A bien fonctionné pour mes besoins.