此页面由 Cloud Translation API 翻译。

确认地址 - 示例

本文档介绍了许多真实场景，在这些场景中，Address Validation API 为可保证您的系统提供 confirm 行为的地址提供响应信号。如需了解上下文，请参阅构建验证逻辑中的工作流概览。

常见示例：确认

以下示例说明了具有类似街道名称的都市圈区域的情况。假设用户打算输入“位于美国华盛顿州柯克兰的 Google D 大厦”的地址。然而，他们并没有输入 Kirkland 作为城市，而是意外输入了 Seattle（西雅图）。

已输入地址	区域
邮编：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 那样详细，SUB_PREMISE 是输入时提供的粒度。响应还包含未确认的组件和替换的组件，因此组合会将这种情况提示到 confirm 类别。

通过查询地址组成部分，可以发现以下需要关注的方面：

{
  "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）。

极端案例示例：确认

以下示例说明了以下极端情况类型：

经 ARE 确认的细微推论。 Address Validation API 会推断国家/地区、邮政编码或州，但其他所有内容都会提供并进行确认。结合粒度和确认级别，对于细微的推断，不一定需要确认操作。
未确认意外的地址组成部分。未经确认的地址组成部分会增加地址的风险等级。这可能需要确认。
已确认的意外地址组成部分。该组件并不严格用于正确地址，并且 Address Validation API 会从输出中移除该组件。格式问题通常不能保证需要确认。

ARE 确认的次要推导

与更精细的已确认数据结合时，如果输入仅缺少以下类型的一个组成部分，则 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
}

虽然所输入地址的正确郡/县是格洛斯特郡，但地址本身的格式不正确。回想一下，Address Validation API 还会评估信息以确保格式正确。