AnyTools
🔤

文字編碼偵測器

瀏覽器端未知編碼偵測器，提供一鍵載入範例、轉換提示與 16 種語言本地化文件。

文字輸入

❓什麼是字元編碼

字元編碼是將字元對應到二進位值以進行電腦儲存和傳輸的系統。不同的編碼使用不同的對應：ASCII 使用 7 位元（128 個字元，僅英語）、ISO-8859-1 (Latin-1) 擴充到 8 位元（256 個字元，西歐）、GB2312/GBK 用於簡體中文、Big5 用於繁體中文、Shift-JIS 用於日語、UTF-8（1-4 位元組，通用，向後相容 ASCII）、UTF-16（2 或 4 位元組）。亂碼（如 �）發生在用一種字元集編碼的文字用另一種字元集解碼時。BOM（位元組順序標記）是檔案開頭的可選簽章，用於識別編碼。正確的編碼偵測防止資料損壞並確保跨系統和語言的正確文字顯示。

✨功能特點

🔍

智慧偵測

使用統計分析、BOM 偵測、字元模式識別自動偵測文字編碼。支援 UTF-8/16/32、GBK、GB2312、Big5、Shift-JIS、ISO-8859 系列、Windows-1252，帶信賴度分數
🔄

字元集轉換

在任何支援的編碼之間轉換文字：UTF-8 ↔ GBK ↔ Big5，修復亂碼問題，新增或刪除 BOM 標記，正確處理代理對和組合字元
🩺

編碼診斷

識別編碼問題：無效位元組序列、同一檔案中的混合編碼、BOM 不符合、代理對錯誤，帶修復建議和詳細錯誤報告
📦

批次處理

同時處理多個檔案的編碼偵測，轉換整個目錄，保留檔案結構，產生帶統計資訊和錯誤記錄的轉換報告
🎯

應用情境

🏢

遺留系統遷移

在遷移財務、ERP 或政府系統時，批次將 GBK/Big5 檔案轉為 UTF-8。
🌐

全球內容品檢

內容與 SEO 團隊驗證多語網站、RSS 與郵件是否宣告正確字元集以避免亂碼。
🧾

資料匯入流程

在將合作夥伴的日誌、CSV、ETL 輸入匯入倉儲或 Spark 前先檢查編碼。
🛠️

開發偵錯

檢閱 Git diff 或資料庫匯出時，快速定位 BOM 衝突與混合編碼。

📋使用指南

1️⃣
上傳或貼上
上傳文字檔案或貼上文字內容進行編碼分析
2️⃣
偵測編碼
點選偵測以自動識別編碼，或在已知時手動指定
3️⃣
檢視結果
檢查偵測到的編碼、信賴度層級、BOM 存在和預覽文字
4️⃣
根據需要轉換
選擇目標編碼，轉換文字，下載或複製轉換後的結果

📚技術介紹

🔤編碼標準

字元編碼的演變以支援不同語言：ASCII（1963，7 位元，128 字元，英語）。ISO-8859 系列（8 位元，256 字元，區域性：-1 拉丁文、-2 中歐、-5 西里爾文、-6 阿拉伯文）。亞洲語言的 DBCS（雙位元組）：GB2312（1980，6763 個簡體中文）、GBK（21886 個字元，GB2312 擴充）、Big5（13060 個繁體中文）、Shift-JIS（日語，複雜位元組規則）。Unicode 聯盟建立通用編碼：UTF-8（可變 1-4 位元組，ASCII 相容，Web 標準）、UTF-16（2 或 4 位元組，Windows/Java 預設，需要 BOM）、UTF-32（固定 4 位元組，浪費但簡單）。現代系統更喜歡 UTF-8 用於儲存，UTF-16 用於記憶體處理。

🔍偵測演算法

編碼偵測使用多種技術：1) BOM 偵測：UTF-8 (EF BB BF)、UTF-16 LE (FF FE)、UTF-16 BE (FE FF)、UTF-32 LE (FF FE 00 00)。2) 統計分析：字元頻率分佈、位元組模式、有效位元組序列。chardet (Python)、ICU (C++)、jschardet (JavaScript) 等函式庫使用字元 n-gram 和在範例文字上訓練的語言模型。3) 驗證：檢查位元組是否為編碼形成有效序列（UTF-8 有特定的延續位元組規則，GB2312 有定義的程式碼範圍）。4) 啟發式方法：檔案副檔名 (.txt)、HTTP 標頭（charset）、XML 宣告（<?xml encoding="">）。信賴度分數組合多個訊號。短文字或罕見字元會出現誤報。

🔄編碼轉換

編碼之間的轉換需要：1) 使用來源編碼將來源位元組解碼為 Unicode 程式碼點。2) 將程式碼點編碼為目標編碼。挑戰：不可對應字元（並非所有 Unicode 字元都存在於舊編碼中）- 使用替換字元 (�)、HTML 實體或錯誤處理。規範化：Unicode 對同一字元有多種表示（é 可以是單個程式碼點 U+00E9 或 e + 組合重音），NFC 規範化為組合，NFD 為分解。BOM 處理：為 UTF-16/32 新增，UTF-8 可選（通常省略）。行尾：CRLF（Windows）vs LF（Unix）需要單獨處理。大檔案的串流轉換處理帶有狀態解碼器的區塊，在區塊之間保持上下文。

