[Résolu] Convertir un fichier de données binaire en texte utf-8

nordinatueur · Le 26/10/2010, à 21:51

Bonsoir, j'ai trouvé pas mal de solutions pour lire des fichiers "texte binaire" mais je n'arrive pas à en extraire le contenu simplement.

Mon téléphone portable me permet de sortir régulièrement la liste des textos émis et reçus. J'ai voulu les stocker en attendant de faire un script bash pour les organiser. Le fichier est binaire et : (j'ai sélectionné iso8859-1 au hasard dans « iconv -l » )

$ file file.txt 
file.txt: data
$ iconv file.txt -t utf8 -f iso8859-1 | tail -n5
   Envoyés : 20/10/2009 20:15
   Contenu :
   Tu me prendre une biere et je te rembourse...

Premier fait surprenant, lorsque je tente un grep j'ai une erreur sauf si j'utilise l'option -a (~ --binary-files=text). Deuxième chose : J'ai demandé 5 lignes à tail, et il ne m'en donne que 4. (Fait exprès, la ligne au dessus contient des coordonnées.)
Mieux encore : j'ai enregistré ce qui précède dans file.tail :

$ file file.tail 
file.tail: data
$ cat file.tail | sed "s/0/Z/g"
   Envoyés : 2Z/1Z/2ZZ9 2Z:15
   Contenu :
   Tu me prendre une biere et je te rembourse...

$ cat file.tail | sed "s/00/Z/g"
   Envoyés : 20/10/2009 20:15
   Contenu :
   Tu me prendre une biere et je te rembourse...

