Tableau cinquième version

Dernière étape avant l’analyse linguistique : l’extraction de notre mot-clé avec ses contextes.

Nos mots-clés dans les langues de notre corpus :

• en français : nucléaire

• en anglais : nuclear power

• en japonais : 原発

Au préalable, il faut télécharger le programme minigrepmultilingue qui va pouvoir traiter les motifs écrits dans n’importe quelle langue en Unicode.

Pour pouvoir utiliser le minigrep, nous vous conseillons la lecture de cette page.

/!\Attention : lors de l’exécution des commandes make, il est vivement recommandé d’être placé dans l’arborescence du disque local et non sur une clé USB par exemple. Cela vous évitera une perte de temps et de changer 4 fois d’ordinateur (retenir : le problème ne vient jamais de l’ordinateur !).

Une fois l’installation effectuée, il faut inclure quelques lignes de code dans notre script :

perl minigrep/minigrepmultilingue.pl « codage » « le chemin relatif vers le fichier dans lequel on va chercher le motif » « chemin relatif vers fichier contenant le motif recherché » « chemin relatif vers le fichier-cible-contexte »

Ensuite nous souhaitons créer des fichiers qui vont contenir, pour chaque langue, l’ensemble des contextes : fichiers globaux contextes. Et la même chose pour les fichiers dump en UTF-8.
Pour cela, nous avons utilisé la commande cat:

• cat ../DUMP-TEXT/dumputf8/$langue/dump$ligne.txt >> ../DUMP-TEXT/dumpGlobalUTF8_$langue.txt;

• cat ../CONTEXTES/CONTEXTE_UTF8/$langue/contexte$ligne.txt >> ../CONTEXTES/contexteGlobalUTF8_$langue.txt

Puis nous avons créé deux variables nbreD et nbreC pour compter le nombre de fichiers concaténés dans chaque fichier global.

Résolutions d’anciens problèmes et amélioration du script :
Dans ce script nous avons dû intégrer des lignes de code pour traiter quelques problèmes particuliers :

• page française numéro 2 après Fukushima :

La page a été mal encodée lors de sa création. Nous avons l’impression que le texte utilise à différents endroits des encodages différents. Nous avons détecté ce problème lors de l’utilisation du Trameur (article à venir). Il nous affiche un message d’erreur. Un caractère n’est pas correctement codé en UTF8. Après une recherche sur les octets via la commande « hexdump -C » pour voir où se situait le problème, nous avons constaté qu’effectivement, il y a des caractères accentués dont les octets correspondants (représentés en hexadécimal) ne correspondent pas au codage UTF8. Nous avons noté la présence d’octets indésirables entre les deux octets pour l’UTF8 (c3 et a9 pour le caractère « é » par exemple, étaient entrecoupés de deux octets supplémentaires). Nous avons également noté que certains caractères étaient encodés en latin-1.

La page est donc inutilisable pour l’analyse. Nous avons fait en sorte que le script n’intègre pas cette page dans les fichiers globaux. (cf le script, voir les sections « traitement particulier »)

•  forcer la conversion :

Après la réussite de la conversion en UTF8, certaines pages n’étaient pas complètes. En effet, lors de la conversion on obtenait un message qui indiquait une « séquence d’échappement impossible à la position x ». X désignant l’indice de la chaîne de caractères qui contient le texte de la page. Pour régler ce problème, nous avons ajouté l’option « -c » qui permet de forcer la conversion lorsqu’il y a problème.

• page japonaise numéro 25 avant Fukushima :

L’URL 25 est encodée en UTF16LE mais cet encodage n’est pas traitable par la commande « lynx -display-charset=… » donc le dump donnait un mauvais affichage pour la conversion en UTF8. Pour résoudre ce problème nous avons utilisé l’option « -assume_charset » pour cette page.

Conseil : Avant de lancer votre programme, supprimer tous les fichiers qui vont être créés par ce même programme. Nous avons rencontré des problèmes dans certains de nos fichiers globaux simplement car nos dossiers étaient très « encombrés » (c’était le bazar!!).

C’est parti !

Notre script

Extrait du tableau