查看文件編碼

在Linux中查看文件編碼可以通 過以下幾種方式:

1.在Vim中可以直接查看文件編碼

:set fileencoding

即可顯示文件編碼格式。

如果你 只是想查看其它編碼格式的文件或者想解決用Vim查看文件亂碼的問題，那么你可以在

~/.vimrc 文件中添加以下內容:

let &termencoding=&encoding

set fileencodings=utf-8,ucs-bom,gbk,cp936

這樣，就可以讓vim自動識別文 件編碼(可以自動識別UTF-8或者GBK編碼的文件)，其實就是依照fileencodings提供的編碼列表嘗試，如果沒有找到合適的編碼，就用 latin-1(ASCII)編碼打開。

文件編碼轉換

1.在Vim中直接進行轉換文件編碼,比如將一個文件轉 換成utf-8格式

:set fileencoding=utf-8

2. iconv 轉換，iconv的命令格式如下:

iconv -f encoding -t encoding inputfile   # 比如將一個UTF- 8 編碼的文件轉換成GBK編碼

iconv -f GBK -t UTF-8 file1 -o file2

Linux 對一個3G的文本進行編碼轉換全過程

本過程中涉及到的Linux的命令有:split, iconv, cat 問題:有一個3G 的文本a.txt，編碼格式為gbk，現在需要對其進行轉換成為utf-8。 難點:iconv的轉換是在內存中進行的，因此3G大小的文本，無法 進行直接轉換。 思路:先利用split進行文件切分，然后對每一個字文件進行ivonv轉換，最后進行cat合并。

1) ll -h a.txt 查看文件的大小，2.9G

2) wc -l a.txt 查看文件的行數，9千200萬行

3) split -l 20000000 a.txt chunk 按照每個文件2千萬行進行切割，共分成5個文件 4) 進行轉換

iconv -f gbk -t utf-8 chunka > chunka_utf8 -c iconv -f gbk -t utf-8 chunkb > chunkb_utf8 -c iconv -f gbk -t utf-8 chunkc > chunkc_utf8 -c iconv -f gbk -t utf-8 chunkd > chunkd_utf8 -c iconv -f gbk -t utf-8 chunke > chunke_utf8 -c 5) rm chunka chunkb chunkc chunkd chunke 刪除原文件

6) cat chunk* > a.txt_utf8 進行合并

至此，工作完成

二、

批 量文件編碼轉換

本操作有風險，請注意操作前備份文件。

1.將原來所有編碼為gb2312的.java文件轉換為編碼為utf-8 的.java.new文件 for i in find . -name "*.java"; do iconv -f

gb2312 -t utf-8 $i -o $i.new; done

2.將*.java.new文件的.new擴展名去除

find . -name "*.new" | sed 's/\(.*\).new$/mv "&" "\1"/' | sh

三、

• linux下有 許多方便的小工具來轉換編碼，

• 文本內容轉換 iconv

• 文件名轉換 convmv

• mp3標簽轉換 python-mutagen

四、

用法: iconv [選項...] [文件...]

轉換給定文件的編碼。

輸 入/輸出格式規范:

-f, --from-co

de=名稱 原始文本編碼

-t, --to-code=名 稱 輸出編碼

信息:

-l, --list 列舉所有已知的字符集

輸出 控制:

-c 從輸出中忽略無效的字符

-o, --output=FILE 輸出文件

-s, --silent 關閉警告

--verb-?, --help 給出該系統求助列表

--usage 給出簡要的用法信息

-V, --version 打印程序版本號

五、

find default -type d -exec mkdir -p utf/{} \; find default -type f -exec iconv -f GBK -t UTF-8 {} -o utf/{} \;

這兩行命令將default目錄下的文件由GBK編碼轉換為UTF-8編碼，目錄結構 不變，轉碼后

的文件保存在utf/default目錄下。

六、

Linux下文件名編碼批量轉換convmv

由于FC將字 符編碼統一成了UTF8，原來在gb18030下建立的ext3分區中的文件和目錄，一掛載到FC上就顯示成亂碼。google遍整個互聯網，說對于目錄 名和文件名，有一個叫convmv的軟件可以對其進行自動轉換。

今日下載了convmv，摸索了一套使用方法如下:

convmv -f code1 -t code2 -r

code1:分區原來使用的字符集編碼。支持gb2312、gbk、 big5，不支持gb18030和big5-hkscs。 code2:預轉換到的字符集編碼。對于FC，這里填寫utf8

-r 參數:轉換子目錄。

dir:要轉換的目錄，當前目錄用./表示。

回車執行，這個時候convmv會顯示執行的結果，但不會真正對文件進 行修改。并提示使用--replace參數進行修改。

七、

批量轉換文件的編碼

for i in `find ./ -name *.htm` ; do echo $i;iconv -f gb18030 -t utf8 $i -o

/tmp/iconv.tmp;mv /tmp/iconv.tmp $i; done

find -name “*.htm“ \

-exec iconv -f gb2312 -t utf8 ‘{}‘ -o /tmp/iconv.tmp \; \ -exec mv /tmp/iconv.tmp ‘{}‘ \;

修改你的.vimrc文件，讓其支持 gb2312就行，會自動識別的。

可以參考我的設置

代碼:

"設定文件編碼類型，徹底解決中文編碼問題

let &termencoding=&encoding

set fileencodings=utf-8,gbk,ucs-bom,cp936

按照karron的方法解決了終端中vi看中文字問題。謝謝

略微查了一下.vimrc中添加內容的含意，這篇文章有相關解釋。