Ainsi avec sed je peux uniquement changer des caractères un par un... Ce qui n'est pas pratique du tout pour reconnaître des champs ...
Le man de sed ne parle pas de fichiers binaires (ou en tout cas je n'ai rien trouvé.) Et je ne sais utiliser que sed pour traiter des fichiers automatiquement.

Quelqu'un sait-il comment je peux changer le format de mes fichiers "texte binaire" ? Ou tout du moins, comment indiquer à sed comment lire et comprendre ce fichier ?
Malheureusement, pour des raisons de confidentialité, je ne peux pas vous communiquer ce fichier en entier, et étant donné que sed ne veut rien faire, je ne peux pas enlever les lignes sensibles.

Merci d'avance pour votre aide et/ou votre attention !

Dernière modification par nordinatueur (Le 27/10/2010, à 01:51)

ehmicky · Le 27/10/2010, à 01:11

Salut,
Que donne la zone indiquant "2009" en hexadécimal ?

hexdump -Cn 40 file.tail

Peut-être y-a-t'il un '\0' entre les deux zeros ? Si oui :

< file.tail tr -d '\0' | sed "s/00/Z/g"

Edit : au passage :

< file.tail sed "s/0/Z/g"

Dernière modification par ehmicky (Le 27/10/2010, à 01:34)

nordinatueur · Le 27/10/2010, à 01:26

Merci ! J'avais déjà effectué un hexdump et un xxd après quelques tours sur le forum, mais j'ai pas compris le résultat...

$ hexdump -Cn 60 file.tail
00000000  00 20 00 20 00 20 00 45  00 6e 00 76 00 6f 00 79  |. . . .E.n.v.o.y|
00000010  00 c3 a9 00 73 00 20 00  3a 00 20 00 32 00 30 00  |....s. .:. .2.0.|
00000020  2f 00 31 00 30 00 2f 00  32 00 30 00 30 00 39 00  |/.1.0./.2.0.0.9.|
00000030  20 00 32 00 30 00 3a 00  31 00 35 00              | .2.0.:.1.5.|
0000003c

Les points sont-ils effectivement là où est-ce qu'ils représentent seulement le début des lettres sur 2 octets ?
Le \0, c'est le caractère de fin de chaîne ?

Edit : Je viens de remarquer un truc : Les points arrivent tous les deux caractères sauf après ce qui semble être le « é » « c3a9 » et qui me rappelle drôlement la notation dans les uri ... comme pour le dossier « Téléchargement .» Ça a un rapport ?

Dernière modification par nordinatueur (Le 27/10/2010, à 01:35)

nordinatueur · Le 27/10/2010, à 01:41

Merci beaucoup ! Ça fonctionne avec « tr -d '\0' » !
Et oui j'utilise d'ordinaire les redirections, mais j'ai essayé pas mal de trucs pour voir ce qui clochait, et j'ai pensé que sed n'aimait pas le binaire, donc je suis passé par cat, mais c'est exactement pareil...

Sinon, sais-tu comment faire une conversion vers un format plus utilisable ?
Edit : Je passe en [Résolu], pour convertir la commande est :

tr -d '\0' file.txt > file2 # à l'encodage près.

J'ai donc fait un :

$ iconv file.txt -t utf8 -f iso8859-1 | tar -d '\0' > file.utf
$ file file.utf 
utf: UTF-8 Unicode English text, with CRLF, LF line terminators

Merci ehmicky !

Dernière modification par nordinatueur (Le 27/10/2010, à 01:49)

ehmicky · Le 27/10/2010, à 01:49

Ton fichier est encodé en UTF-16.
Or, les core-utilities et sed sont conçues pour UTF-8 en théorie.
'\0' est le caractère null, correspondant à la valeur 0 en ASCII. Il est automatiquement supprimé lors d'une impression.
En tout cas, c'est pas une question de fichier binaire/fichier texte.

Edit : en tout cas supprimer les '\0' a l'air ok au premier abord, mais je pense que c'est pas propre.
Edit 2 : non désolé, la clef c3 indique un fichier UTF-8 et non UTF-16, c'est juste que les caractères ont une longueur fixe de 2 octets (wchar_t ?).

Dernière modification par ehmicky (Le 27/10/2010, à 02:03)

nordinatueur · Le 27/10/2010, à 01:54

En effet la conversion utf16 dans iconv est bien mieux ! Cette ligne suffit !

iconv file.txt -t utf8 -f utf16

Mais pourquoi n'est-il pas reconnu par la commande « file » ?

ehmicky · Le 27/10/2010, à 01:58

Attends, je t'ai induit en erreur, c'est bien de l'UTF-8, c'est juste que ça doit être des wchar_t ou similaire. Je pense que supprimer les nulls suffit
Je crois qu'il n'est pas reconnu par file parce que file ne comprend pas tous ces '\0' qui trainent et qu'il pense donc qu'il s'agit d'un binaire, alors que c'est un fichier UTF-8.

Dernière modification par ehmicky (Le 27/10/2010, à 02:00)

nordinatueur · Le 27/10/2010, à 02:17

Je pense qu'une petite recherche sur le sujet s'impose...
Peut-être demain ! Je mets ça dans mes to-do. En tout cas merci pour les explications, même si je ne suis plus sûr de savoir ce qui est ou n'est pas.
Chaque \0 servirait donc de délimiteur pour les caractères... y compris ceux définis sur plusieurs octets. Ça paraît logique, mais ça ne m'est jamais arrivé avec d'autres fichiers. C'est le premier fichier qui me cache des octets nuls.

Wikipédia a écrit :

Chaque point de code est ensuite codé de façon unique sur une suite d'un à quatre octets. Ce format de transformation a été conçu pour être compatible avec de nombreux logiciels originellement prévus pour traiter des caractères codés sur un seul octet.

Source : http://fr.wikipedia.org/wiki/UTF-8
Bien que cela semble analogue pour UTF-16 (2 octets) et UTF-32 (4 octets), ça ne l'est pas du tout.

ehmicky · Le 27/10/2010, à 02:33

Non désolé de t'avoir embrouillé. Donc, en clair, comment je vois les choses :
Le fichier est encodé en UTF-8, qui utilise des tailles variables de 1 à 3 octets par caractère. Les caractères ASCII sont représentés sur 1 octet, les autres caractères sur 2 octets, et quelques très rares caractères (par exemple hyeroglyphes...) jamais utilisés sur 3 octets. Pour ce qui est des 4 octets, 3 octets suffisent à représenter l'ensemble des 17 tables Unicode, donc on n'utilise jamais 4 octets.
Le problème, c'est que les fonctions de comparaison, de tri, etc. ont besoin de faire des comparaisons caractère par caractère. Historiquement, quand il n'y avait pas Unicode, 1 caractère = 1 octet. Avec UTF-8 cependant, 1 caractère peut ou pas = 1 octet.
Pour faciliter les fonctions de comparaison, tri, etc., donc un type wide character est fourni en C qui s'assure que tout caractère UTF-8 tient sur 2 ou 4 octets, en remplissant les octets non-utilisés avec des '\0'. Ainsi les '\0' ne servent pas à "délimiter" un caractère, mais à remplir le 2ème octet d'un caractère n'ayant besoin que d'un octet pour être représenté.
Or les wide characters posent problème avec de nombreuses commandes Unix, dont sed, qui résonnent octet par octet. C'est pourquoi tu peux supprimer les '\0' pour retourner à de l'UTF-8 normal.

Ma confusion venait du fait que je pensais qu'il s'agissait d'UTF-16, un moyen concurrent d'encoder les caractères Unicode, utilisé notamment par W$, et qui code tous les caractères sur 2 octets. Mais c'est pas le cas.
Pour ce qui est d'UTF-32, tout est encodé sur 4 octets, mais c'est quasiment pas utilisé.

Dernière modification par ehmicky (Le 27/10/2010, à 02:42)

nordinatueur · Le 27/10/2010, à 02:53

Ben ça ne m'étonnerait pas que mon téléphone utilise un format proprio... Comment es-tu sûr que c'est de l'utf-8 ?
Deuxièmement, dans la lecture des octets, tout était décalé par l'apparition du « é » qui était sur 2 octets et était précédé et suivi d'un \0. Dans ce cas, pour le « é » serait mis sur 3 octets ?

Et alors dans le cas général, si sed ne veut lire les octets qu'un par un, comment fait-il d'ordinaire pour lire les caractères accentués, et tous les autres qui ne sont pas dans la table ASCII ?

ehmicky · Le 27/10/2010, à 16:35

nordinatueur a écrit :

Ben ça ne m'étonnerait pas que mon téléphone utilise un format proprio... Comment es-tu sûr que c'est de l'utf-8 ?

Parce que c3a9 pour coder un "é", c'est de l'UTF-8 ! Les clefs c2 et c3 sont typiques des caractères UTF-8 non-ASCII, mais courants en français (il s'agit des caractères Unicode U+0080 à U+00FF) : cf doc' sur l'encodage UTF-8.

nordinatueur a écrit :

Deuxièmement, dans la lecture des octets, tout était décalé par l'apparition du « é » qui était sur 2 octets et était précédé et suivi d'un \0. Dans ce cas, pour le « é » serait mis sur 3 octets ?

Effectivement, j'avais pas vu. Donc c'est de l'UTF-8 avec un '\0' à la fin de chaque caractère.

nordinateur a écrit :

Et alors dans le cas général, si sed ne veut lire les octets qu'un par un, comment fait-il d'ordinaire pour lire les caractères accentués, et tous les autres qui ne sont pas dans la table ASCII ?

Parce que sed se fiche de l'encodage utilisé. Il ne voit qu'un flux d'octets. Vu que les terminaux Linux sont UTF-8, quand tu tapes : sed 's/é/&/g', le "é" est traduit binairement par un "c3a9" (UTF-8). Donc sed voit juste qu'il faut remplacer toute suite de "\xc3\xa9". Donc sur un terminal UTF-8, ça équivaut à sed 's/\xc3\xa9/&/g'. Donc ça remplace bien les é dans les fichiers encodés en UTF-8.

Dernière modification par ehmicky (Le 27/10/2010, à 17:22)

nordinatueur · Le 28/10/2010, à 09:54

Merci beaucoup pour ta réponse, je comprends beaucoup mieux.
Reste à savoir pourquoi ce pseudo-format a été employé... Pas super pratique et ça alourdit le fichier...

Encore merci !

P.S. : Joli avatar.

Dernière modification par nordinatueur (Le 28/10/2010, à 09:55)

ehmicky · Le 28/10/2010, à 15:37

nordinatueur a écrit :

Merci beaucoup pour ta réponse, je comprends beaucoup mieux.
Reste à savoir pourquoi ce pseudo-format a été employé... Pas super pratique et ça alourdit le fichier...

C'est peut-être une alternative aux wchar_t : le fait d'utiliser un délimiteur '\0' permet de traiter les fichiers caractère par caractère (délimiteur par délimiteur), peu importe le nombre d'octets du caractère.
Si le sujet des encodages, notamment UTF-8 et UTF-16 t'intéresse, je t'ai mis un bout de mes fiches perso dessus. Ca vaut ce que ça vaut... à la base, je les écrit juste pour moi, donc y'a plein de trucs obscurs, et puis bon ça doit être bourré d'erreurs, c'est pas de la vraie documentation hein... Mais bon, c'est le résultat de recherches sur beaucoup d'autres doc', et y'a des trucs comme une description et une histoire des principaux encodages, des tables montrant rapidement leur caractères, un moyen (à mon avis très mal expliqué mais à la base c'est pour moi) pour convertir une valeur hexa UTF-8 en codepoint Unicode, etc. Et c'est lisible sur un terminal.

nordinateur a écrit :

P.S. : Joli avatar.

Date de l'époque lointaine où je faisais des trucs avec Photoshop et Blender, ce dernier m'ayant ouvert au monde du libre

Dernière modification par ehmicky (Le 28/10/2010, à 15:38)

nordinatueur · Le 29/10/2010, à 10:00

Pour moi qui aime les docs, c'est Noël avant l'heure !
J'y jette un œil dès que je peux ... (ça va être ce soir j'imagine !) Et pour ce qui est de l'obscurité, je suis un fin chercheur en soif de connaissances. C'est pas que je trouve, mais je cherche...

