QT 中文亂碼解決問題 跨平臺操作是本文要介紹的內容。跨平臺(Linux  Windows)中文文件名亂碼的解決，從網路上搜了很久，都是沒有能夠把ubuntu下用gftp的中文亂碼問題解決的，這篇文章雖然廢話但思路比較清晰，容易了解問題所在及如何解決。就轉載于此。

事情的起因是這樣的～～

在很久很久以前——大約是2年多年前，我整了一臺P3的機器裝了FreeBSD 6.2做服務器，經常用Filezilla的SFTP往里面備份本地的文件，當然也包括一些中文名的文件。一切都很正常，上傳下載都沒問題，即使是用 SSH連過去用Tar打包再Gzip壓縮以后下載下來解開都沒問題。

但是好日子在前幾天到頭了。我前一陣又弄了一臺P3的機器裝了Ubuntu 7.10。問題出現了：

首先是在Windows上用Filezilla連接Ubuntu時看到的中文文件名全是亂碼，但是用Putty通過SSH連接Ubuntu卻是正常 的（原先是亂碼，后來改設置為UTF－8編碼就好了，不過Filezilla沒有類似的設置可改）。如果用Filezilla向Ubuntu上傳本地的中 文文件，則在Filezilla里看到Remote端的文件名是正確的，但在Putty里看到是亂碼。

然后更嚴重的問題是：當我在Ubuntu上用Filezilla的SFTP從FreeBSD上下載文件時發現那些中文文件名都成了亂碼。只好改用 tar/tar.gz再試，結果還是亂。***問了Google，但是結果并不理想，試過很多方法都無法解決，甚至為此特地在FreeBSD和Ubuntu 上都裝了p7zip試驗，也還是不行。

折騰了好幾天之后，我才想到應該研究一下幾個系統上的locale設置究竟是如何的——坦白說，要不是因為搜到的資料里有提到這方面，我從前還真沒注意到這回事。在FreeBSD和Ubuntu上分別運行了locale命令檢查的結果是：

FreeBSD的LC_ALL為“C”，即”POSIX”的別名，似乎是一種無固定編碼的方案，或者可以認為就是本地編碼，默認的設置。
Ubuntu的LC_ALL為“zh_CN.UTF-8”，這個是我設置的。
Windows不必說了，肯定是本地編碼——只是我沒有想到的是，公司里用的英文版Windows居然也是本地編碼，我一直以為是Unicode的，看來是為了保持兼容。

這樣就好理解了，Filezilla不改變編碼方式，所以當Remote端與本機的編碼不一致時，必然亂碼。所以在Windows上用 Filezilla連接Ubuntu看到亂碼，而我的Putty因為是設置為UTF－8編碼，所以看到的是正確的——因為Ubuntu一端是UTF－8。 而如果用Filezilla上傳中文文件，則因為Windows是本地編碼，所以上傳以后仍然為本地編碼（GB系），而Ubuntu是UTF－8所以是亂 碼。

FreeBSD那邊的問題也是一樣的，因為那些文件都是以前從Windows上傳上去的，用的都是GB系編碼，而早年我用Putty都是用默認的本 地編碼方案，所以一直沒有發現問題。這樣的話，因為FreeBSD是本地編碼，與Ubuntu的UTF－8不一致，所以怎么弄都是亂碼。

但是據說用7zip這樣的工具打包以后是可以解決這樣的編碼不一致問題的，我試了卻沒有成功。后來才想明白，因為7zip是根據系統的locale設置來對文件名進行相應的處理，因為原來我處理的時候文件名是GB系的編碼，而系統是設置為UTF－8，所以總也不對。

***的解決方案是：

在ubuntu上用以下命令：

export LC_ALL="zh_CN.GBK"scp raptor@freebsdserver:/home/raptor/myfiles/*.* .export LC_ALL="zh_CN.UTF-8"convmv -f GBK -t UTF-8 --notest *.*原理就是先把ubuntu的locale改為GBK，然后用SSH COPY文件過來，再改locale為UTF－8，然后用convmv來轉換文件名的編碼。

不過經過試驗表明，不改變locale直接scp也是可以的，因為scp并不會改變文件的編碼方式，不過改了locale以后便于在轉編碼之前檢查scp過來的內容（否則scp過來是亂碼，要到轉編碼后才正常）。

這樣做的結果就是，這些文件在ubuntu上是正常了，以后要再弄回windows就比較麻煩，需要用7zip之類的工具打包下載再解開。

歸根到底這些問題都是因為該死的Windows用本地編碼來記錄文件名，Unicode化做得不夠徹底。

小結：關于QT 中 中文亂碼解決問題 跨平臺操作的內容介紹完了，希望本文對你有所幫助。有問題可以留言，一起討論！更多相關內容請參考編輯推薦。