Nous allons présenté aujourd'hui une proposition alternative afin de traiter les problèmes d'encodage et de conversion en UTF-8. Il s'agit en gros d'ajouter une option à la commande lynx afin d'obtenir un dump directement en UTF-8 et donc de supprimer une bonne partie des conditions if et des boucles de notre script...
Afin de régler les problèmes d'encodage que nous rencontrions depuis le début, nous avons fait toute une série de tests à partir de fichier html encodé en :
- UTF-8
- ISO-8859-1
- MacRoman
- Windows-1256
On a d'abord constaté que des navigateurs comme Safari et Lynx n'affichaient pas toujours les caractères de ces pages web de la même manière. Il arrive fréquemment que Lynx n'affiche pas ou mal certains caractères non ASCII.
Voici un exemple avec une petite page HTML encodée en ISO-8859-1 :
D'après cette capture d'écran, on voit bien que le fichier est encodé en ISO-8859-1 et que cette encodage est correctement indiqué dans la balise <meta> du code HTML. Pour notre test, on a inséré en plus des caractères accentués leur équivalent en caractère spéciaux HTML. Ce document est donc valide et s'affiche comme ceci dans notre navigateur Safari :
On ne constate aucun problème d'affichage contrairement à Lynx où après avoir tapé la commande lynx suivi du nom de notre fichier HTML on obtient le résultat suivant :
On remarque qu'un espace remplace les caractères accentués, que le "t" de "fête" ne s'affiche pas et que le dernier caractère spéciaux HTML est mal interprété ! On peut préciser que notre shell a pour encodage par défaut UTF-8, mais qu'on obtient le même résultat lorsqu'on sélectionne ISO-8859-1 dans les préférences du terminal. Lorsqu'on fait un dump sur la commande lynx, on obtient un résultat encodé en ISO-8859-1 avec tous les caractères du texte présents. Les caractères spéciaux HTML on bien été remplacés par les caractères correspondants.
Voici les détails en hexadécimal du fichier dump obtenu :
On voit sur cette capture d'écran que le caractère "ê" dans "fête" correspond dans l'écriture hexadécimal à EA, ce qui correspond bien au symbole "ê" dans la table d'encodage ISO-8859-1 :
Tout est bien qui fini bien donc puisque tous les caractères qu'on voyait dans notre navigateur Safari se retrouvent dans notre fichier dump dans l'encodage d'origine.
Mais voyons maintenant ce qui se passe avec la même page web encodée en MacRoman...
On voit sur la capture d'écran que l'encodage de la page est bien en Mac OS Roman et que cet encodage est indiqué correctement dans la balise <meta> du code source. Ce fichier est donc valide et peut être correctement interprété par le navigateur Safari :
On a également vérifié l'encodage de ce fichier HTML à travers sa représentation en notation hexadécimale :
On voit que le caractère "ê" de "fête" correspond en hexadécimal à 90, ce qu'on retrouve bien dans la table d'encodage de MacRoman :
On constate les mêmes problèmes d'affichage que lors de notre test sur la page HTML encodé en ISO-8859-1...
Et voici les détails en hexadécimal du fichier dump obtenu par la commande lynx -dump MacRoman-meta.html > dump-MAC.txt :
On remarque que le caractère "ê" de "fête" correspond en hexadécimal à EA et non à 90. On peut donc en déduire que le fichier dump obtenu est encodé en ISO-8859-1 et non en MacRoman comme la page web d'origine ! Dans ce cas, on ne peut donc plus se baser sur l'encodage de la page web d'origine pour convertir le fichier dump en UTF-8...
En essayant de mieux comprendre comment fonctionnait Lynx, nous sommes tombés dans le man de cette commande sur une option très intréssante concernant les problèmes d'encodage :
-display_charset=MIMEname
set the charset for the terminal output.
Nous avons alors fait quelques tests en donnant UTF-8 comme encodage pour l'output et voici quelques-uns de nos résultats.
Avec la commande lynx -display_charset=UTF-8 suivie du nom du fichier de la page HTML encodée en ISO-8859-1 on obtient le résultat suivant :
On voit que cette fois-ci tous les caractères s'affichent correctement. C'est aussi le cas avec le fichier encodé en MacRoman :
On a alors vérifié à travers la représentation en hexadécimal dans quel encodage étaient les fichiers dump produits à partir de la commande lynx -display_charset=UTF-8 -dump sur ces pages web en ISO-8859-1 et MacRoman. Le résultat est identique dans les deux cas :
On remarque que le caractère "ê" de "fête" est encodé sur deux octects C3 AA qui correspondent bien à "ê" dans la table de l'UTF-8 :
Pour résumer, on peut donc penser que l'ajoute de l'option -display_charset=UTF-8 à la commande lynx -dump permettrait d'obtenir un fichier texte encodé en UTF-8 quelque soit l'encodage de la page web d'origine. En tout cas, les tests que nous sommes en train de faire sur l'arabe ont l'air d'aller dans ce sens à condition que le terminal dans lequel on travaille ait pour encodage par défaut UTF-8.
Par conséquent, cette nouvelle option nous permettrait de réduire le nombre de conditions et de boucles dans notre script actuel : un bon coup de défrisage pour la nouvelle année !!!
En essayant de mieux comprendre comment fonctionnait Lynx, nous sommes tombés dans le man de cette commande sur une option très intréssante concernant les problèmes d'encodage :
-display_charset=MIMEname
set the charset for the terminal output.
Nous avons alors fait quelques tests en donnant UTF-8 comme encodage pour l'output et voici quelques-uns de nos résultats.
Avec la commande lynx -display_charset=UTF-8 suivie du nom du fichier de la page HTML encodée en ISO-8859-1 on obtient le résultat suivant :
On voit que cette fois-ci tous les caractères s'affichent correctement. C'est aussi le cas avec le fichier encodé en MacRoman :
On remarque que le caractère "ê" de "fête" est encodé sur deux octects C3 AA qui correspondent bien à "ê" dans la table de l'UTF-8 :
Pour résumer, on peut donc penser que l'ajoute de l'option -display_charset=UTF-8 à la commande lynx -dump permettrait d'obtenir un fichier texte encodé en UTF-8 quelque soit l'encodage de la page web d'origine. En tout cas, les tests que nous sommes en train de faire sur l'arabe ont l'air d'aller dans ce sens à condition que le terminal dans lequel on travaille ait pour encodage par défaut UTF-8.
Par conséquent, cette nouvelle option nous permettrait de réduire le nombre de conditions et de boucles dans notre script actuel : un bon coup de défrisage pour la nouvelle année !!!
Aucun commentaire:
Enregistrer un commentaire