戰(zhàn)修復(fù))
1. 亂碼不是玄學(xué)是編碼鏈路里某一環(huán)對(duì)不上干開(kāi)發(fā)這行十幾年被問(wèn)得最多的問(wèn)題里為什么我這里中文顯示成亂碼絕對(duì)排前三。很多人第一次遇到亂碼時(shí)的反應(yīng)是電腦壞了軟件有bug其實(shí)亂碼從來(lái)不是隨機(jī)事件它是一條非常確定的因果鏈一段文字從產(chǎn)生到顯示中間經(jīng)過(guò)了編碼、傳輸、存儲(chǔ)、解碼四個(gè)環(huán)節(jié)只要其中任意兩個(gè)環(huán)節(jié)用的字符集不一致亂碼就必然出現(xiàn)。理解這一點(diǎn)后面所有的排查都有了方向。先把最基礎(chǔ)的概念捋清楚不然后面全是空中樓閣。字符集Character Set是一張字符到編號(hào)的映射表比如 Unicode 規(guī)定中這個(gè)字的編號(hào)是 U4E2D編碼Encoding則是把這張表里的編號(hào)變成實(shí)際字節(jié)的規(guī)則比如 UTF-8 把 U4E2D 編成E4 B8 AD三個(gè)字節(jié)而 GBK 把它編成D6 D0兩個(gè)字節(jié)。同一個(gè)中字UTF-8 和 GBK 給出的字節(jié)完全不同這就是亂碼的根源。我見(jiàn)過(guò)太多人把UTF-8和Unicode混為一談。Unicode 是字符集UTF-8 是它的一種編碼實(shí)現(xiàn)UTF-16、UTF-32 也是。GBK、GB2312、GB18030 則是另一套獨(dú)立的字符集加編碼體系主要覆蓋中文。ASCII 是最早的只有 128 個(gè)字符連中文都裝不下。搞清楚這幾層關(guān)系你就能明白亂碼的本質(zhì)是用 A 規(guī)則寫(xiě)的字節(jié)被用 B 規(guī)則讀了。這篇文章適合所有被中文亂碼折磨過(guò)的人——不管你是寫(xiě) Java、Python、C 的后端還是搞 MATLAB、LabVIEW、ABAP 的工程黨或者是天天跟終端、編輯器、數(shù)據(jù)庫(kù)打交道的運(yùn)維。我會(huì)從原理講到實(shí)戰(zhàn)把 Windows、Linux、macOS 三大平臺(tái)以及編輯器、終端、數(shù)據(jù)庫(kù)、文件傳輸這些高頻場(chǎng)景的亂碼問(wèn)題挨個(gè)拆開(kāi)給出可以直接抄的解決方案。2. 從字節(jié)到屏幕一次中文顯示到底經(jīng)歷了什么2.1 編碼、解碼、轉(zhuǎn)碼三個(gè)動(dòng)作的區(qū)別很多人排查亂碼時(shí)腦子是糊的因?yàn)榉植磺寰幋a和解碼到底誰(shuí)對(duì)誰(shuí)。我用一個(gè)寄快遞的類比編碼就是打包把中這個(gè)字按某種規(guī)則塞進(jìn)箱子字節(jié)流解碼就是拆包按某種規(guī)則把箱子里的東西還原成字轉(zhuǎn)碼就是換箱子把 A 規(guī)則打的包拆開(kāi)再用 B 規(guī)則重新打包。關(guān)鍵點(diǎn)在于編碼和解碼必須用同一套規(guī)則否則拆出來(lái)的就是垃圾。你拿 UTF-8 的鑰匙去開(kāi) GBK 的鎖出來(lái)的就是涓枃這種鬼東西——這其實(shí)是中文兩個(gè)字的 UTF-8 字節(jié)被當(dāng)成 GBK 解讀的經(jīng)典結(jié)果。反過(guò)來(lái)GBK 字節(jié)被當(dāng)成 UTF-8 讀通常會(huì)出現(xiàn)這種替換字符因?yàn)?GBK 的字節(jié)序列往往不構(gòu)成合法的 UTF-8 序列。轉(zhuǎn)碼則是解決亂碼的正道。當(dāng)你確認(rèn)原始字節(jié)是 GBK但目標(biāo)環(huán)境要 UTF-8正確做法是用 GBK 解碼得到正確的字符再用 UTF-8 編碼寫(xiě)出去。千萬(wàn)不要直接對(duì)字節(jié)做替換那樣只會(huì)越搞越亂。2.2 為什么涓枃和錕斤拷會(huì)反復(fù)出現(xiàn)這兩個(gè)詞是中文亂碼界的名場(chǎng)面認(rèn)識(shí)它們能幫你快速定位問(wèn)題。涓枃這類現(xiàn)象是UTF-8 字節(jié)被 GBK 解碼的典型產(chǎn)物。UTF-8 里一個(gè)中文字符占 3 個(gè)字節(jié)GBK 里占 2 個(gè)字節(jié)字節(jié)數(shù)對(duì)不上于是每 3 個(gè) UTF-8 字節(jié)被硬拆成 1.5 個(gè) GBK 字符拼出來(lái)的就是一堆生僻字?？吹竭@種每個(gè)字都認(rèn)識(shí)但連起來(lái)不像話的亂碼基本可以斷定是 UTF-8 被當(dāng) GBK 讀了。錕斤拷則是另一個(gè)方向的經(jīng)典GBK 字節(jié)被 UTF-8 解碼失敗后被替換成 UFFFD替換字符再經(jīng)過(guò)一次錯(cuò)誤編碼產(chǎn)生的。它通常出現(xiàn)在數(shù)據(jù)被反復(fù)轉(zhuǎn)碼、或者經(jīng)過(guò)不支持原始編碼的中間環(huán)節(jié)之后?？吹藉K斤拷說(shuō)明數(shù)據(jù)已經(jīng)臟了原始字節(jié)可能已經(jīng)丟失恢復(fù)難度大很多。提示判斷亂碼方向有個(gè)土辦法——如果亂碼里全是看起來(lái)像漢字但很怪的字多半是 UTF-8 被 GBK 讀如果出現(xiàn)大量或錕斤拷多半是 GBK 被 UTF-8 讀且已經(jīng)發(fā)生替換。2.3 編碼問(wèn)題的三大高發(fā)地帶根據(jù)我這些年的排查經(jīng)驗(yàn)亂碼集中爆發(fā)在三個(gè)地方記住它們能省你一半時(shí)間。第一是文件讀寫(xiě)。用 Python 的open()不指定encoding在 Windows 上默認(rèn)走 GBK在 Linux 上默認(rèn)走 UTF-8同一份代碼換個(gè)系統(tǒng)就亂。第二是終端與命令行。Windows 的 cmd 默認(rèn)代碼頁(yè)是 936GBKPowerShell 老版本也是而你的程序輸出的是 UTF-8兩邊一撞就亂。第三是跨系統(tǒng)傳輸。文件從 Windows 傳到 Linux從 Mac 傳到服務(wù)器編碼不會(huì)自動(dòng)轉(zhuǎn)換全靠你手動(dòng)處理。下面這張表是我整理的常見(jiàn)亂碼現(xiàn)象與對(duì)應(yīng)原因遇到問(wèn)題先對(duì)號(hào)入座亂碼現(xiàn)象大概率原因典型場(chǎng)景涓枃、鏂囦歡UTF-8 字節(jié)被 GBK 解碼網(wǎng)頁(yè)、日志、跨平臺(tái)文件錕斤拷、大量 GBK 字節(jié)被 UTF-8 解碼并替換數(shù)據(jù)庫(kù)、多次轉(zhuǎn)碼后問(wèn)號(hào) ???目標(biāo)編碼無(wú)法表示該字符向 GBK/ASCII 寫(xiě)入生僻字方框 □□□字體缺失不是編碼問(wèn)題PDF、ArcGIS 圖例部分字正常部分亂混合編碼或截?cái)嗥唇幼址?、分包傳?. Windows 平臺(tái)亂碼代碼頁(yè) 936 是繞不開(kāi)的坎3.1 cmd 與 PowerShell 的中文輸出處理Windows 中文版的默認(rèn)代碼頁(yè)是 936也就是 GBK。這意味著你在 cmd 里跑一個(gè)輸出 UTF-8 的程序中文必然亂。最直接的解決辦法是在程序開(kāi)頭或運(yùn)行前把代碼頁(yè)切成 UTF-8chcp 65001chcp是 change code page 的縮寫(xiě)65001 就是 UTF-8 的代碼頁(yè)編號(hào)。切完之后再運(yùn)行程序中文就正常了。但要注意chcp 65001 只對(duì)當(dāng)前這個(gè)命令行窗口生效關(guān)掉就恢復(fù)。想永久改得去注冊(cè)表或系統(tǒng)區(qū)域設(shè)置里動(dòng)但我不建議永久改因?yàn)楹芏嗬铣绦蛞蕾?936改了反而讓它們亂。PowerShell 的情況稍微復(fù)雜。老版本 PowerShell 5.x 默認(rèn)輸出編碼是 GBK處理 UTF-8 文件時(shí)經(jīng)常亂?？梢栽谀_本開(kāi)頭加[Console]::OutputEncoding [System.Text.Encoding]::UTF8 $OutputEncoding [System.Text.Encoding]::UTF8這兩行分別管控制臺(tái)輸出和管道輸出的編碼。我踩過(guò)的坑是只設(shè)了第一行結(jié)果管道傳給下一個(gè)命令時(shí)還是亂必須兩行都設(shè)。另外.ps1腳本文件本身如果存成 UTF-8 帶 BOM老版本 PowerShell 能識(shí)別存成 UTF-8 無(wú) BOM就可能把中文當(dāng)亂碼解析建議腳本文件統(tǒng)一存成UTF-8 with BOM。3.2 記事本、VSCode 的編碼識(shí)別陷阱Windows 高版本W(wǎng)in10 1903 之后的記事本默認(rèn)改成 UTF-8 了這本來(lái)是好事但帶來(lái)一個(gè)新問(wèn)題打開(kāi)老文件時(shí)記事本可能用 UTF-8 去讀 GBK 內(nèi)容直接亂給你看。解決辦法是打開(kāi)時(shí)手動(dòng)選編碼或者用另存為看當(dāng)前編碼再?zèng)Q定。VSCode 相對(duì)聰明它有自動(dòng)編碼檢測(cè)但檢測(cè)不是萬(wàn)能的。我遇到過(guò) VSCode 把 GBK 文件誤判成 UTF-8 的情況中文全亂。這時(shí)候點(diǎn)右下角的編碼按鈕顯示UTF-8那個(gè)選Reopen with Encoding然后選 GBK就能正常顯示。確認(rèn)內(nèi)容對(duì)了之后再選Save with Encoding存成 UTF-8完成轉(zhuǎn)碼。這個(gè)先 Reopen 再 Save的流程是 VSCode 處理編碼問(wèn)題的標(biāo)準(zhǔn)動(dòng)作比手動(dòng)改文件靠譜得多。VSCode 運(yùn)行 Java 報(bào)亂碼也是高頻問(wèn)題。根因通常是編譯時(shí)用的編碼和運(yùn)行時(shí)控制臺(tái)編碼不一致?？梢栽趕ettings.json里加java.jdt.ls.vmargs: -Dfile.encodingUTF-8, terminal.integrated.defaultProfile.windows: Command Prompt配合chcp 65001基本能解決。如果還亂檢查一下JAVA_TOOL_OPTIONS環(huán)境變量有時(shí)候它被設(shè)成了-Dfile.encodingGBK會(huì)覆蓋你的設(shè)置。3.3 文件名亂碼與解壓亂碼的修復(fù)從 Linux 或 Mac 傳過(guò)來(lái)的壓縮包在 Windows 上解壓經(jīng)常出現(xiàn)文件名亂碼因?yàn)閴嚎s時(shí)用的是 UTF-8 文件名Windows 解壓工具按 GBK 解讀。7-Zip 有個(gè)設(shè)置項(xiàng)叫文件名編碼可以手動(dòng)指定成 UTF-8 或 GBK選對(duì)了文件名就正常。WinRAR 也有類似選項(xiàng)在選項(xiàng)-名稱編碼里。如果已經(jīng)解壓出一堆亂碼文件名可以用 Python 批量修復(fù)。核心思路是把亂碼文件名按錯(cuò)誤編碼還原成字節(jié)再用正確編碼解碼import os def fix_filename(path): for name in os.listdir(path): try: # 把亂碼名按 GBK 編碼回字節(jié)再按 UTF-8 解碼 fixed name.encode(gbk).decode(utf-8) os.rename(os.path.join(path, name), os.path.join(path, fixed)) print(f{name} - {fixed}) except Exception as e: print(f跳過(guò) {name}: {e}) fix_filename(./your_folder)這段代碼不是萬(wàn)能的如果原始字節(jié)已經(jīng)丟失就救不回來(lái)但對(duì)付UTF-8 被 GBK 讀這種可逆亂碼非常有效。注意先備份改錯(cuò)了文件名比亂碼更麻煩。4. Linux 與 macOS默認(rèn) UTF-8 也不代表萬(wàn)事大吉4.1 locale 配置與終端亂碼Linux 默認(rèn)用 UTF-8但前提是 locale 配對(duì)了。用locale命令看一眼如果LANG是zh_CN.GBK或者POSIX中文就可能亂。正確配置一般是export LANGzh_CN.UTF-8 export LC_ALLzh_CN.UTF-8LC_ALL優(yōu)先級(jí)最高會(huì)覆蓋其他LC_*變量。我建議在~/.bashrc或~/.zshrc里固定下來(lái)避免每次登錄都要設(shè)。如果系統(tǒng)沒(méi)裝zh_CN.UTF-8這個(gè) locale用locale -a看看有哪些沒(méi)有的話用locale-gen生成。minicom 這類串口工具亂碼是另一個(gè)經(jīng)典。它默認(rèn)可能用 GBK 或 Latin-1需要在配置里把字符集改成 UTF-8。minicom 里按CtrlA再按O進(jìn)配置找到Screen and keyboard把Character set改成 UTF-8。改完重啟 minicom 就正常了。4.2 解壓文件亂碼的兩種處理路徑Linux 解壓 Windows 傳來(lái)的 zip文件名亂碼很常見(jiàn)因?yàn)?zip 格式對(duì)文件名編碼沒(méi)有強(qiáng)制規(guī)定Windows 用 GBKLinux 用 UTF-8。unzip有個(gè)-O參數(shù)可以指定編碼unzip -O GBK your_file.zip如果unzip版本不支持-O有些發(fā)行版閹割了可以用7z7z x your_file.zip -mcp936-mcp936就是指定代碼頁(yè) 936GBK。或者用 Python 的zipfile模塊手動(dòng)處理思路和前面修文件名一樣。tar.gz 一般不會(huì)有這個(gè)問(wèn)題因?yàn)?tar 通常保留原始字節(jié)解壓后文件名就是對(duì)的。4.3 Mac 上的字體與編碼雙重坑Mac 上中文亂碼有時(shí)候不是編碼問(wèn)題而是字體缺失。比如打開(kāi)一個(gè)用了方正仿宋_GBK的 Word 文檔Mac 上沒(méi)裝這個(gè)字體就會(huì)顯示成方框或亂碼。這時(shí)候裝字體就行方正仿宋 GBK、方正小標(biāo)宋 GBK 這些在字體網(wǎng)站都能找到。裝完重啟 Word字體就正常了。Mac 的 Word 下載字體要注意版本有些字體是 Windows 專用的 TTFMac 裝了可能不識(shí)別。優(yōu)先找 OTF 或 Mac 版的 TTF。另外 Mac 的默認(rèn)編碼是 UTF-8和 Linux 一致所以 Mac 和 Linux 之間傳文件基本不會(huì)亂主要坑在 Mac 和 Windows 之間。5. 編程語(yǔ)言與工具鏈里的編碼實(shí)戰(zhàn)5.1 PythonUnicodeEncodeError 的根治方法Python 3 的字符串是 Unicode但寫(xiě)文件、打印到終端時(shí)會(huì)編碼成字節(jié)這一步最容易出UnicodeEncodeError: gbk codec cant encode character。根因是 Windows 上open()和print()默認(rèn)用 GBK遇到 GBK 表示不了的字符比如某些 emoji 或生僻字就報(bào)錯(cuò)。根治辦法是顯式指定編碼永遠(yuǎn)不要依賴默認(rèn)值# 寫(xiě)文件 with open(out.txt, w, encodingutf-8) as f: f.write(中文內(nèi)容) # 讀文件 with open(in.txt, r, encodingutf-8) as f: content f.read() # 打印時(shí)如果終端是 GBK可以重定向 import sys sys.stdout.reconfigure(encodingutf-8)sys.stdout.reconfigure是 Python 3.7 的用法能把標(biāo)準(zhǔn)輸出切成 UTF-8。如果版本低可以用io.TextIOWrapper包一層。核心原則所有涉及編碼的地方都顯式寫(xiě)出來(lái)別偷懶。5.2 Javafile.encoding 與編譯運(yùn)行的一致性Java 的亂碼幾乎都和file.encoding有關(guān)。這個(gè)系統(tǒng)屬性決定了 JVM 默認(rèn)用什么編碼讀寫(xiě)文件和控制臺(tái)。Windows 上默認(rèn)是 GBKLinux 上默認(rèn)是 UTF-8。你看到的Picked up JAVA_TOOL_OPTIONS: -Dfile.encodingGBK就是它在作祟。解決辦法有兩個(gè)方向。一是統(tǒng)一改成 UTF-8java -Dfile.encodingUTF-8 YourClass或者在代碼里盡早設(shè)置System.setProperty(file.encoding, UTF-8);但注意file.encoding在 JVM 啟動(dòng)后再改對(duì)已經(jīng)初始化的部分可能無(wú)效最好在啟動(dòng)參數(shù)里設(shè)。二是編譯時(shí)也指定編碼javac -encoding UTF-8 YourClass.java編譯和運(yùn)行兩邊編碼必須一致否則源碼里的中文常量在編譯時(shí)就已經(jīng)亂了。IDEA 里要在 Settings-File Encodings 里把 Global、Project、Default 全設(shè)成 UTF-8并勾選Transparent native-to-ascii conversion針對(duì) properties 文件。5.3 MATLAB、LabVIEW、ABAP 等工程工具的編碼處理MATLAB 2023 的中文注釋亂碼是個(gè)新問(wèn)題。它的編碼器默認(rèn)是 GBK但新版本編輯器可能按 UTF-8 存文件導(dǎo)致注釋亂。改法是在matlab.prf或偏好設(shè)置里把編碼改成 UTF-8或者用命令feature(DefaultCharacterSet, UTF-8)改完重啟 MATLAB。如果已有文件是 GBK需要先轉(zhuǎn)碼再打開(kāi)否則改了設(shè)置也救不回已經(jīng)亂的內(nèi)容。LabVIEW 里 GBK 轉(zhuǎn) Unicode 要用字符串轉(zhuǎn)換函數(shù)把 GBK 字節(jié)數(shù)組先按 GBK 解碼成字符串再轉(zhuǎn)成 Unicode 字符串。LabVIEW 內(nèi)部用 Unicode所以關(guān)鍵是入口處把外部字節(jié)正確解碼。ABAP 的 UTF-8 轉(zhuǎn) ANSI 類似用CL_ABAP_CONV_IN_CE和CL_ABAP_CONV_OUT_CE兩個(gè)類做轉(zhuǎn)換指定源編碼和目標(biāo)編碼即可。Tecplot 報(bào)no mapping for unicode通常是數(shù)據(jù)文件里有它不認(rèn)識(shí)的字符檢查一下文件編碼轉(zhuǎn)成 ASCII 或 UTF-8 無(wú) BOM 再試。PaddleOCR 識(shí)別亂碼多半是輸入圖片的編碼或字體問(wèn)題不是 OCR 本身的鍋。6. 數(shù)據(jù)庫(kù)、網(wǎng)頁(yè)與傳輸環(huán)節(jié)的編碼一致性6.1 數(shù)據(jù)庫(kù)連接串里的編碼參數(shù)MySQL 亂碼的經(jīng)典原因是連接編碼、表編碼、字段編碼三者不一致。連接串里要加jdbc:mysql://host:3306/db?useUnicodetruecharacterEncodingutf8characterEncodingutf8告訴驅(qū)動(dòng)用 UTF-8 通信。表建的時(shí)候用DEFAULT CHARSETutf8mb4字段也繼承。utf8mb4比utf8多支持 emoji現(xiàn)在建議直接用utf8mb4。三處一致了中文就不會(huì)亂。排查時(shí)用SHOW VARIABLES LIKE character%看服務(wù)器配置用SHOW CREATE TABLE看表編碼。如果發(fā)現(xiàn)表是 latin1用ALTER TABLE ... CONVERT TO CHARACTER SET utf8mb4轉(zhuǎn)過(guò)來(lái)。轉(zhuǎn)之前備份大數(shù)據(jù)量轉(zhuǎn)換可能鎖表。6.2 HTML 的 meta charset 與 BOM 問(wèn)題網(wǎng)頁(yè)亂碼先看meta charsetutf-8有沒(méi)有寫(xiě)對(duì)位置要在head最前面越早越好讓瀏覽器盡早知道編碼。如果 meta 寫(xiě)的是 utf-8 但文件實(shí)際是 GBK照樣亂。這時(shí)候要么改文件編碼要么改 meta。!doctype htmlhtml langzh-cnheadmeta charsetutf-8這套是標(biāo)準(zhǔn)寫(xiě)法lang 用 zh-cn 或 zh-hk 都行主要影響字體和斷詞不影響編碼。BOM 是個(gè)坑UTF-8 帶 BOM 的文件在某些老瀏覽器或 PHP 里會(huì)在頁(yè)面頂部多出空白或亂碼建議網(wǎng)頁(yè)文件存成UTF-8 無(wú) BOM。6.3 抓包工具與接口傳輸?shù)膩y碼Charles 抓包亂碼通常是響應(yīng)頭里的Content-Type沒(méi)帶 charset或者帶了但和實(shí)際編碼不符。Charles 里可以手動(dòng)設(shè)置解碼方式在響應(yīng)上右鍵選Encoding指定。接口傳輸建議統(tǒng)一用 UTF-8請(qǐng)求和響應(yīng)頭都帶charsetutf-8這樣兩端不會(huì)猜?？缦到y(tǒng)傳文件時(shí)最穩(wěn)的做法是傳輸前統(tǒng)一轉(zhuǎn)成 UTF-8接收端也按 UTF-8 讀。如果必須傳 GBK就在文件名或協(xié)議頭里標(biāo)明編碼別讓對(duì)方猜。猜編碼是亂碼的最大來(lái)源。7. 一套可復(fù)用的亂碼排查流程7.1 先定位環(huán)節(jié)再動(dòng)手改遇到亂碼別急著改代碼先按這個(gè)順序定位第一步確認(rèn)原始字節(jié)是什么編碼。用十六進(jìn)制工具如xxd、HxD看幾個(gè)字節(jié)對(duì)照編碼表判斷。第二步確認(rèn)讀取端用什么編碼。第三步看兩者是否一致。不一致的地方就是問(wèn)題所在。我常用的命令是file -i your_file.txt # 看文件編碼 xxd your_file.txt | head # 看字節(jié) iconv -f GBK -t UTF-8 in.txt -o out.txt # 轉(zhuǎn)碼file -i能給出 MIME 編碼信息xxd看原始字節(jié)iconv做轉(zhuǎn)碼。這三個(gè)工具組合起來(lái)大部分亂碼都能定位。7.2 轉(zhuǎn)碼的正確姿勢(shì)與不可逆情況轉(zhuǎn)碼用iconv或編程語(yǔ)言的轉(zhuǎn)換函數(shù)核心是先解碼再編碼不要直接改字節(jié)。Python 里就是s.encode(gbk).decode(utf-8)這種鏈?zhǔn)讲僮鞣较蛞獙?duì)。不可逆的情況主要有兩種一是字節(jié)被替換成了或錕斤拷原始信息已丟失二是字符在目標(biāo)編碼里根本不存在比如向 GBK 寫(xiě) emoji只能丟或替換。這兩種情況只能從源頭重新生成數(shù)據(jù)沒(méi)有技術(shù)手段能恢復(fù)。7.3 預(yù)防勝于治療統(tǒng)一 UTF-8 的工程規(guī)范與其每次亂碼了再救不如一開(kāi)始就統(tǒng)一。我的建議是項(xiàng)目?jī)?nèi)所有文本文件、源碼、配置、數(shù)據(jù)庫(kù)、接口全部用 UTF-8終端和編輯器也設(shè)成 UTF-8。團(tuán)隊(duì)里寫(xiě)進(jìn)規(guī)范新人入職第一件事就是配編碼。這樣雖然偶爾和老系統(tǒng)交互時(shí)要轉(zhuǎn)一下但整體亂碼率能降 90% 以上。具體清單源碼文件 UTF-8 無(wú) BOM數(shù)據(jù)庫(kù) utf8mb4連接串帶 characterEncodingHTML meta 寫(xiě) utf-8終端 chcp 65001 或 locale 設(shè) UTF-8Git 配core.autocrlf和i18n.commitEncodingutf-8。這些配好基本告別亂碼。8. 幾個(gè)容易被忽略的細(xì)節(jié)與我的實(shí)操心得8.1 字體亂碼和編碼亂碼要分開(kāi)治很多人把方框字當(dāng)成編碼問(wèn)題折騰半天編碼沒(méi)用。方框、豆腐塊是字體缺失不是編碼錯(cuò)。ArcGIS 圖例亂碼、Acrobat 缺字體亂碼、Mac Word 方正字體亂碼都是這一類。解決辦法是裝對(duì)應(yīng)字體或者把文檔里的字體替換成系統(tǒng)有的。判斷方法很簡(jiǎn)單如果復(fù)制這些亂碼到別處能正常顯示那就是字體問(wèn)題如果復(fù)制出來(lái)還是亂才是編碼問(wèn)題。8.2 編碼轉(zhuǎn)換中的性能與數(shù)據(jù)安全大批量文件轉(zhuǎn)碼時(shí)別用腳本直接原地改先復(fù)制一份再轉(zhuǎn)。我見(jiàn)過(guò)有人寫(xiě)腳本批量iconv覆蓋原文件結(jié)果中途出錯(cuò)一半文件損壞。正確做法是轉(zhuǎn)到新目錄校驗(yàn)無(wú)誤后再替換。另外轉(zhuǎn)碼是 CPU 密集型操作幾萬(wàn)個(gè)文件建議分批處理加個(gè)進(jìn)度輸出別一口氣跑完不知道卡在哪。8.3 關(guān)于亂碼久愛(ài)這類搜索詞的說(shuō)明搜索熱詞里出現(xiàn)亂碼久愛(ài)這種詞多半是用戶輸入時(shí)本身就被亂碼了或者是在找某個(gè)特定場(chǎng)景。這類詞沒(méi)有通用技術(shù)含義不用糾結(jié)。真正有價(jià)值的是那些具體場(chǎng)景詞比如printf 中文亂碼vscode 終端中文亂碼linux 解壓文件亂碼這些才是真實(shí)痛點(diǎn)按前面章節(jié)的方法逐個(gè)擊破即可。8.4 我個(gè)人的三條鐵律最后分享我這些年總結(jié)的三條鐵律。第一永遠(yuǎn)顯式指定編碼不管是open()、javac還是數(shù)據(jù)庫(kù)連接別信默認(rèn)值。第二看到亂碼先看字節(jié)別猜xxd一敲真相大白。第三統(tǒng)一 UTF-8從源頭減少轉(zhuǎn)換環(huán)節(jié)轉(zhuǎn)換越少出錯(cuò)概率越低。這三條看著簡(jiǎn)單但能解決我遇到的九成以上亂碼問(wèn)題。編碼這事說(shuō)到底不復(fù)雜就是誰(shuí)寫(xiě)的、誰(shuí)讀的、規(guī)則一不一致三個(gè)問(wèn)題。把這條鏈路理清楚再配合工具定位亂碼就不再是玄學(xué)而是一個(gè)可以穩(wěn)定復(fù)現(xiàn)和修復(fù)的工程問(wèn)題。 中文亂碼全解析：從編碼原理到Windows、Linux、macOS實(shí)戰(zhàn)修復(fù)
1. 亂碼不是玄學(xué)是編碼鏈路里某一環(huán)對(duì)不上干開(kāi)發(fā)這行十幾年被問(wèn)得最多的問(wèn)題里為什么我這里中文顯示成亂碼絕對(duì)排前三。很多人第一次遇到亂碼時(shí)的反應(yīng)是電腦壞了軟件有bug其實(shí)亂碼從來(lái)不是隨機(jī)事件它是一條非常確定的因果鏈一段文字從產(chǎn)生到顯示中間經(jīng)過(guò)了編碼、傳輸、存儲(chǔ)、解碼四個(gè)環(huán)節(jié)只要其中任意兩個(gè)環(huán)節(jié)用的字符集不一致亂碼就必然出現(xiàn)。理解這一點(diǎn)后面所有的排查都有了方向。先把最基礎(chǔ)的概念捋清楚不然后面全是空中樓閣。字符集Character Set是一張字符到編號(hào)的映射表比如 Unicode 規(guī)定中這個(gè)字的編號(hào)是 U4E2D編碼Encoding則是把這張表里的編號(hào)變成實(shí)際字節(jié)的規(guī)則比如 UTF-8 把 U4E2D 編成E4 B8 AD三個(gè)字節(jié)而 GBK 把它編成D6 D0兩個(gè)字節(jié)。同一個(gè)中字UTF-8 和 GBK 給出的字節(jié)完全不同這就是亂碼的根源。我見(jiàn)過(guò)太多人把UTF-8和Unicode混為一談。Unicode 是字符集UTF-8 是它的一種編碼實(shí)現(xiàn)UTF-16、UTF-32 也是。GBK、GB2312、GB18030 則是另一套獨(dú)立的字符集加編碼體系主要覆蓋中文。ASCII 是最早的只有 128 個(gè)字符連中文都裝不下。搞清楚這幾層關(guān)系你就能明白亂碼的本質(zhì)是用 A 規(guī)則寫(xiě)的字節(jié)被用 B 規(guī)則讀了。這篇文章適合所有被中文亂碼折磨過(guò)的人——不管你是寫(xiě) Java、Python、C 的后端還是搞 MATLAB、LabVIEW、ABAP 的工程黨或者是天天跟終端、編輯器、數(shù)據(jù)庫(kù)打交道的運(yùn)維。我會(huì)從原理講到實(shí)戰(zhàn)把 Windows、Linux、macOS 三大平臺(tái)以及編輯器、終端、數(shù)據(jù)庫(kù)、文件傳輸這些高頻場(chǎng)景的亂碼問(wèn)題挨個(gè)拆開(kāi)給出可以直接抄的解決方案。2. 從字節(jié)到屏幕一次中文顯示到底經(jīng)歷了什么2.1 編碼、解碼、轉(zhuǎn)碼三個(gè)動(dòng)作的區(qū)別很多人排查亂碼時(shí)腦子是糊的因?yàn)榉植磺寰幋a和解碼到底誰(shuí)對(duì)誰(shuí)。我用一個(gè)寄快遞的類比編碼就是打包把中這個(gè)字按某種規(guī)則塞進(jìn)箱子字節(jié)流解碼就是拆包按某種規(guī)則把箱子里的東西還原成字轉(zhuǎn)碼就是換箱子把 A 規(guī)則打的包拆開(kāi)再用 B 規(guī)則重新打包。關(guān)鍵點(diǎn)在于編碼和解碼必須用同一套規(guī)則否則拆出來(lái)的就是垃圾。你拿 UTF-8 的鑰匙去開(kāi) GBK 的鎖出來(lái)的就是涓枃這種鬼東西——這其實(shí)是中文兩個(gè)字的 UTF-8 字節(jié)被當(dāng)成 GBK 解讀的經(jīng)典結(jié)果。反過(guò)來(lái)GBK 字節(jié)被當(dāng)成 UTF-8 讀通常會(huì)出現(xiàn)這種替換字符因?yàn)?GBK 的字節(jié)序列往往不構(gòu)成合法的 UTF-8 序列。轉(zhuǎn)碼則是解決亂碼的正道。當(dāng)你確認(rèn)原始字節(jié)是 GBK但目標(biāo)環(huán)境要 UTF-8正確做法是用 GBK 解碼得到正確的字符再用 UTF-8 編碼寫(xiě)出去。千萬(wàn)不要直接對(duì)字節(jié)做替換那樣只會(huì)越搞越亂。2.2 為什么涓枃和錕斤拷會(huì)反復(fù)出現(xiàn)這兩個(gè)詞是中文亂碼界的名場(chǎng)面認(rèn)識(shí)它們能幫你快速定位問(wèn)題。涓枃這類現(xiàn)象是UTF-8 字節(jié)被 GBK 解碼的典型產(chǎn)物。UTF-8 里一個(gè)中文字符占 3 個(gè)字節(jié)GBK 里占 2 個(gè)字節(jié)字節(jié)數(shù)對(duì)不上于是每 3 個(gè) UTF-8 字節(jié)被硬拆成 1.5 個(gè) GBK 字符拼出來(lái)的就是一堆生僻字?？吹竭@種每個(gè)字都認(rèn)識(shí)但連起來(lái)不像話的亂碼基本可以斷定是 UTF-8 被當(dāng) GBK 讀了。錕斤拷則是另一個(gè)方向的經(jīng)典GBK 字節(jié)被 UTF-8 解碼失敗后被替換成 UFFFD替換字符再經(jīng)過(guò)一次錯(cuò)誤編碼產(chǎn)生的。它通常出現(xiàn)在數(shù)據(jù)被反復(fù)轉(zhuǎn)碼、或者經(jīng)過(guò)不支持原始編碼的中間環(huán)節(jié)之后?？吹藉K斤拷說(shuō)明數(shù)據(jù)已經(jīng)臟了原始字節(jié)可能已經(jīng)丟失恢復(fù)難度大很多。提示判斷亂碼方向有個(gè)土辦法——如果亂碼里全是看起來(lái)像漢字但很怪的字多半是 UTF-8 被 GBK 讀如果出現(xiàn)大量或錕斤拷多半是 GBK 被 UTF-8 讀且已經(jīng)發(fā)生替換。2.3 編碼問(wèn)題的三大高發(fā)地帶根據(jù)我這些年的排查經(jīng)驗(yàn)亂碼集中爆發(fā)在三個(gè)地方記住它們能省你一半時(shí)間。第一是文件讀寫(xiě)。用 Python 的open()不指定encoding在 Windows 上默認(rèn)走 GBK在 Linux 上默認(rèn)走 UTF-8同一份代碼換個(gè)系統(tǒng)就亂。第二是終端與命令行。Windows 的 cmd 默認(rèn)代碼頁(yè)是 936GBKPowerShell 老版本也是而你的程序輸出的是 UTF-8兩邊一撞就亂。第三是跨系統(tǒng)傳輸。文件從 Windows 傳到 Linux從 Mac 傳到服務(wù)器編碼不會(huì)自動(dòng)轉(zhuǎn)換全靠你手動(dòng)處理。下面這張表是我整理的常見(jiàn)亂碼現(xiàn)象與對(duì)應(yīng)原因遇到問(wèn)題先對(duì)號(hào)入座亂碼現(xiàn)象大概率原因典型場(chǎng)景涓枃、鏂囦歡UTF-8 字節(jié)被 GBK 解碼網(wǎng)頁(yè)、日志、跨平臺(tái)文件錕斤拷、大量 GBK 字節(jié)被 UTF-8 解碼并替換數(shù)據(jù)庫(kù)、多次轉(zhuǎn)碼后問(wèn)號(hào) ???目標(biāo)編碼無(wú)法表示該字符向 GBK/ASCII 寫(xiě)入生僻字方框 □□□字體缺失不是編碼問(wèn)題PDF、ArcGIS 圖例部分字正常部分亂混合編碼或截?cái)嗥唇幼址?、分包傳?. Windows 平臺(tái)亂碼代碼頁(yè) 936 是繞不開(kāi)的坎3.1 cmd 與 PowerShell 的中文輸出處理Windows 中文版的默認(rèn)代碼頁(yè)是 936也就是 GBK。這意味著你在 cmd 里跑一個(gè)輸出 UTF-8 的程序中文必然亂。最直接的解決辦法是在程序開(kāi)頭或運(yùn)行前把代碼頁(yè)切成 UTF-8chcp 65001chcp是 change code page 的縮寫(xiě)65001 就是 UTF-8 的代碼頁(yè)編號(hào)。切完之后再運(yùn)行程序中文就正常了。但要注意chcp 65001 只對(duì)當(dāng)前這個(gè)命令行窗口生效關(guān)掉就恢復(fù)。想永久改得去注冊(cè)表或系統(tǒng)區(qū)域設(shè)置里動(dòng)但我不建議永久改因?yàn)楹芏嗬铣绦蛞蕾?936改了反而讓它們亂。PowerShell 的情況稍微復(fù)雜。老版本 PowerShell 5.x 默認(rèn)輸出編碼是 GBK處理 UTF-8 文件時(shí)經(jīng)常亂?？梢栽谀_本開(kāi)頭加[Console]::OutputEncoding [System.Text.Encoding]::UTF8 $OutputEncoding [System.Text.Encoding]::UTF8這兩行分別管控制臺(tái)輸出和管道輸出的編碼。我踩過(guò)的坑是只設(shè)了第一行結(jié)果管道傳給下一個(gè)命令時(shí)還是亂必須兩行都設(shè)。另外.ps1腳本文件本身如果存成 UTF-8 帶 BOM老版本 PowerShell 能識(shí)別存成 UTF-8 無(wú) BOM就可能把中文當(dāng)亂碼解析建議腳本文件統(tǒng)一存成UTF-8 with BOM。3.2 記事本、VSCode 的編碼識(shí)別陷阱Windows 高版本W(wǎng)in10 1903 之后的記事本默認(rèn)改成 UTF-8 了這本來(lái)是好事但帶來(lái)一個(gè)新問(wèn)題打開(kāi)老文件時(shí)記事本可能用 UTF-8 去讀 GBK 內(nèi)容直接亂給你看。解決辦法是打開(kāi)時(shí)手動(dòng)選編碼或者用另存為看當(dāng)前編碼再?zèng)Q定。VSCode 相對(duì)聰明它有自動(dòng)編碼檢測(cè)但檢測(cè)不是萬(wàn)能的。我遇到過(guò) VSCode 把 GBK 文件誤判成 UTF-8 的情況中文全亂。這時(shí)候點(diǎn)右下角的編碼按鈕顯示UTF-8那個(gè)選Reopen with Encoding然后選 GBK就能正常顯示。確認(rèn)內(nèi)容對(duì)了之后再選Save with Encoding存成 UTF-8完成轉(zhuǎn)碼。這個(gè)先 Reopen 再 Save的流程是 VSCode 處理編碼問(wèn)題的標(biāo)準(zhǔn)動(dòng)作比手動(dòng)改文件靠譜得多。VSCode 運(yùn)行 Java 報(bào)亂碼也是高頻問(wèn)題。根因通常是編譯時(shí)用的編碼和運(yùn)行時(shí)控制臺(tái)編碼不一致?？梢栽趕ettings.json里加java.jdt.ls.vmargs: -Dfile.encodingUTF-8, terminal.integrated.defaultProfile.windows: Command Prompt配合chcp 65001基本能解決。如果還亂檢查一下JAVA_TOOL_OPTIONS環(huán)境變量有時(shí)候它被設(shè)成了-Dfile.encodingGBK會(huì)覆蓋你的設(shè)置。3.3 文件名亂碼與解壓亂碼的修復(fù)從 Linux 或 Mac 傳過(guò)來(lái)的壓縮包在 Windows 上解壓經(jīng)常出現(xiàn)文件名亂碼因?yàn)閴嚎s時(shí)用的是 UTF-8 文件名Windows 解壓工具按 GBK 解讀。7-Zip 有個(gè)設(shè)置項(xiàng)叫文件名編碼可以手動(dòng)指定成 UTF-8 或 GBK選對(duì)了文件名就正常。WinRAR 也有類似選項(xiàng)在選項(xiàng)-名稱編碼里。如果已經(jīng)解壓出一堆亂碼文件名可以用 Python 批量修復(fù)。核心思路是把亂碼文件名按錯(cuò)誤編碼還原成字節(jié)再用正確編碼解碼import os def fix_filename(path): for name in os.listdir(path): try: # 把亂碼名按 GBK 編碼回字節(jié)再按 UTF-8 解碼 fixed name.encode(gbk).decode(utf-8) os.rename(os.path.join(path, name), os.path.join(path, fixed)) print(f{name} - {fixed}) except Exception as e: print(f跳過(guò) {name}: {e}) fix_filename(./your_folder)這段代碼不是萬(wàn)能的如果原始字節(jié)已經(jīng)丟失就救不回來(lái)但對(duì)付UTF-8 被 GBK 讀這種可逆亂碼非常有效。注意先備份改錯(cuò)了文件名比亂碼更麻煩。4. Linux 與 macOS默認(rèn) UTF-8 也不代表萬(wàn)事大吉4.1 locale 配置與終端亂碼Linux 默認(rèn)用 UTF-8但前提是 locale 配對(duì)了。用locale命令看一眼如果LANG是zh_CN.GBK或者POSIX中文就可能亂。正確配置一般是export LANGzh_CN.UTF-8 export LC_ALLzh_CN.UTF-8LC_ALL優(yōu)先級(jí)最高會(huì)覆蓋其他LC_*變量。我建議在~/.bashrc或~/.zshrc里固定下來(lái)避免每次登錄都要設(shè)。如果系統(tǒng)沒(méi)裝zh_CN.UTF-8這個(gè) locale用locale -a看看有哪些沒(méi)有的話用locale-gen生成。minicom 這類串口工具亂碼是另一個(gè)經(jīng)典。它默認(rèn)可能用 GBK 或 Latin-1需要在配置里把字符集改成 UTF-8。minicom 里按CtrlA再按O進(jìn)配置找到Screen and keyboard把Character set改成 UTF-8。改完重啟 minicom 就正常了。4.2 解壓文件亂碼的兩種處理路徑Linux 解壓 Windows 傳來(lái)的 zip文件名亂碼很常見(jiàn)因?yàn)?zip 格式對(duì)文件名編碼沒(méi)有強(qiáng)制規(guī)定Windows 用 GBKLinux 用 UTF-8。unzip有個(gè)-O參數(shù)可以指定編碼unzip -O GBK your_file.zip如果unzip版本不支持-O有些發(fā)行版閹割了可以用7z7z x your_file.zip -mcp936-mcp936就是指定代碼頁(yè) 936GBK。或者用 Python 的zipfile模塊手動(dòng)處理思路和前面修文件名一樣。tar.gz 一般不會(huì)有這個(gè)問(wèn)題因?yàn)?tar 通常保留原始字節(jié)解壓后文件名就是對(duì)的。4.3 Mac 上的字體與編碼雙重坑Mac 上中文亂碼有時(shí)候不是編碼問(wèn)題而是字體缺失。比如打開(kāi)一個(gè)用了方正仿宋_GBK的 Word 文檔Mac 上沒(méi)裝這個(gè)字體就會(huì)顯示成方框或亂碼。這時(shí)候裝字體就行方正仿宋 GBK、方正小標(biāo)宋 GBK 這些在字體網(wǎng)站都能找到。裝完重啟 Word字體就正常了。Mac 的 Word 下載字體要注意版本有些字體是 Windows 專用的 TTFMac 裝了可能不識(shí)別。優(yōu)先找 OTF 或 Mac 版的 TTF。另外 Mac 的默認(rèn)編碼是 UTF-8和 Linux 一致所以 Mac 和 Linux 之間傳文件基本不會(huì)亂主要坑在 Mac 和 Windows 之間。5. 編程語(yǔ)言與工具鏈里的編碼實(shí)戰(zhàn)5.1 PythonUnicodeEncodeError 的根治方法Python 3 的字符串是 Unicode但寫(xiě)文件、打印到終端時(shí)會(huì)編碼成字節(jié)這一步最容易出UnicodeEncodeError: gbk codec cant encode character。根因是 Windows 上open()和print()默認(rèn)用 GBK遇到 GBK 表示不了的字符比如某些 emoji 或生僻字就報(bào)錯(cuò)。根治辦法是顯式指定編碼永遠(yuǎn)不要依賴默認(rèn)值# 寫(xiě)文件 with open(out.txt, w, encodingutf-8) as f: f.write(中文內(nèi)容) # 讀文件 with open(in.txt, r, encodingutf-8) as f: content f.read() # 打印時(shí)如果終端是 GBK可以重定向 import sys sys.stdout.reconfigure(encodingutf-8)sys.stdout.reconfigure是 Python 3.7 的用法能把標(biāo)準(zhǔn)輸出切成 UTF-8。如果版本低可以用io.TextIOWrapper包一層。核心原則所有涉及編碼的地方都顯式寫(xiě)出來(lái)別偷懶。5.2 Javafile.encoding 與編譯運(yùn)行的一致性Java 的亂碼幾乎都和file.encoding有關(guān)。這個(gè)系統(tǒng)屬性決定了 JVM 默認(rèn)用什么編碼讀寫(xiě)文件和控制臺(tái)。Windows 上默認(rèn)是 GBKLinux 上默認(rèn)是 UTF-8。你看到的Picked up JAVA_TOOL_OPTIONS: -Dfile.encodingGBK就是它在作祟。解決辦法有兩個(gè)方向。一是統(tǒng)一改成 UTF-8java -Dfile.encodingUTF-8 YourClass或者在代碼里盡早設(shè)置System.setProperty(file.encoding, UTF-8);但注意file.encoding在 JVM 啟動(dòng)后再改對(duì)已經(jīng)初始化的部分可能無(wú)效最好在啟動(dòng)參數(shù)里設(shè)。二是編譯時(shí)也指定編碼javac -encoding UTF-8 YourClass.java編譯和運(yùn)行兩邊編碼必須一致否則源碼里的中文常量在編譯時(shí)就已經(jīng)亂了。IDEA 里要在 Settings-File Encodings 里把 Global、Project、Default 全設(shè)成 UTF-8并勾選Transparent native-to-ascii conversion針對(duì) properties 文件。5.3 MATLAB、LabVIEW、ABAP 等工程工具的編碼處理MATLAB 2023 的中文注釋亂碼是個(gè)新問(wèn)題。它的編碼器默認(rèn)是 GBK但新版本編輯器可能按 UTF-8 存文件導(dǎo)致注釋亂。改法是在matlab.prf或偏好設(shè)置里把編碼改成 UTF-8或者用命令feature(DefaultCharacterSet, UTF-8)改完重啟 MATLAB。如果已有文件是 GBK需要先轉(zhuǎn)碼再打開(kāi)否則改了設(shè)置也救不回已經(jīng)亂的內(nèi)容。LabVIEW 里 GBK 轉(zhuǎn) Unicode 要用字符串轉(zhuǎn)換函數(shù)把 GBK 字節(jié)數(shù)組先按 GBK 解碼成字符串再轉(zhuǎn)成 Unicode 字符串。LabVIEW 內(nèi)部用 Unicode所以關(guān)鍵是入口處把外部字節(jié)正確解碼。ABAP 的 UTF-8 轉(zhuǎn) ANSI 類似用CL_ABAP_CONV_IN_CE和CL_ABAP_CONV_OUT_CE兩個(gè)類做轉(zhuǎn)換指定源編碼和目標(biāo)編碼即可。Tecplot 報(bào)no mapping for unicode通常是數(shù)據(jù)文件里有它不認(rèn)識(shí)的字符檢查一下文件編碼轉(zhuǎn)成 ASCII 或 UTF-8 無(wú) BOM 再試。PaddleOCR 識(shí)別亂碼多半是輸入圖片的編碼或字體問(wèn)題不是 OCR 本身的鍋。6. 數(shù)據(jù)庫(kù)、網(wǎng)頁(yè)與傳輸環(huán)節(jié)的編碼一致性6.1 數(shù)據(jù)庫(kù)連接串里的編碼參數(shù)MySQL 亂碼的經(jīng)典原因是連接編碼、表編碼、字段編碼三者不一致。連接串里要加jdbc:mysql://host:3306/db?useUnicodetruecharacterEncodingutf8characterEncodingutf8告訴驅(qū)動(dòng)用 UTF-8 通信。表建的時(shí)候用DEFAULT CHARSETutf8mb4字段也繼承。utf8mb4比utf8多支持 emoji現(xiàn)在建議直接用utf8mb4。三處一致了中文就不會(huì)亂。排查時(shí)用SHOW VARIABLES LIKE character%看服務(wù)器配置用SHOW CREATE TABLE看表編碼。如果發(fā)現(xiàn)表是 latin1用ALTER TABLE ... CONVERT TO CHARACTER SET utf8mb4轉(zhuǎn)過(guò)來(lái)。轉(zhuǎn)之前備份大數(shù)據(jù)量轉(zhuǎn)換可能鎖表。6.2 HTML 的 meta charset 與 BOM 問(wèn)題網(wǎng)頁(yè)亂碼先看meta charsetutf-8有沒(méi)有寫(xiě)對(duì)位置要在head最前面越早越好讓瀏覽器盡早知道編碼。如果 meta 寫(xiě)的是 utf-8 但文件實(shí)際是 GBK照樣亂。這時(shí)候要么改文件編碼要么改 meta。!doctype htmlhtml langzh-cnheadmeta charsetutf-8這套是標(biāo)準(zhǔn)寫(xiě)法lang 用 zh-cn 或 zh-hk 都行主要影響字體和斷詞不影響編碼。BOM 是個(gè)坑UTF-8 帶 BOM 的文件在某些老瀏覽器或 PHP 里會(huì)在頁(yè)面頂部多出空白或亂碼建議網(wǎng)頁(yè)文件存成UTF-8 無(wú) BOM。6.3 抓包工具與接口傳輸?shù)膩y碼Charles 抓包亂碼通常是響應(yīng)頭里的Content-Type沒(méi)帶 charset或者帶了但和實(shí)際編碼不符。Charles 里可以手動(dòng)設(shè)置解碼方式在響應(yīng)上右鍵選Encoding指定。接口傳輸建議統(tǒng)一用 UTF-8請(qǐng)求和響應(yīng)頭都帶charsetutf-8這樣兩端不會(huì)猜?？缦到y(tǒng)傳文件時(shí)最穩(wěn)的做法是傳輸前統(tǒng)一轉(zhuǎn)成 UTF-8接收端也按 UTF-8 讀。如果必須傳 GBK就在文件名或協(xié)議頭里標(biāo)明編碼別讓對(duì)方猜。猜編碼是亂碼的最大來(lái)源。7. 一套可復(fù)用的亂碼排查流程7.1 先定位環(huán)節(jié)再動(dòng)手改遇到亂碼別急著改代碼先按這個(gè)順序定位第一步確認(rèn)原始字節(jié)是什么編碼。用十六進(jìn)制工具如xxd、HxD看幾個(gè)字節(jié)對(duì)照編碼表判斷。第二步確認(rèn)讀取端用什么編碼。第三步看兩者是否一致。不一致的地方就是問(wèn)題所在。我常用的命令是file -i your_file.txt # 看文件編碼 xxd your_file.txt | head # 看字節(jié) iconv -f GBK -t UTF-8 in.txt -o out.txt # 轉(zhuǎn)碼file -i能給出 MIME 編碼信息xxd看原始字節(jié)iconv做轉(zhuǎn)碼。這三個(gè)工具組合起來(lái)大部分亂碼都能定位。7.2 轉(zhuǎn)碼的正確姿勢(shì)與不可逆情況轉(zhuǎn)碼用iconv或編程語(yǔ)言的轉(zhuǎn)換函數(shù)核心是先解碼再編碼不要直接改字節(jié)。Python 里就是s.encode(gbk).decode(utf-8)這種鏈?zhǔn)讲僮鞣较蛞獙?duì)。不可逆的情況主要有兩種一是字節(jié)被替換成了或錕斤拷原始信息已丟失二是字符在目標(biāo)編碼里根本不存在比如向 GBK 寫(xiě) emoji只能丟或替換。這兩種情況只能從源頭重新生成數(shù)據(jù)沒(méi)有技術(shù)手段能恢復(fù)。7.3 預(yù)防勝于治療統(tǒng)一 UTF-8 的工程規(guī)范與其每次亂碼了再救不如一開(kāi)始就統(tǒng)一。我的建議是項(xiàng)目?jī)?nèi)所有文本文件、源碼、配置、數(shù)據(jù)庫(kù)、接口全部用 UTF-8終端和編輯器也設(shè)成 UTF-8。團(tuán)隊(duì)里寫(xiě)進(jìn)規(guī)范新人入職第一件事就是配編碼。這樣雖然偶爾和老系統(tǒng)交互時(shí)要轉(zhuǎn)一下但整體亂碼率能降 90% 以上。具體清單源碼文件 UTF-8 無(wú) BOM數(shù)據(jù)庫(kù) utf8mb4連接串帶 characterEncodingHTML meta 寫(xiě) utf-8終端 chcp 65001 或 locale 設(shè) UTF-8Git 配core.autocrlf和i18n.commitEncodingutf-8。這些配好基本告別亂碼。8. 幾個(gè)容易被忽略的細(xì)節(jié)與我的實(shí)操心得8.1 字體亂碼和編碼亂碼要分開(kāi)治很多人把方框字當(dāng)成編碼問(wèn)題折騰半天編碼沒(méi)用。方框、豆腐塊是字體缺失不是編碼錯(cuò)。ArcGIS 圖例亂碼、Acrobat 缺字體亂碼、Mac Word 方正字體亂碼都是這一類。解決辦法是裝對(duì)應(yīng)字體或者把文檔里的字體替換成系統(tǒng)有的。判斷方法很簡(jiǎn)單如果復(fù)制這些亂碼到別處能正常顯示那就是字體問(wèn)題如果復(fù)制出來(lái)還是亂才是編碼問(wèn)題。8.2 編碼轉(zhuǎn)換中的性能與數(shù)據(jù)安全大批量文件轉(zhuǎn)碼時(shí)別用腳本直接原地改先復(fù)制一份再轉(zhuǎn)。我見(jiàn)過(guò)有人寫(xiě)腳本批量iconv覆蓋原文件結(jié)果中途出錯(cuò)一半文件損壞。正確做法是轉(zhuǎn)到新目錄校驗(yàn)無(wú)誤后再替換。另外轉(zhuǎn)碼是 CPU 密集型操作幾萬(wàn)個(gè)文件建議分批處理加個(gè)進(jìn)度輸出別一口氣跑完不知道卡在哪。8.3 關(guān)于亂碼久愛(ài)這類搜索詞的說(shuō)明搜索熱詞里出現(xiàn)亂碼久愛(ài)這種詞多半是用戶輸入時(shí)本身就被亂碼了或者是在找某個(gè)特定場(chǎng)景。這類詞沒(méi)有通用技術(shù)含義不用糾結(jié)。真正有價(jià)值的是那些具體場(chǎng)景詞比如printf 中文亂碼vscode 終端中文亂碼linux 解壓文件亂碼這些才是真實(shí)痛點(diǎn)按前面章節(jié)的方法逐個(gè)擊破即可。8.4 我個(gè)人的三條鐵律最后分享我這些年總結(jié)的三條鐵律。第一永遠(yuǎn)顯式指定編碼不管是open()、javac還是數(shù)據(jù)庫(kù)連接別信默認(rèn)值。第二看到亂碼先看字節(jié)別猜xxd一敲真相大白。第三統(tǒng)一 UTF-8從源頭減少轉(zhuǎn)換環(huán)節(jié)轉(zhuǎn)換越少出錯(cuò)概率越低。這三條看著簡(jiǎn)單但能解決我遇到的九成以上亂碼問(wèn)題。編碼這事說(shuō)到底不復(fù)雜就是誰(shuí)寫(xiě)的、誰(shuí)讀的、規(guī)則一不一致三個(gè)問(wèn)題。把這條鏈路理清楚再配合工具定位亂碼就不再是玄學(xué)而是一個(gè)可以穩(wěn)定復(fù)現(xiàn)和修復(fù)的工程問(wèn)題。