Souci d'encodage MacOs - Lynx

Soucis encodage MacOs - Lynx 

Nous faisons cette entrée pour laisser évidence d’un souci d'encodage qu’on a rencontré concernant la 

commande lynx sur MacOs. En effet, nous avons remarqué dans certaines URLs aspirées qu' il y avait

des rendus bizarres. Notamment pour les caractères diacrités et la c cédille (ç). Ci-dessous quelques 

captures d'écran pour illustrer cette situation. 

 

 

Au début, nous croyions à un souci d’encodage des URL. Nous avons donc bien ajouté dans notre script les deux boucles

pour convertir les encodages reconnus avec la commande curl et detect encoding sans pour autant avoir une amélioration dans les rendus de nos pages aspirées. 

Normalement, en lançant ce script, si le site n’est pas encodé en UTF-8 une erreur devrait s'afficher dans 

le tableau qu’il génère au niveau de la colonne 1, mais aucune erreur ne s’affiche, au contraire il indique 

que le site est bien encodé en  UTF-8. 

Une vérification manuelle du charset a été effectuée sur certains sites. Pour la plupart c’eest du l’UTF-8 

y est déclaré. 

Sachant que cela n’est pas complètement révélateur, Nous avons ensuite vérifié le fichier aspiré en format 

txt sur l'éditeur hexadécimal et en analysant les octets on a pu aussi affirmer qu’il s’agissait bien d’UTF. 

Une autre vérification a été faite sur le fichier txt : sur la console à l’aide de la commande file. Nous avons

 obtenu comme résultat ceci. 

Ce qui nous a paru étonnant c'est qu'en tapant la commande less utf8_1-3.txt sur le terminal on obtient un 

rendu presque net. On y voit que le texte s’affiche avec un seul erreur qui correspond à “à”

 

 

Nous nous sommes dit que peut-être il n’y avait aucun problème, que c’était l’éditeur de texte qui 

n’était pas performant. En essayant d’ouvrir le texte avec d’autres éditeurs, c’était toujours un affichage comme celui-ci:

 

En l’ouvrant sur l’éditeur de texte Brackets, il a reconnu l'encodage du texte comme étant du 

Windows-1252. On a cru qu’en utilisant l’option iconv on parviendrait à une solution :  iconv -f 

WINDOWS-1252 -t UTF-8 utf8_1-3.txt. Mais, en fait non, cette erreur s’affiche dans le Terminale.  

Finalement, Nous tenons à préciser un autre phénomène qui nous surprend, lorsqu'on ouvre le fichier 

contexte2.html (fichier html qui contient les contextes extraits par minigrep-multilingue) ainsi que les 

bigrams et les index qui sont créés à partir du DUMP des sites aspirés, aucun soucis d’encodage n’y est 

repéré, les résultats semblent bien encodés. 

Un message à été envoyé à Madame Moreaux, professeure du cours de Gestion Informatique du

 Multilinguisme qui nous a gentiment aidé. Voici sa réponse.  

J'ai fait la manip (aspiration, puis dump)  sur Ubuntu installé dans une

machine virtuelle : aucun problème.

Sur MacOS, la manip produit les mêmes problèmes que ceux que vous

décrivez : aspiration (curl) fonctionne correctement, le problème vient

avec la version de lynx sur MacOS qui semble ne savoir interpréter

certains octets.

Pour m'en convaincre, j'ai aspiré la page sur MacOs, puis je l'ai dumpée

sur Ubuntu : pas de problème.

Malheureusement, pour l'instant je ne vois pas vraiment comment corriger

le bug du lynx de MacOs.

Cordialement,

M-Anne Moreaux.

 

Tous comptes faits, ce souci d'encodage n’a été identifié que sur certaines URLs et est dû principalement

 à la version Lynx utilisée sur MacOS. Les rendus bizarres, qui pourraient polluer notre corpus DUMP

 concaténé, ont été modifiés à l’aide du rechercher/remplacer de notre éditeur de texte sans problème.