当前位置: 首页 > news >正文

再谈java乱码:GBK和UTF-8互转尾部乱码问题分析

为什么80%的码农都做不了架构师?>>>   hot3.png

一直以为,java中任意unicode字符串,可以使用任意字符集转为byte[]再转回来,只要不抛出异常就不会丢失数据,事实证明这是错的。

经过这个实例,也明白了为什么 getBytes()需要捕获异常,虽然有时候它也没有捕获到异常。

言归正传,先看一个实例。

用ISO-8859-1中转UTF-8数据

设想一个场景:

用户A,有一个UTF-8编码的字节流,通过一个接口传递给用户B;

用户B并不知道是什么字符集,他用ISO-8859-1来接收,保存;

在一定的处理流程处理后,把这个字节流交给用户C或者交还给用户A,他们都知道这是UTF-8,他们解码得到的数据,不会丢失。

下面代码验证:

public static void main(String[] args) throws Exception {
  //这是一个unicode字符串,与字符集无关
  String str1 = "用户";

  System.out.println("unicode字符串:"+str1);

  //将str转为UTF-8字节流
  byte[] byteArray1=str1.getBytes("UTF-8");//这个很安全,UTF-8不会造成数据丢失

  System.out.println(byteArray1.length);//打印6,没毛病

  //下面交给另外一个人,他不知道这是UTF-8字节流,因此他当做ISO-8859-1处理

  //将byteArray1当做一个普通的字节流,按照ISO-8859-1解码为一个unicode字符串
  String str2=new String(byteArray1,"ISO-8859-1");

  System.out.println("转成ISO-8859-1会乱码:"+str2);

  //将ISO-8859-1编码的unicode字符串转回为byte[]
  byte[] byteArray2=str2.getBytes("ISO-8859-1");//不会丢失数据

  //将字节流重新交回给用户A

  //重新用UTF-8解码
  String str3=new String(byteArray2,"UTF-8");

  System.out.println("数据没有丢失:"+str3);
}

输出:

unicode字符串:用户
6
转成ISO-8859-1会乱码:ç¨æ·
数据没有丢失:用户

用GBK中转UTF-8数据

重复前面的流程,将ISO-8859-1 用GBK替换。

只把中间一段改掉:

    //将byteArray1当做一个普通的字节流,按照GBK解码为一个unicode字符串
		String str2=new String(byteArray1,"GBK");

		System.out.println("转成GBK会乱码:"+str2);

		//将GBK编码的unicode字符串转回为byte[]
		byte[] byteArray2=str2.getBytes("GBK");//数据会不会丢失呢?

运行结果:

unicode字符串:用户
6
转成GBK会乱码:鐢ㄦ埛
数据没有丢失:用户

好像没有问题,这就是一个误区。

修改原文字符串重新测试

将两个汉字 "用户" 修改为三个汉字 "用户名" 重新测试。

ISO-8859-1测试结果:

unicode字符串:用户名
9
转成GBK会乱码:ç¨æ·å
数据没有丢失:用户名

GBK 测试结果:

unicode字符串:用户名
9
转成GBK会乱码:鐢ㄦ埛鍚�
数据没有丢失:用户�?

结论出来了

ISO-8859-1 可以作为中间编码,不会导致数据丢失;

GBK 如果汉字数量为偶数,不会丢失数据,如果汉字数量为奇数,必定会丢失数据。

why?

为什么奇数个汉字GBK会出错

直接对比两种字符集和奇偶字数的情形

重新封装一下前面的逻辑,写一段代码来分析:

public static void demo(String str) throws Exception {
  System.out.println("原文:" + str);

  byte[] utfByte = str.getBytes("UTF-8");
  System.out.print("utf Byte:");
  printHex(utfByte);
  String gbk = new String(utfByte, "GBK");//这里实际上把数据破坏了
  System.out.println("to GBK:" + gbk);

  byte[] gbkByte=gbk.getBytes("GBK");
  String utf = new String(gbkByte, "UTF-8");
  System.out.print("gbk Byte:");
  printHex(gbkByte);
  System.out.println("revert UTF8:" + utf);
  System.out.println("===");
//		如果gbk变成iso-8859-1就没问题
}

