Google 会使用 AI 技术将内容翻译成您偏好的语言。AI 翻译可能包含错误。

确认地址 - 示例

本文档介绍了一些真实场景，在这些场景中，Address Validation 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
}

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 在西雅图 找到了与所提供地址非常接近的地址，并替换了邮政编码（一个更高级别的组件），以解析为西雅图 的地址。这可能是有效的替换，但考虑到组件未确认，因此有必要确保用户打算输入西雅图的地址，而不是其他地址（例如柯克兰）。

极端情况示例：确认

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

已确认的次要推断。 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 和 How to address UK and international mail。

因此，当客户在英国地址中提供郡时，该服务会将其评估为意外输入。

输入的地址	区域
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 还会评估信息是否格式正确。