同一欄混著中文、英文地址，批次整理前要怎麼分流？
不要把整欄直接套用中文地址規則，也不要看到拉丁字母就斷定那一列是完整英文地址。比較安全的做法是先保留原文和列識別碼，再新增 language_bucket，把資料分成中文、英文、混合、未知四組。這個分組只決定下一個處理流程，不是翻譯結果，更不是地址存在或可投遞的證明。
四組資料的處理邊界
| 分組 | 判斷線索 | 可以做的下一步 | 不應直接做 |
|---|---|---|---|
| 中文 | 主要由漢字與中文地址單位組成 | 用中文工具檢查行政區、路名與元件 | 宣稱官方英譯一定存在 |
| 英文 | 主要由拉丁字母、數字及英文縮寫組成 | 保留原文，人工拆出國家、城市、街道與門牌 | 用中文解析器反推唯一中文地址 |
| 混合 | 中文地名與英文道路或單位並存 | 標出可辨識片段，交人工核對來源 | 刪除其中一種語言 |
| 未知 | 只有建物名、代碼、暱稱或殘缺片段 | 向來源補完整地址 | 當成空白、錯誤修正或成功資料 |
例如「範例市學習路8號」只能當中文格式的虛構失敗／隱私測試；「No. 8, Learning Rd., Sample City」只能當英文字串範例，因為地名沒有官方對照，不能聲稱兩者是同一地址。「Dorm A」「3F Reception」也可能只是建物或配送說明，不足以判為英文地址。
先分流，不先改值
- 匯入時建立不可變的 record_id、raw_address、source_system 與 received_at。
- 以是否含漢字、拉丁字母、中文地址單位及常見英文縮寫建立候選分組，規則結果寫入新欄。
- 抽查公司名、社區名、飯店名、羅馬數字與電子郵件，避免把名稱誤認為地址語言。
- 每組保留「分類原因」，例如含漢字＋路／街、含 City＋No.、中英混合或資訊不足。
- 分流前後核對總列數與 record_id，不能因空白、換行或編碼問題漏列。
- 規則無法穩定分類的列進人工清單，不要硬塞進中文或英文組。
- 修正 language_bucket 時只改分類欄，原始地址與先前判斷仍保留以便追查。
Unicode 正規化可以處理部分等價字元序列，例如組合字元的表現方式，但它不會理解地址語意、不會翻譯路名，也不會判斷中英文是否指向同一地點。應先決定你要解決的是編碼差異、語言分流，還是實體地址比對；三件事不能用同一個「正規化」按鈕代替。
中文組可以怎麼處理
中文組可交給批次地址整理工具，取得確定、可能、無法確認或錯誤及原因。工具只處理台灣中文地址；確定代表目前官方資料可支持行政區、路名等判讀，不代表門牌實際存在。可能、無法確認及錯誤列要保留原值並人工處理，不可為了提高成功率自行補行政區或門牌。
確實需要英文候選時，再把中文列送到中文地址轉英文工具。若官方英譯資料沒有對應路名、段別不足或行政區無法確定，工具可能不輸出英文。這是安全邊界，不應改用自行拼音填滿空白。輸出的英文候選要和 record_id 一起保存，避免排序後配錯列。
英文與混合組不能套中文比對器
本站地址比較工具會把兩個輸入都當成台灣中文地址解析，沒有中英文對齊模式。因此，英文組不要送進地址比較或地址去重工具。先由人工確認資料的國家、行政區、道路、門牌、樓室與郵遞區號是否可分辨；若英文列本來就有一筆中文來源，優先用共同 record_id、訂單 ID 或來源欄位配對，而不是靠文字相似度猜關係。
配對後，可從中文來源產生官方英文候選，再把英文原文與候選按元件人工核對。縣市、區、路名要有可信中英對照；門牌、之號、樓層與室號逐項比數字；任何關鍵數字衝突都停止合併。完整保存方式可參考中英文收件地址一起保存，讓中文原文、英文原文、產生方式、來源與確認日期分欄。
合併回主表前的驗收
四組處理完後，以 record_id 回接，不用列序或目前排序位置。核對每個 ID 恰好出現一次，分類前後總列數相同，並分別統計成功、待確認與失敗。英文列沒有可靠中文來源時，維持英文原文與未確認狀態；混合列若無法判斷某個片段是建物名還是道路，也應送人工覆核。
最後抽樣讀回原始值、分類原因、工具狀態與輸出欄。格式已整理只代表文字處理完成；官方英譯對上也只支撐名稱轉寫。門牌是否存在、收件人是否仍在該處、英文地址是否適用本次寄件，都需要另外的來源或收件人確認。