public static void printHex(byte[] byteArray) {
  StringBuffer sb = new StringBuffer();
  for (byte b : byteArray) {
    sb.append(Integer.toHexString((b >> 4) & 0xF));
    sb.append(Integer.toHexString(b & 0xF));
    sb.append(" ");
  }
  System.out.println(sb.toString());
};

public static void main(String[] args) throws Exception {
  String str1 = "姓名";
  String str2 = "用户名";
  demo(str1,"UTF-8","ISO-8859-1");
  demo(str2,"UTF-8","ISO-8859-1");

  demo(str1,"UTF-8","GBK");
  demo(str2,"UTF-8","GBK");
}

输出结果:

原文:姓名
UTF-8 Byte:e5 a7 93 e5 90 8d
to ISO-8859-1:å§å
ISO-8859-1 Byte:e5 a7 93 e5 90 8d
revert UTF-8:姓名
===
原文:用户名
UTF-8 Byte:e7 94 a8 e6 88 b7 e5 90 8d
to ISO-8859-1:ç¨æ·å
ISO-8859-1 Byte:e7 94 a8 e6 88 b7 e5 90 8d
revert UTF-8:用户名
===
原文:姓名
UTF-8 Byte:e5 a7 93 e5 90 8d
to GBK:濮撳悕
GBK Byte:e5 a7 93 e5 90 8d
revert UTF-8:姓名
===
原文:用户名
UTF-8 Byte:e7 94 a8 e6 88 b7 e5 90 8d
to GBK:鐢ㄦ埛鍚�
GBK Byte:e7 94 a8 e6 88 b7 e5 90 3f
revert UTF-8:用户�?
===

为什么GBK会出错

前三段都没问题,最后一段,奇数个汉字的utf-8字节流转成GBK字符串,再转回来,前面一切正常,最后一个字节,变成了 "0x3f",即"?"

我们使用"用户名" 三个字来分析,它的UTF-8 的字节流为:

[e7 94 a8] [e6 88 b7] [e5 90 8d]

我们按照三个字节一组分组,他被用户A当做一个整体交给用户B。

用户B由于不知道是什么字符集,他当做GBK处理,因为GBK是双字节编码,如下按照两两一组进行分组:

[e7 94] [a8 e6] [88 b7] [e5 90] [8d ?]

不够了,怎么办?它把 0x8d当做一个未知字符,用一个半角Ascii字符的 "?" 代替,变成了:

[e7 94] [a8 e6] [88 b7] [e5 90] 3f

数据被破坏了。

为什么 ISO-8859-1 没问题

因为 ISO-8859-1 是单字节编码,因此它的分组方案是:

[e7] [94] [a8] [e6] [88] [b7] [e5] [90] [8d]

因此中间不做任何操作,交回个用户A的时候,数据没有变化。

关于Unicode编码

因为UTF-16 区分大小端,严格讲:unicode==UTF16BE。

public static void main(String[] args) throws Exception {
  String str="测试";
  printHex(str.getBytes("UNICODE"));
  printHex(str.getBytes("UTF-16LE"));
  printHex(str.getBytes("UTF-16BE"));
}

运行结果:

fe ff 6d 4b 8b d5
4b 6d d5 8b
6d 4b 8b d5

其中 "fe ff" 为大端消息头,同理,小端消息头为 "ff fe"。

小结

作为中间转存方案,ISO-8859-1 是安全的。

UTF-8 字节流,用GBK字符集中转是不安全的;反过来也是同样的道理。

byte[] utfByte = str.getBytes("UTF-8");
String gbk = new String(utfByte, "GBK");
这是错误的用法,虽然在ISO-8859-1时并没报错。

