sdx-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE : [sdx-users] Re: UTF-8


From: Martin Sévigny
Subject: RE : [sdx-users] Re: UTF-8
Date: Fri, 19 Jul 2002 08:10:48 +0200

Bonjour,

> Effectivement, il devient impossible de poser une question 
> avec des mots 
> accentués. Le contenu de la boîte de saisie est converti en utf-8 et 
> l'URL est encodée en conséquence. Par exemple l'encodage de 
> "viêt" donne 
> vi%C3%AAt dans la requête.
> 
> En revanche si l'on envoi une requête avec l'encodage vi%EAt tout se 
> passe bien. Est-ce à dire que l'indexation est faite en utf-16?

L'indexation n'est pas en cause ici. Elle est faite à partir de String
Java (encodées en binaire) qui sont, bien sûr, conceptuellement en
Unicode.

> Y a-t-il une solution pour traiter des documents en utf-8 et les 
> interroger de manière correspondante?

Oui, c'est celle que j'ai expliquée la dernière fois. Il faut bien
comprendre la suite des événements. Ce qui est critique, ce sont les
étapes où la chaîne de caractères n'est pas une String Java. Si
lorsqu'elle l'est elle est correcte, il n'y aura pas de problèmes.

En gros, la séquence est celle-ci:

- on saisit une chaîne de caractère dans un formulaire HTML à l'aide
d'un navigateur, par exemple "viêt"
- on clique sur "chercher" (par exemple)
- le navigateur encode les données en "www-url-encoded" pour les envoyer
dans la requête HTTP POST ou encore l'URL pour un HTTP GET (ça ne fait
pas de différence côté serveur)

Je fais une pause ici parce que c'est important. Le navigateur doit à ce
moment "sérialiser" la chaîne de caractères, il n'a pas le choix. De
plus, il n'y a pas de moyen standard et supporté en HTTP pour indiquer
le jeu de caractères de cette sérialisation! Mes investigations m'ont
amené à cette conclusion : les navigateurs sérialisent les données de
formulaire dans le même jeu de caractères que la page HTML où se trouve
le formulaire... Donc si la page est en UTF-8, on aura cinq octets pour
"viêt", si elle est en ISO-8859-1, on aura 4 octets.

- le serveur Web reçoit les données et (dans le cas d'une application
SDX) les passe au moteur de servlets (par exemple Tomcat)

Autre pause : je crois que ce passage se fait correctement, c'est-à-dire
sur une séquence d'octets. Mais je n'ai pas vérifié explicitement.

- le moteur de servlets (par exemple Tomcat) reçoit les informations

Encore une pause : le moteur de servlets est en Java, du moins en
général. Il va donc lire un flux d'octets et puisque l'API des servlets
retourne les paramètres de la requête HTTP sous forme de String, il doit
donc convertir un flux d'octets en String Java, donc en Unicode. C'est
donc le moment critique, car cette interprétation suppose que l'on
connaît le jeu de caractères!

Malheureusement, la spécification des servlets n'indique pas comment
dire au moteur quel encodage utiliser, à supposer que l'on soit capable
de le savoir... Alors que fait Tomcat (je ne sais pas pour les autres)?
Il utilise l'encodage spécifié par la propriété système
java.lang.encoding.

Où est définie cette propriété? Comme toute propriété Java, on peut la
spécifier lors du démarrage de Java, avec un argument tel que
-Djava.lang.encoding=UTF-8. Sinon, je crois que Java 1.3 utilise
l'encodage de la machine, sous Windows c'est ISO-8859-1, sur les Linux
récents en français ça semble être UTF-8 (à vérifier).

Donc si on envoie du HTML en ISO-8859-1 et que l'on a un Java en UTF-8,
on aura toujours des problèmes...

- le reste se passe en SDX donc en Java et à ma connaissance tout va
vien

Conclusion sur cette partie : il faut que les pages HTML soient dans le
même encodage que Java! L'encodage des pages HTML est spécifié dans
webapps/sdx/WEB-INF/cocoon.properties, l'encodage de Java peut être
spécifié dans bin/tomcat.bat ou bin/tomcat.sh.

Ca c'était pour la recherche. Pour l'indexation, SDX obtient les données
depuis un document XML. Un document XML enlève toute ambiguité sur le
jeu de caractères : ou bien il est explicitement mentionné, ou bien
c'est Unicode (UTF-8 ou UTF-16). Si le jeu de caractères spécifié n'est
pas supporté par le parseur, le document ne sera jamais indexé... Une
fois ce document XML obtenu, tout se passe en Java, jusqu'au stockage
dans les index propres à Lucene.

J'ai vu des témoignages de personnes indiquant que Lucene indexait
correctement du chinois et d'autres langues, alors je ne crois pas qu'il
y ait de problèmes de ce côté.

Donc pour répondre au problème de Michel: est-ce que l'encodage des
pages HTML est le même que celui de Java? J'ai fait des installations de
SDX sur Linux où j'ai dû faire cet ajustement, mais une fois fait ça
marchait parfaitement.

En terminant, je voudrais souligner que les explications fournies ici
sont issues à la fois de la lecture de spécifications, de ma propre
interprétation de ces lectures, de quelques recherches sur Internet pour
des problèmes similaires, et de quelques expériences avec Tomcat,
expériences sommes toutes assez limitées. Il y a sûrement des failles
dans l'explication, n'hésitez pas à les souligner.

Par ailleurs, j'ai noté à certains endroits que des personnes ont
proposé des ajustements à Tomcat pour permettre de spécifier l'encodage
des requêtes HTTP reçues. Nous n'avons pas encore étudié ces solutions,
mais si nous les trouvons viables il est prévu de faire en sorte que SDX
2 puisse les exploiter.

A bientôt,

Martin Sévigny




reply via email to

[Prev in Thread] Current Thread [Next in Thread]