8
votes

Entrée d'octets hexagonaux avec SED - pas de match

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


1 commentaires

Votre exemple Perl m'a aidé énormément, merci.


7 Réponses :


0
votes

Vous pouvez obtenir les codes hexagonaux avec \ xff \ xfe et le remplacer par rien.


0 commentaires

4
votes
LANG='' sed 's/[^ -~]//g' myfile

10 commentaires

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 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 vous obtiendrez fffe 0a0a 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.



3
votes

Le ff et fe 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 Indique UTF-16 dans la petite Endian

Voici un extrait de la FAQ:

Q: Comment je devrais traiter avec des bombes?

A: Voici quelques lignes directrices à suivre:

  1. Un protocole particulier (par exemple, des conventions Microsoft pour .txt 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.
  2. Certains protocoles permettent des boms facultatifs dans le cas de texte non étiqueté. Dans ces cas,
    • Lorsqu'un flux de données texte est connu pour être un texte brut, mais d'un codage inconnu, BOM peut être utilisé comme signature. S'il n'y a pas de naissance, le codage pourrait être n'importe quoi.
    • Lorsqu'un flux de données texte est connu pour être un texte unicode simple (mais non quel endian), alors la nomenclature peut être utilisée comme signature. S'il n'y a pas de naissance, le texte doit être interprété comme Big-Endian.
    • Certains protocoles orientés d'octets attendent des caractères ASCII au début d'un fichier. Si UTF-8 est utilisé avec ces protocoles, l'utilisation de la nomenclature en tant que signature de formulaire de codage doit être évitée.
    • Lorsque le type précis du flux de données est connu (par exemple, un petit endian Big-Endian ou Unicode), le noyau ne doit pas être utilisé. En particulier, chaque fois qu'un flux de données est déclaré être UTF-16BE, UTF-16LE, UTF-32BE ou UTF-32Le BOM ne doit pas être utilisé.

      Références


0 commentaires

4
votes

Ceci éliminera toutes les lignes qui commencent par les octets spécifiques FF FE

sed -e 's/\xff\xfe//g' hexquestion.txt


2 commentaires

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.



1
votes

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' ou sed 's / ^ \ xfeff // g' en fonction de l'endianesse.


0 commentaires

0
votes

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|


0 commentaires

0
votes

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


0 commentaires