QFtp 與中文問題

2021-08-25 19:16:44 字數 1956 閱讀 3499

鏈結 。既然這樣,就將自己兩次回答簡單整理一下,作為一篇部落格吧。

如果你對文字不感興趣,不妨直接看看這個表:(看看網路中傳遞的檔案路徑名、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,但是轉碼後又不是,怎麼辦...