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