J'ai un fichier texte avec deux octets non-ASCII (0xFF et 0XFE):
$ perl -pe 's/^\xFF\xFE//' test.csv 58832520.3,ABC 348384,DEF
7 Réponses :
Vous pouvez obtenir les codes hexagonaux avec \ xff \ xfe et le remplacer par rien. p>
LANG='' sed 's/[^ -~]//g' myfile
Merci - mais cela ne semble pas fonctionner pour moi. Lorsque j'exécute cela sur le fichier de test, le seul changement est un retour de chariot (x0a) ajouté à la fin du fichier.
Le dernier commentaire était en ce qui concerne la première approche. La seconde élimine le premier caractère légitime (5) mais laisse les octets FF et Fe. Cela n'a pas de sens pour moi pourquoi ...
Oh. Émettez-vous le résultat de SED à un nouveau fichier, c'est-à-dire s / [^ - ~ ~] // g 'test.csv> test1.csv code> sed elle-même ne change pas le fichier, il génère une version modifiée sur stdout.
Oui, je le fais juste en ligne à des fins d'affichage ici.
@Greg quelle version d'OSX?, Et avez-vous remplacé le SED original?
Ceci est v10.6.4 et est l'original Sed Afaik
Consultez ma mise à jour, le problème est que Lang = EN_US.UTF-8 (supposant peut-être à tort que vous êtes un USIAN). Je ne sais pas pourquoi ça vis de choses.
Je vais poser une question de savoir pourquoi elle se blesse.
@Deinst, il visse (au moins comme je le comprends) car le FF Fe n'est pas traité comme faisant partie du contenu du fichier, mais comme formatant des métadonnées - et donc les règles d'édition ne l'appliquent pas. De même, si vous avez fait SED 'S /.// G' | xxd code> vous obtiendrez
fffe 0a0a code> parce que le 0A (Linefeeds) ne faisait pas partie des lignes, ce sont des terminateurs de ligne et ne disposent donc pas de la règle "Supprimer tout" appliqué.
@Gordon Merci, je commence à comprendre les subtilités de l'UTF-8. Donnez-moi les jours où les hommes étaient des hommes et que tout était ASCII.
Le Voici un extrait de la FAQ: P>
Q: Comment je devrais traiter avec des bombes? P>
A: Voici quelques lignes directrices à suivre: p>
ff code> et
fe code> octets au début de votre fichier est ce qu'on appelle un "point de commande d'octet (bom)". Il peut apparaître au début des flux de texte Unicode pour indiquer l'endansion du texte.
FF Fe CODE> Indique UTF-16 dans la petite Endian P>
.txt code> fichiers) peut nécessiter une utilisation de la nomenclature sur certains flux de données Unicode, tels que des fichiers. Lorsque vous devez vous conformer à un tel protocole, utilisez un bom. Li>
Références h3>
Voir aussi h3>
Ceci éliminera toutes les lignes qui commencent par les octets spécifiques FF FE
sed -e 's/\xff\xfe//g' hexquestion.txt
Merci pour cela - je ne savais pas cela à propos de []. Malheureusement, cela ne semble pas résoudre mon problème particulier.
J'ai relu votre question et j'ai mis à jour ma réponse pour attraper toutes les occurrences de ce modèle. En outre, il s'avère que cette solution fonctionne pour moi sur Cygwin, Redhat Linux 4.8 mais échoue sur un système de redhat plus ancien et Solaris 9. Les versions plus anciennes de SRD ne pourraient pas être en mesure de traiter avec la non-ASCII.
sur OS X, la marque d'ordre d'octets est probablement en train d'être lue comme un seul mot. Essayez soit sed 's / ^ \ xfffe // g' code> ou
sed 's / ^ \ xfeff // g' code> en fonction de l'endianesse. p>
Pour montrer que ce n'est pas un problème de la nomenclature Unicode, mais une question de huit bits de caractères à sept bits et liée à la locale, essayez ceci:
Afficher tous les octets: P>
$ printf '123 abc\xff\xfe\x7f\x80'|LANG=C sed 's/[^[:alnum:]]//g' | hexdump -C 00000000 31 32 33 61 62 63 |123abc|
comme alternative que vous pouvez utiliser ED (1):
printf '%s\n' H $'g/[\xff\xfe]/s///g' ',p' | ed -s test.csv printf '%s\n' H $'g/[\xff\xfe]/s///g' wq | ed -s test.csv # in-place edit
Votre exemple Perl m'a aidé énormément, merci.