相关疑难解决方法(0)

使用UTF-8编码创建String时存在不一致.

运行此代码:

public static void encodingIssue() throws IOException {
    byte[] array = new byte[3];
    array[0] = (byte) -19;
    array[1] = (byte) -69;
    array[2] = (byte) -100;

    String str = new String(array, "UTF-8");
    for (char c : str.toCharArray()) {
        System.out.println((int) c);
    }
}

在Java 1.8.0_20(及更早版本)上,我们得到了结果

 65533

在Java 1.7和1.6上,我们得到了正确的结果:

 57052

你遇到过这个错误吗？这有解决方法吗？

这种不一致也表现为Shift_JIS,JIS_X0212-1990,x-IBM300,x-IBM834,x-IBM942,x-IBM942C,x-JIS0208,但显然UTF-8更为紧迫.

前言:

1. 我要告诉你的是错误,我很清楚我做这种愚蠢的事情打破封装有多糟糕.
2. 我不是要解决任何更普遍的I/O问题.这只是一个实验.

我正在尝试sun.nio.ch.SourceChannelImpl使用JDK中存在的包私有构造函数的包私有类子类(在rt.jar中),所以我必须在sun.nio.ch包中创建它.

这是我的子类:

package sun.nio.ch;
import java.io.FileDescriptor;
import java.nio.channels.spi.SelectorProvider;
class MySourceChannel extends SourceChannelImpl {
  public MySourceChannel(SelectorProvider sp, FileDescriptor fd) {
    super(sp, fd);
  }
}

这是我的简单测试:

package sun.nio.ch;
import java.io.FileDescriptor;
public class Main {
  public static void main(String[] args) {
    new MySourceChannel(null, FileDescriptor.in);
  }
}

而这是失败:

Exception in thread "main" java.lang.IllegalAccessError: class sun.nio.ch.MySourceChannel cannot access its superclass sun.nio.ch.SourceChannelImpl
        at java.lang.ClassLoader.defineClass1(Native Method)
        at java.lang.ClassLoader.defineClass(ClassLoader.java:800)
        at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
        at java.net.URLClassLoader.defineClass(URLClassLoader.java:449)
        at java.net.URLClassLoader.access$100(URLClassLoader.java:71)
        at java.net.URLClassLoader$1.run(URLClassLoader.java:361)
        at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
        at java.security.AccessController.doPrivileged(Native …

我最近将 JBoss AS 5 的应用程序迁移到 Wildfly 8，因此必须从 Java 6 迁移到 Java 8。

我现在在通过 Ant 运行我的单元测试之一时遇到问题：

[javac] C:\\Users\\test\\JAXBClassTest.java:123: error: unmappable character for encoding UTF8\n

测试类的第123行是：

Assert.assertEquals("J\xc2\xb5hn", JAXBClass.getValue()); \n

该测试专门用于确保 JAXB 编组器可以处理 UTF-8 字符，我相信这一点\xc2\xb5。我已在 JAXB 编组器上添加了一个属性，以确保允许使用这些字符：

marshaller.setProperty(Marshaller.JAXB_ENCODING, "UTF-8");\n

我见过多个问题（1 , 2 , 3），这些问题似乎很相似，但它们的答案解释了为什么以前以一种方式解码的无效字符现在以另一种方式解码，或者似乎实际上没有和我一样的问题。

如果所有字符都有效，这会导致问题吗？我知道我一定错过了一些东西，但我看不到什么。

某些使用新字符串的字节数组（字节[]，“ UTF-8”）在jdk 1.7和1.8中返回不同的结果

byte[] bytes1 = {55, 93, 97, -13, 4, 8, 29, 26, -68, -4, -26, -94, -37, 32, -41, 88};
        String str1 = new String(bytes1,"UTF-8");
        System.out.println(str1.length());

        byte[] out1 = str1.getBytes("UTF-8");
        System.out.println(out1.length);
        System.out.println(Arrays.toString(out1));

byte[] bytes2 = {65, -103, -103, 73, 32, 68, 49, 73, -1, -30, -1, -103, -92, 11, -32, -30};
        String str2 = new String(bytes2,"UTF-8");
        System.out.println(str2.length());

        byte[] out2 = str2.getBytes("UTF-8");
        System.out.println(out2.length);
        System.out.println(Arrays.toString(out2));

bytes2使用新的String（byte []，“ UTF-8”），结果（str2）在jdk7和jdk8中不相同，但byte1相同。bytes2有什么特别之处？

测试“ ISO-8859-1”代码，bytes2的结果与jdk1.8中的相同！

jdk1.7.0_80：

15
27
[55, 93, 97, -17, -65, -67, 4, …