編碼這個話題但凡干過程序員幾乎都跟它交過手。你以為是懂了的比如 UTF-8 和 Base64可真到排查亂碼、調(diào)接口、處理二進(jìn)制時才發(fā)現(xiàn)自己只是“聽說過”。我早年踩過不少坑后來把自己關(guān)在房間里對著調(diào)試器啃了一周才算把字符編碼、數(shù)值表示這些底層的邏輯理順了。今天這篇就把這些家底掏出來從最根本的 ASCII 講到浮點(diǎn)數(shù)再講到數(shù)碼管、壓縮編碼這類特定場景的編碼方式一次聊透。1. 編碼的本質(zhì)一臺“翻譯機(jī)”解決的是“怎么存”先看一個最樸素的例子電報(bào)時代摩爾斯電碼用“點(diǎn)”和“劃”的組合來表示字母和數(shù)字。這其實(shí)就是編碼——用一種約定的規(guī)則把人類能理解的信息變成機(jī)器或信道能存儲、傳輸?shù)男问?。到?jì)算機(jī)里面所有信息歸根到底只有兩個狀態(tài)通電和斷電對應(yīng) 1 和 0。所以不管你要存的是英文字母、漢字、圖片還是一個傳感器輸出的溫度值最終都得變成一串二進(jìn)制數(shù)組。編碼就是約定“怎么變”的規(guī)則。理解編碼有個關(guān)鍵心法編碼不是數(shù)據(jù)本身它是一層外殼。同一份信息用不同的編碼外殼包起來結(jié)果完全不同。比如“中”這個字在 GBK 里是D6 D0在 UTF-8 里是E4 B8 AD。你說哪個是真正的“中”都不是它們都只是“中”在這兩套規(guī)則下的二進(jìn)制表現(xiàn)形式。這就引出了一系列問題誰定規(guī)則規(guī)則怎么選怎么避免沖突1.1 字符編碼的演進(jìn)一套規(guī)則統(tǒng)一全球文字字符編碼是編碼里最貼近日常的一塊。最早是 ASCII7 位編碼定義了 128 個字符包含英文字母、數(shù)字、標(biāo)點(diǎn)和控制字符。7 位是一個很經(jīng)典的設(shè)計(jì)因?yàn)楫?dāng)時是用 1 字節(jié)存的最高位留作奇偶校驗(yàn)或擴(kuò)展用?，F(xiàn)在很多協(xié)議里還殘留著這個影子——比如 HTTP 頭、某些老協(xié)議的報(bào)文你都能看到最高位必須為 0 的約束。ASCII 只能表示英文漢字怎么辦中國搞出了 GB2312/GBK用兩個字節(jié)表示一個漢字并且最高位置 1跟 ASCII 區(qū)分開。這套思路在“各說各話”的時代沒問題但全球化之后一個系統(tǒng)里又要存中文、又要存日文、又要存阿拉伯文各自的編碼互不兼容亂碼成了一團(tuán)漿糊。所以誕生了 Unicode——它不負(fù)責(zé)“怎么存儲”只負(fù)責(zé)“給每個字符發(fā)一個唯一的身份證號”這個號叫碼點(diǎn)比如“中”的碼點(diǎn)是 U4E2D。碼點(diǎn)是編號存儲格式還得另說于是就有了 UTF-8、UTF-16。UTF-8 的核心是變長編碼英文 1 字節(jié)中文 3 字節(jié)特殊字符最多 4 字節(jié)。它兼容 ASCII這在很多老舊協(xié)議和邊界處理上幫了大忙。寫代碼時我習(xí)慣所有文件保存成 UTF-8 無 BOM數(shù)據(jù)庫連接串加上characterEncodingutf8請求響應(yīng)頭標(biāo)清charsetutf-8這樣能把 80% 的亂碼問題在發(fā)生前按死。1.2 字符編碼制作層面查表程序才是王道底層上面字符編碼的“翻譯”本質(zhì)上就是查表。一個很實(shí)用的技巧不管是什么編碼自己寫個查表程序把字節(jié)序列和碼點(diǎn)對應(yīng)關(guān)系打出來比任何文檔都直觀。比如用 Pythontext 中 print(text.encode(utf-8).hex()) # e4b8ad print(text.encode(gbk).hex()) # d6d0這一步能幫你建立直覺編碼轉(zhuǎn)換 先按 A 規(guī)則解碼成碼點(diǎn)再按 B 規(guī)則編碼成字節(jié)。很多人以為“改編碼”是直接把字節(jié)改掉不對。必須經(jīng)過中間層所以如果不知道原始編碼硬轉(zhuǎn)必然產(chǎn)生亂碼。1.3 字符編碼排查工具File 一眼看出原始編碼工具推薦我最常用的組合file命令識別編碼iconv做轉(zhuǎn)換hexdump看原始字節(jié)。在 Linux 下file -bi filename.txt iconv -f gbk -t utf-8 filename.txt filename_utf8.txt xxd filename.txt | head -20有一次拿到第三方導(dǎo)出的 CSV 亂碼file -bi顯示iso-8859-1系統(tǒng)判定它是單字節(jié)拉丁編碼其實(shí)是 GBK 的字節(jié)被強(qiáng)行按 ISO-8859-1 顯示了。這種場景很典型編碼本身沒變是“解讀方式”錯了。用iconv轉(zhuǎn)一下就好重點(diǎn)是把“字節(jié)流”和“解釋字節(jié)流的規(guī)則”分清楚。我在折騰 UTF-16 的報(bào)文時也常用hexdump看高位字節(jié)在前還是低位在前。2. 數(shù)值表示數(shù)據(jù)在內(nèi)存里到底長什么樣與字符編碼并列的是數(shù)值編碼。如果說字符編碼解決的是“文字怎么存”那數(shù)值編碼解決的就是“數(shù)字怎么算、怎么存、怎么不丟精度”。2.1 原碼、反碼與補(bǔ)碼為什么 CPU 只認(rèn)補(bǔ)碼先說整數(shù)的補(bǔ)碼這是每一個做底層開發(fā)的人必須刻在腦子里的知識。正數(shù)的補(bǔ)碼 原碼本身。負(fù)數(shù)的補(bǔ)碼 原碼按位取反再加 1。聽起來簡單但當(dāng)年我學(xué)到這里時一直不明白為什么這么折騰原因只有一個統(tǒng)一加減法不用判斷符號位。比如 3 和 -3 在 8 位補(bǔ)碼里3 00000011 -3 11111101如果直接用原碼3 (-3) 會得到 10000010這顯然不對。但用補(bǔ)碼00000011 11111101 00000000丟棄進(jìn)位結(jié)果恰好為 0。正是因?yàn)檫@種設(shè)計(jì)CPU 里只需要加法器不用單獨(dú)做減法器。而且補(bǔ)碼的范圍是非對稱的8 位補(bǔ)碼能表示 -128 到 127這個 -128 是沒有原碼和反碼對應(yīng)物的。所以寫代碼時Integer.MIN_VALUE取絕對值結(jié)果還是它自己——我就在面試題里見過不少人中招。2.2 大小端與字節(jié)序跨平臺坑你沒商量數(shù)值不是一行字節(jié)嗎為什么還分端序因?yàn)?CPU 對多字節(jié)數(shù)值的存儲順序不一致。x86 是小端低字節(jié)在前網(wǎng)絡(luò)字節(jié)序是大端高字節(jié)在前C 語言里有個老生常談的問題把 int 通過指針強(qiáng)行轉(zhuǎn)成 char*取出來的第一個字節(jié)在不同機(jī)器上結(jié)果不一樣。我當(dāng)年調(diào)一個跨平臺通信協(xié)議客戶端 x86 發(fā)送了一個 32 位整數(shù) 0x12345678小端序下內(nèi)存里是 78 56 34 12服務(wù)端按網(wǎng)絡(luò)字節(jié)序 12 34 56 78 去解析數(shù)值直接變成 305419896。這種事情不要靠記“哪臺機(jī)器是什么序”而是要在協(xié)議設(shè)計(jì)時定死一律按網(wǎng)絡(luò)字節(jié)序傳輸接收端再轉(zhuǎn)成本機(jī)序。C 語言有htonl/ntohlJava 里可以用ByteBuffer.order()指定大小端。最常見的信息媒介就是 Wireshark抓包后面板會明確標(biāo)出源 IP、目的 IP我這個例子是看報(bào)文前的 4 字節(jié)。2.3 浮點(diǎn)數(shù)IEEE 754 的“不精確”不是 bug是特性比整數(shù)更難纏的是浮點(diǎn)數(shù)。IEEE 754 把浮點(diǎn)數(shù)分成三部分符號位、指數(shù)位、尾數(shù)位。32 位 float1 位符號 8 位指數(shù) 23 位尾數(shù)。64 位 double1 位符號 11 位指數(shù) 52 位尾數(shù)。關(guān)鍵點(diǎn)是指數(shù)是有偏置的float 的偏置是 127。比如指數(shù)域存的是 130實(shí)際指數(shù)是 130 - 127 3。尾數(shù)是 1.xxx 的“隱藏位”省略了整數(shù)位的 1。那一句有名的坑0.1 0.2 不等于 0.3。原因就是 0.1 在二進(jìn)制里是無限循環(huán)小數(shù)轉(zhuǎn)換精度損失了。遇到金額計(jì)算任何底層開發(fā)都用整數(shù)分存儲而不是浮點(diǎn)。這種場景里不要用比較浮點(diǎn)數(shù)而是比較差值的絕對值是否小于某個極小值比如1e-9。再說一個隱藏問題浮點(diǎn)數(shù)里還有Infinity和NaN。C 里浮點(diǎn)運(yùn)算出現(xiàn)除零不會直接崩而是產(chǎn)生inf或nan但如果你把它轉(zhuǎn)成 int行為是未定義的。我在嵌入式設(shè)備上就遇到過溫度傳感器故障返回了nan一路傳上去渲染成文字直接把 UI 搞崩。加保護(hù)判斷isnan再兜底這個是常識。3. 實(shí)用編碼剖析URL、Base64以及你天天見但未必懂的隱藏邏輯字符編碼和數(shù)值編碼之外還有一組“應(yīng)用層編碼”它們不屬于存儲而是為了“傳輸安全”和“數(shù)據(jù)表達(dá)”而存在。3.1 URL 編碼 / 百分號編碼為什么空格有 3 種表現(xiàn)URL 編碼的本質(zhì)是把非安全字符替換成十六進(jìn)制字節(jié)形式前面加%。比如空格的 ASCII 是 0x20在 URL 里寫成%20但老式 HTML 表單里還有個大坑——號經(jīng)常被解釋為空格兩者混用會鬧出事故。我在調(diào) OAuth 簽名時就踩過一回客戶端把請求體的空格分別 urlencode 成%20和服務(wù)端驗(yàn)簽用的解碼規(guī)則是另一個標(biāo)準(zhǔn)兩邊對不上簽名一直失敗。正確的做法是知道自己在哪一層。Query 參數(shù)按application/x-www-form-urlencoded規(guī)則解碼是空格Path 部分用 RFC 3986 解碼就是。不要用正則手工替直接用語言自帶的URLSearchParams或parse_qs。3.2 Base64 編碼不是加密但能“隱藏”Base64 用 64 個安全字符A-Z、a-z、0-9、、/來表示任意二進(jìn)制數(shù)據(jù)把每 3 個字節(jié)變成 4 個字符。規(guī)則很簡單原始字節(jié) 11111100 11001101 10101010 分割成6位 111111 001100 110110 101010 Base64字符 / M 2 q長度不是 3 的倍數(shù)怎么辦補(bǔ)這就是你常看到 Base64 串末尾有 1 到 2 個的原因。我開發(fā)日志脫敏時經(jīng)常用 Base64 把敏感 ID 或內(nèi)部文件名轉(zhuǎn)成“看似亂碼”的短串方便日志打印和傳輸。但這只是混淆不能用來做安全防護(hù)任何人拿 Base64 解碼工具都能還原?，F(xiàn)在很多 CTF 題里喜歡玩“Base64 編碼隱藏”——就是把一段信息套多層編碼比如先 Base64再反轉(zhuǎn)再 16 進(jìn)制層層剝。我處理這類問題時會寫個小工具鏈順序嘗試 Base64、Base58、十六進(jìn)制、ROT13、URL 解碼基本能解掉 90% 的套殼。3.3 “表面編碼”CSS 那些偽裝術(shù)和后端編碼沖突如果你看到“表面編碼”這個詞多半是指前端用 CSS 隱藏元素或者偽裝文本但那屬于“顯示層的障眼法”跟編碼無關(guān)。真正要留神的是“隱性編碼”有些爬蟲返回的 JSON 里嵌了\u4e2d這種 Unicode 轉(zhuǎn)義或者把中文 base64 后放在 cookie 里。這類逃逸字符在 JSON 解析時如果不做 unescape字面量會原樣輸出。有一次我給登錄接口寫報(bào)文解析對方返回的nickname是\u5f20\u4e09我如果用正則切分根本找不到中文。后來統(tǒng)一用 JSON 標(biāo)準(zhǔn)解析數(shù)據(jù)才正常。規(guī)則很簡單數(shù)據(jù)和編碼分開文本里的轉(zhuǎn)義序列交給標(biāo)準(zhǔn)解析器絕不自己手寫解轉(zhuǎn)義邏輯。4. 進(jìn)階編碼壓縮、糾錯與特殊硬件里的編碼學(xué)上面是通用編碼真正讓我覺得“編碼腦洞大開”的是壓縮、糾錯和硬件驅(qū)動里的編碼。這部分的套路非常值得借鑒而且踩坑了才知道坑有多深。4.1 哈夫曼編碼最省存儲的“聰明”算法哈夫曼編碼是經(jīng)典的不定長編碼。它的原理是根據(jù)符號出現(xiàn)頻率給高頻符號分配短編碼給低頻符號分配長編碼然后要求任何編碼都不能是另一個編碼的前綴這樣不需要分隔符也能無歧義解碼。我在壓縮日志時試過自己實(shí)現(xiàn)哈夫曼樹先統(tǒng)計(jì)字符頻率建最小堆反復(fù)取兩個最小節(jié)點(diǎn)合并直到剩下根節(jié)點(diǎn)。但真正工程上要小心“編碼長度溢出”——符號集太大有的編碼會長到 20 多位解碼時要逐位匹配性能反而下降。所以哈夫曼通常配合靜態(tài)字典或動態(tài)建模用比如 DEFLATE 算法里就有哈夫曼的影子。你要是拿純哈夫曼去壓 4KB 的數(shù)據(jù)庫文本開頭還得存頻率表文件反而變大這個“開銷包不住收益”的坑我親身經(jīng)歷。4.2 LZW 編碼壓縮里的“字典學(xué)派”LZW 編碼的思想是自建字典邊讀取邊生成新條目而且字典是動態(tài)增長的——解碼端不用額外接收字典它跟著編碼過程同步重建。GIF 和 TIFF 圖像格式里L(fēng)ZW 就是基礎(chǔ)。早期嵌入式開發(fā)內(nèi)存緊張我曾在 8KB RAM 芯片上跑 LZW數(shù)據(jù)的限長、字典的清空時機(jī)都要摳。注意 LZW 里有個細(xì)節(jié)壓縮到字典貼滿后要不要清空不清空會繼續(xù)膨脹結(jié)束后壓縮率驟降清空太頻繁會丟失長上下文。我當(dāng)時按 4096 個字典條目觸發(fā)清空壓傳感器日志能到 40% 左右已經(jīng)比裸文本好很多但遠(yuǎn)不如現(xiàn)在的 zstd。4.3 糾錯編碼LDPC 與 CD 唱片老技術(shù)糾錯編碼是另一類“編碼”它給數(shù)據(jù)增加冗余讓接收端能發(fā)現(xiàn)甚至糾正傳輸錯誤。LDPC 低密度奇偶校驗(yàn)碼就是 5G、衛(wèi)星通信里的大殺器性能接近香農(nóng)極限。它的“校驗(yàn)矩陣稀疏”是特點(diǎn)工程實(shí)現(xiàn)要處理迭代譯碼、矩陣構(gòu)造復(fù)雜度很高一般應(yīng)用用不上。真正日常里你會碰到的糾錯編碼是 RAID 里的奇偶校驗(yàn)、ECC 內(nèi)存里的漢明碼以及二維碼里的 Reed-Solomon。我給 U 盤燒錄設(shè)備固件時就吃過虧U 盤壞塊讓固件少了幾 KB程序起不來日志只在 bootloader 階段打出來。后來我給固件包增加了簡單的 CRC32 校驗(yàn)燒錄完先驗(yàn)一遍校驗(yàn)不過就重新燒錄這才消停。4.4 數(shù)碼管3位6腳與段碼的編碼人生硬件里的編碼還不僅是數(shù)據(jù)更是“控制信號”。最近總有網(wǎng)友問“3位6腳的數(shù)碼管怎么分析和編碼”我當(dāng)年調(diào)數(shù)碼管時也被整得抓狂共陰共陽搞反段碼表全亂位選和段選搞混顯示全瞎。這里寫個系統(tǒng)的經(jīng)驗(yàn)。3 位 6 腳的數(shù)碼管一般引腳排列是 3 個公共端COM加 3 個段位端或反過來3 個段位公共端 3 個段選。核心思路就是動態(tài)掃描。同一時刻只點(diǎn)亮其中一位讓視覺暫留把三位“同時”顯示出來。第一步確定共陰還是共陽。用萬用表二極管檔紅表筆接某腳黑表筆逐個掃其他腳如果某一段亮了說明這是共陰管公共端接負(fù)。共陰管段碼表是 1 亮 0 滅共陽管相反段碼表是 0 亮 1 滅。第二步查段碼。比如數(shù)碼管的 a~dp按常見排布數(shù)字 0 點(diǎn)亮 a、b、c、d、e、f不亮 g、dp段碼二進(jìn)制按 a 為最低位或最高位取決于接線可能是 0x3F共陰或 0xC0共陽。第三步動態(tài)掃描的“坑”位選切換要先把段選清零否則會有拖影。這句是靈魂很多人顯示錯亂就是沒做“消影”。我調(diào) MPU 6050 姿態(tài)數(shù)據(jù)顯示時一開始刷新頻率 50Hz 拖影肉眼可見改成先熄滅所有位再送段碼再開位選拖影基本消失顯示穩(wěn)定。5. 常見問題與排查技巧實(shí)錄講了這么多理論和擴(kuò)展還是得上點(diǎn)實(shí)戰(zhàn)排查干貨。下面這些問題全是我自己在命令行和日志里吃過的塹。5.1 亂碼的根源三步定位法遇到亂碼的通用處理先看字節(jié)再定編碼最后做轉(zhuǎn)換。比如一個文件里的中文亂碼成??‘??ˉ其實(shí)這是典型的 UTF-8 字節(jié)被 GBK 解碼了。?的 UTF-8 字節(jié)是 0xC3 0xA6用 GBK 解出來就是“?”。反過來如果一個 GBK 文件被 UTF-8 解就會看到或者“錕斤拷”。原理是GBK 文件字節(jié)被誤按 UTF-8 解碼時遇到非法字節(jié)序列UTF-8 會用替換字符 UFFFD 代替轉(zhuǎn)回就會變成“錕斤拷”這類高頻重復(fù)詞。具體步驟# 第一步看原始字節(jié) xxd test.log | head -30 # 第二步嘗試猜測編碼 file -bi test.log # 第三步強(qiáng)行轉(zhuǎn) iconv -f gbk -t utf-8 test.log test_utf8.logfile有時候不靠譜因?yàn)樗翘卣髯R別樣本少時錯誤率不低。更保險(xiǎn)是肉眼配合 xxd 查特征如果大量字節(jié)大于 0x80 且成雙出現(xiàn)多半是 GBK如果出現(xiàn)E4、E5、E6開頭的三字節(jié)序列多半是 UTF-8。5.2 網(wǎng)絡(luò)編碼HTTP 請求里的隱形殺手HTTP 層的編碼涉及 Request Header 里的Content-Type和charset。我調(diào)試別人接口時最常踩的坑是前端發(fā) JSON 時沒指定Content-Type: application/json; charsetutf-8后端默認(rèn)按 ISO-8859-1 解析中文全變問號。還有更隱蔽的Ajax 請求里設(shè)置編碼格式時encodeURIComponent和encodeURI混用。encodeURI不會編碼:/?這類 URL 保留字encodeURIComponent卻會。所以拼接 URL 參數(shù)時我都有規(guī)則參數(shù)值一律用encodeURIComponent完整 URL 用encodeURI或直接拼接前提就是每個參數(shù)都已預(yù)編碼。5.3 編碼污染與編碼后門不只是“技術(shù)上”有一種“編碼”不是編碼技術(shù)而是“代碼編碼風(fēng)格”的含糊說法比如 PEP 8 是 Python 的代碼風(fēng)格指南它不是字符編碼但業(yè)界常把它跟“編碼規(guī)范”混一起討論。我們在團(tuán)隊(duì)里推行統(tǒng)一編碼風(fēng)格時也用工具自動檢測避免人工 review 時爭論“這個空格要不要留”。讓機(jī)器管格式人管邏輯這是工程化的思維。再有“編碼電機(jī)”這個熱詞其實(shí)指的是電機(jī)控制器里的“編碼器”——不是字符而是把角位移、直線位移變成脈沖或數(shù)字信號。增量編碼器輸出 A、B 相通過相位差判斷方向Z 相歸零絕對編碼器直接輸出絕對角度。想要實(shí)時控制電機(jī)轉(zhuǎn)速就得解析編碼器信號很多 PLC 項(xiàng)目里就是靠這個回讀位置閉環(huán)。5.4 工程建議從定位到預(yù)防的三條鐵律第一所有邊界文件統(tǒng)一聲明編碼。寫代碼時源碼文件一律 UTF-8 無 BOM數(shù)據(jù)庫連接顯式指定字符集接口返回前給Content-Type帶上 charset。第二二進(jìn)制協(xié)議里絕不出現(xiàn)“假設(shè)某機(jī)器默認(rèn)編碼”。做協(xié)議設(shè)計(jì)時字節(jié)序、編碼、定長變長全部寫進(jìn)文檔否則調(diào)試一次要命。第三能自動化的編碼操作不要手工做。編碼轉(zhuǎn)換、Base64 加解密、CRC 校驗(yàn)全交給命令行工具或腳本人工容易抄錯。6. 結(jié)尾小記我個人在實(shí)際操作中的體會是編碼這東西剛學(xué)覺得是小工具學(xué)到后面發(fā)現(xiàn)它是一道分水嶺。你能不能在 5 分鐘內(nèi)定位一個亂碼問題決定了你在團(tuán)隊(duì)里的口碑是“靠譜”還是“再改改”。最后再分享一個小技巧遇到看不懂的二進(jìn)制數(shù)據(jù)先把前 16 字節(jié)用 hexdump 按十六進(jìn)制寫出來再對照 ASCII 列看90% 的編碼格式都能看出端倪。改了幾年編碼問題我總結(jié)下來就一句話所有編碼問題最終都能歸結(jié)為“數(shù)據(jù)是同一份字節(jié)解釋標(biāo)準(zhǔn)不一致”。你只要能把字節(jié)和解釋規(guī)則分離就不會被任何亂碼困住。