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 对文字进行转码，实在是大逆不道。