EVALUATION DU PROJET

Nous estimons à une cinquantaine d'heures de travail le temps de réalisation de ce projet, compte tenu du partage des tâches entre les membres du groupe. La répartition de ce temps travaillé sur le semestre a été principalement concentré au moment des problèmes de conversion d'encodages et de réalisation du site. Nous dirions donc que le gros des efforts a été fourni dans le dernier tiers du projet. En particulier pour les personnes n'étant pas familières avec l'écriture de pages html, peut-être aurait-il été judicieux d'occuper le début du projet avec une première ébauche de site.

Grâce au découpage et à l'avancée progressive dans l'écriture du script, nous sommes arrivés à un résultat qui, au début du semestre, nous apparaissait bien ambitieux. Cependant, nous nous sommes aperçus, après plusieurs exécutions du script que les résultats obtenus n'étaient pas toujours consistants. En particulier, notre script nous permettait de rentrer à la main l'encodage d'une page aspirée lorsque celui-ci n'avait pas été repéré automatiquement et nous avons remarqué que les pages pour lesquelles cette information était demandée différaient d'une exécution à l'autre, pour des raisons que nous n'avons pas réussi à élucider. De plus, le temps d'aspiration des pages pouvait être particulièrement long voire l'aspiration pouvait échouer ce qui obligeait alors à relancer l'exécution depuis le début.

Nous avons rencontré des difficultés liées à la non portabilité des scripts d'un système d'exploitation à l'autre (Mac, Linux et Windows) puisque chaque membre du groupe utilisait un système différent.

Le bash permet d'automatiser relativement simplement des tâches une fois les notions de chemin relatif, de variables et de boucles comprises et la syntaxe que requiert le système qu'on utilise acquise. Mais comme ce langage offre un énorme éventail de commandes assorties d'options, il est souvent nécessaire de passer du temps à consulter les manuels. Nous nous sommes également rendu compte que certaines commandes (file, curl) ne fournissait pas de résultats fiables.

DIFFICULTE RENCONTREE : L'ENCODAGE DES CARACTERES

De part le choix de nos langues (arabe, chinois, coréen), nous avons été particulièrement sensibilisés au problème d'encodage des caractères, sujet dont nous avons amplement entendu parler pendant le semestre au cours de Gestion informatique du multilinguisme.

Au vu des nombreuses embûches liées à ces problèmes d'encodage et que nous avons rencontrées durant le projet, il nous a semblé utile de faire une synthèse des connaissances à avoir sur le sujet et de proposer des solutions ou du moins des pistes de réflexion.

Ce qu'il faut garder en mémoire, c'est que la visualisation d'un fichier repose sur une interprétation de la suite d'octets contenus dans ce fichier.

Avant Unicode, la correspondance entre caractère et information binaire se faisait principalement à l'aide des tables 8 bits qui à un caractère associait une valeur comprise entre 0 et 255. Il existe une multitude de ces tables qui ont été élaborées au gré des besoins des utilisateurs ou bien en fonction des rivalités culturelles et politiques. Ainsi la famille des codes normalisée sous le nom d'ISO-8859 permettent de coder les langues latines, le grec, le cyrillique, l'arabe, l'hébreu, etc.

Dans le cas du coréen et du chinois, il s'agit de tables 16 bits ou de longueur variable (ex: EUC-KR pour le coréen, GB2312 pour le chinois).

Avec le développement d'internet et besoin grandissant d'échange d'information, il est apparu nécessaire de pouvoir traiter et visualiser sans ambigüité les caractères de l'ensemble des langues du monde entier. C'est dans ce contexte que le consortium Unicode a développé son projet de standard UNICODE ayant pour but de constituer un catalogue exhaustif des caractères de tous les systèmes d'écriture textuelle du monde.

Unicode entend par caractère l'association d'un code (en anglais code point) et d'un nom (ex: latin capital letter I with dot above) mais ne définit aucun glyphe.
Nous ne donnerons pas plus de détail sur le sujet mais tout le cours sur Unicode est accessible dans le lien suivant: Cours sur Unicode de Jean-François Perrot

