1樓：匿名使用者
1、檔案分割槽型別的目錄結構有自己的編碼。
2、分割槽在掛載時分割槽的驅動很多都有自己的編碼轉換功能。
3、本地編碼和系統輸入輸出編碼也是影響的地方。
4、現在還有這種問題嗎？樓主你不會是還在用很古老的系統吧？
你隨便轉換就會遇到混亂問題，也就是明明是 utf8 的編碼，你非要按照 gb 編碼轉換到 utf8 編碼的過程，這樣資料肯定轉換的會有問題。轉換過去後就是錯誤編碼資料，再轉換回來肯定會因為資料錯誤而無法轉換，當然這個錯誤資料有的是可以處理，有的是不可以處理的。因為 gb 系列和 utf 系列都是動態長度的編碼，而且都是用的差不多的演算法，區別也就是表示的字元不同。
所以錯誤資料有的時候可以處理，有的時候不能處理。
qomo 預設應該是 utf8 編碼環境，檔案系統的目錄結構掛載後也轉換成了 utf8 編碼掛載。但並不代表文字檔案裡面的資料也全都是 utf8 。我記得 qomo 為了相容，預設的文字處理編碼是 gb 系列 。
也就是說，環境編碼和檔案內容編碼是不同的。
而且，gbk 和 gb 2312 和 gb18030 理論上相容，但其實是需要碼錶轉換的。所以直接 gbk 並不一定行。
再另外，圖形介面的終端裡面也有顯示的編碼設定。
無盡的編碼問題最好的解決辦法是隻用 7bit 表示的語言。
2樓：匿名使用者
我這裡是中文qomo linux 1.2。
你的郵件我已收到。 convmv同樣出現了轉換失敗問題。
我用ls > ../name.txt將檔名輸出到一個檔案裡，然後用系統自帶的編碼轉換工具iconv進行測試。結果如下（顯示編碼為utf8)
superhacker@linux ~ pts5 $ iconv -f utf8 -t gbk name.txt
閸氬�鏁��iconv: 未知 24 處的非法輸入序列
superhacker@linux ~ pts5 $ iconv -f gbk -t utf8 name.txt
闂佸憡鑹鵑ˇ閬嶅極欏栨稓顩叉慨姍iconv: 未知 32 處的非法輸入序列
如果顯示字元為gbk的話，效果如下
superhacker@linux ~ pts5 $ iconv -f gbk -t utf8 name.txt
闂備礁鎲￠懝楣兯囬柆宥呮瀬妞ゆ牗紼撻々鍙夋叏濮梚conv: 鏈�煡 32 澶勭殑闈炴硶杈撳靉搴忓垪
superhacker@linux ~ pts5 $ iconv -f utf8 -t gbk name.txt
闁告艾顦遍弫顖涗iconv: 鏈�煡 24 澶勭殑闈炴硶杈撳靉搴忓垪
superhacker@linux ~ pts5 $ cat name.txt
闂佸憡鑹鵑ˇ閬嶅極欏栨稓顩叉慨姍�浜墮昆妤呮倵濞戣櫕瀚�- 闂侀潧媧ら崐鍫曞磹閻愬搫桅閻忕偠顏婄紓鎾繪煏閸ラ攱瀚�- 闂佸搫鍠溳幏錕�闂佺粯鐗曞∧妤呭χ嫻犲�瑙《い鎺戝�歸悾閬嶆煛閸愶箑鍔滄繝鈧�弶嬈炬槳閻忕偟鍋撻柨錕�***
utf8下的檔案顯示為
闁告艾顦遍弫顖涗�濮橀亶鍋楅悗娑蟲嫹 - 闁靛洤鍊墮崐鐐哄φ鐏炶�緙撻柕鍥鋒嫹 - 闁哄喛鎷� 闁繪牕媯楅妶浠嬪觸欏掑倹鐣遍柡鍐〉劜濠€鏉款潰鐏炵偓閿�.***
從效果上看，應該是你在轉換編碼的過程中由於檔案系統的原因或者其他原因出現了資訊丟失。有些檔案系統不能支援一些特殊符號，而異常轉換的時候由於產生了這些特殊符號導致了資訊丟失。比如ntfs不能有\ /等等。
這應該不是單純的編碼轉換能夠解決的問題了。試試還能不能找到原始的cddb資訊吧。
3樓：匿名使用者
用大寫的「utf-8」
linux下，檔名後帶有符號是什麼意思
一般來說文bai件名最後的du字母是 那麼這個檔案是vim的備份zhi 檔案dao.如 有個檔案a.txt,用vim編輯a.txt,然後儲存,則就會專生成a.txt 圖形介面為了屬好看吧,才不顯示備份檔案.我要是寫個圖形介面還不顯示.bak的檔案呢.linux下，目錄中的 符號代表什麼意思？代表的是...
的檔名和資料夾的檔名變成綠色
windows加密 efs 後的檔案 資料夾就是綠色的字型，如果是壓縮的就是藍色的字型。右鍵點資料夾 屬性 高階 加密內容以保護資料 前面的勾去掉就可可以了。這種加密很方便，但要小心，如果沒有備份金鑰，在更改windows登入密碼，或者用其他使用者名稱登入，都無法開啟檔案，更改回原先的密碼也不行了。...
看看這些檔名
根據您提供的情況來看，並不是內碼轉換的問題。具體說來，windows分為win32核心和winnt核心，前者的代表是win95 win98 winme，後者的代表是win2000，winxp，win2003，當然前者是逐漸淘汰的趨勢。二者的重要區別之一就是win32從核心層次上支援ansi字符集，以...