为什么想要写这个,是因为在上周,表格存储的一个客户,告知我们在将数据通过DataX从OTS导出到ODPS后,发现数据『丢失』了。而在调查过后,发现数据并不是所谓的『丢失』了,而是数据被『改变』了。
什么原因导致数据发生了『改变』呢?却是因为一个大部分Java程序员都会忽略的问题导致的,所以我觉得有必要单独拿出来讲讲。
首先看下如下代码:
byte[] original1 = new byte[]{(byte)0xef, (byte)0x8f, (byte)0x8f};
byte[] transformed1 = new String(original1).getBytes();
System.out.println(Arrays.toString(original1));
System.out.println(Arrays.toString(transformed1));
System.out.println(Arrays.equals(original1, transformed1));
它的执行结果是:
[-17, -113, -113]
[-17, -113, -113]
true
这两个字节数组内容是完全相等的,第一个byte array在经过到String的转换,再到bytes的转换后,内容保持不变。
再看如下代码:
byte[] original2 = new byte[]{(byte)0xef, (byte)0x8f, (byte)0xff};
byte[] transformed2 = new String(original2).getBytes();
System.out.println(Arrays.toString(original2));
System.out.println(Arrays.toString(transformed2));
System.out.println(Arrays.equals(original2, transformed2));
它的执行结果是:
[-17, -113, -1]
[-17, -65, -67, -17, -65, -67]
false
这一次,两个byte array的结果不一样了,且结果差异很大。
这两段代码的唯一区别是,original1的最后一个字节值是0x8f, 而original2的最后一个字节值为0xff。
为何就这么一个微小的变更,就会导致结果差异这么大?
在Java中,byte[]是字节数组,而String是unicode的字符集合。字节到字符的转换规则,由编码决定(关于字节、字符和编码的概念解释,可以参考这篇文章。)。
在Java中,字节到String的转换,大部分人会选用new String(byte[] bytes)这个函数。但是这不是一个推荐的选择,因为在该函数中,会选择系统默认的字符集作为转换的编码。从而会导致同一段程序,在不同的执行环境下,结果可能是不同的。为了保证程序运行的确定性,尽量避免干扰因素,我们通常做法是在程序中显式指定一个编码,所以建议是使用new String(byte[] bytes, String charset)。
上面的示例代码的执行环境中,系统默认的字符集是UTF-8,所以字节到字符的转换,会按UTF-8编码来进行转换。
从表面看,original1和original2只是最后一个字节的值的差别,但是这带来的一个非常大的不同是,original1是一个标准的utf-8编码的字节,而original2却不是一个标准的utf-8编码的字节。
在Java String的实现中,bytes到String的转换,拆解步骤为:
byte[] original2 = new byte[]{(byte)0xef, (byte)0x8f, (byte)0xff};
// 根据指定的编码查找Charset
Charset charset = Charset.forName("utf-8");
// 初始化对应charset的decoder
CharsetDecoder decoder = charset.newDecoder().onMalformedInput(CodingErrorAction.REPLACE).onUnmappableCharacter(CodingErrorAction.REPLACE);
// 使用decoder对字节进行编码转换
decoder.decode(ByteBuffer.wrap(original2));
为何遇到一个非标准的utf-8编码的字节流,会转换到一个完全不对应的字符?这与Java中CharsetDecoder的实现有关,CharsetDecoder在遇到非标准编码的字节时,会有三种对应的策略可选择:
IGNORE(忽略),REPLACE(使用一个默认的字符去替换)和REPORT(抛出异常告知编码错误)。在Java的String实现中,选择的策略是REPLACE,而在CharsetDecoder中,默认初始化选择REPLACE的字符是"\uFFFD"。
我们看一下"\uFFFD"这个字符对应的UTF-8编码字节是什么:
String replaceChar = "\uFFFD";
System.out.println(Arrays.toString(replaceChar.getBytes("utf-8")));
输出结果:
[-17, -65, -67]
知道了String类的实现细节后,我们就可以拆解下上面例子中的original2,为何经过解码再编码的过程,会输出这么一个结果。
- CharsetDecoder读取第一个字节为0xef(1110 1111),根据utf-8编码,这是一个三字节的字符,所以接下来的两个字节必须符合格式为(10xx xxxx, 10xx xxxx)。
- 读取第二个字节为0x8f(1000 1111),符合规则,继续读取下一个。
- 读取第三个字节为0xff(1111 1111),不符合规则。
- Decoder至此解析完毕前两个字节,在第三个字节的时候发现不能与前两个字节完整的解码出一个字符,故认为前两个字节构成一个不符合规则的字符。由于选择的不规则字符处理策略是REPLACE,所以将该字符替换为\uFFFD。
- 从第三个字节开始,重新开始解码。但是第三个字节不符合utf-8编码首字节的规则,故认为该字节为一个不规则的字符,替换为\uFFFD。
- 所有字节处理完毕,结束解码过程。
- 得到最终结果为\uFFFD\uFFFD
而\uFFFD\uFFFD再经过编码,得到的结果就是[-17, -65, -67, -17, -65, -67],这就是整个过程。
这个过程在使用者看来,像是Java偷偷的将数据给『改变』了。所以比较规范的做法应该,当遇到不符合编码规范的字节流就报错,而不是偷偷的做事。
byte[] original2 = new byte[]{(byte)0xef, (byte)0x8f, (byte)0xff};
Charset charset = Charset.forName("utf-8");
CharsetDecoder decoder = charset.newDecoder().onMalformedInput(CodingErrorAction.REPORT).onUnmappableCharacter(CodingErrorAction.REPORT);
decoder.decode(ByteBuffer.wrap(original2));
输出结果:
Exception in thread "main" java.nio.charset.MalformedInputException: Input length = 2
at java.nio.charset.CoderResult.throwException(CoderResult.java:260)
at java.nio.charset.CharsetDecoder.decode(CharsetDecoder.java:781)
......
那如果我们就想把一段bytes解码为String,再从String编码为bytes,要保证bytes能正确的转换回来,应该怎么做呢?
byte[] original2 = new byte[]{(byte)0xef, (byte)0x8f, (byte)0xff};
byte[] transformed2 = new String(original2, "iso-8859-1").getBytes("iso-8859-1");
System.out.println(Arrays.toString(original2));
System.out.println(Arrays.toString(transformed2));
System.out.println(Arrays.equals(original2, transformed2));
可以选择"iso-8859-1"编码,该编码是单字节编码,字节的范围是0x00-0xff,覆盖全范围,不会出现字节流中有不规则的字符。
最后贴上写该文章起因的问题: