背景

產(chǎn)品經(jīng)理要求上傳文件到服務(wù)器，但是文件沒有模板，文件的編碼格式不定，因此不能通過指定的編碼格式解析文件，否則會(huì)出現(xiàn)亂碼。

文件編碼識(shí)別

（1）UTF-8 BOM編碼的文件，前3個(gè)字節(jié)轉(zhuǎn)換成10進(jìn)制數(shù)后分別是：-17、-69、-65。

（2）UTF-16BE BOM編碼的文件，前2個(gè)字節(jié)轉(zhuǎn)換成10進(jìn)制數(shù)后分別是：-2、-1。

（3）UTF-16LE BOM編碼的文件，前2個(gè)字節(jié)轉(zhuǎn)換成10進(jìn)制數(shù)后分別是：-1、-2。

因此，這三種編碼格式的文件檢測(cè)起來比較簡(jiǎn)單，只需要拿到文件的前三個(gè)字節(jié)，然后根據(jù)上面的規(guī)則就可以確定文件是什么編碼。問題是這種檢測(cè)方式只能區(qū)分UTF-8 BOM、UTF-16BE BOM和UTF-16LE BOM編碼的文件，不能區(qū)分UTF-8和GBK編碼的文件。

Google字符編碼檢測(cè)工具

需要引入Maven依賴，Maven坐標(biāo)如下：

<dependency> 
    <groupId> 
        com.googlecode.juniversalchardet    </groupId> 
    <artifactId>juniversalchardet</artifactId> 
    <version>1.0.3</version> 
</dependency> 

Google字符編碼檢測(cè)工具Java代碼示例，目前來看檢查UTF-8和GBK編碼沒有問題，但是其它編碼存在問題，由于上傳的文件只有中文和英文，因此稍微做了點(diǎn)兼容性處理，當(dāng)編碼獲取錯(cuò)誤時(shí)，默認(rèn)取GBK編碼。編碼檢測(cè)工具在生產(chǎn)環(huán)境運(yùn)行了一段時(shí)間，目前來看沒發(fā)現(xiàn)什么問題。

總結(jié)

由于上傳的文件只有中文和英文，在生產(chǎn)環(huán)境運(yùn)行了一段時(shí)間，目前來看是滿足要求的。比如Google的字符編碼檢測(cè)工具會(huì)返回WINDOWS-1252這樣的編碼格式，這種默認(rèn)用GBK編碼就可以。還有一些檢測(cè)不出來的編碼格式，返回null，這種也用默認(rèn)的GBK就行。