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

ctrl c 中文字元到 vnc 裡，中文字元已經被轉碼