代码之家  ›  专栏  ›  技术社区  ›  davek

编码/解码静止路径参数

  •  0
  • davek  · 技术社区  · 15 年前

    我正在努力寻找解决我正在帮助支持的Web应用程序设计缺陷的最佳方法。服务的一部分将一个参数(“myparam”)传递给.jsp页面,该页面反过来调用一个REST服务,其中包括作为路径参数的myparam。设计缺陷位是MyParam应该作为表单参数传递,因为它可以是自由文本。但是,我们不能更改实现,因为其他各方都参与到.jsp的末尾。

    我的解决方案是使用十六进制编码对myparam进行编码(仅URL编码不起作用,因为您最终得到的是“%”等,而org.restlet实现的rest不喜欢在路径参数中看到)。使用Apache编解码器库,我有如下功能:

    选项1(仅十六进制):

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

    这是为了我们的目的。我真正想做的是将URL和十六进制编码结合起来,以便真正涵盖所有的可能性:

    选项2(十六进制+URL解码):

    参数准备:

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

    解码(休息):

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

    我有两个问题:

    1. 为什么第二个选项不起作用?(每当我尝试和URL解码我的字符串在D)我得到一个Java.Lang.ILLCALL ARGUMUMENT异常)。我已经测试了参数值的双重编码和解码 http://ostermiller.org/calc/encode.html 没问题。

    2. 有没有更好的方法可以用rest编码路径参数?

    1 回复  |  直到 14 年前
        1
  •  1
  •   wds    15 年前

    在上面关于字符集的代码中,有很多东西看起来不太合适。在编码步骤中,您假设十六进制类做什么(这个框架来自哪个框架?)返回在运行JVM的编码中可以解释为字符串的字节。如果合同 Hex.encodeHex() 支持它。

    然后是另一边。首先,您要使用UTF-8解码十六进制字符串。您已经悄悄地假定您的JVM是以UTF-8运行的,因为您正在传递 new String() ,它假定来自hex.decodeHex()的char数组是当前运行的JVM所使用的编码,如果您这样对它进行解码,那么它只能是utf-8。我也看不到URL编码在这里传递的意义。这似乎是完全多余的。

    我想这些都不是核心问题。中间JSP中到底发生了什么问题。它可能会解码它得到的任何东西并重新编码。这应该是透明的,但我不确定您接受这些数据的级别。如果在它作为参数解码之前看到它,可能会导致错误的解释。