Samedi 7 janvier 2012
6
07
/01
/Jan
/2012
20:24
CACOGRAPHIE n. f. XVIe siècle. Composé de caco- et de graphie.
Litt. Mauvaise écriture ; mauvais style ou orthographe fautive.
(Dictionnaire de l'Académie Française, neuvième édition)
Le script tel qu'il a été présenté dans le billet précédent posait problème car certaines étapes étaient manquantes ou dans un ordre incorrect, si bien que les pages web qui n'étaient pas en
UTF-8 mais dont l'encodage était détecté par file -i étaient traitées comme si l'encodage était inconnu de iconv. Le script allait alors chercher l'encodage
directement dans les métadonnées des pages web, parfois sans résultat (d'où l'apparition de cases "Encodage non détecté" dans les tableaux précédents).
Il nous a fallu du temps pour repérer l'erreur et la corriger. Nous avons tenté de réécrire tout le script à partir de zéro, mais cela a créé plus de problèmes qu'il n'en a réglé, c'est pourquoi
nous nous sommes efforcés de corriger le script existant. Nous en avons profité pour réorganiser les commentaires et la présentation du script, qui était devenu difficilement lisible pour un être
humain.
Au final, nous avons perdu du temps (presque un mois sans nouveau billet sur le blog) mais nous comprenons à présent mieux l'organisation du script et l'ordre des tâches à programmer.
Voici donc le script corrigé :
(cliquer sur les vignettes pour agrandir les images)
Nous avons également peaufiné l'affichage des données dans le Terminal :
(idem)
Malheureusement, nous n'avons toujours pas pu résoudre le problème qui fait s'afficher le message [: 202: Illegal number: Bad request quand egrep détecte un Bad request dans une
page web. Cela ne semble pas empêcher le bon fonctionnement du programme, mais le Terminal semble détecter une erreur.
Voilà le tableau obtenu après exécution du script :
(idem)
Remarques : Il n'y a plus aucune cellule indiquant "Encodage non détecté".
L'URL numéro 21 du premier tableau a fait l'objet d'un dump texte initial avant conversion en UTF-8, alors même que sa cellule Dump-texte indique qu'il s'agissait d'UTF-8. Après vérification dans
l'historique du Terminal et vérification manuelle avec file -i, nous nous sommes aperçus que file -i détectait l'encodage de la page comme
"unknown-8bit" (d'où nécessité d'aller chercher le charset dans le code source de la page web).
Il y a maintenant un problème d'encodage avec les URLs en russe, problème que nous avons détecté dès la rédaction du billet précédent, mais que nous avons remis à plus tard à cause des problèmes
inhérents au script.
Comme les captures du tableau l'indiquent, la totalité des pages aspirées en russe (troisième et dernier tableau) ont été détectées par file -i comme de l'ISO 8859-1.
Or :
- Firefox a indentifié l'encodage comme étant du windows-1251 (et comme il a affiché les pages sans aucune anomalie visible, on présume qu'il avait raison), cf. image ci-dessous
- Le charset ISO 8859-1 ne permet d'afficher que des caractères latins (pour l'alphabet cyrillique, il s'agit de l'ISO 8859-5).
Par conséquent, le dump texte ne s'est pas effectué comme attendu, et le résultat pour nos URLs en russe est illisible. Voici comment s'affiche le dump initial de la première URL du troisième
tableau, dans un éditeur de texte et dans Firefox avec réglage par défaut (il interprète ce qu'il lit comme de l'ISO 8859-1 et se trompe, fatalement)
En changeant manuellement l'interprétation du fichier par Firefox (en choisissant Cyrillic (Windows-1251)), on retrouve un texte lisible :
En revanche, après conversion de ce dump imparfait vers un fichier texte en UTF-8, rien ne va plus. Le texte est devenu complètement illisible, quelle que soit l'interprétation choisie sous
Firefox.
Si nous ne pouvons pas régler ce problème, nous craignons de devoir nous passer complètement des pages en russe pour notre projet, ce qui serait dommage.
Prochaine étape : l'extraction des contextes !
