Codage/décodage des paramètres du chemin REST

Question

J'essaie de trouver le meilleur moyen de contourner une faille de conception dans une application Web que j'aide. Une partie du service passe un paramètre ("myparam") à une page .jsp, qui à son tour appelle un service REST incluant notre myparam comme paramètre de chemin. Le bit de défaut de conception est que myparam doit être passé en tant que paramètre de formulaire, car il peut s'agir de texte libre. Cependant, nous ne pouvons pas modifier la mise en œuvre car d'autres parties sont impliquées dans l'extension .jsp. Ma solution était de coder le myparam en utilisant le codage hexadécimal (le codage d'URL seul ne fonctionne pas car vous finissez par "%" etc. que l'implémentation org.restlet de REST n'aime pas voir dans les paramètres de chemin). Utilisation de la bibliothèque Apache codec, j'ai quelque chose comme ceci:

Option 1 (juste hex):

String decodedParam = new String(Hex.decodeHex(myparam.toCharArray())); 

qui fonctionne pour nos besoins. Ce que je voulais vraiment faire était de combiner URL- et Hex-encodage, pour que je puisse vraiment couvrir tous les posibilités:

Option 2 (hex + url-décodage):

Préparation des paramètres:

String workText = URLEncoder.encode(inText, encoding); // a 
char[] encodedBytes = Hex.encodeHex(workText.getBytes()); // b 
String myparam = new String(encodedBytes); 

décodage (REST):

String decodedParam = new String(Hex.decodeHex(myparam.toCharArray())); // c 
String doubleDecodedParam = URLDecoder.decode(decodedParam, "UTF-8"); // d 

J'ai deux questions:

1. Pourquoi la deuxième option ne fonctionne-t-elle pas? (à chaque fois que j'essaie de décoder ma chaîne en d), j'obtiens une exception java.lang.IllegalArgumentException). J'ai testé le double encodage et décodage de mes valeurs de paramètres à http://ostermiller.org/calc/encode.html sans problème.

2. Y at-il un meilleur moyen de coder les paramètres de chemin avec REST?

Answer 1

Il y a un tas de choses qui ne me semblent pas très justes dans le code ci-dessus concernant les jeux de caractères. Dans l'étape de l'encodage, vous supposez que quelle que soit la classe Hex (quelle structure est celle de?) Renvoie des octets qui peuvent être interprétés comme une chaîne dans l'encodage dans lequel votre JVM s'exécute. Je suppose que cela fonctionne si le contrat est Hex.encodeHex() le soutient.

Ensuite, il y a l'autre côté. Tout d'abord, vous décodez la chaîne hexadécimale en utilisant UTF-8. Vous avez supposé silencieusement que votre JVM s'exécutait en UTF-8, car vous passez le résultat d'un new String(), ce qui suppose que les tableaux char de Hex.decodeHex() sont dans le codage sur lequel la JVM est actuellement exécutée, ne peut être UTF-8 que si vous le décodez comme tel. Je ne vois pas non plus le but de cet encodage d'URL. Il semble que c'est complètement redondant. Je suppose que rien de tout cela n'est vraiment le problème principal. Il y a un autre problème de ce qui se passe exactement dans la JSP intermédiaire. Il décode probablement tout ce qu'il obtient et le ré-encode. Cela devrait être transparent, mais je ne suis pas certain du niveau que vous prenez dans ces données. Si vous le voyez avant qu'il ne soit décodé en tant que paramètre, une mauvaise interprétation pourrait en résulter.