Difficultés
Problème relatif au système d'exploitation
Au début du semestre, lorsque j'ai du choisir de quelle manière j'allais utiliser Unix chez moi, j'ai commencé par me tourner vers une solution qui me paraissait simple et peu risquée : j'ai créée une clé USB bootable (avec Linux Live) qui me permettait de démarrer mes machines sous Linux. Cela s'est révélé être une fausse bonne idée, car le fonctionnement était assez lent, avec une tendance au "freeze" assez prononcée. Je m'en accomodais jusqu'au freeze de trop où mon ordinateur n'a plus répondu du tout ! J'ai alors forcé l'extinction, et ce fut le drame. La clé a été endommagée et surtout, je ne sais comment, l'OS d'origine de ma machine (Windows Vista) était devenu introuvable au démarrage. Pour une solution que j'avais lue "sûre"...Heureusement, l'ordinateur en question ne risquait pas grand chose, je l'avais préalablement vidé de son contenu. J'en ai alors pris mon parti et j'ai installé Linux pour de bon. Je n'ai plus rencontré aucun problème !
Moralité : ce vieil ordinateur qui trainait chez moi et que je n'utilisais plus depuis longtemps à cause de sa lenteur est maintenant mon outil de travail préféré.
Problème relatif à la commande curl
Concernant l'aspiration des pages, nous avions le choix entre deux commandes, wget et curl, avec d'emblée une mise en garde : curl fonctionnerait bien mieux que wget. Je n'ai pas tardé à le constater par moi même, et j'ai donc choisi d'intégrer curl à mon script. Les premiers tests ont été concluants, les pages s'aspiraient correctement. J'ai ensuite ajouté diverses options en plus de -o (permettant l'écriture du flux de sortie dans un fichier), pour suivre les liens de la page par exemple. Ce n'est que bien plus tard, vers la fin du semestre, que j'ai constaté un problème assez grave : en inversant l'ordre d'aspiration de mes fichiers d'URL, les langues se mélangeaient dans les tableaux. Pour un lien en anglais, la page aspirée correspondante était en français par exemple. J'ai eu du mal à comprendre le souci mais j'ai fini par mettre le doigt dessus : pour une raison que j'ignore, lorsque je mets plus d'une option à une commande, cela l'empêche de s'exécuter. J'ai essayé de les écrire séparément (-e -L -o) ou ensemble (-eLo), rien n'y a fait. C'est ainsi que depuis des semaines je travaillais sur les pages aspirées au tout début du projet... J'en ai retenu une bonne leçon : avant d'éxécuter le script, toujours vider les dossiers dans lesquels on s'apprête à créer des fichiers. On est ainsi certain que les fichiers présents après l'éxécution sont bien ceux qui viennent d'être créés.De l'intérêt de la commande echo
Dans l'effervescence de ma découverte de la programmation, j'ai pris la mauvaise habitude d'exécuter le script d'une seule traite et de voir les erreurs dans les tableaux générés. C'est une très mauvaise idée. Voir le résultat en html permet certes de cerner les problèmes mais pas d'en identifier les causes. C'est ainsi qu'à la mi-semestre j'ai découvert que l'une de mes conditions était mal formulée, ce qui faisait que le traitement s'en échappait constamment alors qu'il aurait du y entrer. C'est grâce à l'ajout d'une commande echo, associée à un read que j'ai pu le constater. Dans ce cas précis, echo fait apparaître en sortie standard que iconv ne reconnait pas l'encodage, et read permet de demander au script d'attendre une réponse de l'utilisateur avant de poursuivre l'exécution.Le cas Wikipedia
Dans ma recherche initiale d'URL, j'ai sélectionné à plusieurs reprises, dans les trois langues, des adresses d'articles issus de Wikipedia.
Ces articles se sont révélés poser des problèmes assez étranges
En effet, malgré le fait que les pages de Wikipédia soient, semble-t-il, encodées "correctement" (c'est à dire en UTF-8) et s'aspirent sans problème je n'ai pas réussi à obtenir de dump-texts exploitables. Ce problème s'est retrouvé dans les autres groupes qui utilisaient des URL issues de Wikipedia.
J'ai choisi d'illustrer ce problème à travers des captures d'écran des différents stades de traitement.
Captures des pages d'origines :
Les pages aspirées ne posent pas de problèmes comme on peut le voir ici :
Et c'est au niveau des dumps que les ennuis commencent :
Capture des codes sources des pages Wikipedia (où l'on constate que la page est bien encodée en UTF-8) :
J'ai donc noté que contrairement au japonais et au français, les pages en anglais ne posaient pas de problème. Cela m'a intrigué, et dans la mesure du temps qu'il me restait pour achever le projet, j'ai décidé de réinvestir mon script de travail dans une "enquête complémentaire" portant sur Wikipédia.
J'ai sélectionné un sujet (tout à fait au hasard, les Monty Python) à propos duquel je pourrais trouver des articles dans suffisamment de langues différentes.
J'ai modifié le script pour ne retenir que les étapes d'aspiration et de dump des pages, puis j'ai choisi une dizaine de langues utilisant des systèmes d'écritures différents. Parmi celles-ci, j'ai choisi le néerlandais : en effet, comme l'anglais, c'est une langue n'utilisant pas (ou peu) de signes diacritiques, elle s'écrit donc
principalement grâce aux caractères ASCII.
Voici le résultat, un nouveau tableau :
| Tableau de liens Wikipédia | ||||||
| URL | PAGES ASPIREES | RETOUR CURL | DUMP | CODAGE | DUMP CONVERTI | |
| ALLEMAND | PAGE ASPIREE1 | 0 | DUMP-TEXT | utf-8 | - | |
| ANGLAIS | PAGE ASPIREE2 | 0 | DUMP-TEXT | utf-8 | - | |
| COREEN | PAGE ASPIREE3 | 0 | DUMP-TEXT | utf-8 | - | |
| ESPAGNOL | PAGE ASPIREE4 | 0 | DUMP-TEXT | utf-8 | - | |
| FRANCAIS | PAGE ASPIREE5 | 0 | DUMP-TEXT | utf-8 | - | |
| JAPONAIS | PAGE ASPIREE6 | 0 | DUMP-TEXT | utf-8 | - | |
| NEERLANDAIS | PAGE ASPIREE7 | 0 | DUMP-TEXT | utf-8 | - | |
| RUSSE | PAGE ASPIREE8 | 0 | DUMP-TEXT | utf-8 | - | |
| TCHEQUE | PAGE ASPIREE9 | 0 | DUMP-TEXT | utf-8 | - | |