Encodage/décodage RESTE du chemin paramètres
Je suis en train d'essayer de trouver la meilleure façon de contourner ce défaut de conception d'application web, je suis d'aider à l'appui. Une partie du service transmet un paramètre ("myparam") à la une .page jsp, qui appelle à son tour un service REST, y compris notre myparam comme un paramètre de chemin d'accès. Le défaut de conception peu, c'est que myparam doit être passé comme un paramètre de formulaire, car il peut être en texte libre. Cependant, nous ne pouvons pas changer la mise en œuvre que d'autres parties sont impliquées à la .jsp fin des choses.
Ma solution a été de coder le myparam à l'aide de codage hexadécimal (le codage d'url à lui seul ne fonctionne pas comme vous jusqu'à la fin avec "%" etc. qui le org.restlet mise en œuvre de REPOS n'aime pas à voir en chemin paramètres). À l'aide de l'Apache bibliothèque de codec, j'ai quelque chose comme ceci:
Option 1 (juste hex):
String decodedParam = new String(Hex.decodeHex(myparam.toCharArray()));qui fonctionne pour nos fins. Ce que je voulais vraiment faire était de combiner URL - et Hex-encodage, afin que je puisse réellement répondre à toutes les posibilités:
Option 2 (hex + adresse url de décodage):
Paramètre préparation:
String workText = URLEncoder.encode(inText, encoding); //a
char[] encodedBytes = Hex.encodeHex(workText.getBytes()); //b
String myparam = new String(encodedBytes);De décodage (REPOS):
String decodedParam = new String(Hex.decodeHex(myparam.toCharArray())); //c
String doubleDecodedParam = URLDecoder.decode(decodedParam, "UTF-8"); //dJ'ai deux questions:
-
pourquoi ne pas la deuxième option travail? (chaque fois que j'essaie et URL-décoder ma chaîne à d), je reçois un java.lang.IllegalArgumentException). J'ai testé le double-codage et décodage de mes valeurs de paramètre au http://ostermiller.org/calc/encode.html sans problème.
-
est-il une meilleure façon de coder chemin de paramètres avec le RESTE?
- 1. Où obtenez-vous l'IllegalArgumentException à? Tout stacktrace? Au moins du point où l'exception est levée?
Vous devez vous connecter pour publier un commentaire.
Il y a un tas de trucs qui ne semble pas tout à fait le droit de me dans le code ci-dessus concernant les jeux de caractères. Dans l'étape de l'encodage vous êtes en supposant que quel que soit le sortilège de classe (qui est le cadre que un?) est de retour octets qui peut être interprété comme une Chaîne de caractères dans l'encodage de votre JVM est en cours d'exécution. Je suppose que cela fonctionne si le contrat de
Hex.encodeHex()prend en charge.Puis il y a l'autre côté. Tout d'abord, vous êtes le décodage de la chaîne hexadécimale de l'utilisation de l'UTF-8. Vous avez en silence supposé que votre JVM est en cours d'exécution en UTF-8, comme vous êtes de passage dans le résultat d'une
new String(), ce qui suppose que les tableaux de char de Hex.decodeHex() sont dans l'encodage de la JVM est en cours d'exécution, qui ne peut être en UTF-8 si vous êtes le décodage en tant que tel. Aussi, je ne vois pas l'intérêt de l'encodage d'URL y passe. Il semble que c'est complètement superflu.Je suppose que rien de cela n'est vraiment au cœur du problème. Il y a un autre problème de ce qui se passe réellement dans l'intermédiaire JSP. Il est probable décode ce qu'il obtient et re-encode. Qui devrait être transparent, mais je ne suis pas sûr à quel niveau vous êtes à la prise de ce type de données. Si vous le voyez avant d'être décodé comme un paramètre d'une mauvaise interprétation qui pourraient en résulter.