鏈結 。既然這樣，就將自己兩次回答簡單整理一下，作為一篇部落格吧。
如果你對文字不感興趣，不妨直接看看這個表：（看看網路中傳遞的檔案路徑名、qftp提供的檔案路徑名、以及我們期待的檔案路徑名的關係）
網路傳遞的
(位元組流)
qftp介面提供的
（字串）
中間態位元組流
(原始位元組流)
我們操作的
(字串)
qbytearray
====>
qstring
====>
qbytearray
====>
qstring
<====
<====
<====
latin1編譯碼
latin1編譯碼
gb18030(或utf8)
qftp內部動作
程式設計師的責任
qftp的自作聰明
抵消qftp的自作聰明
(獲取真實的位元組流)
此處選擇和伺服器相同編碼，
不知道伺服器採用何種編碼?
那這可是個世界性難題了。猜吧
ftp 是乙個古老的協議，ftp 在編碼問題上相當笨，笨到對編碼一無所知。
因為設計上如此，在現在的協議下，無法從根本上解決。所以我們使用ftp是將不可避免地遇到編碼問題。
不管你是那種客戶端，如果你不知道伺服器採用的編碼，你只能去猜測伺服器採取何種編碼，所以不可避免會有亂碼問題(如果你用ftp，相信你深有感受)。qftp 遇到這麼笨的 ftp 也很無奈。
中文問題:
儘管這個編碼問題很棘手，但是具體到簡體中文，問題還是很簡單的。只要伺服器採用中文，要麼是gb18030，要麼是utf8。所以二選一，最多嘗試2次即可解決問題。
我們知道：不管你的伺服器編碼是什麼，只要整個過程中都是作為latin1來處理的，就可以保證資訊不會丟失(因為latin1用全了乙個位元組的0~255，是位元組流, 同樣的方法，在早期的資料庫中也被採用）。
qftp 也是這麼處理的，所有需要和伺服器互動的字串都是用的latin1的位元組流。但是，它有點做過了，所有的latin1位元組流，它用qstring封裝了一下(個人認為是qftp設計的嚴重失誤，如果是都換成qbytearray將非常容易理解和使用)。
使用這些函式的時候，我們需要傳遞乙個字串！！
連線到這些訊號時，我們接受的資料報含乙個字串!!
這有神馬問題麼？你有沒有這樣的疑問。答案是，沒有問題，只要你不介意你的使用者看到的是亂碼，qftp工作一切都很正常。
我們通過某種方式已經知道了伺服器採用的編碼了，比如是gb18030，那麼客戶端如何正常顯示出中文呢？
在qt中，我們在客戶端處理檔名等字串時，使用的是包含正確資訊qstring，qftp中用的也是qstring(位元組流的封裝)。這中間需要乙個轉換，qstring 和 qstring 的轉換！！
網路傳遞的位元組流
qftp介面
中間態位元組流
我們操作的字串
qbytearray
====>
qstring
====>
qbytearray
====>
qstring
<====
<====
<====
latin1編譯碼
latin1編譯碼
gb18030(或utf8)
qftp內部動作
程式設計師的責任
qftp的自作聰明
抵消qftp的自作聰明
換種表達方式：(以服務端採用utf8為例)
QFtp 與中文問題
鏈結 既然這樣，就將自己兩次回答簡單整理一下，作為一篇部落格吧。如果你對文字不感興趣，不妨直接看看這個表 看看網路中傳遞的檔案路徑名 qftp提供的檔案路徑名 以及我們期待的檔案路徑名的關係 網路傳遞的 位元組流 qftp介面提供的 字串 中間態位元組流 原始位元組流 我們操作的 字串 qbytea...
QFtp中文亂碼的問題
1 理論上ftp伺服器支援utf8的話，就可以直接傳送用utf8編碼的中文檔名 開啟utf8的方法是 rawcommand opts utf8 on 2 如果不支援的話，因為ftp協議裡面，規定檔名編碼為iso 8859 1，iso 8859 1的別名是latin1，正是qt中qstring預設的內...
Jsoncpp與中文出現的問題
一般我們在vs中都是gbk編碼，如果我們要給json賦值乙個中文字串怎麼辦 jsres body message 我是中國人 對方收到是一串類似 u8bc6 u522b u5931 u8d25 u9700 u7ee7 u7eed u62cd u7167 看著是unicode，但是轉碼後又不是，怎麼辦...