http://blog.dawnh.net/comment.php?type=trackback&entry_id=59

內容如下:

vim中編輯不同編碼的文件時需要注意的一些地方

此文講解的是vim編輯多字節編碼文檔(中文)所要了解的一些基礎知識，注意其沒有涉及gvim，純指字符終端下的vim。

[vim編碼方面的基礎知識]

1，存在3個變量:

encoding----該選項使用于緩沖的文本(你正在編輯的文件)，寄存器，Vim 腳本文件等等。你可以把 'encoding' 選項當作是對 Vim 內部運行機制的設定。

fileencoding----該選項是vim寫入文件時采用的編碼類型。

termencoding----該選項代表輸出到客戶終端(Term)采用的編碼類型。

2，此3個變量encoding----與系統當前locale相同，所以編輯文件的時候要考慮當前locale，否則要設置的東西就比較多了。

fileencoding----vim打開文件時自動辨認其編碼，fileencoding就為辨認的值。為空則保存文件時采用encoding的編碼，如果沒有修改encoding，那值就是系統當前locale了。 termencoding----默認空值，也就是輸出到終端不進行編碼轉換。

由此可見，編輯不同編碼文件需要注意的地方不僅僅是這3個變量，還有系統當前locale和、文件本身編碼以及自動編碼識別、客戶運行vim的終端所使用的編碼類型3個關鍵點，這3個關鍵點影響著3個變量的設定。

如果有人問:為什么我用vim打開中文文檔的時候出現亂碼,

答案是不確定的，原因上面已經講了，不搞清楚這3個關鍵點和這3個變量的設定值，出現亂碼是正常的，倒是不出現亂碼那反倒是湊巧的。

再來看一下常見情況下這三個關鍵點的值以及在這種情況下這3個變量的值:

1.locale----目前大部分Linux系統已經將utf-8作為默認 locale了，不過也有可能不是，例如有些系統使用中文locale zh_CN.GB18030。在locale為utf-8的情況下，啟動vim后encoding將會設置為utf-8，這是兼容性最好的方式，因為內部 處理使用utf-8的話，無論外部存儲編碼為何都可以進行無缺損轉換。locale決定了vim內部處理數據的編碼，也就是

encoding。

2.文件的編碼以及自動編碼識別----這方面牽扯到各種編碼的規則，就不一一細講了。但需要明白的是，文件編碼類型并不是保存在文件內的，也就是說沒有 任何描述性的字段來記錄文檔是何種編碼類型的。因此我們在編輯文檔的時候，要么必須知道這文檔保存時是以什么編碼保存的，要么通過另外的一些手段來斷定編 碼類型，這另外的手段，就是通過某些編碼的碼表特征來斷定，例如每個字符占用的字節數，每個字符的ascii值是否都大于某個字段來斷定這個文件屬于何種 編碼。這種方式vim也使用了，這就是vim的自動編碼識別機制了。但這種機制由于編碼各式各樣，不可能每種編碼都有顯著的特征來辨別，所以是不可能 100%準確的。對于我們GB2312編碼，由于其中文是使用了2個acsii值高于127的字符組成漢字字符的，因此不可能把gb2312編碼的文件與 latin1編碼區分開來，此自動識別編碼的機制對于gb2312是不成功的，它只會將文件辨識為latin1編碼。此問題同樣出現在gbk，big5 上等。因此我們在編輯此類文檔時，需要手工設定encoding和fileencoding。如果文檔編碼為utf-8時，一般vim都能自動識別正確的 編碼。

3.客戶運行vim的終端所使用的編碼類型----同第二條一樣，這也是一個比較 難以斷定的關鍵點決這個問題。此問題更多出現在我們的 windows desktop機遠程ssh登錄服務器的情況下，這里牽扯到不同系統的編碼轉換問題。所以又與windows本身以及ssh客戶端有很大相關性。在 windows下存在兩種編碼類型的軟件，一種是本身就為unicode編碼方式編寫的軟件，一種是ansi軟件，也就是程序處理數據直接采用字節流，不 關心編碼。前一種程序可以在任何語言的windows上正確顯示多國語言，而后一種則編寫在何種語言的系統上則只能在何種語言的系統上顯示正確的文字。對 于這兩種類型的程序，我們需要區別對待。以ssh客戶端為例，我們使用的putty是unicode軟件，而secure CRT則是ansi 軟件。對于前者，我們要正確處理中文，只要保證vim輸出到終端的編碼為utf-8即可，就是termencoding=utf-8。但對于后者，一方面 我們要確認我們的windows系統默認代碼頁為cp936(中文windows默認值)，另一方要確認vim設置的termencoding= cp936。

最后來看看處理中文文檔最典型的幾種情況和設置方式:

1.系統locale是utf-8(很多linux系統默認的locale形 式)，編輯的文檔是GB2312或GBK形式的(Windows記事本默認保存形式，大部分編輯器也默認保存為這個形式，所以最常見)，終端類型utf- 8(也就是假定客戶端是putty類的unicode軟件)

則vim打開文檔后，encoding=utf-8(locale決定的)，fileencoding=latin1(自動編碼判斷機制不準導致的)，termencoding=空(默認無需轉換term編碼)，顯示文件為亂碼。 解決方案1:首先要修正fileencoding為cp936或者euc-cn(二者一樣的，只不過叫法不同)，注意修正的方法不是:set fileencoding=cp936，這只是將文件保存為cp936，正確的方法是重新以cp936的編碼方式加載文件為:edit ++enc=cp936，可以簡寫為:e ++enc=cp936