本頁面由 Cloud Translation API 翻譯而成。

確認地址 - 範例

本文說明多種實際情況，在這些情況下，地址驗證 API 會針對可能需要系統確認的地址提供回應信號。如需相關背景資訊，請參閱「範例工作流程」一節，瞭解如何建構驗證邏輯。

常見範例：確認

以下範例說明都會區街道名稱相似的情況。假設使用者想輸入美國華盛頓州柯克蘭的 Google D 大樓地址，但他們不小心輸入了「西雅圖」，而非「柯克蘭」。

輸入的地址	區域
Building D, 451 7th Avenue South, Seattle, WA 98033	美國

取代資料的判定結果

以下範例會強調回應中的重要信號。

{
  "inputGranularity": "SUB_PREMISE",
  "validationGranularity": "PREMISE_PROXIMITY",
  "geocodeGranularity": "PREMISE_PROXIMITY",
  "addressComplete": true,
  "hasUnconfirmedComponents": true
  "hasReplacedComponents": true,
  "possibleNextAction": "CONFIRM"
}

possibleNextAction 初步顯示地址可能需要與顧客確認。判決中的其他信號會提供更多詳細資料，說明地址可能存在的問題。PREMISE_PROXIMITY 表示建築物地址的近似值，但不如 SUB_PREMISE 詳細，後者是輸入時提供的精細度。回覆內容也包含未確認和已更換的元件。

查詢地址元件後，發現以下問題：

{
  "componentName": {
    "text": "451",
  },
  "componentType": "street_number",
  "confirmationLevel": "UNCONFIRMED_BUT_PLAUSIBLE",
}
...
{
  "componentName": {
    "text": "98104",
  },
  "componentType": "postal_code",
  "confirmationLevel": "CONFIRMED",
  "replaced": true
}
...
{
  "componentName": {
    "text": "Building D",
    "language_code": "en"
  },
  "componentType": "subpremise",
  "confirmationLevel": "UNCONFIRMED_BUT_PLAUSIBLE",
}
.......

    "unconfirmedComponentTypes": [
      "street_number",
      "subpremise"
    ]

在本例中，Address Validation API 找到與所提供地址最接近的地址，並將郵遞區號這個較高層級的元件替換為西雅圖地址。這可能是有效的替代方案，但由於元件未經確認，因此有必要確保使用者打算輸入西雅圖地址，而非其他地址，例如柯克蘭。

特殊案例範例：確認

以下範例說明下列邊緣情況類型：

已確認的次要推論。地址驗證 API 會推斷國家/地區、郵遞區號或州別，但其他所有資訊都會提供並確認。粒度和確認層級的組合會產生次要推論，不一定需要確認動作。
未確認的非預期地址元件。未確認的地址元件會增加地址的風險等級。這可能需要確認。
已確認的非預期地址元件。這個元件並非正確地址的必要條件，而且 Address Validation API 會從輸出內容中移除這個元件。格式問題通常不需要確認。

已確認的次要推論

如果輸入內容只缺少下列其中一種類型的單一元件，API 仍可結合更精細層級的已確認資料，做出正確推論：

城市
州
郵遞區號
國家/地區

舉例來說，顧客提供麻州春田鎮麥當勞餐廳的有效街道地址，但忘記輸入城市，且提供的郵遞區號沒有 4 位數的擴展碼。

輸入的地址	區域
1402 Allen St, MA 01118	美國

缺少城市資訊的判決

{
  "inputGranularity": "PREMISE",
  "validationGranularity": "PREMISE",
  "geocodeGranularity": "PREMISE",
  "addressComplete": true,
  "hasInferredComponents": true,
  "possibleNextAction": "CONFIRM"
}

如果地址驗證 API 推斷出較高層級的元件，以產生可遞送的地址，您就能更有把握系統提供的資料正確無誤。這是因為代表廣泛地理區域的推斷元件，更容易與更精細的已確認地址元件比對。即使在城市名稱重複的國家/地區 (例如美國的 Springfield)，其他元件與城市名稱結合後，仍可提供不重複的地址。

以上述範例來說，掃描所有地址元件後，會發現每個元件都已確認，表示這些元件與 Address Validation API 儲存的資料相符，且服務也會推斷出兩個較高層級的元件。

{
  "componentName": {
    "text": "Springfield",
    "languageCode": "en"
  },
  "componentType": "locality",
  "confirmationLevel": "CONFIRMED",
  "inferred": true
},
{
  "componentName": {
    "text": "1806"
  },
  "componentType": "postal_code_suffix",
  "confirmationLevel": "CONFIRMED",
  "inferred": true
}

未確認的非預期地址元件

這個情境說明瞭在未確認元件時檢查的重要性。如果地址元件不符預期，Address Validation API 會從輸出內容中移除該元件。在這些情況下，您可以接受地址，也可以視風險程度和信心程度，與顧客重新確認地址。

舉例來說，地址可能來自某個地區，當地顧客經常輸入郵政主管機關會忽略的無害資訊，在這種情況下，您會接受該地址。不過，在某些情況下，未確認的元件可能不是顧客想要的。

輸入的地址	區域
59 Cherrydown Avenue, Chingford, London E4 8DT	英國

未確認非預期地址元件的判決

{
  "inputGranularity": "PREMISE",
  "validationGranularity": "PREMISE",
  "geocodeGranularity": "PREMISE",
  "unconfirmedComponents": true,
  "possibleNextAction": "ACCEPT"
}

除了含有未確認元件的判定結果，Address Validation API 也會傳回下列格式化地址：

"formattedAddress": "59 Cherrydown Avenue, London E4 8DT, UK",

掃描未確認的元件後，API 會從傳回的地址中移除「Chingford」：

{
  "componentName": {
    "text": "Chingford",
    "languageCode": "en"
  },
  "componentType": "sublocality_level_1",
  "confirmationLevel": "UNCONFIRMED_BUT_PLAUSIBLE",
  "unexpected": true
}

已確認的非預期地址元件

這個範例說明如何將英國郡別納入提供的地址，這是常見做法。不過，英國郵政主管機關並未規定必須提供這項資訊，因此基本上會忽略這項資訊。請參閱 postoffice.co.uk 和如何填寫英國和國際郵件的地址。

因此，當顧客在英國地址中提供郡時，服務會將此視為非預期的輸入內容。

輸入的地址	區域
33 Dunalley St, Cheltenham, Gloucestershire, GL50 4AP	英國

已確認的非預期地址元件的判決

{
   "inputGranularity": "PREMISE",
   "validationGranularity": "PREMISE",
   "geocodeGranularity": "PREMISE",
   "possibleNextAction": "ACCEPT"
}

在此，address_complete 會評估為 false，且地址元件的分析結果會顯示非預期的旗標。

{
  "componentName": {
    "text": "Gloucestershire",
    "languageCode": "en"
  },
  "componentType": "administrative_area_level_2",
  "confirmationLevel": "CONFIRMED",
  "unexpected": true
}

雖然輸入的地址位於格洛斯特郡，但地址格式不正確。請注意，Address Validation API 也會評估資訊格式是否正確。