java 编码/解码 REST 路径参数
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/1485812/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Encoding/decoding REST path parameters
提问by davek
I am trying to find the best way of getting round a design flaw in a web app I'm helping to support. One part of the service passes a parameter ("myparam") to a .jsp page, which in turn calls a REST service including our myparam as a path parameter. The design flaw bit is that myparam should be passed as a form parameter, since it can be free text. However, we cannot change the implementation as other parties are involved at the .jsp end of things.
我正在努力寻找解决我正在帮助支持的 Web 应用程序中的设计缺陷的最佳方法。服务的一部分将参数（“myparam”）传递到 .jsp 页面，该页面又调用 REST 服务，包括我们的 myparam 作为路径参数。设计缺陷是 myparam 应该作为表单参数传递，因为它可以是自由文本。但是，我们无法更改实现，因为 .jsp 结束时涉及其他方。
My solution was to encode the myparam using hex encoding (url encoding alone doesn't work as you end up with "%" etc. which the org.restlet implementation of REST doesn't like seeing in path parameters). Using the Apache codec library, I have something like this:
我的解决方案是使用十六进制编码对 myparam 进行编码（单独的 url 编码不起作用，因为你最终得到“%”等，REST 的 org.restlet 实现不喜欢在路径参数中看到）。使用 Apache 编解码器库，我有这样的东西：
Option 1 (just hex):
选项 1（仅十六进制）：
String decodedParam = new String(Hex.decodeHex(myparam.toCharArray()));
which works for our purposes. What I really wanted to do was to combine URL- and Hex-encoding, so that I can really cover all posibilities:
这适用于我们的目的。我真正想做的是结合 URL 和十六进制编码，这样我就可以真正涵盖所有可能性：
Option 2 (hex + url-decoding):
选项 2（十六进制 + url 解码）：
Parameter preparation:
参数准备：
String workText = URLEncoder.encode(inText, encoding); // a
char[] encodedBytes = Hex.encodeHex(workText.getBytes()); // b
String myparam = new String(encodedBytes);
Decoding (REST):
解码（REST）：
String decodedParam = new String(Hex.decodeHex(myparam.toCharArray())); // c
String doubleDecodedParam = URLDecoder.decode(decodedParam, "UTF-8"); // d
I have two questions:
我有两个问题：
why doesn't the second option work? (whenever I try and URL-decode my string at d) I get a java.lang.IllegalArgumentException). I've tested the double-encoding-and-decoding of my parameter values at http://ostermiller.org/calc/encode.htmlwithout problem.
is there a better way to encode path parameters with REST?
为什么第二个选项不起作用？（每当我尝试在 d 处对我的字符串进行 URL 解码时）我得到一个 java.lang.IllegalArgumentException）。我已经在http://ostermiller.org/calc/encode.html 上测试了我的参数值的双重编码和解码，没有问题。
有没有更好的方法来用 REST 编码路径参数？
回答by wds
There's a bunch of stuff that doesn't look quite right to me in the above code concerning character sets. In the encoding step you are assuming that whatever the Hex class does (which framework is that one from?) is returning bytes that can be interpreted as a String in the encoding your JVM is running in. I guess this works if the contract of Hex.encodeHex()supports it.
在上面关于字符集的代码中，有一堆东西在我看来不太合适。在编码步骤中，您假设 Hex 类所做的任何事情（那个框架来自哪个框架？）都返回字节，这些字节可以在您的 JVM 运行的编码中解释为字符串。我想这在Hex.encodeHex()支持合同的情况下有效它。
Then there's the other side. First off, you're decoding the hex string using UTF-8. You've silently assumed that your JVM is running in UTF-8, as you are passing in the result of a new String(), which assumes that the char arrays from Hex.decodeHex() are in the encoding the JVM is currently running at, which can only be UTF-8 if you're decoding it as such. I also don't see the point of that URL encoding pass there. It seems like it's completely redundant.
然后是另一边。首先，您正在使用 UTF-8 解码十六进制字符串。您已经默默地假设您的 JVM 以 UTF-8 运行，因为您正在传递 a 的结果new String()，它假定来自 Hex.decodeHex() 的字符数组采用 JVM 当前正在运行的编码，这可以如果您将其解码为 UTF-8，则只能使用 UTF-8。我也没有看到那个 URL 编码传递的意义。这似乎是完全多余的。
I guess none of this is really the core issue. There's another problem of what is exactly happening in the intermediate JSP. It likely decodes whatever it gets and re-encodes it. That should be transparent, but I'm not sure on what level you're taking in this data. If you see it before it's decoded as a parameter a wrong interpretation might result.
我想这些都不是真正的核心问题。在中间 JSP 中究竟发生了什么还有另一个问题。它可能会解码它得到的任何东西并重新编码。这应该是透明的，但我不确定您在此数据中的级别。如果您在将其解码为参数之前看到它，可能会导致错误的解释。
