Je parlais il y a un peu plus d'un an de l'encodage des URL déficient de Domino. Jusqu'à peu, j'étais convaincu que le décodage des URL ne posait pour sa part aucun problème. J'avais tort.

Le premier point n'est pas tant un problème d'implémentation que de standard (à défaut de meilleur terme). En effet, le RFC 1738 décrit la façon dont les caractères spéciaux doivent être encodés. En outre, les espaces sont représentés par %20, ce que la formule @URLDecode gère correctement. Toutefois, et comme indiqué dans la spec HTML 4.01, dans le cas d'un formulaire web soumis avec le type de contenu application/x-www-form-urlencoded, toutes les données sont encodées selon ledit RFC sauf les espaces, qui sont quant à eux représentés par des signes +, et ce pour d'obscures raisons historiques que je ne souhaite pas connaître (c'est là la différence entre urldecode() et rawurldecode() en PHP). Aussi, lorsque vous êtes menés à décoder dans un agent LS du contenu soumis par un formulaire web de ce type, il ne faudra pas oublier de remplacer préalablement les signes + par des espaces :

Evaluate(|@URLDecode({Domino} ; {|+Replace( parse( contextDoc.Request_Content(0), "mon-paramètre"), "+", " ")+|})|)

Le second point est plus problématique, et inhérent au moteur même de Domino. Lorsqu'on soumet, toujours via un formulaire web, des données comprenant des retours à la ligne (par exemple du texte saisi depuis un textarea), ces caractères ne sont a priori pas décodés de la même façon selon que cette opération soit réalisée nativement par Domino (enregistrement classique de formulaire) ou par la fonction @URLDecode. En effet, les retours à la ligne (\r\n sous DOS et Windows) sont encodés selon la méthode décrite ci-dessus (soit %0D%0A), transmis, puis décodés coté serveur. Vient alors 2 possibilités : un décodage par @URLDecode retournera \r\n alors qu'un décodage natif par Domino retournera \r uniquement ! Où est passé le \n ? (non, pas DMC).

En vérité, je ne sais pas si cette issue est réellement liée au décodage natif de Domino, ou bien à la façon dont il stocke et restitue les retours à la ligne, mais les faits sont là : si on récupère les données dans un agent au WQS, les \n auront disparu. Alors que si on récupère les données directement dans un agent (avec décodage manuel du contenu de la requête (champ CGI Request_Content)), on retrouve bien les \r\n. Au fond, tout ça, dans la grande majorité des cas on s'en fout un peu puisque les données sont correctement restituées à l'affichage, mais dans certaines situations ça peut être particulièrement bloquant. Lorsqu'on joue avec les expressions rationnelles, par exemple (les \r n'étant pas matchés comme des retours à la ligne). Information assez dispensable donc, mais à garder dans un coin de la tête quand même ; ça pourrait vous épargner quelques heures de lutte.