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 對文字進行轉碼，實在是大逆不道。