之前在做云平台项目的时候，在VS里写好的Python代码，上传到Linux服务器上后，总是报字符集错误。然后写好的shell脚本文件，上传到服务器上后，显示起来总是乱码。尽管shell脚本文件里一个中文也没有，依然不能正常运行。Shell里提示不可识别的字符。

        这种不可见的字符就跟鬼一样，经常会产生莫名其妙的问题。比如明明是好好的python文件，上传到服务器就gg了。明明是没有错误的脚本，上传到服务器时，出现了乱码。如果说有中文，还好理解，那是不管你怎么设置，那些乱码总是不能正常的消除掉。似乎不管用什么样的字符集编码都不能正常的解决问题。

        就这样，这些乱码就跟鬼魂一样存在着，让人烦不胜烦。今天决定研究一下，彻底解决这个问题。

        下面是在Notepad++写好内容：

        字符集为UTF-8、换行符设置为Unix的换行符。内容一切正常。然后将写好的内容复制粘贴到Linux的终端上，结果如下：

        傻眼了吧。这是什么情况？？难道是终端粘贴内容是编码不对吗？查看一下：

        编码没有错误，但是却出现了乱码。试想一下，这样的内容拿去执行，能不报错吗！！能识别得出来吗！！那么python文件上传到服务器，服务器也识别出来这样的，请问你还如何好好的执行python代码呀。所以就动不动就是编码错误，而你压根就不知道哪出了问题。字符编码倒转千回都无济于事。

        我们将刚才的内容保存为shell文件，执行结果如下：

        因为无法识别命令，所以就一大片的command not found。这种问题也就是乱码引起的。

        那么这个问题如何解决呢？别急！我们得先弄懂问题的根本原因，才好解决问题。

        我们在notepad中新建一个文件，设置utf-8编码，输入了“中文”两个字，然后将这两个字复制，粘贴到了终端。结果如下：

        看到了乱码了是吧。这种乱码，至少还可以识别第一个字哦。而且这种乱码相信大家还是经常可以看到的，破坏力还不大，很好解决，删掉就可以了。我们此时的终端确实是UTF-8编码的。问题就在这，我们将复制的内容粘贴到终端时，使用的并不是UTF-8，而是GB2312。所以，请你将终端的字符集编码设置为GB2312，再粘贴试试！结果如下：

        编码是不是就正常了呀。而且此时的文字，你可以直接在终端的vim编辑器里编辑，一个中文两个字节，所以需要连续删除两次才删的掉这个中文。不过在删一次的时候，这个中文不会变成乱码，直到删除了两次才不见。此时就很正常了。

        那我们继续看一个情况：

        图中蓝紫色的字就是我们前面说的粘贴时因为编码不对，才出现了乱码。有的中文是正常的，有的是蓝紫色的乱码。而另外的问号呢？这个就不是我们前面说的乱码了。

        我们将这个问号所在的位置和原始文件对比，就可以发现，蓝紫色的乱码虽然看起来是乱的，单只是看起来不美观。 而问号这个乱码，就有点厉害了。也就是这个问号的乱码，导致了shell无法识别命令，导致python解释器无法解释python文件。

        为了再次确认问号所在的位置就是乱码，我们在本地的文件里进行识别。在Notepad++里面，显示一下所有的字符，让不可见的字符也显示出来：

        然后再看看文件的内容：

        在文件里看到了LF表示的Unix格式的换行符，没有看到其他符号了。似乎也没有发现什么蛛丝马迹。但是此时，你再仔细想想，我们已经让制表符、空格、也一并显示出来了。而这里竟然还有空格，不是有点奇怪吗？？难道是我们设置的空格显示没有起作用吗？？我们手动输入一些空格和制表符看看是有没有效果。结果如下：

        可以看到，连续的点连起来的是我打的空格，右箭头则是我打的tab制表符。然文字中显示的空格又是什么鬼！！我们试着删除这些空格，然后再打空格，结果如下：

        这些所谓的空格被删除了，然后被点号的空格（正常的空格）显示出来了。这说明什么？？这说明在设置了显示所有字符后还显示为空格的空格字符并不是真的空格字符，而是不可显示的乱码字符。而这些乱码字符在终端vim编辑器中因为无法表示，所以就显示为了问号。

        我们将不可见的乱码空格删掉，然后重新打一个空格字符，然后将这些字符复制到终端vim编辑器中，保存，再运行。一切正常了！！结果如下：

        我们是按照GB2312编码复制进去的，所以中文也是正常的。删除了不可见的乱码后，也不再出现?号，所以就没有乱码 。那么如果你遇见这样的问题，解决办法很简单。也就是像上面一样，将所有字符显示出来，把那些不可见的乱码空格删掉替换为正常的空格就好了。支持显示所有不可见字符的编辑器还有UE，设置也差不多，就不在此赘述了。

        问题找到了，也知道解决办法了。然而，这个问题如何出现的呢？也就是说，这些不可见的乱码究竟从哪冒出来的呢？如果知道这个原因，我们就可以在日后的使用中避免这样的乱码，减少自己的困扰。很烦人一点，这样的乱码可以被复制走的。比如发布到网页之后，你一样可以复制出来，所以一样还是会传播乱码。只有你真正研究明白了，就可以断掉这个乱码的传播，感觉这个乱码就跟看不见的病毒一样，和鬼魂一般，很难缠。至少我是深受其害，现在终于知道原因了。

        现在来说说这个乱码是如何出现的。在终端里这种乱码以问号显示出来了。然而在notepad++、UE等都没有表示出来，都是跟空格一样的显示着。这也就让我们被误导了。而这样的字符复制到记事本中，记事本在保存文件时会提示你说字符里含有了Unicode字符，如果不使用Unicode编码保存可能会丢失数据。但是却一脸懵逼吧。这也就是这些隐含的乱码造成的。所以呀，复制需谨慎呀！！虽然这个不是病毒，却害人不浅哦。

        而这些乱码的出现就跟一些软件有关。比如vim在编辑中文的时候，需要删除两次才删除掉这个字符。如果是正确的编码的话，vim可以在删除了两下之后才删掉字符，避免你只删除一次而漏掉一次。但是很多时候，我们使用了错误的编码时，粘贴上去的中文都是乱码，删除的时候就很奇怪了。然后我们删除的只要看不见字符了，就以为删除完毕了。谁知道，有些字符编码刚好是不可见的编码值。因为Unicode字符占两个字节，删除了一个字节，另一个字节变成了不可见字符的编码，你没有删掉，然后就一直留在文件里。那么这样的那件就如同带了一个病毒一般，去到哪就会造成哪里的崩溃。前面说了Python解释器，就炸了。而且像notepad、ue这样的软件还没有直接显示出来这样的不可见乱码字符，也就让我们很难觉察，除非特别去找这个问题。

        其实研究这个乱码问题，我们还可以使用winhex软件，可以看到每一个字节的内容，然后可以看到映射出来的字符。可以发现这些不可见的字符的编码值。即使这个不可见的字符有一个编码值，但是却没有对应到任何可见字符，也就成了孤魂野鬼一般。

        到此，这个问题就彻底研究清楚了。以后再也不怕编码乱码问题了。这也告诉大家一个信息，那就是在处理编码问题时，如果出现了乱码时，不要直接去编辑，而是要设置好了编码显示正常了再去编辑，这样就不会产生不可见的乱码了。