编码/解码REST路径参数 [英] Encoding/decoding REST path parameters

问题描述

我正在寻找在网络应用中找到设计缺陷的最好方法我正在帮助支持。服务的一部分将参数（myparam）传递到.jsp页面，后者又调用REST服务，包括我们的myparam作为路径参数。设计缺陷位是myparam应该作为一个表单参数传递，因为它可以是自由文本。然而，我们不能改变实现，因为其他方涉及的.jsp结束的东西。

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.

我的解决方案是使用十六进制编码（url编码单独的在你最终以％等工作，这是REST的org.restlet实现不喜欢在路径参数中看到的）。使用Apache编解码器库，我有这样的：

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:

选项1（十六进制）：

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

这是我们的目的。我真正想做的是结合URL和Hex编码，所以我真的可以覆盖所有的可能性：

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:

选项2（hex + url-解码）：

参数准备：

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

解码（REST）：

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

我有两个问题：

1. 为什么第二个选项不工作？ （每当我尝试和URL解码我的字符串在d）我得到一个java.lang.IllegalArgumentException）。我已在 http://ostermiller.org上测试了我的参数值的双重编码和解码/calc/encode.html 。

是否有更好的方式使用REST对路径参数进行编码？

is there a better way to encode path parameters with REST?

推荐答案

有一些东西在上面的代码中看起来不太对我有用集。在编码步骤，你假设无论什么Hex类做的（该框架是一个从？）返回的字节，可以解释为一个字符串在您的JVM运行的编码。我想如果合同的 Hex.encodeHex（）支持它。

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.

然后是另一边。首先，你使用UTF-8解码十六进制字符串。你默认地假设你的JVM运行在UTF-8中，因为你传递的是一个 new String（）的结果，它假设来自Hex .decodeHex（）在JVM当前运行的编码，如果你解码它只能是UTF-8。我也没有看到那个URL编码传递那里的点。它似乎是完全多余的。

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.

我想这不是真正的核心问题。另一个问题是中间JSP中发生了什么。它可能解码任何它获得和重新编码。这应该是透明的，但我不知道你在这个数据采取什么级别。如果您在解码为参数之前看到它，可能会导致错误的解释。

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.

这篇关于编码/解码REST路径参数的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！