首先,byte[] utfByte = str.getBytes("UTF-8");
执行完成之后,utfByte 已经很明确,这是utf-8格式的字节流;

然后,gbk = new String(utfByte, "GBK"),
对utf-8的字节流使用gbk解码,这是不合规矩的。

就好比一个美国人说一段英语,让一个不懂英文又不会学舌的日本人听,然后传递消息给另一个美国人。

为什么ISO-8859-1 没问题呢?

因为它只认识一个一个的字节,就相当于是一个录音机。我管你说的什么鬼话连篇,过去直接播放就可以了。

getBytes() 是会丢失数据的操作,而且不一定会抛异常。

unicode是安全的,因为他是java使用的标准类型,跨平台无差异。

转载于:https://my.oschina.net/polly/blog/1523584

相关文章:

  • 1.ubuntu网络配置
  • 戴尔软件调查结果显示中型企业正积极实施大数据项目
  • C#基础知识整理:C#类和结构(4)
  • bzoj 1692: [Usaco2007 Dec]队列变换 ——二分+hash
  • Android 快捷小工具
  • linux find命令详解
  • 自动化测试基础篇--Selenium简介
  • Elasticsearch的使用场景深入详解
  • Microsoft Office Word 遇到问题需要关闭
  • 【算法导论】第15章动态规划
  • Objective-C——消息、Category和Protocol
  • 物理世界的安防
  • [emuch.net]MatrixComputations(7-12)
  • 【科普】手机版项目管理系统软件的功能是什么?
  • 修改统计信息自动收集时间窗口
  • [js高手之路]搞清楚面向对象,必须要理解对象在创建过程中的内存表示
  • 《Javascript数据结构和算法》笔记-「字典和散列表」
  • 4. 路由到控制器 - Laravel从零开始教程
  • Asm.js的简单介绍
  • leetcode386. Lexicographical Numbers
  • Quartz初级教程
  • Spring Boot快速入门(一):Hello Spring Boot
  • TypeScript迭代器
  • Unix命令
  • Vue.js 移动端适配之 vw 解决方案
  • vue的全局变量和全局拦截请求器
  • Vue官网教程学习过程中值得记录的一些事情
  • 关键词挖掘技术哪家强(一)基于node.js技术开发一个关键字查询工具
  • 关于List、List?、ListObject的区别
  • 关于字符编码你应该知道的事情
  • 基于Dubbo+ZooKeeper的分布式服务的实现
  • 简析gRPC client 连接管理
  • 日剧·日综资源集合(建议收藏)
  • 融云开发漫谈:你是否了解Go语言并发编程的第一要义?
  • 推荐一个React的管理后台框架
  • 用 Swift 编写面向协议的视图
  • 7行Python代码的人脸识别
  • postgresql行列转换函数
  • Spring Batch JSON 支持
  • 仓管云——企业云erp功能有哪些?
  • 交换综合实验一
  • (BFS)hdoj2377-Bus Pass
  • (C语言)球球大作战
  • (第27天)Oracle 数据泵转换分区表
  • (二)构建dubbo分布式平台-平台功能导图
  • (分享)自己整理的一些简单awk实用语句
  • (附源码)计算机毕业设计SSM在线影视购票系统
  • (亲测)设​置​m​y​e​c​l​i​p​s​e​打​开​默​认​工​作​空​间...
  • (一) springboot详细介绍
  • (转)Linux下编译安装log4cxx
  • (自用)learnOpenGL学习总结-高级OpenGL-抗锯齿
  • .bat批处理(四):路径相关%cd%和%~dp0的区别
  • .NET 将混合了多个不同平台(Windows Mac Linux)的文件 目录的路径格式化成同一个平台下的路径
  • .net 前台table如何加一列下拉框_如何用Word编辑参考文献
  • .NET 设计模式—适配器模式(Adapter Pattern)