Question

我遇到了一个奇怪的问题。我的servlet收到一个urlencoded字符串，从日志中我可以看出这个字符串是正确的。

我试过这个字符串：

"test+%F0%9F%98%8E+1+%E2%99%A7+%E2%99%A2+%E2%99%A1+%E2%99%A4+%E3%80%8A"

以下内容：

"test  1 ♧ ♢ ♡ ♤ 《"

然而，当我运行测试时，得到的结果与我在服务器上获得的结果相同：

"test ? 1 ? ? ? ? ?"

转储我得到的十六进制代码

00: 74 65 73 74 20 3F 20 31  20 3F 20 3F 20 3F 20 3F | test ? 1  ? ? ? ? 
10: 20 3F -- -- -- -- -- --  -- -- -- -- -- -- -- -- |  ?

我的预期：

00: 74 65 73 74 20 F0 9F 98  8E 20 31 20 E2 99 A7 20 | test ... . 1 ... 
10: E2 99 A2 20 E2 99 A1 20  E2 99 A4 20 E3 80 8A -- | ... ...  ... ...

现在是“有趣”的一点。这发生在我的服务器和Eclipse IDE上，但如果我将源文件保存为UTF-8，则URLDecoder会返回正确的数据！但它在我的服务器上没有帮助。

1：我看不出那是怎么回事，URLDecoder应该听取请求的编码。 2：我显然需要替换java.net.URLDecoder，如果它这样做，它从根本上被打破了。有什么建议？

测试代码：

public class URLDecoderTest {
    public static void main(String[] args) {
        String reqMsg = "test+%F0%9F%98%8E+1+%E2%99%A7+%E2%99%A2+%E2%99%A1+%E2%99%A4+%E3%80%8A";
        System.out.println("reqMsg      : " + reqMsg);
        try {
            reqMsg = URLDecoder.decode(reqMsg, "UTF-8");
        } catch (UnsupportedEncodingException e) {
            // TODO Auto-generated catch block
            e.printStackTrace();
        }
        System.out.println("reqMsg      : " + reqMsg);
        System.out.println(HexTools.dump(reqMsg));
        System.out.println("Expected (fixed):");
        System.out.println("00: 74 65 73 74 20 F0 9F 98  8E 20 31 20 E2 99 A7 20 | test ... . 1 ... ");
        System.out.println("10: E2 99 A2 20 E2 99 A1 20  E2 99 A4 20 E3 80 8A -- | ... ...  ... ...");
    }
}

注意：HexTools来自Mobicents： http://code.google.com/p/mobicents/source/browse/trunk/commons/src/main/java/org/mobicents/commons/HexTools.java?r=21908

修改查看URLDecoder.decode的源代码，它使用新的String（字节，0，pos，enc）来解码字节。由于某些原因失败，但是对于unicode，新的String（字节，0，pos）工作正常。

Java的StringCoding类中是否存在错误，它会自动回退到“默认”字符集，无论传递给它的是什么？ String调用的decode方法是静态的，它在调用解码之前在另一个静态方法中设置请求的编码，然后解码将使用此静态。换句话说：它不是线程安全!!!

更新几乎所有实现层都遇到了问题。表情符号字符（4字节utf-8字符）例如在MySQL上造成了麻烦。即使它被设置为utf8，我也会从中获得asciified字符。

结束语： 问题的一部分，或者真正感知的问题，是由于滥用HexTools.dump（String）引起的，这是一个为处理二进制数据而构建的类，其中偶数字符串的字符只包含低字节中的数据。

为了将来参考，对HexTools.dump的调用应该是：

        System.out.println(HexTools.dump(reqMsg.getBytes("UTF-8")));

将UnsupportedEncodingException的catch块向下移动以覆盖该行。这样做，返回与预期相同的十六进制帧。

Answer 1

HexTools.dump必须犯错。它传递了String = Unicode文本。那怎么能转储字节呢？除了使用默认的平台编码，可能是Windows ANSI。

尝试类似：

System.out.println(Arrays.toString(reqMsg.getBytes(StandardCharsets.UTF_8)));

您不会看到问号（0x3F == 63）。

Answer 2

此代码按预期工作：

import java.io.IOException;
import java.net.URLDecoder;

public class Dump {
  public static void main(String[] args) throws IOException {
    String reqMsg = 
         "test+%F0%9F%98%8E+1+%E2%99%A7+%E2%99%A2+%E2%99%A1+%E2%99%A4+%E3%80%8A";
    String decoded = URLDecoder.decode(reqMsg, "UTF-8");
    // UTF-16
    for (char ch : decoded.toCharArray()) {
      System.out.format("%04x ", (int) ch);
    }
    System.out.println();
    // UTF-8
    for (byte ch : decoded.getBytes("UTF-8")) {
      System.out.format("%02x ", 0xFF & ch);
    }
  }
}

但是，您可能会丢失信息：

System.out.println

以上PrintStream将执行（可能有损）转码操作。来自文档：

使用平台的默认字符编码将PrintStream打印的所有字符转换为字节。

在许多系统上，Java使用过时的遗留编码。

也可能是您的servlet容器配置错误。不确定最新版本是否属实，但Tomcat历史上默认使用ISO-8859-1进行URL编码。

java.net.URLDecoder依赖于源文件编码？

2 个答案: