Robobun 修復 Bun 模塊加載器的 UTF-8 編碼錯誤
Bun 的 PR #33864 修復了一個模塊加載器錯誤：當使用 `--target=bun` 且包含非 ASCII 的 banner/footer 時，UTF-8 字節被錯誤地解釋為 Latin-1，導致文本亂碼和語法錯誤。修復後，加載器正確解碼 UTF-8，同時保持 ASCII 快速路徑。此外，還修復了字節碼緩存鍵不匹配的問題。
Bun 項目的 PR #33864 近日修復了一個影響模塊加載器的編碼問題。當開發者使用 bun build --target=bun 並添加自定義 banner 或 footer 時，如果這些內容包含非 ASCII 字符（如中文或表情符號），Bun 會錯誤地將 UTF-8 編碼的字節當作 Latin-1（ISO 8859-1）處理。這種誤解導致字符串字面量出現亂碼（mojibake），而非 ASCII 標識符則直接拋出 SyntaxError。
問題根源在於，Bun 的內置模塊加載器在遇到 // @Bun 編譯指示時，會將文件直接交給 JavaScriptCore（JSC）處理。然而，加載器在構建內部字符串時使用了 String::clone_latin1 方法，該方法將每個字節視為一個 Latin-1 代碼單元。對於大部分由 ASCII 字符組成的代碼來説，這並無問題；但當 banner/footer 包含 UTF-8 編碼的非 ASCII 字符時，多字節序列被拆解為多個 Latin-1 字符，導致數據損壞。
Robobun 的修復方案是將兩處加載邏輯改為使用 String::clone_utf8。新方法利用了 simdutf 庫：對於純 ASCII 輸入，它仍通過快速路徑使用 Latin-1 複製（性能不變）；對於非 ASCII 輸入，則正確執行 UTF-8 解碼。這一改動確保了無論是源代碼還是附加的 banner/footer，都能以正確的編碼格式傳遞給 JSC。
修復並未止步於此。隨後的提交（68c1594）發現，當同時啓用 --bytecode 標誌時，字節碼緩存也會受到影響。由於緩存鍵（SourceCodeKey）在加載器和代碼生成器之間使用了不同的字符串構造方式——加載器生成 UTF-8 解碼的鍵，而緩存生成器仍使用 Latin-1 鍵——導致 decodeCodeBlock 拒絕匹配，JSC 不得不重新解析代碼，使得預編譯的 .jsc 文件成為無效的負擔。該提交通過一個輔助函數統一了兩種場景下的字符串構造，該函數同樣利用 simdutf 進行 ASCII 快速路徑或 UTF-8 解碼。
PR #33864 由 Robobun 編寫，Claude 機器人進行了代碼審查，並標記了“claude”和“slop”標籤。雖然 CI 在多種平台上出現了 5 項測試失敗（包括 WebSocket、WebView 和代理壓力測試），但其中部分失敗與本次編碼修復無關。最終，該 PR 在 2026 年 7 月 9 日被關閉併合並。此修復對於需要國際化支持或使用自定義 banner 的 Bun 用户來説至關重要，它消除了一個可能在生產環境中引發隱蔽錯誤的源頭。