Hello tout le monde,
 
je cross post un peu un topic que j'ai lancé sur OSA. Voici le problème :
 
Je regarde des fichiers de log générés sur un serveur Unreal Tournament tournant sous Linux et entre chaque caractère j'ai un ^@ qui apparait, Voici un exemple où on voit marqué game GameMutator
 

 
 
Kristoph m'a fait la remarque suivante :
 

 
En faisant un cat sur ce fichier, il s'affiche correctement. Mais en redirigeant le cat sur un fichier et en éditant celui après, j'ai toujours la même chose. J'ai bidouillé sans trop de raisons avec flip et dos2unix, mais ca ne change pas. J'ai fini par tenté un less apres un export LESSCHARSET=utf-8, mais ca ne fonctionne pas.
 
Il me faudra juste un cat "unicode", que je puisse redirigé sa sortie dans un fichier. Une idée d'outil déja existant ou autre ?
 
Merci d'avance à vous !
 
A+

J'ai mis au point une petite fonction en C qui vaut ce qu'elle vaut, et qui me permet d'obtenir un fichier sans les ^@ entre chaque caractère, juste en me décalant d'un octet avant chaque lecture...
 

 
Rien d'exceptionnel donc... J'aimerais tout de même en savoir un peu plus sur le fond du problème... =)
 
Par ailleurs, je profite de cette question pour vous demander comment exploiter les jokers en ligne de commande ? J'imagine bien sur qu'il va falloir passer par argc, argv* char[], mais c'est pour savoir si il y a des mécanismes tout fait ou il faut que je fasse ca avec mes petites mains ?
 
Par exemple, si je veux convertir un ensemble de fichier d'un répertoire avec mon petit programme, que je nommerais conv, et que je veuille appliquer ce prog à l'ensemble de fichiers d'un répertoire en faisant ./conv * ?
 
Merci d'avance !
 
A+

 
si ca vient d'un ftp ton fichier c'est normal que ca ai merde, tu etait pas dans le bon mode....
ascii/bin
 
tu peux utiliser dos2unix comme script par exemple
 

 
Bin en fait, Unicode c'est une énoooorme table ASCII dans laquelle sont stockés les caractères de tous les langages. Evidemment, en codant les caractères sur 2 octets comme en Anglais ou Français, c'est pas suffisant pour tout mettre. Donc pour pouvoir faire ça, chaque caractère Unicode est encodé sur 4 octets. Du coup, un caractère comme espace au lieu d'être encodé sous la forme 0x20 bin il devient 0x0020. D'où l'apparition des caractères zarbes que t'as eus

kuroineko > Merci pour ta réponse, mais le problème ne venait pas de là, j'avais d'ailleurs déja fait des essais avec dos2unix et flip =)
 
Taiche > Merci énormément pour tes précisions !
 
A+

   
T'as fumé la moquette toi ! D'ou t'as vu qu'unicode est codé sur 4 octets ?
Unicode est codé sur 16 bits, donc 2 octets ! Tu trouves que 65535 caractères possibles, c pas suffisant ?
Et 0x0020 est un nombre 16 bits, et non 32 bits !

 
Humpf, je me suis carrément mélangé les pinceaux
Oui, c'est bien évidemment 2 octets et non 4 comme j'ai pu l'écrire dans un élan de connerie (fatigue ???) hier soir. Sinon y aurait 3 caractères zarbes devant chaque lettre et non un seul
Bref, désolé...

Alors j'viens de me renseigner et comme j'me disais bien que 65535 caractères, c'était pas assez pour tout coder (si on prend tous les langages existants, vivants ou morts), bin en fait il existe un truc encore plus bourrin qui est l'UCS-4 (ISO 10646). C'est codé sur 31 bits (le 32ème n'est pas utilisé) et est assez rarement pris en compte dans la pratique. Bref, ça existe mais c'est tout A noter que la forme UCS-2 est équivalente à l'Unicode.
Tout ça pour dire que l'encodage sur (presque) 4 octets, ça existe si jamais y a des gens qui le cherchent