ctrl c 中文字符到 vnc 里，中文字符已经被转码

为了测试程序对多语言字符的支持状况，我找来一段中文和北欧的文字，但愿把这些文字上传到elasticsearch，并能正确显示。

首先测试了北欧文字，一切OK。

可是中文复制到 VNC 客户端(Linux)后倒是问号，由于Linux原本就打不出中文，因此显示乱码我也没在乎，我以为中文的编码无非就是一坨二进制的东西，我又没有改变什么，显示问号只是 linux 没法解析而已。跑了下程序，而后到elasticsearch查询结果，中文部分依然显示的是问号。

接下来就几个想法，首先是，程序在某处应该设置charset，我却没有设置，就像 apche email 同样，邮件里显示乱码是由于没有设置 utf-8 的charset，若是是这个缘由的话，很难找到解决办法。其次是，那一坨二进制确定在哪里被转码了，使得上传到elasticsearch后的中文字符已经不是原始的“中文字符了”，可是是在哪转的码呢，也不知道，多是在http connection上。最后，难道是和 linux 系统没有安装语言包有关，由于个人程序在我本身的mac上跑就没问题，可以正确处理多种文字。

和同事聊了下，由于多语言的问题一直在困扰着你们，在 perl 写的程序中也有非 ascii 码特殊处理的状况，因此又出现了这种问题时，你们都比较无奈。

我跑去找二叔，描述了问题，他说没有想法，要具体分析。不知何时，我说本身是把中文字符 ctrl + c 拷到 linux 的 terminal 的，二叔说 ctrl + c 可能会有问题。让我试试 scp 拷贝。我以为有可能，赶忙跑回去测试，把一段中文字符 ctrl + c 拷到terminal，而后再拷出来，果真已经恢复不出来中文字符了。操做不可逆，显然，期间发生了转码，问题解决。

 

因此有了问题，花了必定的时间搞不定后，赶忙去问老同事。和他们描述问题会理清思路，排除极不可能的选项。

其实文字的编码，不管从哪里流到哪里，二进制应该不会变的，不管是硬件位置的改变还网络传输，即使真正发生了改变，也应该有一个 marshall, unmarshall 的过程，且此过程对咱们透明，至于乱码与否，就看当前的环境是否有能力把这一坨二进制显示出来。而 clipboard 对文字进行转码，实在是大逆不道。