揭開字元編碼的神秘面紗
在數位世界中，電腦無法直接閱讀文字，只能理解數字。字元編碼（Character Encoding）就是將人類可讀的文字轉換為二進位碼的規則。若編碼不統一，使用者就會看到惱人的亂碼。
早期電腦系統為了節省記憶體，僅定義了少數基礎字符。這導致了不同國家各自發展出一套編碼系統，卻無法互相溝通，造成了極大的資訊交換障礙。
ASCII 編碼：數位時代的基石
ASCII（American Standard Code for Information Interchange）是編碼界的始祖。它使用 7 位元來表示 128 個字元，包含了英文字母、數字與常見符號。
儘管 ASCII 奠定了基礎，但它無法處理非拉丁語系文字，例如漢字或平假名。這促使了後續擴展字元集的開發，但仍無法解決全球化需求。
Unicode：全球統一的編碼夢想
Unicode 的誕生旨在為世界上所有的文字分配一個唯一的數字識別碼（Code Point）。這徹底解決了不同語系之間的衝突，讓軟體能夠同時顯示繁體中文、英文與表情符號。
Unicode 本身只是一份對照表，真正的儲存方式則取決於編碼方案，例如 UTF-8、UTF-16 或 UTF-32，選擇合適的儲存方案是軟體架構的關鍵。
UTF-8 的靈活與高效
UTF-8 是目前網際網路上最流行的編碼方案。它採用變長度編碼，英文字元僅需 1 個位元組，而中文字元則需 3 個位元組，這在儲存空間與效能之間取得了最佳平衡。
由於其向後相容 ASCII 的特性，許多舊系統在升級至 UTF-8 時並不需要進行大規模的資料重構，這也是它能迅速普及的重要原因。
URL 編碼：保障傳輸安全
當我們在網址中輸入非 ASCII 字元時，必須進行 URL 編碼（Percent-encoding）。將特殊符號轉換為 % 加上十六進位碼，確保伺服器能夠正確解析路徑與參數。
若未經編碼直接傳輸，特殊符號可能會被系統誤判為指令，導致嚴重的安全性漏洞或請求失敗，這在 REST API 設計中尤其需要注意。
| 編碼方案 | 適用場景 | 優勢 |
|---|---|---|
| UTF-8 | 網頁與 API 通訊 | 相容性最高 |
| Base64 | 二進位資料傳輸 | 可安全傳輸文字 |
| ASCII | 系統核心指令 | 資源消耗極低 |
Base64：讓二進位檔案融入文字流
Base64 並非嚴格意義上的字元編碼，而是一種二進位轉文字的方案。它將二進位資料轉換為 64 個可列印 ASCII 字元，方便在 Email 或 JSON 中嵌入圖片。
雖然 Base64 會增加約 33% 的資料大小，但其帶來的傳輸便利性，讓它在現代前後端資料交換中扮演著不可或缺的角色。
克服編碼陷阱的實戰技巧
開發者常遇到的問題多半源自於「編碼不匹配」。例如將 Big5 編碼的檔案讀取為 UTF-8，導致中文變成亂碼，這時需要透過工具進行編碼轉換。
透過標準化的編碼流程，我們可以確保系統從資料庫讀取到前端顯示的過程中，每個環節都能正確處理字元，從而提升使用者的體驗品質。