关于Java中bytes到String的转换

简介: 本片文章主要介绍在Java中byte array到String转换的细节,特别是在处理非utf-8字节流转换到String时容易踩到的一些坑。
    为什么想要写这个,是因为在上周,表格存储的一个客户,告知我们在将数据通过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,为何经过解码再编码的过程,会输出这么一个结果。
  1. CharsetDecoder读取第一个字节为0xef(1110 1111),根据utf-8编码,这是一个三字节的字符,所以接下来的两个字节必须符合格式为(10xx xxxx, 10xx xxxx)。
  2. 读取第二个字节为0x8f(1000 1111),符合规则,继续读取下一个。
  3. 读取第三个字节为0xff(1111 1111),不符合规则。
  4. Decoder至此解析完毕前两个字节,在第三个字节的时候发现不能与前两个字节完整的解码出一个字符,故认为前两个字节构成一个不符合规则的字符。由于选择的不规则字符处理策略是REPLACE,所以将该字符替换为\uFFFD。
  5. 从第三个字节开始,重新开始解码。但是第三个字节不符合utf-8编码首字节的规则,故认为该字节为一个不规则的字符,替换为\uFFFD。
  6. 所有字节处理完毕,结束解码过程。
  7. 得到最终结果为\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,覆盖全范围,不会出现字节流中有不规则的字符。

最后贴上写该文章起因的问题:https://yq.aliyun.com/ask/44190

目录
相关文章
|
3天前
Failed to bind properties under ‘logging.level‘ to java.util.Map java.lang.String, java.lang.String
Failed to bind properties under ‘logging.level‘ to java.util.Map java.lang.String, java.lang.String
4 0
|
3天前
|
安全 Java 数据安全/隐私保护
Java基础4-一文搞懂String常见面试题,从基础到实战,更有原理分析和源码解析!(二)
Java基础4-一文搞懂String常见面试题,从基础到实战,更有原理分析和源码解析!(二)
12 0
|
3天前
|
JSON 安全 Java
Java基础4-一文搞懂String常见面试题,从基础到实战,更有原理分析和源码解析!(一)
Java基础4-一文搞懂String常见面试题,从基础到实战,更有原理分析和源码解析!(一)
10 0
|
3天前
|
Java
guava Splitter 与java 内置的string的split 方法的区别
guava Splitter 与java 内置的string的split 方法的区别
5 0
|
5天前
|
SQL 分布式计算 大数据
MaxCompute操作报错合集之在数据同步时,遇到报错"InvalidData: The string's length is more than 8388608 bytes."是什么导致的
MaxCompute是阿里云提供的大规模离线数据处理服务,用于大数据分析、挖掘和报表生成等场景。在使用MaxCompute进行数据处理时,可能会遇到各种操作报错。以下是一些常见的MaxCompute操作报错及其可能的原因与解决措施的合集。
|
5天前
|
Java
Java中判断String类型为空和null的方法
Java中判断`String`变量是否为空或`null`需用`== null`和`.isEmpty()`。示例代码提供两种方法:`main`方法直接判断,`safeGetString`方法提供默认值。当输入为`null`或空时,返回默认值。代码包含三个测试案例,分别处理`null`、空字符串和非空非`null`字符串。
21 0
|
12天前
|
Java
Java中String的用法
Java中String的用法
|
12天前
|
存储 缓存 安全
Java性能优化(二):Java基础-String对象及其性能优化
在深入探讨了String字符串的性能优化后,我们认识到优化字符串处理对提升系统整体性能的重要性。Java在版本迭代中,通过精心调整成员变量和内存管理机制,不断对String对象进行优化,以更高效地使用内存资源。String对象的不可变性是Java语言设计中的一个关键特性,它不仅确保了字符串的安全性,也为字符串常量池的实现提供了基础。通过减少相同值的字符串对象的重复创建,常量池有效地节约了内存空间。然而,不可变性也带来了挑战。在处理长字符串拼接时,我们需要显式使用类来避免性能下降。
18 1
|
12天前
|
安全 Java 测试技术
滚雪球学Java(50):理解Java中String、StringBuilder和StringBuffer的区别与选择
【6月更文挑战第4天】🏆本文收录于「滚雪球学Java」专栏,专业攻坚指数级提升,希望能够助你一臂之力,帮你早日登顶实现财富自由🚀;同时,欢迎大家关注&&收藏&&订阅!持续更新中,up!up!up!!
12 0
滚雪球学Java(50):理解Java中String、StringBuilder和StringBuffer的区别与选择
|
12天前
|
Java 索引
26. 【Java教程】 String类
26. 【Java教程】 String类
20 0