Histoire peu commune ! C'est Blender qui t'a ouvert au libre ? Comment ça s'est passé ? Qu'est-ce qui t'as fait dire « Je préfère le libre ! » sans avoir honte du regard des gens ?

ehmicky · Le 29/10/2010, à 21:43

nordinatueur a écrit :

Histoire peu commune ! C'est Blender qui t'a ouvert au libre ? Comment ça s'est passé ? Qu'est-ce qui t'as fait dire « Je préfère le libre ! » sans avoir honte du regard des gens ?

Bah la communauté Blender (surtout celle anglophone) parle beaucoup de Linux, même s'il y a de nombreux utilisateurs W$. Ca m'a donné envie d'essayer. Dual Boot plusieurs années, et depuis récemment seulement Ubuntu.
Le regard des gens, je crois que c'est pas de la honte. Je crois que l'attitude générale c'est plus de l'incompréhension et du "Ah moi du moment que ça marche, je me prends pas la tête". Je pense qu'on connais tous ça ici

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 26/10/2010, à 21:51

[Résolu] Convertir un fichier de données binaire en texte utf-8

#2 Le 27/10/2010, à 01:11

Re : [Résolu] Convertir un fichier de données binaire en texte utf-8

#3 Le 27/10/2010, à 01:26

Re : [Résolu] Convertir un fichier de données binaire en texte utf-8

#4 Le 27/10/2010, à 01:41

Re : [Résolu] Convertir un fichier de données binaire en texte utf-8

#5 Le 27/10/2010, à 01:49

Re : [Résolu] Convertir un fichier de données binaire en texte utf-8

#6 Le 27/10/2010, à 01:54

Re : [Résolu] Convertir un fichier de données binaire en texte utf-8

#7 Le 27/10/2010, à 01:58

Re : [Résolu] Convertir un fichier de données binaire en texte utf-8

#8 Le 27/10/2010, à 02:17

Re : [Résolu] Convertir un fichier de données binaire en texte utf-8

#9 Le 27/10/2010, à 02:33

Re : [Résolu] Convertir un fichier de données binaire en texte utf-8

#10 Le 27/10/2010, à 02:53

Re : [Résolu] Convertir un fichier de données binaire en texte utf-8

#11 Le 27/10/2010, à 16:35

Re : [Résolu] Convertir un fichier de données binaire en texte utf-8

#12 Le 28/10/2010, à 09:54

Re : [Résolu] Convertir un fichier de données binaire en texte utf-8

#13 Le 28/10/2010, à 15:37

Re : [Résolu] Convertir un fichier de données binaire en texte utf-8

#14 Le 29/10/2010, à 10:00

Re : [Résolu] Convertir un fichier de données binaire en texte utf-8

#15 Le 29/10/2010, à 21:43

Re : [Résolu] Convertir un fichier de données binaire en texte utf-8

Pied de page des forums