最近我们汇道科技程序员彪彪跟天瑞地安的程序猿明明一起合作，在写一个关于C语言demo，明明在windows7中文操作系统上使用nodepad++写了一段代码。然后彪彪在centos英文版中使用sublime进行打开发现，所有的中文注释都变成了乱码。他们俩就为何会出现乱码分析许久，小编总结如下：
这一次的编码问题不是在纠结utf8，gbk以及unicode的关系而是思考了一下在编程的时候，所采用的的默认编码方式是什么的问题。
无论你在写什么程序（c语言或者nodejs程序），或者就是简单编辑一下txt文件，你有没有想过这些文件以什么样的形式存储在硬盘上。
程序是由诸多的字符串组成，总是要存储的，无论是存在硬盘中还是内存中，总是要被编排成为0，1串。因此从可读的字符到0和1的过程是怎样转换而来的，这就是编码的范畴。
那么我们的程序默认采用了什么样的编码方式呢。这是与操作系统有关的，因此中文操作系统和英文操作系统一定是存在差异的，事实上以上面的情形为例，在中文的windows7操作系统中，默认采用的编码方式为gbk，然后在centos的英文版中默认的编码方式为utf8(通过locale命令查看)。
因此在windows7中创建C 语言程序，nodepad++会默认的使用gbk编码存储程序（即ANSI），然后我使用sublime进行打开的时候，默认是utf8。因此gbk编码的0，1数据流使用utf8进行解码，就会出现中文乱码。同时sublime并不支持gbk，因此怎么看都是乱码。同理在shell中编辑该文件的时候，也是乱码，因为centos英文系统默认utf8编码。
解决办法就是在nodepad++中可以指定其为utf8编码格式存储。
以前为什么很少出现乱码。主要原因是程序基本上都是英文写的，那么主流的编码基本都是兼容ascii码的，即英文字符的编码。也就是说英文的编码在各种编码方式之间基本是一致的。当然在同一个系统中，编码保持一致，也很少出现此问题。当然如果nodejs向C语言传输了一个utf8编码的字符串作为命令行的参数，而实际的C语言采用的却是gbk编码格式，则会导致错误。
终于整理完两位程序大哥的分析了，整理过程中，小编都害怕两位程序员的怒火殃及无辜群众，但，不管怎样，我们还是相亲相爱的“汇道人”！