此页面由 Cloud Translation API 翻译。

确认地址 - 示例

本文档介绍了一些实际场景，其中 Address Validation API 会为需要系统执行确认行为的地址提供响应信号。如需了解背景信息，请参阅构建验证逻辑中的工作流程概览。

常见示例：确认

以下示例展示了街道名称相似的大都市地区的情况。假设用户打算输入 Google Building D in Kirkland, WA, United States（美国华盛顿州柯克兰市 Google Building D）的地址。不过，他们无意中输入的是 Seattle（西雅图），而不是 Kirkland（柯克兰）。

输入的地址	区域
Building D, 451 7th Avenue South, Seattle, WA 98033	美国

替换数据的判定结果

以下示例突出显示了响应中的重要信号。

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

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 找到了与所提供的西雅图地址相近的地址，并替换了邮政编码（更高级别的组件），以解析出西雅图地址。这可能是有效的替换项，但鉴于组件未经确认，因此有必要确保用户打算输入的是西雅图地址，而不是其他地址（例如 Kirkland）。

边缘情况示例：确认

以下示例展示了以下边界情况类型：

已确认的次要推理。 Address Validation API 会推断出国家/地区、邮政编码或州/省，但所有其他信息均由您提供并确认。精确度和确认级别的结合使得次要推理不一定需要确认操作。
意外的地址组成部分未确认。未经确认的地址组成部分会增加地址的风险级别。这可能需要确认。
已确认的意外地址组成部分。正确的地址并非严格要求包含此组件，Address Validation API 会将其从输出中移除。格式问题通常不需要确认。

已确认的轻微推断

与更精细级别的已确认数据结合使用时，即使输入数据仅缺少以下类型的一个组成部分，该 API 仍可做出正确的推理：

城市
州
邮编
国家/地区

例如，客户提供了位于马萨诸塞州斯普林菲尔德的麦当劳餐厅的有效街道地址，但忘记输入城市，并且提供的邮政编码没有 4 位数的后缀。

输入的地址	区域
1402 Allen St, MA 01118	美国

缺少城市的判定结果

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

在 Address Validation API 推断出更高级别的组件以生成可投递的地址的情况下，您可以更确信系统中的数据是正确的。这是因为，代表广大地理区域的推断出组成部分更容易与更精细的已确认地址组成部分匹配。即使在重复使用城市名称的国家/地区（例如美国的斯普林菲尔德），结合使用其他组件也可以提供唯一的地址。

使用上面的示例，对所有地址组成部分进行扫描后，您会发现每个组成部分均已确认，这意味着该组成部分与 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 会将其从输出中移除。在这种情况下，您可以接受地址，也可以与客户重新确认地址，具体取决于风险级别和信心级别。

例如，某个地址可能位于客户经常输入无害信息且邮政机构会忽略信息的地区，在这种情况下，您可以接受该地址。不过，在某些情况下，未经确认的组件可能不是客户想要的。

输入的地址	区域
1 Rue Grenache, la caritat 2, 34630 Saint-Thibéry	法国

未确认针对意外地址组件的判定结果

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

除了包含未经确认组件的判定结果之外，Address Validation API 还会返回以下格式的地址：

"formattedAddress": "1 Rue Grenache, 34630 Saint-Thibéry, France",

扫描未经确认的组件后，发现该 API 已从返回的地址中移除 la caritat 2：

{
  "componentName": {
    "text": "la caritat 2",
    "languageCode": "fr"
  },
  "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"
}

在这里，address_complete 的计算结果为 false，而对地址组件的分析显示了一个意外的标志。

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

虽然 Gloucestershire 是输入地址的正确郡，但地址本身的格式不正确。回想一下，Address Validation API 还会评估信息是否采用了正确的格式。