資料提取
OCR 身份證件掃描 API，返回結構化欄位，而唔係一大段文字。
ShieldID 將政府簽發嘅相片身份證件轉化為結構化嘅逐欄位資料：姓名、出生日期、證件號碼、有效期、地址等等，每個欄位都附帶來源同自己嘅判定結果。同一個工作階段內，既係證件資料提取 API，亦係證件驗證 API。
返回內容
結構化欄位，以證件實際載有者為準。
並非每種證件都載有所有欄位。ShieldID 會返回證件上有嘅內容，並標明冇嘅部分。
- 全名
- 按印刷內容，以及證件載有條碼或 MRZ 時按其編碼內容。
- 出生日期
- 從印刷正面讀取，並同條碼同 MRZ 交叉比對。
- 證件號碼
- 執照號碼或護照號碼，喺發證機關嘅格式容許時，會檢查內部一致性。
- 有效日期
- 從印刷正面以及條碼或 MRZ 讀取。
- 地址
- 從印刷正面同條碼（如有）讀取；可同另外上載嘅地址文件比對。
- 性別
- 證件有印刷或編碼嗰陣就會讀取。
- 簽發司法管轄區
- 如條碼載有可辨識嘅發證機構代碼,便據此識別,視乎資料是否可用而定。
三個來源，一次比對
條碼、MRZ 同證件正面印刷內容，都係有意識地讀取，而唔係無意中混為一談。
每個欄位都會標明來源。當兩個來源不一致時，結果上會標示為警示，而唔係將兩個數字取平均值。
PDF417 條碼
北美駕駛執照或身分證嘅背面會被解碼成結構化嘅 AAMVA 欄位。當文件載有條碼時,條碼欄位優先於正面嘅印刷內容。
護照 MRZ
機讀區會被定位、讀取，並根據機讀區內置嘅 ICAO 校驗位公式進行驗證。系統會按最低有效性分數把關，決定從 MRZ 讀取嘅欄位是否可信——連自身校驗和都未能通過嘅機讀區，不能凌駕於更清晰嘅來源之上。
證件正面嘅結構化及整頁 OCR
證件嘅印刷面會按已識別嘅文件版面讀取;如文件並不熟悉,則退而使用整頁 OCR,令陌生文件亦能得出可讀取嘅欄位。
衝突會被標示，而唔係取平均值
如果姓名或出生日期喺正面、條碼同 MRZ 之間不一致，結果上會報告為不符。流程中冇任何環節會靜靜地揀出一個勝出者而隱藏分歧。
MRZ 校驗和驗證
機讀區必須先通過自身嘅數學校驗，我哋先會信任。
護照上嘅 ICAO 機讀區設計上附有校驗位。ShieldID 會先驗證校驗位，再將從 MRZ 讀取嘅欄位視為可靠。
專用偵測器負責定位 MRZ，讀取器擷取字元，然後根據機讀區自身嘅校驗和公式評估有效性分數。只有達到最低有效性分數嘅欄位，先會以完整優先級獲得信任；讀取質素欠佳嘅機讀區會被相應處理，而唔會當作清晰嘅資料直接放行。
條碼優先
來源重疊時，以最可靠者為準。
同一個欄位可能同時出現喺條碼、MRZ 同印刷正面。ShieldID 每次都按同一個一致嘅次序處理。
- PDF417 條碼
- 護照 MRZ（通過校驗和後）
- 印刷正面嘅結構化讀取
- 整頁 OCR 後備
地址證明文件
上傳第二份文件，即可得到直接明瞭嘅地址比對。
當驗證需要地址證明時，申請人會上傳另一份文件，ShieldID 讀取嘅方式同讀取身份證件一樣。
地址文件會經過 OCR，並將其地址同從身份證件讀取嘅地址作比對。呢個係純文字同詞元比對，並非獨立嘅文件分類器，而且只會喺工作階段有需要、並且確實提供咗文件時先執行。
遮蔽及個人身份資料處理
擷取到嘅資料同影像受到同樣嘅保護。
結構化欄位同套用於身份證件相片本身嘅私隱管控並行。
出生日期靜態加密
出生日期以加密方式靜態儲存；如果冇加密金鑰，服務唔會運行。
影像按計時器清除
所擷取嘅證件同自拍影像會按較短嘅計時器自動清除，預設為七日。系統會定時執行清理，並且每次重新啟動後不久再執行一次，所以即使有一段時間冇人使用，影像都唔會逾期保留。
裝置端分數遮蔽
如果配對或信心數值原本會顯示喺申請人自己部手機上，ShieldID 會喺訊息顯示前移除當中嘅百分比，所以原始分數絕不會在你嘅帳戶以外顯示。
紀錄比影像保存得更久
影像會按時間表處理。驗證曾經進行過，以及發現咗啲乜，會保留喺你嘅帳戶——如果係 Trust Ledger 整合，亦會作為已驗證／失敗嘅條目記錄喺 Activity Ledger（ShieldID API 帳戶嘅紀錄條目：即將推出）。
範例結果
逐個欄位嘅判定結果，格式同 API 返回嘅一樣。
以下嘅姓名、號碼同地址均為本範例虛構。欄位組合、來源同判定結果，就係結果嘅真實格式。
| 欄位 | 數值 | 來源 | 判定 |
|---|---|---|---|
| person.name | "Priya Chandrasekaran" | barcode | match |
| person.dob | "1991-07-22" | barcode | match |
| person.document_number | "C4839201" | mrz | match |
| person.document_country | "CA" | barcode issuer code | match |
| person.address | "18 Spruce Ave, Ottawa ON" | barcode | match |
| identity.name_match | PASS | front vs barcode vs requester | PASS |
| checks.document_tamper | "no_indication" | advisory model | advisory — not gating |
// Sample result. Names, numbers and addresses are fictional.
{
"session_id": "ses_9f2c...sample",
"status": "VERIFIED",
"environment": "sandbox",
"person": {
"name": "Priya Chandrasekaran",
"dob": "1991-07-22",
"document_type": "DRIVERS_LICENCE",
"document_country": "CA",
"document_jurisdiction": "ON",
"address": "18 Spruce Ave, Ottawa ON"
},
"identity": {
"checks": ["name_match"],
"warnings": [],
"sources": {
"name": "barcode",
"dob": "barcode",
"address": "barcode"
}
},
"checks": {
"document": "PASS",
"identity": "PASS",
"document_tamper": "no_indication"
},
"completed_at": "2026-09-17T14:02:11Z"
}整合說明
無論你喺邊度讀取結果，欄位都一樣。
結構化欄位並唔係獨立於驗證工作階段之外嘅產品，而係同一份結果嘅一部分。
- 驗證完成後，欄位會包含喺你透過 API 擷取嘅工作階段結果入面。
- 驗證完成時，同一份結果會透過已簽署嘅 webhook 傳送到你嘅端點，所以你毋須輪詢。
- 每個欄位都標明來源並附帶自己嘅判定結果，API 結果同 webhook 內容都一樣。
- Sandbox 工作階段返回同正式環境一樣嘅欄位結構，所以你喺讀取任何真實證件之前就可以開始建構整合。
問題
有關資料擷取嘅直接解答。
親眼睇下欄位
執行一次 sandbox 驗證，讀取結構化結果。
建立一個 sandbox 工作階段，用你自己嘅手機掃描證件，然後喺回應中睇到每個欄位、其來源同判定結果。Sandbox 工作階段絕不收費。