Avant Unicode, le jeu de caractères codés (en anglais character set) pouvait se confondre avec la forme de codage des caractères, c'est-à-dire leur représentation en mémoire (en anglais encoding) puisqu'il y avait correspondance directe entre le code du caractère (un entier représenté en base 8, 10 ou 16) et sa représentation en binaire sur un octet.

C'est seulement à partir de la création d'Unicode que ces termes vont rendre compte de deux réalités bien distinctes. D'une part le jeu de caractères avec leurs points de code et de l'autre les codages (UTF-8, 16 ou 32) correspondant au format de représentation des points de code (ex: le point de code du caractère £ est 163 en décimal, U+00A3 en hexadécimal et son codage en UTF-8 est 0xC2A3 qui diffère bien du point de code)

Il est fortement conseillé d'utiliser UTF-8 qui est un format de taille variable (entre 1 et 4 octets) et qui permet donc de coder les caractères au-delà de 16 bits (avantage par rapport à UTF-16) en restant économique en place (avantage par rapport à UTF-32).

Cependant l'utilisation d'UNICODE sur le web est loin d'avoir atteint le degré d'uniformisation souhaitée et dans le cadre de notre projet qui nécessitait la concaténation de pages html aux encodages hétérogènes, l'étape de conversion de ces pages en UTF-8 était indispensable mais a soulevé de nombreux problèmes.

On pourrait penser que cette tâche est simple à réaliser puisqu'il existe une commande shell, iconv, qui permet de convertir un fichier d'un encodage source vers un encodage cible. Mais il est nécessaire de fournir explicitement à la commande l'encodage source.

Les difficultés sont apparues au niveau de l'identification automatique de cet encodage.

La commande shell file avec l'option -i (ou -I sur Mac) prend en argument le nom d'un fichier et renvoie son encodage mais nous avons constaté que cette commande, pour des raisons qui nous sont inconnues, ne fournit pas toujours l'information correcte.

"Unknow-8bit" : une erreur fréquente pour la commande file.

Exemple d'une page en arabe (arabe5.html) encodée en windows-1256 (ce qu'indique le code source) mais dont file trouve comme en encodage iso-8859-1 (iso latin 1) !

D'autre part, une page html bien écrite devrait contenir dans une balise meta l'information relative à l'encodage. Celle-ci se trouve généralement au niveau de l'attribut charset, lorsqu'elle est dans une balise meta, ou encoding, lorsqu'elle figure au tout début du document sous forme de déclaration XML (on peut constater ici la confusion terminologique décrite ci-dessus). Ainsi nous avons tenté de filtrer cette information à l'aide de la commande egrep et de la liste des encodages attendus. Seulement, il est arrivé que cette information ne figure pas dans le code source de la page ou bien qu'elle soit erronée (charset annoncé différent de celui effectivement utilisé). Dans ce cas, il est possible de s'aider de l'information que donne le navigateur sur l'encodage qu'il a détecté mais là non plus, la détection n'est pas fiable à 100%.

En résumé, nous pouvons donner quelques règles utiles à garder en mémoire lorsque l'on a à faire à ces problèmes d'encodage:

- utiliser UTF-8 permet d'avoir le jeu le plus large possible de caractères et permet donc de mélanger les langues dans un même document sans problème de rendu.

- "l'encodage se produit au moment d'enregistrer le fichier" (W3C Québec). Pour être correcte, la déclaration, par exemple d'une page html, doit correspondre à celle qui a réellement été utilisée dans l'éditeur de texte qui a servi à la saisie du code source.
- "il ne suffit pas de changer la déclaration d'encodage pour qu'un changement d'encodage se produise."(W3C Québec)

- "les éditeurs de texte ne sont pas également fiables en matière d'encodage et de changement d'encodage."(W3C Québec). Pour les éditeurs de texte basiques tels que Bloc Notes ou TextEdit l'information encodage d'un fichier n'est pas directement accessible. De plus lorsque l'on écrit du code html dans ces éditeurs, l'indication d'encodage fournie en en-tête ou dans la balise meta n'est pas vérifiée par l'éditeur et peut donc différer de l'encodage réellement utilisé par le programmeur lors de la saisie si celui-ci n'y a pas porté attention.