关于windows下程序开发的中文乱码问题小结

Posted 2020-09-20 Clitter的博客

笔者遇到的问题背景：

windows 下使用notepad++6.7 ，ftp连接远程ubuntu主机，在本地创建远程主机文件，编辑后上传出现中文乱码。

 

笔者最开始不明白问题出在哪，因为设置了在notepad++中默认使用UTF-8编码格式进行新建文件，但依旧无效。

笔者一步步探索问题：

1. 新建一个文件，写入纯英文html文本后上传至ubuntu主机，vi ：set fileencoding显示此时为utf-8编码
2. 上述文件新增几个中文，保存后上传至ubuntu主机，这个时候提示fileencoding变成了latin1编码，相应的中文部分就变成了乱码
3. 网上有很多人说设置一下meta标签，就是最常见的charset=utf-8这个属性，我也进行了尝试，宣告失败，没有解决乱码问题。

我觉得问题出现了，一个文件，没写中文前是utf-8编码，写入文件后是latin1编码，这就是问题的关键。

一顿百度之后发现，在notepad++，选项卡中有一个“格式(M)”，其中有很多选项：其中主要有两个大块：以XXX格式编码，转为XXX格式编码，这就是解决问题的关键所在。

 

结合笔者以前遇到过一些关于中文乱码，让很多网友头疼不已的问题，需要明白的道理总结如下：

内容涉及windows操作系统，linux操作系统以及浏览器的解析三个部分。

第一、要明白该问题是windows上默认的字符编码与Linux上的字符编码不同导致的，一般前者是ANSI，后者是UTF-8；

在不同平台上文本显示的乱码问题是因为操作系统之间默认的字符编码不同造成的，上面的例子，纯英文文本，ANSI编码和UTF-8编码可以说是等价的，没有问题。

但是涉及到中文编码时，ANSI是不支持的，或者说与UTF-8的编码是不同的。一份ANSI编码的文本送给Linux，它用UTF-8格式来解开，结果是解除一对乱码。

另外，windows和linux同样使用UTF-8对文本进行编码时，略有区别，这就是有BOM和无BOM的区别（具体参看其他文章），Linux无BOM。

　　总结：

1. 为了使得两个系统平台的文件能够正常无缝显示，很大的一个关键点是：windows使用UTF-8编码（无BOM格式）来保存文件或者用UTF-8编码来保存（别用其他编码，使用其他编码保存中文，假设用ANSI保存，想转为别的码时，因为本身已经乱码，再转很可能也是乱码）
2. 当在文件要上传至Linux主机上时，要做一次检查，将文件转成UTF-8（无BOM）再传上去，确保完全没问题。

 

第二、meta标签，就是最常见的charset=utf-8这个属性的问题

这个问题造成的乱码，其实来自于文本文件本身的编码和浏览器解析时使用的编码不同而导致的，这与第一点造成的乱码不是同一个概念。

• 举例1：访问一个UTF-8格式的网页文本，该文本没有指定<meta charset=utf-8>，很可能遇到浏览器默认以GBK编码对网页进行解析。结果：以GBK解码一份以UTF-8编码的文本，乱码。
• 举例2：访问一个一个UTF-8格式的网页文本，该文本指定<meta charset=utf-8>，很可能遇到浏览器默认以GBK编码对网页进行解析，此时遇到meta，懂得要以utf-8来解析它。结果：以UTF-8正确解析了一份以UTF-8编码的文本，没问题。
• Ps:例子2也可能还是对中文解析出乱码。这是为什么？那是因为，服务端的那份UTF-8编码的文件，在有中文的地方，本身就已经是乱码！原因是什么？是的，这种情况下，就可以将两个中文乱码的原因联系起来了。在windows上编写完代码上传至服务端主机时，就已经因为两个系统的编码矛盾而致使中文乱码了，当浏览器发起访问时，不管解析使用的编码是否正确，错误的编码再怎么解析，都是错的，这就是问题的由来。

 

总结：不同的系统之间传输文件，注意编码要使用正确的，确保文件本身没有错；客户端访问时，用meta告知浏览器文件的编码，确保解析文件没有错，有这两步，一般不会都能解决中文乱码问题！