RE erreur: illégal séquence d'octets sur Mac OS X

<sup>Un exemple de commande qui présente le symptôme: sed 's/./@/' <<<$'\xfc' échoue, car octet 0xfc n'est pas UTF-8 valide char.

Notez que, par contraste, GNU sed (Linux, mais aussi installable sur macOS) passe tout simplement l'octet non valide à travers, sans rapport d'erreur.</sup>

À l'aide de la auparavant accepté de répondre à est une option si vous ne me dérange pas de perdre le support pour vos paramètres régionaux (si vous êtes sur un système AMÉRICAIN et vous n'avez jamais besoin de traiter avec des caractères étrangers, qui peuvent être à l'aise.)

Cependant, la même effet peut être dû ad-hoc pour un de commande unique seulement:

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

Remarque: Ce qui compte c'est un efficace LC_CTYPE réglage de C, donc LC_CTYPE=C sed ... serait normalement aussi travailler, mais si LC_ALL arrive à régler (pour autre chose que C), il remplace individu LC_*-catégorie de variables telles que LC_CTYPE. Ainsi, l'approche la plus efficace est de mettre en LC_ALL.

Cependant, (efficacement) réglage LC_CTYPE à C traite les chaînes comme si chaque octet étaient son propre caractère (pas interprétation basée sur des règles de codage est effectué), avec aucun égard pour le multi-octets sur demande - l'encodage UTF-8 que OS X utilise par défaut, où caractères étrangers ont encodages multi-octets.

En un mot: réglage LC_CTYPE à C causes de la coquille et des utilitaires pour seulement reconnaître un anglais de base, lettres que lettres (celles de l'ASCII 7 bits de gamme), de sorte que étrangères caractères. ne seront pas traités comme des lettres, provoquant, par exemple, dans le haut-/minuscules conversions à l'échec.

Encore une fois, cela peut être bien si vous n'avez pas besoin de match multi-octets caractères codés comme é, et veulent simplement passer ces personnages à travers.

Si cela est insuffisant et/ou vous souhaitez comprendre la cause de l'erreur d'origine (y compris la détermination de ce que les octets d'entrée est la cause du problème) et effectuer les conversions d'encodage sur demande, lire sur ci-dessous.

---

Le problème est que l'entrée de codage du fichier ne correspond pas à l'environnement.

Plus précisément, le fichier d'entrée contient des caractères codés d'une manière qui n'est pas valide en UTF-8 (comme @Klas Lindbäck a déclaré dans un commentaire) - qu'est ce que le sed message d'erreur est en train de dire par invalid byte sequence.

Le plus souvent, votre fichier d'entrée utilise un un octet de 8 bits de codage comme ISO-8859-1, fréquemment utilisé pour encoder "europe Occidentale" langues.

Exemple:

La lettre accentuée à a Unicode codepoint 0xE0 (224) - le même que dans ISO-8859-1. Toutefois, en raison de la nature de UTF-8 encodage, ce codepoint est représenté comme 2 octets - 0xC3 0xA0, tandis que d'essayer de passer le seul octet 0xE0 est invalide en vertu de l'UTF-8.

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

Noter que le sed commande est effectivement un no-op qui passe tout 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}'

Simplement ignorer le problème, le ci-dessus LCTYPE=C approche peut être utilisée:

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

Si vous voulez déterminer quelles parties de l'entrée de la cause de ce problème, essayez les solutions suivantes:

  # 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 la haute ensemble de bits (octets qui dépassent les 7 bits ASCII) dans le format hexadécimal. (Notez, cependant, que, qui comprend également correctement encodé en UTF-8 multi-octets séquences - une approche plus fine serait nécessaire afin de déterminer précisément l'invalide-en-octets UTF-8.)

---

D'effectuer les conversions d'encodage sur demande:

Utilitaire Standard iconv peut être utilisé pour convertir (-t) et/ou (-f) codages; iconv -l listes de toutes les prises en charge.

Exemples:

Convertir ISO-8859-1 pour l'encodage en effet dans le shell (basé sur LC_CTYPE, qui est UTF-8base par défaut), en s'appuyant sur l'exemple ci-dessus:

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

Noter que cette de conversion vous permet de bien correspondre 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 ARRIÈRE pour ISO-8859-1 après le traitement, il vous suffit de canaliser le résultat à une autre iconv commande:

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

mklement0 réponse est grande, mais j'ai quelques petites modifications.

Il semble être une bonne idée de spécifier explicitement bash's l'encodage lors de l'utilisation de iconv. Aussi, il convient d'ajouter une marque d'ordre d'octet (même si le standard unicode ne le recommande pas) parce que il peut être légitime de confusions entre UTF-8 et ASCII sans une marque d'ordre d'octet. Malheureusement, iconv ne pas ajouter une marque d'ordre d'octet lorsque vous spécifiez explicitement une endianness (UTF-16BE ou UTF-16LE), nous avons donc besoin d'utiliser UTF-16, qui utilise une plate-forme spécifique endianness, et ensuite utiliser file --mime-encoding de découvrir le vrai endianness iconv utilisé.

(I majuscule tous mes encodages parce que quand vous la liste de tous iconv's codage pris en charge avec iconv -l ils 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 avez simplement à pipe d'une iconv commande avant le sed de commande.
Ex avec file.txt entrée :

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

-f option est le 'de' jeu de caractères et l'option-t est le " à " jeu de caractères de conversion.

Prendre soin de cas, des pages web présentent généralement minuscules comme ça < charset=iso-8859-1"/>
et iconv utilise des majuscules.
Vous avez la liste de iconv pris en charge codesets dans votre système avec la commande iconv -l

UTF8-MAC est moderne OS Mac jeu de caractères pour la conversion.