Décidemment, je crois que je ne m'en sortirai jamais avec ces histoires d'encodage et décodage d'URL. Pour ceux qui prennent le sujet en cours de route, petit rappel chronologique :
Quel est le problème cette fois-ci, me demanderiez-vous ? Et bien observez l'extrait de code publié dans ce billet, rapprochez le de cet autre récent billet évoquant la limite de taille des chaînes de caractères dans une formule, et je vous laisse deviner la suite : un texte à décoder trop volumineux amène à un lamentable croûtage de l'Evaluate(). Voilà qui est bien fâcheux. Alors, comment gérer ce type de situation, sachant qu'il n'existe pas de méthode native en LS pour décoder des URLs et que l'utilisation des formules est à proscrire ?
Pour peu que l'on recherche sur le net, on peut trouver des fonctions LS de décodage des URL développées par des tiers : chez Mike Golding, ou encore chez Johan Känngård par exemple. Malheureusement, lors des différents tests que j'ai pû mener, les caractères spéciaux étaient mal restitués, pour des raisons que je n'ai pas vraiment réussi à élucider mais manifestement liées au fait que la tâche HTTP de Domino sert et reçoit (dans ma configuration) les pages en UTF-8 et que, à en croire la documentation, le jeu de caractères natif de l'environnement Domino est celui de la plateforme sur laquelle il s'exécute (dans mon cas Windows 2000), soit selon toutes vraissemblances l'ISO-8859-1 (en tout cas, pas l'UTF-8). Quoi qu'il en soit, même si ce point reste obscur (et ma déduction probablement bancale), il semble clair que le problème est lié à l'encodage des caractères, et on peut en conclure sans crainte qu'il manque un paramètre à toutes ces fonctions de décodage des URL : le jeu de caractères considéré.
Les recherches du coté de LotusScript n'ayant pas donné grand chose de concluant, tournons nous vers Java. Premier réflexe : jeter un coup d'oeil aux spécifications de l'API. Chouette, se dit-on après quelques recherches, Java possède une classe de décodage d'URL : java.net.URLDecoder, et même qu'on peut spécifier le jeu de caractères !
La joie est toutefois de courte durée, puisqu'on s'aperçoit (plus ou moins) rapidement que ce paramètre a été introduit dans la version 1.4 de Java et que la version précédente en est démunie. Or, avec Domino 6.x, c'est bien une JVM 1.3 qui est embarquée. Aussi, à moins d'utiliser un serveur Domino 7 - ce qui n'est pas mon cas - on est de nouveau coincé.
C'est finalement chez Apache que nous trouverons notre salut, du coté du projet Jakarta Commons, avec l'ensemble de composants Commons Codec et plus précisément la classe URLCodec qui - miracle - permet de spécifier un jeu de caractères.
Pour utiliser cette librairie avec Domino, deux solutions : soit dans un agent Java, soit dans un agent LotusScript via LS2J. J'ai opté pour la seconde solution car mon agent LS devant réaliser le décodage était déjà écrit et utilisait tout un tas d'autres bibliothèques LS que je n'avais pas forcément envie de porter en Java. Mais rien ne vous empêche choisir la première.
Pour une solution LS2J, la première étape consiste à mettre au point une librairie de scripts interfaçant cette librairie, que l'on va s'empresser de créer en l'intitulant "URLDecoder" et en y incluant le fichier commons-codec-1.3.jar (téléchargeable ici).
Inclusion de la librairie Commons Codec dans la librairie de scripts URLDecoder
Puis on y insère le code suivant :
import org.apache.commons.codec.net.URLCodec;
public class URLDecoder {
public static String decode(String s) {
try {
URLCodec codec = new URLCodec("UTF-8") ; // selon la plateforme
return codec.decode(s) ;
}
catch (org.apache.commons.codec.DecoderException e) {
return "URLDecoder error : "+e.getMessage();
}
}
}
L'interface Java étant créée, on peut maintenant l'utiliser très naturellement dans nos agents LotusScript via des appels LS2J :
Uselsx "*javacon"
Dim jSession As JavaSession
Dim urlDecoder As JavaClass
Dim decodedString as String
Set jSession = New JavaSession()
Set urlDecoder = jSession.GetClass("URLDecoder")
decodedString = urlDecoder.decode("la chaîne encodée")
Et voilà. Avec cette méthode, les chaînes de caractères sont proprement décodées, les caractères spéciaux correctement restitués, et ce sans limite de taille (puisque c'était là notre problème, pour rappel). Est-ce à utiliser systématiquement pour autant ? Non, car les temps d'exécution sont nettement plus longs qu'avec une méthode basée sur les formules. Toutefois, quand vous ne maîtrisez pas la longueur de la chaîne que vous devez décoder, cette solution peut vous sauver la mise.
Et j'espère ne plus jamais avoir à revenir sur ce sujet.
