第一次遇到 HTTPS 抓包亂碼，大多數人的反應都很直接：是不是字符集不對？是不是 gzip？是不是工具顯示有問題？
我以前也是這麼想的。但在真正排查過幾次之後，會發現“亂碼”只是結果，背後原因往往並不在顯示層，而是在你到底抓到了什麼。
一次看似普通的亂碼場景
事情起因很簡單： 一個 iOS App 在真機環境下抓包，HTTPS 請求能看到，但 body 全是不可讀的內容。Header 看起來正常，狀態碼也是 200，但響應體像是隨機字節。
同樣的接口，在測試環境、模擬器、甚至服務端日誌裏都是正常 JSON。
這個時候，如果直接下結論説“抓包工具不行”，往往會走偏。
先確認：抓到的是不是“解密後的 HTTPS”
HTTPS 抓包亂碼，最常見的情況其實是： 你看到的內容並不是解密後的數據，而是 TLS 層之上的加密結果。
代理抓包工具在這一步非常有價值。 它們的優勢不在於“萬能”，而在於能快速驗證一件事：
這個請求，在理想條件下能不能被正確解密？
在可控網絡環境下，如果代理抓包能看到清晰的請求和響應，説明接口本身沒有額外加密，亂碼問題更可能出現在真機或安全機制上。
HTTPS Pinning 出現時，亂碼就變成了信號
回到這個案例，代理抓包在模擬器裏一切正常，真機卻全部是亂碼。 這時基本可以確定：不是編碼問題，而是 HTTPS 校驗策略在起作用。
很多 App 在真機環境下啓用了 HTTPS pinning，甚至是雙向校驗。這種情況下，代理工具往往只能看到連接存在，卻無法完成真正的解密，於是就留下了一堆“看起來像亂碼”的數據。
這裏的關鍵不是“怎麼顯示”，而是你有沒有權限看到明文。
設備側抓包，才能確認“真實通信內容”
在需要確認真實 HTTPS 內容時，我後來改用了 抓包大師（Sniff Master） 這類從設備側抓取數據的工具。
它在這個流程裏的作用很明確： 不是替代代理工具，而是驗證一個假設——
這個 App 在真機上，到底發了什麼、收了什麼？
由於不依賴系統代理，也不需要改 App 或越獄，它更接近用户真實環境。 在同一個接口上，用 Sniff Master 抓到的數據已經是可讀的結構化內容，這一步基本就可以確認：之前看到的“亂碼”，並不是數據本身的問題。
並不是所有“可讀內容”都是業務數據
不過事情並沒有到此結束。
在進一步分析時發現，某些響應雖然不再是亂碼，但內容依然不像業務 JSON。 這時就需要再往下看一層：是不是應用層又做了一次加密？
這一點很容易被忽略。 HTTPS 解決的是傳輸安全，不等於業務一定是明文。有些 SDK 會在 HTTPS 之上再包一層自定義加密，這時候即便 HTTPS 解密成功，內容依然“看不懂”。
數據流視角，幫忙判斷“是不是二次加密”
判斷是否存在二次加密，單看 HTTP 視圖並不夠。 我後來抓了一段 TCP 數據流，對比請求和響應長度、結構變化，發現數據具有明顯的固定頭和校驗特徵。
這類分析更偏數據流層，而不是接口層。 抓包大師支持直接抓 TCP / UDP 數據流，並導出給 Wireshark 做進一步分析，這一步的意義在於確認：
- 這是不是一個穩定結構的數據包
- 是否存在明顯的協議格式
- 是否需要再用業務邏輯去解碼
一旦確認是二次加密，亂碼就不再是“問題”，而只是“正常現象”。
亂碼排查中，攔截和修改也有價值
在某些情況下，我會直接修改響應內容，觀察客户端行為。 比如返回空數據、非法格式，或者替換部分字段，看看 App 是否能正常處理。
這類操作不一定是為了“破解”，而是為了確認客户端對數據的依賴程度。 抓包大師支持通過攔截器和腳本修改請求和響應，這在驗證假設時很方便。
HTTPS 抓包亂碼，本質是視角問題
回頭看這類問題，真正有用的不是“某個工具多強”，而是你是否清楚自己現在站在哪一層：
- 代理抓包：驗證接口邏輯
- 設備抓包：還原真實 HTTPS 內容
- 數據流抓包：判斷是否存在額外協議或加密
- 攔截修改：驗證客户端處理邏輯
亂碼只是一個表象，它提醒你：現在看到的，很可能還不是你真正要看的東西。
