La commande wc -m petit souci [Résolu]

[ToTo13]

Bonjour,

je souhaitais lire une image pgm avec un soft java, mais j'ai eu un souci de EOF. J'ai donc fais une petite vérification :

- Les image pgm ont cette forme :

Code :

1
2
3
4
5
6
7
 
P5
#des commentaires
512 512
#des commentaires
255
jfgiormeztufeormtuerl456789r!uez!eliqf elfi

Autrement dis :
- un type : P5
- largeur et hauteur : 512 512
- un niveau maximum de gris : 255
- largeur*hauteur caractères.

J'ai donc fait un wc -m pour savoir combien il y avait de caractères dans l'image suivante : abe j'ai obtenu : 262178 caractères
Puis j'ai enlevé les caractères, donc je n'ai laissé que l'entête et j'ai obtenu : 34 caractères
J'ai alors enlevé l'entête et compté le nombre de caractères et j'ai obtenu : 262139 caractères.

Pourquoi ai je une différence de 5 caractères quand je décompose l'image ?
J'ai répété plusieurs fois l'opération pour m'assurer que je n'avais pas fait d'erreur.

Est ce que quelqu'un sait pourquoi ???

merci...

[ggnore]

Certaines valeurs ascii ne sont pas écrivables. Ceux sont des valeurs qui sont en dessous de 30 si je me souviens.

Une image est un fichier binaire : il n'est pas traité comme un fichier texte quand il est interprété.

Si tu manipules un fichier binaire comme si il était composé de caractères, tes outils peuvent rencontrer des problèmes d'interprétation car ils doivent travailler avec des valeurs pour lesquels ils n'ont pas été faits.

C'est une piste

[MarcG]

Je ne comprend pas bien ce que tu veut faire mais si tu doits compter le nombre de caractere d'un fichier binaire utilise "od"
genre :

Code :

1
2
 
od -x mon_fichier | wc -ml

le nombre d'octet est la difference ntre le nombre de ligne+1 et le total sortie par wc.

le plus simple et quand même un "ls -l" voir un "stat".......

[ToTo13]

Bonjour,

une image PGM n'est pas codé entièrement en binaire.
L'entete est du texte et le corp est composé de caractères représentant une valeur binaire.

En C on peut tout écrire comme valeur à l'aide de la fonction fwrite et réciproquement tout lire avec fread. Les autres fonction connaissent certaines difficultés pour les valeur comme 13 ('\n') ou 10 ('\t').

En revanche, il semblerait que wc ne lise pas tout...

[2Eurocents]

J'aurai tendance à me méfier de wc -m pour un fichier contenant des données binaires. wc -c me paraît plus fiable ...

Maintenant, en toute logique, la partie "image" du fichier fait 512 x 512 pixels, soit 262144 octets. Toute valeur différente dénote soit un fichier corrompu, soit une erreur de manipulation lors de la séparation.

Le fichier, en tout, fait 262178 octets.

L'entête doit donc faire 262178 - 262144 = 34 octets.

La valeur totale et la longueur de l'entête correspondant, tu as du te tromper lors de la séparation.

Je crois que ton éditeur n'a pas supporté les données binaires et en a supprimé quelques caractères entre la lecture et l'écriture du bloc de données.

[ToTo13]

Bonjour,

j'ai émis cette hypothèse, mais cela me semble tout de même bizarre. J'ai bien compté 34 caractères supprimés...

[2Eurocents]

Envoyé par ToTo13

j'ai émis cette hypothèse, mais cela me semble tout de même bizarre. J'ai bien compté 34 caractères supprimés...

Moi, ça ne me choque pas ... tu supprimes 34 caractères, Ok, mais si ton éditeur rencontre des caractères qu'il ne sait pas gérer, il peut en dégager aussi ...

Si tu veux vraiment être sûr de ne dégager que les 34 premiers caractères, fais le avec une commande de copie binaire, plutôt qu'un éditeur. Regarde ce que donne cette commande :

Code :

dd if=abe.pgm of=image_abe.truc ibs=1 skip=34

Je parie sur une taille de image_abe.truc à 262144 octets.

[ToTo13]

Bonjour,

bien vu !!!
Effectivement ça marche maintenant...

Merci