La tête dans les nuages, les pieds dans les arbres

Nous nous sommes lancés dans la création d'arbre à l'aide du TreeCloud en partant de nos fichiers Contextes Globaux. Pour cela avons utilisé le TreeCloud (http://www2.lirmm.fr/~gambette/treecloud/NuageArbore.cgi) en ligne dans lequel nous avons rentré notre texte (contexteglobal) que le logiciel a "nettoyé" pour ensuite créer un arbre qui représente les mots la  proximité des mots.
Voici le résultat obtenu pour l'anglais :

Un problème est survenu avec les contextes de l'arabe, il semble que TreeCloud ne reconnaisse pas l'arabe...

Notre deuxième fut de faire les nuages de mots, pour cela nous avons utilisé WORDLE : http://www.wordle.net/ . Il suffit d'entrer notre texte (contexte globale) dans la partie "create" et la logicile nous donne un beau nuage de mot ( les plus fréquents dans notre texte. Nous avons éliminé le mot Kadhafi qui était sur-représenté afin de pouvoir mieux observer son entourage sémantique.
Voici un exemple du résultat en arabe :

 

La fin approche les amis!!! Prochaine étape : création du site internet .

A bientôt pour de nouvelles aventures

Script final des tableaux

Les bras cassés approchent enfin de la ligne d'arrivée ! Notre script des tableaux est terminée et fonctionne correctement sous linux avec la dernière proposition présentée ici même (Miracle : Une seule condition If!!! )

et voilà le résultat :

Exemple du contexte en arabe :

Comme on peut le voir sur cette image, nous avons utilisé une seule expression régulière qui prenne en compte à la fois l'anglais, le français et l'arabe. Le motif choisi est Kadhafi afin de voir ce qui ressort dans les différents articles publiés après sa mort, dans les trois langues.


A suivre : Nuages et arbres!!

PROBLEME AVEC L'OPTION DUMP

Quand nous lançons notre script, un message d'erreur apparaît au moment du traitement de certains fichiers DUMP par le programme miniegrepmultilingue :

Comme on le voit sur cette capture d'écran, le fichier dump3-2-UTF-8.txt contient trois caractères qui posent problème au miniegrepmultilingue, comme par exemple :

utf8 "\xC3" does not map to Unicode at minigrepmultilingue-v2.2-regexp/minigrepmultilingue.pl line 86.

Cela ne se produit par exemple pas avec le fichier suivant dump3-3-UTF-8.txt.

Quand on ouvre le fichier dump3-2-UTF-8.txt avec notre navigateur, on aperçoit rapidement les caractères qui posent problème puisqu'ils sont représentés par une icône avec un point d'interrogation. Voici les trois contextes :

On devine qu'il s'agit à chaque fois du caractère "à" positionné en fin de ligne !

Nous n'avons pas encore trouvé d'explication certaine, mais lorsqu'on examine ce fichier de plus près grâce à un éditeur hexadécimal, on observe la chose suivante :

En Unicode, le caractère "à" est encodé sur deux octets C3 A0. Or chaque ligne semble se terminer par l'octet A0 puis recommence avec la suite d'octet 20 20 20 20 20 20 20. A0 correspond d'après le tableau des caractères Unicode à un "non-breaking space" et 20 à un espace...

Si on ajoute une nouvelle option à lynx comme -nomargins par exemple, on aura toujours le même problème dès lors qu'un "à" se trouvera en fin de ligne. Par exemple pour le fichier dump3-2-UTF-8.txt on a obtenu avec cette nouvelle option les deux erreurs suivantes :

On peut préciser que dans l'exemple que nous donnons la page web d'origine est déjà encodée en UTF-8. Quand on fait une commande lynx sans dump, tout s'affiche correctement dans via le terminal :

L'erreur semble donc bien provenir de la mise en page effectuée par le dump...

DUMP EN UTF-8 AVEC LYNX (partie 1)

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 :

- ASCII
- 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 :

Voici maintenant le résultat obtenu avec le navigateur Lynx :

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  !!!