擷取拿到的是顯示的樣子，不是能用的值
一個頁面上寫著 1.234,56 €，另一個寫著 €1,234.56。這兩個數字完全相等，但直接匯進表格，一個會被辨識成一千二百三十四點五六，另一個可能被辨識成一點二三。
這不是擷取的問題——兩個頁面顯示的都沒錯，只是國家不同。問題出在拿到資料之後：你要的是可以計算、可以排序、可以去重的值，而頁面給的是給當地人看的寫法。
這一步就是清洗。它不產生新資料，但它決定這份資料能不能直接用。下面五類是海外資料裡最常撞上的。
一、公司名後綴
這是海外名單去重最大的坑。
同一家公司，在不同平台上可能寫成：
ABC Handels GmbHABC Handels GmbH & Co. KGABC HandelsABC HANDELS GMBH
各國的公司形式後綴完全不同：德國 GmbH / AG / KG，英國 Ltd / Limited / PLC，美國 Inc. / LLC / Corp.，澳洲 Pty Ltd，荷蘭 B.V. / N.V.，法國 SARL / SAS，義大利 S.r.l. / S.p.A.，西班牙 S.L. / S.A.。日本的 株式会社 還可能出現在名字前面。
去重的做法是產生一個正規化鍵：轉小寫、去標點、去後綴、合併連續空格。ABC Handels GmbH 和 ABC HANDELS 都變成 abc handels，就能比對上。
但這裡有個必須說清楚的限制：ABC Ltd 和 ABC LLC 正規化之後也會撞在一起，而它們可能真是兩家不同的公司。 規則解決不了這個問題。我們的做法是正規化比對之後，用地址或網站網域做二次確認，並把比對的信心度標出來——高信心度的直接合併，邊界情況單獨列出來由你判斷。
二、電話號碼
頁面上的電話是給當地人撥的，不是給系統存的。
德國柏林的一個號碼，本地寫法是 030 12345678。轉成國際格式時，前導的 0 是國內長途前綴，必須去掉，變成 +49 30 12345678。
但義大利是個例外：羅馬的 06 12345678 轉成國際格式是 +39 06 12345678，前導 0 要保留。依德國的規則去處理義大利號碼，得到的號碼撥不通。
其他常見寫法：法國 01 23 45 67 89 兩位一組、美國 (555) 123-4567 帶括號和連字號、英國 020 7123 4567 分三段。
統一的目標格式是 E.164：加號、國碼、剩餘號碼，中間不帶任何分隔符號和空格。這樣存進系統才能做比對和去重。
但原始寫法要保留。 一是號碼本身可能就是殘缺的（頁面只寫了本地號，沒有區碼，而頁面所在國家不一定等於號碼所屬國家），二是出現撥不通的情況時，要能回去看擷取到的原文是什麼。
三、地址
各國地址的欄位順序不一樣，而且不是簡單的前後調換。
德國：Hauptstraße 12, 10115 Berlin——街道名在前門牌號在後，郵遞區號在城市前面。
英國：12 Main Street, London SW1A 1AA——門牌號在前，郵遞區號在城市後面，而且分兩段中間有空格。
美國：12 Main St, Springfield, IL 62701——州用兩位縮寫，郵遞區號五位。
荷蘭郵遞區號是 1234 AB 這種數字加字母的形式。
這裡我們的建議和別的欄位相反：除非你明確需要，否則不要把地址硬拆成結構化欄位。
原因是拆分規則要依國家分別寫，而拆錯的代價比不拆更高。一個德國地址如果把 10115 當成門牌號、把 Berlin 當成街道，那後面所有依城市做的統計都是錯的，而且錯得不明顯——你要等到用這份資料做決策時才會發現。
如果你只是要依國家或城市篩選，保留完整地址加一個單獨的國家欄，通常就夠用了。真要拆，測試階段會先依目標國家跑一批樣本給你看拆分準確率，確認之後再全量。
四、日期與時區
03/04/2026 在美國是 3 月 4 日，在歐洲是 4 月 3 日。
同一個字串，兩個意思，而且無法從資料本身判斷是哪個。 只有知道這筆資料來自哪個站點、那個站點用哪種格式，才能確定。這個資訊在擷取的那一刻是有的，交付之後就沒有了。
所以日期欄位一律轉成 ISO 8601（2026-03-04）再交付，這是唯一沒有歧義的寫法。
還有兩件相關的事：
相對時間必須在擷取時換算。 頁面上寫「2 天前」「上週」的，交付裡存這個字串毫無意義——資料放三個月之後，「2 天前」是相對哪一天的兩天前？我們會在擷取時刻換算成絕對日期，並保留 collected_at 供核對。
擷取時間帶時區。 價格、排名、庫存這類快照欄位，跨時區比較時差幾個小時可能就是不同的狀態。我們預設用 UTC 並在欄位說明裡標明，這一點在資料交付應該按什麼標準驗收裡也提過。
五、數字與貨幣
小數點和千分位的寫法，歐洲和英美是反的：
| 寫法 | 使用地區 | 實際數值 |
|---|---|---|
1,234.56 |
英美、多數英語國家 | 一千二百三十四點五六 |
1.234,56 |
德國、義大利、西班牙、荷蘭 | 一千二百三十四點五六 |
1 234,56 |
法國（千分位是空格） | 一千二百三十四點五六 |
1'234.56 |
瑞士 | 一千二百三十四點五六 |
四種寫法同一個數。如果一份資料裡混著幾個國家站點的價格，直接依字串排序或者直接加總，結果全是錯的，而且不會報錯。
貨幣符號的位置也不統一：€1,234 和 1.234 € 都有，符號本身還可能是 EUR、€，或者乾脆不顯示（頁面靠上下文說明幣別）。
所以價格類欄位我們預設拆成兩欄：price 存純數值，currency 存 ISO 4217 代碼（EUR、USD、GBP）。想還原頁面上的顯示樣子，可以再加一欄原始字串。
一條貫穿的原則：原始值不能丟
上面每一類的建議都帶著同一句話——保留原始值。
原因是標準化一定會丟資訊。ABC GmbH & Co. KG 正規化成 abc 之後，你再也無法從這份資料裡知道它原來是哪種公司形式；030 12345678 轉成 +493012345678 之後，也看不出它原來是不是帶區碼的完整號碼。
更實際的一點是可追溯。資料用出問題時，第一件事是回去比對來源頁面。如果交付裡只有處理後的值，這一步就斷了——你無法判斷是擷取錯了、處理錯了，還是頁面本身就是那麼寫的。
所以我們的預設做法是原始值一欄、標準化值一欄，欄位說明裡寫明哪一欄是處理過的、依什麼規則處理的。檔案會大一些，但這是來源可追溯的前提。
提需求時建議一併說明
- 涉及哪些國家：決定要依幾套規則處理，也決定測試樣本怎麼抽
- 資料拿去做什麼：做去重和做外撥，對電話欄位的處理要求完全不同
- 要不要拆地址：拆的話依哪幾級拆，以及能接受多少拆分誤差
- 能不能接受兩欄：有些系統匯入時欄位數有限制，需要提前確認
這幾項確定後，測試階段會依你的國家範圍抽一批樣本，把處理前後的結果並排給你看。多來源合併時還有額外的口徑問題，寫在多個來源的資料怎麼合併。