À l'aide de la 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, le même effet peut être dû 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 effectif LC_CTYPE
réglage d' C
, alors LC_CTYPE=C sed ...
serait normalement aussi, mais si l' LC_ALL
de passe (pour autre chose que de l' C
), il remplace individuels LC_*
-catégorie de variables telles que l' LC_CTYPE
. Ainsi, l'approche la plus efficace est de mettre en LC_ALL
.
Cependant, (efficacement) paramètre LC_CTYPE
de C
traite des chaînes comme si chaque octet étaient son caractère propre (aucune 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 qui OS X utilise par défaut, où les caractères étrangers ont encodages multi-octets.
En un mot: paramètre LC_CTYPE
de 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 sorte que les étrangers 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 correspondre à multi-octets caractères codés comme é
, et veulent simplement passer de tels personnages.
Si cela est insuffisant et/ou vous voulez 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 d'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 à la coque.
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) - c'est ce que l' sed
message d'erreur est en train de dire par invalid byte sequence
.
Très probablement, votre fichier d'entrée utilise un octet de 8 bits de codage tels que 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 l'UTF-8 codage, ce codepoint est représenté que 2 octets - 0xC3 0xA0
, alors que tente de faire passer pour le seul octet 0xE0
est invalide en vertu de l'UTF-8.
Voici une démonstration du problème à l'aide de la chaîne de caractères voilà
encodé ISO-8859-1
, avec l' à
représenté comme un octet (via ANSI-C-cité bash de chaîne ($'...'
) qui utilise \x{e0}
pour créer de l'octet):
Notez que l' 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, au-dessus de la 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 à l'origine du 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 va vous montrer 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.)
Effectuer les conversions d'encodage sur demande:
Utilitaire Standard iconv
peut être utilisé pour convertir (-t
) et/ou de (-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
, ce qui est UTF-8
-fondé 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}')"
Notez que cette 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 de RETOUR d' 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