Notez que j'étais accro aux spécifications de WebTarget.queryParam () de JAX-RS Client.
Cliquez ici pour les spécifications de WebTarget.queryParam () (https://docs.oracle.com/javaee/7/api/javax/ws/rs/client/WebTarget.html#queryParam-java.lang.String-java. lang.Object ...-). C'est une méthode pour définir les paramètres de requête pour WebTarget.
Il y a une mise en garde concernant cette méthode et le codage URI.
Le modèle URI est une fonction qui insère le paramètre de chemin dans la partie entourée de {}, mais si vous y réfléchissez, il y a un léger problème. Le problème est que la valeur du paramètre de requête ne peut pas contenir "{" ou "}" lui-même. En effet, "{" et "}" sont tous deux interprétés comme des paramètres de chemin.
Pour éviter cela, "{" et "}" doivent être encodés en URI. Cela signifie qu'il devrait être% 7b et% 7d, respectivement.
Cependant, dans les implémentations telles que Jersey et RESTEasy, cette méthode effectue le codage URI comme décrit ci-dessus, donc s'il est à nouveau codé URI tel quel, il doit être converti en% 257b et% 257d. En d'autres termes, si vous ne pouvez pas utiliser {ou}, ...?
L'implémentation de Jersey évite le double encodage URI pour éviter cela. Plus précisément, la règle est que% n'est pas codé s'il y a deux caractères hexadécimaux consécutifs (0-9a-fA-F) après%. Il est donc normal d'encoder {,} tel quel.
Inversement, si vous avez deux caractères hexadécimaux consécutifs après%,% ne sera pas encodé en URL.
Par conséquent, il est préférable de ** toujours vous encoder vous-même l'URI avant d'appeler queryParam () **.
Je ne sais pas ce que font les autres implémentations. À première vue sur le code RESTEasy, il semble que% n'ait pas du tout été encodé.
Bien entendu, le comportement ci-dessus ne peut pas être lu à partir des spécifications JAX-RS (en fonction de l'implémentation). Alors vérifions le fonctionnement avant de l'utiliser.
Recommended Posts