我在使用 UrlEncoder 和 UrlDecoder 时遇到问题。
它看起来像这样: token 示例:
3vv3XIvofg3KIoMjLwU07329C6dsk8HJceuDT2F5jOwox2hyqAnL+03TPej/lW4TCeFWRadRkPKgW0aGxq+9B1VZLMvoevyFfaVXhvzIyLF8AN3NDCqk0hoqb51wlGtb4hUvOYKq5b63wuW2pfssr9O0dgCEK4VZz8QZ4jRpxZw=
我在 Spring 应用程序中为客户设置了 token 。然后我对 token 进行编码以在 url 中使用它:
String token = // generated by mechanism
String encodedToken = UrlEncoder.encode(token, "UTF-8");
String url = "https://myapp.url?token=" + encodedToken;
我收到@RequestParam 形式的 token 。然后通过UrlDecoder对token进行解码
String decodedToken = UrlDecoder.decode(token, "UTF-8");
问题如下: 有时它工作正常,我能够通过 token 找到用户,但有时我会出错,因为解码的 token 无效,并且它看起来与 token 不同。问题是什么?这很奇怪,因为有时有效,有时无效
最佳答案
由于 @RequestParam
注释,您的 token 已被 Spring 解码。
如果 token 包含 +
,则第二次解码会将 +
替换为 (空格)。
我假设您正在使用 java.net.URLEncoder
和 java.net.URLDecoder
?正如 encode(String, String)
和 decode(String, String)
方法的 Javadoc 所描述的,它们对 application/x-www 进行编码和解码-form-urlencoded
格式。在此格式中,+
是替换空格的特殊字符。
因此,+
将en编码为%2B
,de编码为。因为 Spring 已经处理了解码,所以
%2B
将再次成为 +
。您的第二次解码会将其转换为 并且 token 将不再匹配。
关于java - token 编码/解码问题 - Spring,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/58087117/