Discussion :

[DevNico]

Bonjour,

Je suis sur une Red Hat Enterprise Linux ES release 4.
Voici la problématique : je reçois des fichiers qui ont des jeux de caractères divers, et je dois les mettre en utf8 afin de les traiter correctement.

Actuellement j'utilise un petit shell du genre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
dos2unix $1
charset=`file -i $1| cut -d "=" -f 2`
echo "charset original:$charset"
if [ "$charset" == "iso-8859-1" ]
then
	echo "conversion UTF8"
	cp $1 $1.original
	cp $1 $1.tmp	
	iconv -f $charset -t UTF8 $1.tmp > $1
	retour=$?
	if [ "$retour" != "0" ]
	then
		echo "echec de la conversion"
		mv $1.original $1
	else
		echo "conversion OK"
		rm -f $1.original
	fi
else
	echo "Aucune conversion necessaire"
fi
 
#nettoyage 
rm -f $1.tmp
exit $retour

Et j'ai un problème avec un fichier que je viens de recevoir, pour lequel j'ai un retour de la commande file à unknown :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
[nicolas tmp]$ file -i fichier_pb
fichier_pb: text/plain; charset=unknown

Lorsque j'ouvre ce fichier avec textpad, il m'annonce un codepage ANSI.

D'où mes questions :
1°) Pourquoi le file -i n'est-il pas capable de déterminer ce codepage ?
2°) Est-ce que la solution que j'ai mise en place est pertinente ?
3°) Comment faire ?

Merci par avance pour votre aide.

Nicolas

[jmelyn]

Pour la question 1:
Il existe peut-être un caractère spécial sans doute non-affiché qui n'est pas reconnu. Le textpad donne peut-être ANSI comme réponse par défaut lorsqu'il ne sait pas trop.

Question 2:
Ta solution semble correcte. Ligne 4, je ne mettrais qu'un seul '=' (plus POSIX). Et puis il y a beaucoup de $1.*. Je laisserais $1 où il est et je créerais un $1.new qui remplacerait le $1 si tout va bien.

Question 3:
Si tu sauves le fichier depuis le textpad, on peut espérer qu'il ôte le mauvais caractère. Pour être vraiment sûr, il faudrait regarder le ficher avec un éditeur hexa (si ledit fichier n'est pas trop long) ou faire un programme qui donne les codes de chaque caractère et qui supprime les courants pour ne t'afficher que ceux à problème.

[DevNico]

Merci pour tes indications.

Il se trouve que j'ai réussi à isoler le caractère qui posait problème.
(En exécutant des file -i sur des bouts du fichier).

Il s'agit d'une apostrophe (pas le ', ni le `, mais bien le ’).
Son code hexa est 92.

Quand je fais un vi sur le fichier, il n'est pas affiché mais j'ai <92> à la place.

Quelqu'un saurait dire pourquoi ?

[jmelyn]

Bonjour,

En général, il y a les 128 premiers caractères qui sont remplis (7bit-ASCII), puis une "bande interdite", enfin sans caractères, je ne sais pas pourquoi, et enfin des caractères spéciaux à partir de 0xA1 (161) comme: ¡¢£¤¥¦§¨©ª«¬®¯°±²³´µ¶· (je crois que le symbole de l'euro est 0xA4 (164), code que je n'ai pas sur Fedora 8). Le code 0x92 (146) est dans cette "bande interdite".

En te proposant de faire un petit programme, ce que je voulais te dire c'est de repérer précisément les codes qui sont peu probables d'être correctement affichés. Une sorte de vérificateur de code, en quelque sorte.

[DevNico]

En fait, plutôt que d'identifier et isoler les caractères qui peuvent poser problème, mon but est surtout d'identifier quel est le problème avec ce fichier afin de pouvoir remonter ça à l'application qui me l'a envoyée, pour qu'ils corrigent.

Le problème est que si le fichier est vraiment de l'ANSI PC, je ne me vois pas leur dire : envoyez moi de l'utf8. Il me faudra donc trouver un moyen de traiter correctement le fichier.
D'un autre coté, si le fichier a vraiment un problème (par exemple des caractères ASCII, mixés avec des caractères utf8 dans le même fichier (j'ai déjà eu ça)), alors là je peux leur dire : envoyez moi un fichier correct.