🐛亂碼和修復

亂碼（文字化け，亂碼文字）源於編碼不符合：UTF-8 文字解釋為 Latin-1 顯示 à 而不是 é，中文顯示 � 或 中文。常見原因：伺服器傳送 UTF-8 時沒有 charset 標頭、編輯器用錯誤編碼儲存、資料庫在 Latin-1 欄中儲存 UTF-8。修復：1) 用正確編碼重新解碼：如果文字是 UTF-8 但解碼為 Latin-1，重新編碼為 Latin-1 位元組然後解碼為 UTF-8。2) 使用編碼偵測函式庫。3) 檢查 HTTP 標頭、HTML meta 標籤、XML 宣告。預防：始終到處使用 UTF-8，明確宣告編碼，在邊界驗證資料。Ftfy (Python) 函式庫使用統計模式自動修復亂碼。
❓

Frequently Asked Questions

❓

編碼偵測的準確度如何？

偵測器結合 BOM 偵測、統計分析和位元組模式驗證來估計最可能的字元集。每次執行還會顯示信賴度分數，讓您知道何時需要額外的人工審查。
💬

偵測後可以轉換文字嗎？

可以。一旦識別出編碼，您可以選擇任何目標字元集，在瀏覽器中完全轉換文字，並下載或複製轉換後的輸出，無需上傳檔案。
🔍

新增或刪除 BOM 選項有什麼作用？

BOM（位元組順序標記）是 UTF 檔案開頭的可選簽名。新增 BOM 可以幫助某些 Windows 工具偵測編碼，而刪除它可以使檔案在 UNIX 環境中保持精簡。根據文字的使用場景切換此選項。
💡

為什麼轉換後仍然看到亂碼？

如果文字之前使用錯誤的字元集解碼，損壞可能已經儲存。請嘗試重新載入原始檔案，確保選擇了正確的來源編碼，然後再次轉換。單個檔案中的混合編碼也會產生亂碼。
📚

我的文字會被上傳或儲存嗎？

不會。偵測和轉換完全在您的瀏覽器中進行。檔案永遠不會離開您的裝置，因此機密文件保持私密。

💡最佳實務

💡

始終使用 UTF-8

預設情況下在所有地方使用 UTF-8 編碼 - 資料庫、檔案、HTTP 標頭、HTML meta 標籤。UTF-8 是通用的，支援所有語言，向後相容 ASCII，是 Web 標準。在 HTML (<meta charset="UTF-8">) 和 HTTP 標頭 (內容-類型: 文字/html; charset=utf-8) 中明確宣告編碼。這可以防止亂碼並確保跨系統一致的文字顯示。
🔍

轉換前先偵測

在嘗試轉換之前始終偵測編碼以避免資料損壞。使用偵測函式庫的信賴度分數驗證準確性。對於模糊情況（低信賴度），手動檢查範例文字或嘗試多種編碼進行視覺驗證。永遠不要僅基於檔案副檔名或來源假設編碼 - 始終驗證。
📝

正確處理 BOM

檢查檔案開頭的 BOM（位元組順序標記）以進行確定性編碼識別。UTF-8 BOM (EF BB BF) 是可選的但有助於偵測。UTF-16/32 需要 BOM 來確定位元組順序（LE/BE）。一些系統期望 BOM，其他系統拒絕它 - 了解您的目標系統。在轉換期間根據需要刪除或新增 BOM。
🩺

測試亂碼修復

修復亂碼文字時，透過模式分析識別原始編碼和誤解釋的編碼。常見亂碼：UTF-8 作為 Latin-1（é 而不是 é）、中文顯示為 ? 或隨機字元。重新編碼為中間編碼，然後使用正確的編碼解碼。在處理整個檔案之前在範例資料上測試修復。如果資料已在資料庫中損壞，某些亂碼是不可逆的。
⚠️

在邊界驗證

在系統邊界驗證編碼 - 檔案讀取、HTTP 請求、資料庫查詢、API 呼叫。在所有資料傳輸中使用字元集宣告。清理和驗證輸入文字以儘早偵測無效位元組序列。記錄編碼問題以進行除錯。為編碼偵測失敗實作回退策略。永遠不要在單一檔案或資料庫欄中混合編碼。

🔗相關文件

📖Unicode 標準-官方 Unicode 字元編碼規範
🔤RFC 3629 - UTF-8 規範-UTF-8 編碼格式標準
🌏GB18030 中文編碼-中國國家標準字元編碼
🔧ICU 字元編碼偵測-Unicode 國際元件偵測函式庫
📚字元編碼最佳實務-W3C 處理字元編碼的指南

User Comments

0 / 2000
Loading...