关于多字节传输导致的乱码问题

一、系统编码

windows下设置系统编码：控制面板->区域和语言

例如把系统编码改成繁体big5编码

1、格式选项。改成繁体编码：中文(繁体，台湾)。

2、管理->更改系统区域设置。改成繁体编码：中文(繁体,台湾)。

 

二、网页编码

一个网页要想在浏览器中能够正确显示，需要在三个地方保持编码的一致：网页文件，网页编码声明和浏览器编码设置。

三、常见字符集

这些从ANSI标准派生的字符集被习惯的统称为ANSI字符集，它们正式的名称应该是MBCS(Multi-Byte Chactacter System，即多字节字符系统)

常见字符集名称：ASCII字符集、GB2312字符集、BIG5字符集、GB18030字符集、Unicode字符集等

ASCII字符集：ASCII编码

GB2312字符集：GB2312

GBK字符集:GBK

GB18030字符集：GB 18030编码

BIG5字符集：BIG5编码

Unicode是字符集，UTF-32/ UTF-16/ UTF-8是三种字符编码方案。
UTF-8是ASCII的一个超集。

通常说的Unicode就是指UTF-16。

 

utf-8和utf-8 bom

UTF-8 不需要 BOM，尽管 Unicode 标准允许在 UTF-8 中使用 BOM。
所以不含 BOM 的 UTF-8 才是标准形式，在 UTF-8 文件中放置 BOM 主要是微软的习惯（顺便提一下：把带有 BOM 的小端序 UTF-16 称作「Unicode」而又不详细说明，这也是微软的习惯）。
BOM（byte order mark）是为 UTF-16 和 UTF-32 准备的，用于标记字节序（byte order）。微软在 UTF-8 中使用 BOM 是因为这样可以把 UTF-8 和 ASCII 等编码明确区分开，但这样的文件在 Windows 之外的操作系统里会带来问题。

「UTF-8」和「带 BOM 的 UTF-8」的区别就是有没有 BOM。即文件开头有没有 U+FEFF。

四、项目中遇见的一个关于编码格式不同导致乱码问题的解决

问题：在服务某下载服务中，采用多字节编码，系统编码为gbk。

客户端下载逻辑为：用户打开客户端资源窗口->加载下载网页页面(网页嵌入在窗口中，网页的编码格式为utf-8)->点击某个文件的下载按钮->客户端获取从网页下回调的资源文件名等数据->然后打包向下载服务请求下载该资源文件。

服务端下载逻辑：接收到客户端的下载请求->获取下载资源文件名的信息->查找文件是否存在->

1)存在就读取文件数据发送给客户端。

2)不存在就返回错误信息，并打印输出下载失败的文件名。

正常情况下：服务编码格式是多字节,客户端的编码格式也是多字节，下载服务/客户端运行环境都是简体中文windows，区域和语言都是简体中文，客户端点击下载，流程一切正常。

如果有人把客户端系统的区域和语言栏中->当前系统区域改成中文(繁体，台湾),格式->格式改成中文(繁体，台湾)。然后在客户端点击下载，下载失败。

通过日志文件输出信息发现一些下载失败的文件名显示为乱码，其他的中文汉字正常，但是在客户端断点调试显示文件名不是乱码。可以预见文件名在传输过来的时候就变成乱码了。

 

分析原因是：客户端系统的区域和语言栏中->当前系统区域改成中文(繁体，台湾),格式->格式改成中文(繁体，台湾)后，编码方案就编程繁体编码方案了(big5),文件名从utf8转成big5，是可以正确显示的。

当客户端把通过big5编码的文件名传输到下载服务端，服务端gbk去解码文件名，乱码就产生了。因为big5和gbk的编码格式是不同的。同一个汉字在不同的代码页里。

 

解决方法：

方法一、把客户端的区域和语言栏中的繁体中文改成简体中文。

方法二、把客户端和服务端之间的字符传输改成utf-8编码格式传输。