一种地址映射方法及装置

摘要

本申请实施例提供一种地址映射方法及装置，所述方法包括：获取待处理地址数据；在地址数据信息集合包含的正常地址数据中，查询所述待处理地址数据；在所述正常地址数据中未查询到所述待处理地址数据的情况下，依据所述正常地址数据，确定所述待处理地址数据中出现行政区划变更的异常行政区划；依据所述原始地址数据与所述最新地址数据之间的映射关系，确定与所述异常行政区划对应的正常行政区划。不论待处理地址数据中包含变更后行政区划还是变更前行政区划，本申请均基于变更后的行政区划执行处理，从而使控制器准确处理同一地点的具有行政区划变更的不同地址数据。

权利要求

1.一种地址映射方法，其特征在于，包括：

获取待处理地址数据；其中，所述待处理地址数据包括多级行政区划；所述获取待处理地址数据的方式包括：接收用户输入的待处理用户地址、在控制器自身所在地址处理系统维护的地址数据库中选取一个地址，作为待处理地址数据，或者，在获取其它地址处理系统发送的地址，将该地址作为待处理地址数据；

在地址数据信息集合包含的正常地址数据中，查询所述待处理地址数据；其中，所述正常地址数据包括：未进行行政区划变更的地址数据和进行行政区划变更后的最新地址数据；所述地址数据信息集合还包括异常地址数据，其中，所述异常地址数据包括：与所述最新地址数据对应的变更前的原始地址数据，以及，所述原始地址数据与所述最新地址数据之间的映射关系；

在所述正常地址数据中未查询到所述待处理地址数据的情况下，依据所述正常地址数据，确定所述待处理地址数据中出现行政区划变更的异常行政区划；

依据所述原始地址数据与所述最新地址数据之间的映射关系，确定与所述异常行政区划对应的正常行政区划；

其中，所述在地址数据信息集合包含的正常地址数据中，查询所述待处理地址数据，包括：在地址数据信息集合的正常地址数据中，确定与所述待处理地址数据的对应的标准地址数据；

将所述待处理地址数据的行政区划与所述标准地址数据的行政区划进行逐级对比；

其中，所述依据所述正常地址数据，确定所述待处理地址数据中出现行政区划变更的异常行政区划，包括：在所述待处理地址数据的行政区划与所述标准地址数据的行政区划对比不成功的情况下，若所述待处理地址数据中对比不成功的行政区划为空，将对比不成功行政区划的下一级行政区划作为所述异常行政区划；

所述地址数据信息集合的生成过程包括：

对预设数据库中的所有地址按预设协议格式进行初始化，生成初始化地址数据；

解析所述初始化地址数据，生成所述地址数据信息集合；

所述预设协议格式包括两种方式：

第一种方式用于行政区划的级别的变更，包括：用于指示预设协议的起始字段的第一元素；用于指示行政区划变更次数的第二元素；用于指示行政区划变更类型的第三元素；用于指示行政区划变更前的原始地址数据的位置的第四元素；用于指示行政区划变更前的原始地址数据的多个元素；

第二种方式用于对行政区划的名称和代码的变更，包括：用于指示预设协议的起始字段的第一元素；用于指示行政区划变更次数的第二元素；用于指示行政区划变更类型的第三元素；用于指示行政区划变更前的原始地址数据的位置的第四元素；在所述行政区划的变更为合并或分裂的情况下，用于指示行政区划为全部变更或部分变更的第五元素；用于指示行政区划变更前的原始地址数据的多个元素。

2.如权利要求1所述的方法，其特征在于，所述正常地址数据包含除最高级别行政区划外每级行政区划的父级行政区划；则所述在地址数据信息集合的正常地址数据中，确定与所述待处理地址数据的对应的标准地址数据，包括：由最小级别的行政区划开始，依次查询每个行政区划的父级行政区划，直到最高级别的行政区划为止；

将每个行政区划的父级行政区划，以及，所述最小级别的行政区划，按行政区划级别由高到低的顺序排列，生成所述待处理地址数据的标准地址数据。

3.如权利要求1所述的方法，其特征在于，所述依据所述正常地址数据，确定所述待处理地址数据中出现行政区划变更的异常行政区划，还包括：若所述待处理地址数据的行政区划与所述标准地址数据的行政区划对比不成功的情况下，若所述待处理地址数据中对比不成功的行政区划非空，则将所述地址数据中对比不成功的行政区划，确定为出现行政区划变更的所述异常行政区划。

4.如权利要求1所述的方法，其特征在于，所述异常地址数据包括所述原始地址数据和所述最新地址数据之间的多个类型的映射关系；则所述在所述异常地址数据的映射关系中，确定与所述异常行政区划对应的正常行政区划，包括：逐个在每个类型的映射关系中，查找所述异常行政区划；

在某个类型的映射关系中查找到所述异常行政区划的情况下，在该类型的映射关系中，获取与所述异常行政区划对应的所述正常行政区划。

5.如权利要求4所述的方法，其特征在于，所述异常地址数据的多个类型的映射关系，包括：在行政区划的名称发生变更的情况下，用于表示原始地址数据中变更前行政区划的名称，与，最新地址数据中变更后行政区划的名称之间的名称映射关系；

在行政区划的ID发生变更的情况下，用于表示所述原始地址数据中变更前行政区划的ID，与，所述最新地址数据中变更后行政区划的ID之间的ID映射关系；

在行政区划的级别发生变更的情况下，用于表示原始地址数据中级别变更前行政区划的ID，与，最新地址数据中级别变更后行政区划的ID之间的映射关系；和/或，用于表示原始地址数据中级别变更前行政区划的名称，与，最新地址数据中级别变更后行政区划的名称之间的映射关系；

在行政区划有合并或分裂的情况下，用于表示原始地址数据中合并或分裂前行政区划的ID，与，最新地址数据中合并或分裂后行政区划的ID之间的映射关系；和/或，用于表示原始地址数据中合并或分裂前行政区划的名称，与，最新地址数据中合并或分裂后行政区划的名称之间的映射关系。

6.如权利要求5所述的方法，其特征在于，所述异常地址数据的多个类型的映射关系，还包括：在行政区划的级别市级行政区划或县级行政区划的情况下，用于存储原始地址数据中行政区划的ID，与，表示该行政区划是否可进行级别提升的结果之间的映射关系；和/或，在行政区划的级别市级行政区划或县级行政区划的情况下，用于存储原始地址数据中行政区划的名称，与，表示该行政区划是否可进行级别提升的结果之间的映射关系。

7.一种地址映射装置，其特征在于，包括：

第一获取单元，用于获取待处理地址数据；其中，所述待处理地址数据包括多级行政区划；所述获取待处理地址数据的方式包括：接收用户输入的待处理用户地址、在控制器自身所在地址处理系统维护的地址数据库中选取一个地址，作为待处理地址数据，或者，在获取其它地址处理系统发送的地址，将该地址作为待处理地址数据；

第一查询单元，用于在地址数据信息集合包含的正常地址数据中，查询所述待处理地址数据；其中，所述正常地址数据包括：未进行行政区划变更的地址数据和进行行政区划变更后的最新地址数据；所述地址数据信息集合还包括异常地址数据，其中，所述异常地址数据包括：与所述最新地址数据对应的变更前的原始地址数据，以及，所述原始地址数据与所述最新地址数据之间的映射关系；

第一确定单元，用于在所述正常地址数据中未查询到所述待处理地址数据的情况下，依据所述正常地址数据，确定所述待处理地址数据中出现行政区划变更的异常行政区划；

映射单元，用于依据所述原始地址数据与所述最新地址数据之间的映射关系，确定与所述异常行政区划对应的正常行政区划；

其中，所述第一查询单元，包括：

第二确定单元，用于在地址数据信息集合的正常地址数据中，确定与所述待处理地址数据的对应的标准地址数据；

第二查询单元，用于将所述待处理地址数据的行政区划与所述标准地址数据的行政区划进行逐级对比；

其中，所述第一确定单元，包括：

第四确定单元，用于在所述待处理地址数据的行政区划与所述标准地址数据的行政区划对比不成功的情况下，若所述待处理地址数据中对比不成功的行政区划为空，将对比不成功行政区划的下一级行政区划作为所述异常行政区划；

初始化单元，用于对预设数据库中的所有地址按预设协议格式进行初始化，生成初始化地址数据；

解析单元，用于解析所述初始化地址数据，生成所述地址数据信息集合；

所述预设协议格式包括两种方式：

第一种方式用于行政区划的级别的变更，包括：用于指示预设协议的起始字段的第一元素；用于指示行政区划变更次数的第二元素；用于指示行政区划变更类型的第三元素；用于指示行政区划变更前的原始地址数据的位置的第四元素；用于指示行政区划变更前的原始地址数据的多个元素；

第二种方式用于对行政区划的名称和代码的变更，包括：用于指示预设协议的起始字段的第一元素；用于指示行政区划变更次数的第二元素；用于指示行政区划变更类型的第三元素；用于指示行政区划变更前的原始地址数据的位置的第四元素；在所述行政区划的变更为合并或分裂的情况下，用于指示行政区划为全部变更或部分变更的第五元素；用于指示行政区划变更前的原始地址数据的多个元素。

8.如权利要求7所述的装置，其特征在于，所述第二确定单元，包括：

第三查询单元，用于由最小级别的行政区划开始，依次查询每个行政区划的父级行政区划，直到最高级别的行政区划为止；

生成单元，用于将每个行政区划的父级行政区划，以及，所述最小级别的行政区划，按行政区划级别由高到低的顺序排列，生成所述待处理地址数据的标准地址数据。

9.如权利要求7所述的装置，其特征在于，所述第一确定单元，包括：

第三确定单元，用于若所述待处理地址数据的行政区划与所述标准地址数据的行政区划对比不成功的情况下，若所述待处理地址数据中对比不成功的行政区划非空，则将所述地址数据中对比不成功的行政区划，确定为出现行政区划变更的所述异常行政区划。

10.如权利要求7所述的装置，其特征在于，所述异常地址数据包括所述原始地址数据和所述最新地址数据之间的多个类型的映射关系；则所述映射单元，包括：查找单元，用于逐个在每个类型的映射关系中，查找所述异常行政区划；

第二获取单元，用于在某个类型的映射关系中查找到所述异常行政区划的情况下，在该类型的映射关系中，获取与所述异常行政区划对应的所述正常行政区划。

11.如权利要求10所述的装置，其特征在于，所述异常地址数据的多个类型的映射关系，包括：在行政区划的名称发生变更的情况下，用于表示原始地址数据中变更前行政区划的名称，与，最新地址数据中变更后行政区划的名称之间的名称映射关系；

在行政区划的ID发生变更的情况下，用于表示所述原始地址数据中变更前行政区划的ID，与，所述最新地址数据中变更后行政区划的ID之间的ID映射关系；

在行政区划的级别发生变更的情况下，用于表示原始地址数据中级别变更前行政区划的ID，与，最新地址数据中级别变更后行政区划的ID之间的映射关系；和/或，用于表示原始地址数据中级别变更前行政区划的名称，与，最新地址数据中级别变更后行政区划的名称之间的映射关系；

在行政区划有合并或分裂的情况下，用于表示原始地址数据中合并或分裂前行政区划的ID，与，最新地址数据中合并或分裂后行政区划的ID之间的映射关系；和/或，用于表示原始地址数据中合并或分裂前行政区划的名称，与，最新地址数据中合并或分裂后行政区划的名称之间的映射关系。

12.如权利要求11所述的装置，其特征在于，所述异常地址数据的多个类型的映射关系，还包括：在行政区划的级别市级行政区划或县级行政区划的情况下，用于存储原始地址数据中行政区划的ID，与，表示该行政区划是否可进行级别提升的结果之间的映射关系；和/或，在行政区划的级别市级行政区划或县级行政区划的情况下，用于存储原始地址数据中行政区划的名称，与，表示该行政区划是否可进行级别提升的结果之间的映射关系。

说明书

一种地址映射方法及装置

技术领域

[0001] 本申请涉及地址数据处理技术领域，尤其涉及一种地址映射方法及装置。

背景技术

[0002] 随着网络技术的迅速发展，为了更好地实现数据交互，许多终端应用均涉及用户地址，所以对用户地址进行准确识别显得越来越重要。例如，对于各大购物网站或快递行业公司而言，准确识别用户地址，并据此判断是否在其业务覆盖范围内，这是提供快递服务的一个基础环节。

[0003] 一般情况下，用户地址使用多级行政区划的方式进行体现。其中，行政区划为国家行政管理划分的区域级别，比如，省级行政区划、市级行政区划和区级行政区划等。

[0004] 随着国家地址政策的变更，行政区划也会随之变更。行政区划变更的方式可以为：区行政区划的名称更改，两个区行政区划合并为一个行政区划，或，在一个行政区划中增加下级行政区划等。

[0005] 在行政区划发生变更的情况下，在一定时间内会出现用户认知不统一的问题。比如，第一部分用户在一定时间内不知晓行政区划的变更情况，在一定时间后才知晓行政区划的变更情况；第二部分用户在一定时间内便知晓行政区划的变更情况。

[0006] 所以，在一定时间内第一部分用户填写的用户地址为：包含变更前行政区划的错误地址；第二部分用户填写的用户地址为：包含变更后行政区划的正确地址。这使得同一地点可能具有两个及以上的用户地址，导致控制器无法准确处理同一地点的两个不同地址。

发明内容

[0007] 本申请发明人在研究过程中发现解决上述问题的两种方式：

[0008] 第一种方式：强制用户输入正确的用户地址。

[0009] 在用户在填写用户地址时，电商平台系统检测用户填写的用户地址中的各个行政区划是否为最新行政区划；若用户地址中包含变更前行政区划，则提示用户对用户地址升级或者强制用户对用户地址升级。

[0010] 但是，若用户知晓填写的用户地址中某一行政区划发生变更时，则可直接将原始的行政区划维护到变更后的最新行政区划，从而达到升级用户地址的目的。若用户不知晓用户地址中某一行政区划发生变更，则需要用户采用其他方式才能够获知行政区划的变更数据。所以，本方式会影响用户的购物体验，可能造成订单和用户的流失。

[0011] 第二种方式：由地址处理系统识别正确地址和错误地址。

[0012] 若未采用第一种方式的情况下，在用户下单后地址处理系统中可能同时存在：包含变更前行政区划的错误地址，和，包含变更后行政区划的正确地址。但是，本方式中系统缺乏变更前行政区划和变更后行政区划之间建立映射关系，导致系统无法同时兼容变更前行政区划和变更后行政区划。

[0013] 鉴于此，本申请提供一种地址映射方法及装置。本申请能够在变更前行政区划和变更后行政区划之间建立映射关系，从而使控制器准确处理同一地点的具有行政区划变更的不同地址数据。

[0014] 为了实现上述目的，本申请提供了以下技术手段：

[0015] 一种地址映射方法，包括：

[0016] 获取待处理地址数据；其中，所述待处理地址数据包括多级行政区划；

[0017] 在地址数据信息集合包含的正常地址数据中，查询所述待处理地址数据；其中，所述正常地址数据包括：未进行行政区划变更的地址数据和进行行政区划变更后的最新地址数据；所述地址数据信息集合还包括异常地址数据，其中，所述异常地址数据包括：与所述最新地址数据对应的变更前的原始地址数据，以及，所述原始地址数据与所述最新地址数据之间的映射关系；

[0018] 在所述正常地址数据中未查询到所述待处理地址数据的情况下，依据所述正常地址数据，确定所述待处理地址数据中出现行政区划变更的异常行政区划；

[0019] 依据所述原始地址数据与所述最新地址数据之间的映射关系，确定与所述异常行政区划对应的正常行政区划。

[0020] 优选的，所述在地址数据信息集合包含的正常地址数据中，查询所述待处理地址数据，包括：

[0021] 在地址数据信息集合的正常地址数据中，确定与所述待处理地址数据的对应的标准地址数据；

[0022] 将所述待处理地址数据的行政区划与所述标准地址数据的行政区划进行逐级对比。

[0023] 优选的，所述正常地址数据包含除最高级别行政区划外每级行政区划的父级行政区划；则所述在地址数据信息集合的正常地址数据中，确定与所述待处理地址数据的对应的标准地址数据，包括：

[0024] 由最小级别的行政区划开始，依次查询每个行政区划的父级行政区划，直到最高级别的行政区划为止；

[0025] 将每个行政区划的父级行政区划，以及，所述最小级别的行政区划，按行政区划级别由高到低的顺序排列，生成所述待处理地址数据的标准地址数据。

[0026] 优选的，所述依据所述正常地址数据，确定所述待处理地址数据中出现行政区划变更的异常行政区划，包括：

[0027] 若所述待处理地址数据的行政区划与所述标准地址数据的行政区划对比不成功的情况下，若所述待处理地址数据中对比不成功的行政区划非空，则将所述地址数据中对比不成功的行政区划，确定为出现行政区划变更的所述异常行政区划；

[0028] 在所述待处理地址数据中对比不成功的行政区划为空的情况下，将对比不成功行政区划的下一级行政区划作为所述异常行政区划。

[0029] 优选的，所述地址数据信息集合的生成过程包括：

[0030] 对预设数据库中的所有地址按预设协议格式进行初始化，生成初始化地址数据；

[0031] 解析所述初始化地址数据，生成所述地址数据信息集合。

[0032] 优选的，所述预设协议格式包括：

[0033] 用于指示预设协议的起始字段的第一元素；

[0034] 用于指示行政区划变更次数的第二元素；

[0035] 用于指示行政区划变更类型的第三元素；

[0036] 用于指示行政区划变更前的原始地址数据的位置的第四元素；

[0037] 用于指示行政区划变更前的原始地址数据的多个元素。

[0038] 优选的，所述预设协议格式还包括：

[0039] 在所述行政区划的变更类型为合并或分裂的情况下，用于指示行政区划为全部变更或部分变更的第五元素。

[0040] 优选的，所述异常地址数据包括所述原始地址数据和所述最新地址数据之间的多个类型的映射关系；则所述在所述异常地址数据的映射关系中，确定与所述异常行政区划对应的正常行政区划，包括：

[0041] 逐个在每个类型的映射关系中，查找所述异常行政区划；

[0042] 在某个类型的映射关系中查找到所述异常行政区划的情况下，在该类型的映射关系中，获取与所述异常行政区划对应的所述正常行政区划。

[0043] 优选的，所述异常地址数据的多个类型的映射关系，包括：

[0044] 在行政区划的名称发生变更的情况下，用于表示原始地址数据中变更前行政区划的名称，与，最新地址数据中变更后行政区划的名称之间的名称映射关系；

[0045] 在行政区划的ID发生变更的情况下，用于表示所述原始地址数据中变更前行政区划的ID，与，所述最新地址数据中变更后行政区划的ID之间的ID映射关系；

[0046] 在行政区划的级别发生变更的情况下，用于表示原始地址数据中级别变更前行政区划的ID，与，最新地址数据中级别变更后行政区划的ID之间的映射关系；和/或，用于表示原始地址数据中级别变更前行政区划的名称，与，最新地址数据中级别变更后行政区划的名称之间的映射关系；

[0047] 在行政区划有合并或分裂的情况下，用于表示原始地址数据中合并或分裂前行政区划的ID，与，最新地址数据中合并或分裂后行政区划的ID之间的映射关系；和/或，用于表示原始地址数据中合并或分裂前行政区划的名称，与，最新地址数据中合并或分裂后行政区划的名称之间的映射关系。

[0048] 优选的，所述异常地址数据的多个类型的映射关系，还包括：

[0049] 在行政区划的级别市级行政区划或县级行政区划的情况下，用于存储原始地址数据中行政区划的ID，与，表示该行政区划是否可进行级别提升的结果之间的映射关系；和/或，

[0050] 在行政区划的级别市级行政区划或县级行政区划的情况下，用于存储原始地址数据中行政区划的名称，与，表示该行政区划是否可进行级别提升的结果之间的映射关系。

[0051] 一种地址映射装置，包括：

[0052] 第一获取单元，用于获取待处理地址数据；其中，所述待处理地址数据包括多级行政区划；

[0053] 第一查询单元，用于在地址数据信息集合包含的正常地址数据中，查询所述待处理地址数据；其中，所述正常地址数据包括：未进行行政区划变更的地址数据和进行行政区划变更后的最新地址数据；所述地址数据信息集合还包括异常地址数据，其中，所述异常地址数据包括：与所述最新地址数据对应的变更前的原始地址数据，以及，所述原始地址数据与所述最新地址数据之间的映射关系；

[0054] 第一确定单元，用于在所述正常地址数据中未查询到所述待处理地址数据的情况下，依据所述正常地址数据，确定所述待处理地址数据中出现行政区划变更的异常行政区划；

[0055] 映射单元，用于依据所述原始地址数据与所述最新地址数据之间的映射关系，确定与所述异常行政区划对应的正常行政区划。

[0056] 优选的，所述第一查询单元，包括：

[0057] 第二确定单元，用于在地址数据信息集合的正常地址数据中，确定与所述待处理地址数据的对应的标准地址数据；

[0058] 第二查询单元，用于将所述待处理地址数据的行政区划与所述标准地址数据的行政区划进行逐级对比。

[0059] 优选的，所述第二确定单元，包括：

[0060] 第三查询单元，用于由最小级别的行政区划开始，依次查询每个行政区划的父级行政区划，直到最高级别的行政区划为止；

[0061] 生成单元，用于将每个行政区划的父级行政区划，以及，所述最小级别的行政区划，按行政区划级别由高到低的顺序排列，生成所述待处理地址数据的标准地址数据。

[0062] 优选的，所述第一确定单元，包括：

[0063] 第三确定单元，用于若所述待处理地址数据的行政区划与所述标准地址数据的行政区划对比不成功的情况下，若所述待处理地址数据中对比不成功的行政区划非空，则将所述地址数据中对比不成功的行政区划，确定为出现行政区划变更的所述异常行政区划；

[0064] 第四确定单元，用于在所述待处理地址数据中对比不成功的行政区划为空的情况下，将对比不成功行政区划的下一级行政区划作为所述异常行政区划。

[0065] 优选的，还包括：

[0066] 初始化单元，用于对预设数据库中的所有地址按预设协议格式进行初始化，生成初始化地址数据；

[0067] 解析单元，用于解析所述初始化地址数据，生成所述地址数据信息集合。

[0068] 优选的，所述预设协议格式包括：

[0069] 用于指示预设协议的起始字段的第一元素；

[0070] 用于指示行政区划变更次数的第二元素；

[0071] 用于指示行政区划变更类型的第三元素；

[0072] 用于指示行政区划变更前的原始地址数据的位置的第四元素；

[0073] 用于指示行政区划变更前的原始地址数据的多个元素。

[0074] 优选的，所述预设协议格式还包括：

[0075] 在所述行政区划的变更类型为合并或分裂的情况下，用于指示行政区划为全部变更或部分变更的第五元素。

[0076] 优选的，所述异常地址数据包括所述原始地址数据和所述最新地址数据之间的多个类型的映射关系；则所述映射单元，包括：

[0077] 查找单元，用于逐个在每个类型的映射关系中，查找所述异常行政区划；

[0078] 第二获取单元，用于在某个类型的映射关系中查找到所述异常行政区划的情况下，在该类型的映射关系中，获取与所述异常行政区划对应的所述正常行政区划。

[0079] 优选的，所述异常地址数据的多个类型的映射关系，包括：

[0080] 在行政区划的名称发生变更的情况下，用于表示原始地址数据中变更前行政区划的名称，与，最新地址数据中变更后行政区划的名称之间的名称映射关系；

[0081] 在行政区划的ID发生变更的情况下，用于表示所述原始地址数据中变更前行政区划的ID，与，所述最新地址数据中变更后行政区划的ID之间的ID映射关系；

[0082] 在行政区划的级别发生变更的情况下，用于表示原始地址数据中级别变更前行政区划的ID，与，最新地址数据中级别变更后行政区划的ID之间的映射关系；和/或，用于表示原始地址数据中级别变更前行政区划的名称，与，最新地址数据中级别变更后行政区划的名称之间的映射关系；

[0083] 在行政区划有合并或分裂的情况下，用于表示原始地址数据中合并或分裂前行政区划的ID，与，最新地址数据中合并或分裂后行政区划的ID之间的映射关系；和/或，用于表示原始地址数据中合并或分裂前行政区划的名称，与，最新地址数据中合并或分裂后行政区划的名称之间的映射关系。

[0084] 优选的，所述异常地址数据的多个类型的映射关系，还包括：

[0085] 在行政区划的级别市级行政区划或县级行政区划的情况下，用于存储原始地址数据中行政区划的ID，与，表示该行政区划是否可进行级别提升的结果之间的映射关系；和/或，

[0086] 在行政区划的级别市级行政区划或县级行政区划的情况下，用于存储原始地址数据中行政区划的名称，与，表示该行政区划是否可进行级别提升的结果之间的映射关系。

[0087] 从以上技术内容可以看出，本申请具有以下有益效果：

[0088] 本申请实施例中，在地址数据信息集合的正常地址数据中，存储有所有行政区划的最新数据，在异常地址数据中存储有行政区划变更前的原始地址数据与行政区划变更后的最新地址数据之间的映射关系。所以，当待处理地址数据中包含变更后的正常行政区划时，依据正常地址数据均可进行处理。当待处理地址数据中包含变更前的异常行政区划时，将异常行政区划映射到正常行政区划，后续处理可以基于正常行政区划来处理。从而使控制器准确处理同一地点的具有行政区划变更的不同地址数据。

附图说明

[0089] 为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

[0090] 图1为本申请提供的一种地址映射方法的流程图；

[0091] 图2为本申请提供的一种地址映射方法中进行行政区划对比的流程图；

[0092] 图3为本申请提供的一种地址映射方法中生成标准地址数据的流程图；

[0093] 图4为本申请提供的一种地址映射方法中确定正常行政区划的流程图；

[0094] 图5为本申请提供的一种地址映射方法中生成地址数据信息集合的流程图；

[0095] 图6为本申请提供的一种地址映射方法中预设协议体现形式；

[0096] 图7为本申请提供的又一种地址映射方法中预设协议体现形式；

[0097] 图8为本申请提供的又一种地址映射方法中预设协议体现形式；

[0098] 图9为本申请提供的又一种地址映射方法中预设协议体现形式；

[0099] 图10为本申请提供的又一种地址映射方法中预设协议体现形式；

[0100] 图11为本申请提供的一种地址映射装置的结构图示意图；

[0101] 图12为本申请提供的一种地址映射装置中第一查询单元的结构图示意图；

[0102] 图13为本申请提供的一种地址映射装置中第一确定单元的结构图示意图；

[0103] 图14为本申请提供的又一种地址映射装置的结构图示意图；

[0104] 图15为本申请提供的一种地址映射装置中映射单元的结构图示意图。

具体实施方式

[0105] 下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

[0106] 本申请可以应用于电商平台(淘宝网、天猫网、当当网或京东网)的地址处理系统，快递公司的地址处理系统，或者，其他需要兼容变更前行政区划和变更后行政区划的地址处理系统中。

[0107] 如图1所示，本申请提供一种地址映射方法，所述方法应用于地址处理系统的控制器中，具体包括步骤S101～S104：

[0108] 步骤S101：获取待处理地址数据；其中，所述待处理地址数据包括多级行政区划。

[0109] 首先，控制器需要获取一个待处理地址数据。获取待处理地址数据的方式可以为：接收用户输入的待处理用户地址；在控制器自身所在地址处理系统维护的地址数据库中选取一个地址，作为待处理地址数据；或者，在获取其它地址处理系统发送的地址，将该地址作为待处理地址数据。可以理解的是，还可以采用其他方式获取待处理地址数据。

[0110] 待处理地址数据包括多个行政区划，比如，省级行政区划，市级行政区划，区级行政区划，县级行政区划，和，街道或乡镇级行政区划。例如：在待处理地址数据为“新疆省伊犁市霍城县霍尔果斯口岸”时，其中“新疆省”为省级行政区划，“伊犁市”为市级行政区划，“霍城县”为县级行政区划，“霍尔果斯口岸”为街道或乡镇行政区划。

[0111] 步骤S102：在地址数据信息集合包含的正常地址数据中查询所述待处理地址数据；

[0112] 其中，所述正常地址数据包括：未进行行政区划变更的地址数据和进行行政区划变更后的最新地址数据；所述地址数据信息集合还包括异常地址数据，其中，所述异常地址数据包括：与所述最新地址数据对应的变更前的原始地址数据，以及，所述原始地址数据与所述最新地址数据之间的映射关系。

[0113] 本申请实施例采用地址数据信息集合来兼容变更前行政区划和变更后行政区划。其中，地址数据信息集合具体分为两个部分，第一部分为正常地址数据，第二部分为异常地址数据。下面分别对两部分数据进行详细介绍：

[0114] 第一部分：正常地址数据。

[0115] 正常地址数据的主要作用在于存储正确的行政区划，即行政区划的最新数据。所以正常地址数据包括：未进行行政区划变更的地址数据和进行行政区划变更后的最新地址数据。

[0116] 在一个行政区划未进行变更的情况下，该行政区划自身的地址数据便是正确地址数据，同时也是最新的地址数据。所有用户均采用该行政区划的地址数据描述该行政区划，因此该行政区划在使用时不会出现异常情况；所以该行政区划的地址数据属于正常地址数据。

[0117] 在一个行政区划进行变更情况下，在该行政区划变更后，则存在变更前的原始地址数据和变更后的最新地址数据。其中，最新地址数据是行政区划变更后的正确地址数据；若用户使用该行政区划的最新地址数据，则不会出现异常情况。所以，变更后行政区划的最新地址数据属于正常地址数据。

[0118] 可见，正常地址数据中存储的为，用户直接使用后不会出现异常的地址数据。

[0119] 第二部分：异常地址数据。

[0120] 异常地址数据包括：与所述最新地址数据对应的变更前的原始地址数据，以及，所述原始地址数据与所述最新地址数据之间的映射关系。

[0121] 在一个行政区划进行变更情况下，在该行政区划变更后，则存在变更前的原始地址数据和变更后的最新地址数据。其中，原始地址数据在行政区划变更后，理应不再使用。若用户继续使用则会出现异常情况，所以将原始地址数据存储于异常地址数据中。

[0122] 此外，为了保证在待处理地址数据中出现原始地址数据时，能够将原始地址映射到最新地址数据上，在异常地址数据中还设有正常地址数据和异常地址数据之间的映射关系。以便在变更后的最新地址数据和变更前的原始地址数据同时存在时，能够将确定两个地址数据为同一地点。

[0123] 步骤S102的上述内容为对地址数据信息集合的介绍，下面介绍基于地址数据信息集合查询待处理地址数据的具体过程。请参见图2，具体包括步骤S201～S202：

[0124] 步骤S201：在地址数据信息集合的正常地址数据中，确定与所述待处理地址数据的对应的标准地址数据。

[0125] 为了确定待处理地址数据中的多级行政区划是否为行政区划最新地址数据，首先需要在正常地址数据中，确定与待处理地址数据对应的标准地址数据。

[0126] 其中，确定标准地址数据的过程，参见图3，包括步骤S301～S303：

[0127] 步骤S301：由最小级别的行政区划开始，依次查询每个行政区划的父级行政区划，直到最高级别的行政区划为止。在正常地址数据中包含除最高级别行政区划外每级行政区划的父级行政区划。例如：街道或乡镇级行政区划的记录中包含父级行政区划为县级行政区划，在县级行政区划的记录中包含父级行政区划为市级行政区划，在市级行政区划的记录中包含父级行政区划为省级行政区划。

[0128] 本步骤在具体执行时，首先在所述待处理地址数据的多级行政区划中，确定最小级别的行政区划，然后由最小级别的行政区划开始，逐级向上查询父级行政区划，直到达到最高级别的行政区划为止，由此获得多个父级行政区划。

[0129] 当达到最高级别行政区划时，则说明在正常地址数据中，已经完成对待处理地址数据查询。由于最高级别的行政区划无父级行政区划，所以到最高级别的行政区划时便可停止执行本步骤。

[0130] 例如：在待处理地址数据为“新疆省伊犁市霍城县霍尔果斯口岸”时，其中“新疆省”为省级行政区划，“伊犁市”为市级行政区划，“霍城县”为县级行政区划，“霍尔果斯口岸”为街道或乡镇行政区划。

[0131] 其中，“霍尔果斯口岸”为最小级别的行政区划，在正常地址数据的街道或乡镇行政区划中，查找“霍尔果斯口岸”。在查找到“霍尔果斯口岸”后，在“霍尔果斯口岸”的记录中找到“霍尔果斯口岸”的父级行政区划“霍尔果斯市”。由于“伊犁市”进行过行政区划变更，在“伊犁市”下新增加“霍尔果斯市”，并将“霍尔果斯口岸”划分至“霍尔果斯市”管辖。所以，在正常地址数据中，“霍尔果斯口岸”的父级行政区划为“霍尔果斯市”。

[0132] 查询“霍尔果斯市”的父级行政区划“伊犁市”；再查询“伊犁市”的父级行政区划“新疆省”。从而获得“新疆省”、“伊犁市”和“霍尔果斯市”多个父级行政区划。

[0133] 步骤S302：将每个行政区划的父级行政区划，以及，所述最小级别的行政区划，按行政区划级别由高到低的顺序排列，生成所述待处理地址数据的标准地址数据。

[0134] 由于正常地址数据中存储的为行政区划的最新地址数据，所以由正常地址数据中，获得待处理地址数据的多个父级行政区划，也理应为行政区划的最新地址数据。所以，由多个父级行政区划和最小级别的行政区划按级别由高到低的顺序排列，生成的标准地址数据，应该为与待处理地址数据同一地点的最新行政区划的填写方式。

[0135] 例如：行政区划的级别由高到低依次为：省级行政区划，市级行政区划，区级行政区划，县级行政区划，和，街道或乡镇行政区划。则将按“新疆省”、“伊犁市”、“霍尔果斯市”和“霍尔果斯口岸”的排列顺序，组成标准地址数据“新疆省伊犁市霍尔果斯市霍尔果斯口岸”。该标准地址数据，应该为霍尔果斯口岸的最新行政区划的填写方式。

[0136] 接着返回图2，进入步骤S202：将所述待处理地址数据的行政区划与所述标准地址数据的行政区划进行逐级对比。

[0137] 将待处理地址数据中各个级别的行政区划与标准地址数据中各个级别的行政区划，按行政区划级别进行逐一对比。若两者的各个级别的行政区划完全一致，则表示待处理地址数据中不包含变更的行政区划，若两者的行政区划不完全一致，则表示待处理地址数据中包含变更的行政区划。

[0138] 接着返回图1，进入步骤S103：在所述正常地址数据中未查询到所述待处理地址数据的情况下，依据所述正常地址数据，确定所述待处理地址数据中出现行政区划变更的异常行政区划。

[0139] 在接收到待处理地址数据后，首先在地址数据信息集合的正常地址数据中，查询是否有待处理地址数据的记录。由于正常地址数据存储的为行政区划的最新地址数据，若在正常地址数据查找到待处理地址数据，则说明待处理地址数据中行政区划均为最新行政区划，直接采用待处理地址数据执行后续处理即可，此时可以结束本申请的执行程序。

[0140] 若在正常地址数据中未查找到待处理地址数据，则说明待处理地址数据中行政区划存在数据变更，此时继续使用待处理地址数据，则可能出现异常情况，例如，物品派送不到位的异常情况。所以，此时需要确定所述待处理地址数据中，出现行政区划变更的异常行政区划。

[0141] 在步骤S202将所述待处理地址数据与所述标准地址数据的行政区划进行逐级对比之后，会知晓对比不成功的行政区划。若所述待处理地址数据中对比不成功的行政区划非空，直接将所述地址数据中对比不成功的行政区划，确定为出现行政区划变更的所述异常行政区划。

[0142] 例如：待处理地址数据为“新疆省伊犁市霍城县霍尔果斯口岸”，标准地址数据“新疆省伊犁市霍尔果斯市霍尔果斯口岸”。通过对比可知两者在县级行政区划对比不成功。此时，将待处理地址数据中县级行政区划“霍城县”作为异常行政区划。

[0143] 在某些情况下，待处理地址数据和标准地址数据的行政区划的数量不一致，此时则会导致某些行政区划上出现空数据。为了方便执行后续过程，在所述待处理地址数据中对比不成功的行政区划为空的情况下，将对比不成功行政区划的下一级行政区划作为所述异常行政区划。

[0144] 例如：天门市由县级市升级为地级市，待处理地址数据为“湖北省(市级行政区划为空)天门市(县级行政区划)陆羽大道”，标准地址数据中查询得到的地址数据为“湖北省天门市(市级行政区划)(县级行政区划为空)陆羽大道”的时候，则会出现标准地址数据中市级行政区划“天门市”，与，待处理地址数据的市级行政区划“(市级行政区划为空)”对比不成功的情况。但是，待处理地址数据的市级行政区划为空，则将待处理地址数据的下一级县级行政区划“天门市”，作为异常行政区划。

[0145] 上述为确定异常行政区划的一种实现方式，本实施例还提供确定异常行政区划的另一种实现方式：在获知待处理行政区划的各个级别行政区划之后，将各个级别行政区划由上至下依次在正常地址数据中查询。若在正常地址数据中查询到某个行政区划的数据，则说明该行政区划正常再查询下一个行政区划。若在正常地址数据中未查询到一个行政区划的数据，则确定该行政区划出现异常，将该行政区划的数据确定为异常行政区划。可以理解是，还可以采用其他方式来确定异常地址数据，在此不再赘述。

[0146] 异常地址数据其实为行政区划变更前的原始地址数据，在正常地址数据未存储有原始地址数据，所以导致在正常地址数据中，无法查询到异常地址数据。

[0147] 步骤S104：依据所述原始地址数据与所述最新地址数据之间的映射关系，确定与所述异常行政区划对应的正常行政区划。

[0148] 在地址数据信息集合的异常地址数据中，包括原始地址数据与所述最新地址数据之间的多个类型的映射关系，以及，原始地址数据。因此，在确定异常地址数据(原始地址数据)后，便可通过原始地址数据和最新地址数据的映射关系，查询原始地址数据所对应的最新地址数据。

[0149] 参见图4，本步骤的具体执行过程包括：

[0150] 步骤S401：在确定异常行政区划后，逐个在每个类型的映射关系中，查找所述异常行政区划。

[0151] 其中，每个类型的映射关系与行政区划变更类型一一对应。

[0152] 行政区划发生变更的类型，可能是行政区划的名称变更，行政区划的编号变更，或者两个行政区划合并为一个行政区划等变更方式，本申请将各种变更类型中行政区划变更数据均存储至异常地址数据中；并针对每个变更类型维护一个原始地址数据和最新地址数据之间的映射关系。

[0153] 所述异常地址数据包括所述原始地址数据和所述最新地址数据之间的多个类型的映射关系。多个类型的映射关系具体包括：

[0154] 在行政区划的名称发生变更的情况下，用于表示原始地址数据中变更前行政区划的名称，与，最新地址数据中变更后行政区划的名称之间的名称映射关系。

[0155] 在行政区划的ID发生变更的情况下，用于表示所述原始地址数据中变更前行政区划的ID，与，所述最新地址数据中变更后行政区划的ID之间的ID映射关系。

[0156] 在行政区划的级别发生变更的情况下，用于表示原始地址数据中级别变更前行政区划的ID，与，最新地址数据中级别变更后行政区划的ID之间的映射关系；和/或，用于表示原始地址数据中级别变更前行政区划的名称，与，最新地址数据中级别变更后行政区划的名称之间的映射关系。

[0157] 在行政区划有合并或分裂的情况下，用于表示原始地址数据中合并或分裂前行政区划的ID，与，最新地址数据中合并或分裂后行政区划的ID之间的映射关系；和/或，用于表示原始地址数据中合并或分裂前行政区划的名称，与，最新地址数据中合并或分裂后行政区划的名称之间的映射关系。

[0158] 步骤S402：在某个类型的映射关系中查找到所述异常行政区划的情况下，在该类型的映射关系中，获取与所述异常行政区划对应的所述正常行政区划。

[0159] 与异常行政区划对应的正常行政区划为：异常行政区划经过行政区划变更后的最新地址数据。所以，正常行政区划为正常地址数据。例如：在待处理地址数据为“新疆省伊犁市霍城县霍尔果斯口岸”，标准地址数据“新疆省伊犁市霍尔果斯市霍尔果斯口岸”时，可以确定“霍城县”作为异常行政区划。

[0160] 然后将“霍城县”在每个类型的映射关系进行查询；在名称映射关系中查询“霍城县”是否更改名称，发现名称映射关系中无“霍城县”，说明“霍城县”未改名。在表示分裂或合并的映射关系中查询发现“霍城县”分裂，并在对应的分裂后区划中查到“霍尔果斯市”；由此说明“霍尔果斯市”是与“霍城县”分裂后得到的，待处理地址数据中的“霍城县”可以映射到“霍尔果斯市”。

[0161] 在步骤S104中，确定与异常行政区划对应的正常行政区划之后，在涉及到所述异常行政区划的情况下，将所述异常行政区划映射到所述正常行政区划，可以基于所述正常行政区划，执行涉及到所述异常行政区划的操作。

[0162] 本申请实施例中，在地址数据信息集合的正常地址数据中，存储有所有行政区划的最新数据，在异常地址数据中存储有行政区划变更前的原始地址数据与行政区划变更后的最新地址数据之间的映射关系。所以，当待处理地址数据中包含变更后的正常行政区划时，依据正常地址数据均可进行处理。当待处理地址数据中包含变更前的异常行政区划时，将异常行政区划映射到正常行政区划，后续处理可以基于正常行政区划来处理。从而使控制器准确处理同一地点的具有行政区划变更的不同地址数据。

[0163] 在具体实现时，在本申请图1所示实施例执行之前，需要对预设数据库中所有地址执行初始化过程。具体初始化过程，如图5所示，包括步骤S501～S502：

[0164] 步骤S501：对预设数据库中的所有地址按预设协议格式进行初始化，生成初始化地址数据。

[0165] 其中，所述预设协议格式包括两种方式：

[0166] 第一种方式：用于指示预设协议的起始字段的第一元素；用于指示行政区划变更次数的第二元素；用于指示行政区划变更类型的第三元素；用于指示行政区划变更前的原始地址数据的位置的第四元素；用于指示行政区划变更前的原始地址数据的多个元素。

[0167] 第一种方式适用于行政区划的级别的变更，在后续内容中将进行详细介绍。

[0168] 第二种方式包括：用于指示预设协议的起始字段的第一元素；用于指示行政区划变更次数的第二元素；用于指示行政区划变更类型的第三元素；用于指示行政区划变更前的原始地址数据的位置的第四元素；在所述行政区划的变更为合并或分裂的情况下，用于指示行政区划为全部变更或部分变更的第五元素；用于指示行政区划变更前的原始地址数据的多个元素。

[0169] 第二种方式适用于对行政区划的名称和代码的变更，在后续内容中将进行详细介绍。

[0170] 步骤S502：解析所述初始化地址数据，生成所述地址数据信息集合。

[0171] 对初始化地址数据的内容进行解析，从中提取正常地址数据，原始地址数据，和，原始地址数据与最新地址数据之间的映射关系，从而生成地址数据信息集合。

[0172] 下面详细介绍本申请中所使用的预设协议格式，在具体使用时预设协议称为meta协议，下面对meta协议进行详细说明：

[0173] meta协议阐述

[0174] 在数据库中，一个行政区划一般使用行政区划代码(id)、行政区划全称(name)、行政区划的父级别行政区划的代码(parentId)、行政区划级别(level)和行政区划类型(type)等属性表示。

[0175] 当一个行政区划发生变更时，可能为id、name、parentId和level中任一个属性发生改变。所以，本申请需要在行政区划的备注字段(remark字段)中描述出行政区划的变更情况。这样便可以从行政区划的remark字段中推断出一个行政区划的变更情况。

[0176] 在具体应用实现时，meta协议分为两种形式：

[0177] 第一种形式：meta^version^type^pointer^merge^info^info^info。第一种形式为对于行政区划name和id的改变的meta协议格式。

[0178] 第二种形式：meta^version^type^pointer^info^info^info。第二种形式为对于行政区划parentId和level的改变的meta协议格式。

[0179] 其中，meta标记为用于指示预设协议的起始字段的第一元素；version标记为用于指示行政区划变更次数的第二元素；type标记为用于指示行政区划变更类型的第三元素；pointer标记为用于指示行政区划变更前的原始地址数据的存储位置的第四元素；merge标记为在所述行政区划的变更为合并或分裂的情况下，用于指示行政区划为全部变更或部分变更的第五元素；以及，多个info标记用于指示行政区划变更前的原始地址数据的多个元素。

[0180] (1)对于meta协议中各个标记部分的解释如下：

[0181] ^符号：这是一个meta协议对不同部分进行间隔的间隔符。用于解析meta协议不同部分。

[0182] meta标记：用于表示一个字段是否为meta协议。当解析remark字段以meta开头时，便就进入meta协议的处理流程。

[0183] version标记：为版本号，用于标注一条记录修改的时间戳。比如，一个行政区划的name对于这两次不同时间点的改变，version是不同的。version的值可以从1开始，每次改变时，新增的meta协议的版本号version都要在原来最大版本号的基础上加一。

[0184] type标记：为改变的类型，行政区划的改变可能是id改变、name改变、parentId改变或level改变。为了清楚表示行政区划改变的类型，采用type进行表示。并制定type为0表示id改变，type为1表示name改变，type为2表示parentId改变，type为3表示level改变。

[0185] pointer标记：表示这条meta描述的信息是指向变更后行政区划记录还是变更前行政区划记录。当meta描述的信息指向变更前记录的remark字段上，pointer值为0；如果meta描述的信息指向变更后行政区划的remark字段上，则pointer值为1。当有些变更前行政区划由于某种原因，在数据库中被物理删除后，在数据库中便不会存在这条记录。那么，则将变更前行政区划的记录，存储在变更后行政区划的remark字段上。

[0186] merge标记：是用来表述合并或者分裂关系。比如，崇文区合并到东城区，是全部合并的，用采用merge为0来表示。霍尔果斯市是从霍城县中部分分裂出来，并合并成霍尔果斯市中，则采用merge为1表示这种示部分合并关系。

[0187] info标记：为与type标记相关改变描述信息。比如，id发生变更，则info用于表示变更前id和变更后id。

[0188] |符号：为两个meta协议之间的连接符。当一个行政区划发生有多个属性变更时，则使用|符号来表示同一行政区划的多个属性变更。比如，行政区划代码和行政区划名称发生改变，则使用|符号将表示id改变和name改变两个meta协议进行连接。

[0189] (2)meta协议具体格式

[0190] 第一种：行政区划的name改变，即行政区划名称发生改变时meta的格式：meta^version^1^pointer^merge^oldname^oldabbName

[0191] 协议解释：

[0192] 该协议中^符号分隔中第三个位置上type的位置为1，即type＝1。说明该协议是一个描述行政区划name改变信息的meta协议。该协议中的其他位置上的meta、version、pointer、merge和meta协议阐述中解释一致。其中oldname和oldAbbName表示该行政区划改名之前，它的行政区划名称全称和简称。

[0193] 例如：将“八道江区”改为“浑江区”，并且，将变更前的“八道江区”记录在变更后的“浑江区”的remark字段上。则在此情况下，meta协议的内容为：meta^1^1^1^0^八道江区^八道江。

[0194] 参见图6，meta标记表示此为表示行政区划变更的字段。version标记为1，表示行政区划的变更为第一个版本更改。type标记为1，表示这是针对行政区划name变更。pointer标记为1，表示这个meta协议内容是保存在行政区划变更后的新记录的remark上。merge标记为0表示“八道江区”的全部变成“浑江区”，不是只有“八道江区”的部分变成到“浑江区”。后面的“八道江区”和“八道江”是指该行政区划在变更之前全称(八道江区)和简称(八道江)。

[0195] 如果“八道江区”是改名两次才变成“浑江区”。其中，“八道江区”先改变为“九道江区”，然后从“九道江区”改名成“浑江区”，则meta协议为：

[0196] meta^1^1^1^0^八道江区^八道江|meta^2^1^1^0^九道江区^九道江

[0197] 其中，|符号是连接符，连接两个meta协议内容。连接符后面的meta协议中的版本号version为2，说明这是第二次名称变更，行政区划第一次改名是从“八道江区”到“九道江区”，第二次改名是从“九道江区”改名到“浑江区”。每一次的数据变更，表示版本号变更的version均会从当前的版本号增加1。

[0198] 第二种：行政区划的id改变，即行政区划代码发生改变时meta的格式：

[0199] meta^version^0^pointer^merge^id

[0200] 协议解释：

[0201] 该协议中^分隔符分割的第三个元素type位置为1，即type＝0。即，表示这是行政区划代码的变更。meta、version、pointer、merge与上述meta协议阐述中解释一致。如果pointer为1，即meta协议保存变更后在行政区划上，则最后一个id表示行政区划变更之前的id。如果pointer为0，即meta协议保存在行政区划变更前行政区划上，则最后一个id表示行政区划变更后的id。

[0202] 例子详解：

[0203] “阿城市”改名为“阿城区”，且“阿城市”的id为“230185”，“阿城区的id为“230181”，此时行政区划数据库中存在两条记录，新变更前记录都保存于数据库中。

[0204] 如果meta协议保存在变更前的“阿城市”的remark字段上，则meta协议的内容为：

[0205] meta^1^0^0^0^230181|meta^1^1^0^0^阿城区^阿城

[0206] 参见图7，version标记为1，表示这为id变更的第一个版本。type标记为0表示为行政区划id改变的meta协议。pointer标记为0，表示该meta协议是保存在行政区划变更前记录的remark字段上。merge标记为0表示，变更前行政区划(阿城市)是完全变成变更后行政区划(阿城区)。id为“230181”，表示该行政区划变更后的id为“230181”。

[0207] 后面用连接符连接name改变的meta协议，说明在这个例子中，同时发生id改变和name改变。分别用type＝0的meta协议和type＝1的meta协议表示这种方式的行政区划变更。

[0208] 如果meta协议保存在变更后“阿城区”的remark字段上，则meta协议的内容为：meta^1^0^1^0^230185|meta^1^1^1^0^阿城市^阿城

[0209] 参见图8，与图7不同的是pointer为1，说明meta协议的保存在变更后行政区划的新纪录上。id为变更前的记录230185。“阿城市”和“阿城”，表示行政区划变更前的全称和简称是“阿城市”和“阿城”。

[0210] 第三种：parentId改变，即当前行政区划的父级行政区划发生改变时的meta协议格式：

[0211] meta^version^2^pointer^chgId^oldlevel^parentId^pLevel^chgName^chgAbbName

[0212] 协议解释：

[0213] 其中，第三个元素type的位置为2，即type＝2；说明这是描述parentId改变的meta协议。其中meta、version、pointer和前述解释一致。chgId表示发生parentId改变的行政区划的代码id。oldLevel表示当chgId这条记录发生parentId改变的时候，当前的行政区划级别(省、市或区等)。parentId表示当chgId发生父级别改变时，父级行政区划在改变之前的代码id。pLevel是父级行政区划在改变之前的级别。chgName和chgAbbName表示chgId发生行政区划改变之前的全称和简称。

[0214] 例子详解：

[0215] “新疆省”新增“霍尔果斯市”。“霍尔果斯口岸”由原来的“霍城县”下面的镇变成“霍尔果斯市”下面的镇。“霍尔果斯口岸”原来的id为“654023404”，行政区划改变后的id为“654030404”。新增的“霍尔果斯市”的id为“654030”，“霍城县”的id为“654023”。

[0216] 对于“霍尔果斯口岸”而言，它新增一条记录，变更前和变更后的“霍尔果斯口岸”的两条记录同时存在。对于变更前的“霍尔果斯口岸”，它的父级别从“霍城县”变成“霍尔果斯市”，同时它的id改变。所以需要有描述parentId改变和描述id改变的meta协议的组合。

[0217] 如果在区划变更前的变更前纪录代码“654023404”的remark上保存meta协议，则meta协议内容为：

[0218] meta^1^0^0^0^654030404|meta^1^2^0^654023404^5^654023^4^霍尔果斯口岸^霍尔果斯

[0219] 参见图9，version为1，表示这是第一次代码更改。type为2，表示这个描述parentId改变的行政区划变更的meta协议。pointer为0，表示meta协议存放在行政区划变更前的变更前的记录上。chgId为“654023404”，表示发生parentId变更的行政区划的id。oldLevel为5，表示发生parentId变更的行政区划的级别是5，即原“霍尔果斯口岸”的属于镇级别行政区划。parentId为“654023”，表示原行政区划代码为chgId的行政区划的父级别代码是“654023”，pLevel为4，表示原chgId的父级别是属于县级别行政区划。chgName和chgAbbName表示行政区划变更之前chgId的全称和简称。

[0220] 对于这个案例，增加一条id为“654030霍尔果斯市”的记录、增加一条id为“654030404霍尔果斯口岸”的记录，并对新的“霍尔果斯口岸”的记录的remark写入上述meta协议。

[0221] 但是，这次行政区划的变更还未结束。因此“霍城县”也发生变化，它原来的“霍尔果斯口岸”被合并到“霍尔果斯市”中，即“霍城县”发生部分合并的行政区划的变更。所以在“霍城县”的记录的remark字段上，需要写入描述“霍尔果斯口岸”变更的meta协议，内容如下：

[0222] meta^1^0^0^1^654030|meta^1^1^0^1^霍尔果斯市^霍尔果斯

[0223] 这两个meta协议分别表示行政区划代码id发生变更和name发生变更的meta协议。其含义表示“霍城县”的id和name都有部分映射到“霍尔果斯市”的id和name。这样当变更前的“霍尔果斯口岸”的地址作为收货地址的时，比如：将新疆-伊犁-霍城县-霍尔果斯口岸，或者，将代码650000(新疆)-654000(伊犁)-654023(霍城县)-654023404(霍尔果斯口岸)作为系统入口参数时，可以根据meta协议，把id为“654023”的“霍城县”，映射到新id为“654030”的“霍尔果斯市”，name的映射也是相同的原理。

[0224] 特别需要注意的是，在这个meta协议内容中，merge的值为1(部分合并)；即“霍城县”只是部分合并到“霍尔果斯市”。

[0225] 第四种：level改变，即行政区划的级别发生改变时meta的格式。

[0226] meta^version^3^pointer^chgId^oldlevel^oldplevel^oldName^oldAbbName[0227] 协议解释：

[0228] ^符号分隔的第三个位置的3表示type。type为3表示这是描述级别level发生行政区划改变的meta协议。其中meta、version、pointer的含义和上面的含义一致。chgId表示发生了级别level改变的行政区划(改变前)的区划代码id。oldLevel表示行政区划变更前chgId的级别。oldpLevel表示行政区划变更之前chgId的父级区划的级别。oldName和oldAbbName表示行政区划变更前chgId对应全称和简称。

[0229] 例子详解：

[0230] 比如，“天门市”从县级市变成了地级市。“天门市”的行政区划代码为“429006”，级别level为4，表示天门市是一个县级市，且，“天门市”是父级别“湖北省”的县级市。当“天门市”的级别level发生变更，从县级市变成地级市，即level从4变成3。其行政区划代码id和name都没有改变，只有级别发生变化。

[0231] 因为id没有变化，则使用原来的行政区划记录，(在数据库中行政区划代码有唯一性约束，是主键；所以在id没有变化的时候，不能增加新记录)。因此在“天门市”记录的remark字段上，写入表示“天门市”级别level改变的meta协议内容，内容如下：

[0232] meta^1^3^1^429006^4^2^天门市^天门

[0233] 参见图10，version为1表示这是第一次进行级别提升。type为3，表示这是描述level改变的meta协议。pointer为1，表示meta协议内容保存在行政区划变更后的记录的remark字段上。因为id没有改变，所有本次“天门市”行政区划变动的时候，并没有在数据库中新增记录。

[0234] 所有“天门市”当前记录本身就是最新的记录，所以pointer为1，表示后面chgId、oldLevel、oldpLevel和chgName描述的信息，都是行政区划变更之前的信息。chgId表示发生level变更的记录代码id(行政区划发生改变前的，由于id没有改变，故和区划改变后的id一致)。

[0235] oldLevel表示chgId在区划变更前的级别，这里为4，说明天门市在行政区划变更之前属于县级行政区划，是县级市。oldpLevel是行政区划变更前chgId的父级别区划的级别，这里为2，说明行政区划变更前的天门市的父级区划是省级行政区划，属于省直辖的县级市。chgName和chgAbbName表示行政区划变更前，chgId对应的全称和简称分别是“天门市”和“天门”。

[0236] (3)meta协议中各个标记的作用

[0237] a)meta协议中设计version字段的作用

[0238] 因为每年行政区划都会更新，可能在同一条记录上多次更新。为了表示行政区划数据更新的先后顺序，需要使用version。比如“八道江区”在2010年改名为“九道江区”，在2014年又改名为“浑江区”。所以通过version来确定行政区划变更的先后顺序。

[0239] b)meta协议设计pointer字段的作用

[0240] 在构建meta协议之后，需要解析meta协议构建各种映射关系。比如解析meta协议构建对应name改变的metaNameMap、对应id改变的metaIdMap、对应level改变的metaLevelMap等。但是meta协议内容保存在行政区划变更后的最新记录的remark字段上，还是保存行政区划变更前的在变更前记录的remark上，是有区别的。这关系到后续处理过程如何解析meta协议的问题。

[0241] 比如：对于id改变，从“100000”变成“200000”。如果meta协议内容保存在变更前的id对应的记录上，则：

[0242] meta^1^0^0^0^200000

[0243] 这表示当前记录的id可以映射到“200000”这条记录上。这样在构造metaIdmap的时候，便可以使用“100000”作为主键key，“200000”作为值value来构造map。当用户变更前区划地址过来，可以通过id的这种映射，得到最新的对应区划的id。

[0244] 如果meta协议内容保存在新的id对应的记录上，则：

[0245] meta^1^0^1^0^100000

[0246] 这表示当前记录可以被“100000”记录映射，这样就能保证“100000”作为key。因为在进行行政区划的映射的时候，总是把变更前的数据映射到新的数据上，这样能保证key的正确性。

[0247] c)meta协议中设计merge字段的作用

[0248] 用merge来表示一个行政区划是部分合并还是全部合并到一个新的区划。全部合并比较简单。但对于部分合并，在映射的时候就需要考虑更多的上下文信息。比如，崇文区合并到东城区是全部合并，只需要把崇文区映射到东城区即可。但如果崇文区只有其下部分街道合并到东城区，对于崇文区，不能简单的映射到东城区。要考虑到上下文的情况，比如只有给出崇文区和其下的街道，才知道这个行政区划是否被合并。

[0249] 对于通过区划name获取对应区划的记录的接口，入参是崇文区，对于全部合并，可以返回映射到东城区。对于部分合并，不能返回映射到东城区，因为此时崇文区和东城区同时存在的。

[0250] d)meta协议中设计type字段的作用

[0251] 为了扩展性和灵活性的考虑。如果未来需要使用meta协议描述其他类型的改变的时候，可以通过扩展type来适应这种需求。比如，如果需要考虑邮政编码的变化的时候，给予邮政编码改变类型为type＝5。通过这种方式，meta协议对于行政区划的变更的表达能力，将具有非常好的灵活性和扩展性。

[0252] (4)下面介绍解析meta协议的过程

[0253] 在对所有的行政区划变更都使用meta协议描述清楚之后，保存在行政区划数据库对应记录的remark字段上。在使用行政区划数据之前，需要读取数据库中所有数据(中国行政区划数据，由省级行政区划到镇级别行政区划共4万多条记录，数据量大小在10M左右)。

[0254] 然后再解析meta协议，得到行政区划变更的关系总和，并把这种变更关系保存下来，以便方便后面查询这些关系信息。目前本申请采用map来保存这些信息，其中，每个map具有key和value两个参数，从而以保证查询的时间复杂度在线性(O(1)-O(N))的范围之内。解析数据库中所有meta协议的信息，解析出来的结果存放在各类型的map映射中。下面对各个类型的map的形成过程进行描述：

[0255] a)metaIdMap、metaNameMap和metaUsedMap：保存所有行政区划变更中id或者name发生变更的信息。

[0256] 其中，metaIdMap通过type＝0的meta协议解析出来，保存的是行政区划id变更的信息。其中，key为变更之前的id，value为变更之后的id列表，有可能一个行政区划分裂出多个行政区划，所以value可能是一个id的列表。

[0257] metaNameMap和metaUsedMap通过type＝1的meta协议解析出来。其中key是发生行政区划name发生变更的信息。其中，key是行政区划变更之前的name，value是行政区划变更之后的id列表，可能一个name有重名，对应多个id。

[0258] metaNameMap和metaUsedMap的区别是：后者保存的是曾用名的信息，即在行政区划改变中，当且仅当只有name发生变更的情况。而metaNameMap保存的是除了name变更还有其他变更的情况。

[0259] b)metaLevelIdMap，metaLevelNameMap，metaIdPromMap和metaNamePromMap。

[0260] metaLevelIdMap和metaLevelNameMap保存所有行政区划变更中所有级别level发生改变的行政区划的变更前的id和name。其中key分别为id和name，value都是布尔值。当一个行政区划的级别level发生改变时，对应行政区划变更前的id和name分别作为key，给metaLevelIdMap和metaLevelNameMap赋值为true。

[0261] metaIdPromMap和metaNamePromMap保存的为，在行政区划变更前一个行政区划是否可以提级的信息(是否可以提级，在发生在省直辖的区县和县级市中。比如，天门市是省直辖的县级市，是可以提级的)。当type＝3或者type＝2的meta协议中解析出来的oldLevel-oldpLevel＝2，则meta协议描述的这个行政区划是可以提级的，即对metaIdPromMap和metaNameMap赋值为true。

[0262] MetaIdPromMap和metaNameMap还通过type＝2的meta协议(描述parentId改变的)中的解析出来，即当type＝2的meta协议中oldlevel-plevel＝2时，用对应行政区划的id和name作为key对metaIdPromMap和metaNamePromMap进行赋值为true。

[0263] c)metaIdMergeMap和metaNameMergeMap。

[0264] 保存行政区划变更中部分合并还是全部合并的全部信息。通过type＝0或者type＝1解析出merge的信息，当且仅当merge＝1，即部分合并时才会对这两个map进行赋值。以发生部分合并的行政区划变更前id和name作为key，value是布尔值。

[0265] (5)使用meta协议处理行政区划变更的处理流程

[0266] 当完成(4)中的解析meta协议的步骤后，在metaIdMap和metaNameMap、metaUsedMap、metaLevelIdMap和metaLevelNameMap，metaIdPromMap和metaNamePromMap、metaIdMergeMap和metaNameMergeMap这9个Map中保存所有行政区划变更的细节信息。

[0267] 通过这些信息，可以还原出行政区划是如何发生变更的，以及可以通过带有变更前行政区划的地址映射到最新行政区划的地址上去。

[0268] 下面通过几个具体的例子来说明，如何使用上述Map来处理行政区划发生变更后的行政区划的。

[0269] a)第一个例子：曾用名的情况：“八道江区”名称改为“浑江区”。当用户地址中包含“八道江区”的时候，其处理流程为：

[0270] 步骤一：通过八道江区作为查询条件查询数据库。

[0271] 其中，数据库中存储的最新的地址数据。此外，可以将数据库中所有值都加载到内存，直接查询内存，这样可以提升效率。

[0272] 步骤二：查询结果为返回空，在metaUsedMap中查询八道江区。

[0273] 因为“八道江区”是改名为“浑江区”，所以在数据库中不存在name为“八道江区”的记录。查询数据库返回空。查询metaNameMap，是不是八道江区曾经更改name。

[0274] 因为“八道江区”改名为“浑江区”，是只改name不改其他的情况，所以是曾用名的更改name。所以“八道江区”的更改信息不在metaNameMap中记录，系统返回空。

[0275] 步骤三：获得id列表。

[0276] 查询metaUsedMap，以判断“八道江区”是否作为其他区划的曾用名，系统返回一个id列表。说明“八道江区”确实是其他区划的曾用名。

[0277] 步骤四：轮询这个id列表。

[0278] 在数据库中查询id列表中所有数据记录，从而获得浑江区的行政区划记录。由此得知，“八道江区”和“浑江区”是可以对应映射的。后续所有的处理，可以基于“浑江区”进行。

[0279] b)第二例子

[0280] 在“伊犁市”下新增“霍尔果斯市”。原本属于“霍城县”的“霍尔果斯口岸”合并到“霍尔果斯市”，并且“霍尔果斯口岸”的id发生变化。

[0281] 输入系统的入口参数为：650000(新疆)-654000(伊犁)-654023(霍城县)-654023404(霍尔果斯口岸)。在这个地址代码链中，“霍尔果斯口岸”的id还是变更前的id。
若需要判断这个地址链是否在顺丰快递的派送范围。

[0282] 顺丰快递是派送到镇行政区划，由于该地址链的“霍尔果斯口岸”是份行政区划下级的地址，所以可能被判定为不在顺丰快递的派送范围。但是，实际上，“霍尔果斯口岸”已升级为“霍尔果斯市”的县级行政区划，所以“霍尔果斯口岸”在实际上是能够被派送的。

[0283] 在采用本申请提供的方式之后，便不会出现判断有误的情况。具体实现过程可以为：

[0284] 步骤一：依据用户地址中原始的霍尔果斯口岸id，在metaIdMap查询该id是否发生过变更，获得变更后的最新行政区划的id。从而得到霍尔果斯口岸的最新id。

[0285] 步骤二：通过新的霍尔果斯口岸的最新id，查询顺丰能力数据库，得到该地址链可达结果。

[0286] 步骤三：根据可达结果，确定用户可以继续下单。

[0287] c)第三个例子：“天门市”发生提级的行政区划变更。

[0288] 现在有两个用户的收货地址：湖北省天门市(空)竟陵街道，湖北省(空)天门市竟陵街道详细地址。两个地址不同之处在于：第一个，天门市是地级市，第二个地址天门市是县级市。系统需要确定两个地址是否为同一地址。

[0289] 具体执行过程为：

[0290] 步骤一：先比较省行政区划，对比成功。

[0291] 步骤二：比较市级行政区划，发现第二个地址的市行政区划为空。

[0292] 步骤三：对比不成功，然后去metaNameMap中查询，该行政区划的name是否改变，因为“天门市”的name没有改变，所以系统反馈空。

[0293] 步骤四：到metaNamePromMap中查询，是否该行政区划可以提级；系统反馈结果为是。

[0294] 步骤五：在metaLevelNameMap中查询，发现“天门市”的level改变，说明“天门市”提级。

[0295] 步骤六：比较第一个地址的市行政区划和第二个地址的区行政区划，或者比较第一个地址的区行政区划和第二个地址的市行政区划。

[0296] 利用错开一个级别比较的方式，发现都是天门市，所以可以认为对比成功。再比较竟陵街道，发现对比成功则说明两个地址为同一地点。

[0297] 与如图1所示的地址映射方法相对应，本申请提供一种地址映射装置，如图11所示，包括：

[0298] 第一获取单元111，用于获取待处理地址数据；其中，所述待处理地址数据包括多级行政区划。

[0299] 第一查询单元112，用于在地址数据信息集合包含的正常地址数据中，查询所述待处理地址数据；其中，所述正常地址数据包括：未进行行政区划变更的地址数据和进行行政区划变更后的最新地址数据；所述地址数据信息集合还包括异常地址数据，其中，所述异常地址数据包括：与所述最新地址数据对应的变更前的原始地址数据，以及，所述原始地址数据与所述最新地址数据之间的映射关系。

[0300] 第一确定单元113，用于在所述正常地址数据中未查询到所述待处理地址数据的情况下，依据所述正常地址数据，确定所述待处理地址数据中出现行政区划变更的异常行政区划。

[0301] 映射单元114，用于依据所述原始地址数据与所述最新地址数据之间的映射关系，确定与所述异常行政区划对应的正常行政区划。

[0302] 其中，如图12所示，所述第一查询单元112，包括：

[0303] 第二确定单元121，用于在地址数据信息集合的正常地址数据中，确定与所述待处理地址数据的对应的标准地址数据。

[0304] 第二查询单元122，用于将所述待处理地址数据的行政区划与所述标准地址数据的行政区划进行逐级对比。

[0305] 其中，所述第二确定单元121，包括：

[0306] 第三查询单元1211，用于由最小级别的行政区划开始，依次查询每个行政区划的父级行政区划，直到最高级别的行政区划为止。

[0307] 生成单元1212，用于将每个行政区划的父级行政区划，以及，所述最小级别的行政区划，按行政区划级别由高到低的顺序排列，生成所述待处理地址数据的标准地址数据。

[0308] 如图13所示，所述第一确定单元113，包括：

[0309] 第三确定单元131，用于若所述待处理地址数据的行政区划与所述标准地址数据的行政区划对比不成功的情况下，若所述待处理地址数据中对比不成功的行政区划非空，则将所述地址数据中对比不成功的行政区划，确定为出现行政区划变更的所述异常行政区划。

[0310] 第四确定单元132，用于在所述待处理地址数据中对比不成功的行政区划为空的情况下，将对比不成功行政区划的下一级行政区划作为所述异常行政区划。

[0311] 如图14所示，本申请提供的地址映射装置，还包括：

[0312] 初始化单元141，用于对预设数据库中的所有地址按预设协议格式进行初始化，生成初始化地址数据。

[0313] 解析单元142，用于解析所述初始化地址数据，生成所述地址数据信息集合。

[0314] 其中，所述预设协议格式包括：

[0315] 用于指示预设协议的起始字段的第一元素；用于指示行政区划变更次数的第二元素；用于指示行政区划变更类型的第三元素；用于指示行政区划变更前的原始地址数据的位置的第四元素；用于指示行政区划变更前的原始地址数据的多个元素。在所述行政区划的变更类型为合并或分裂的情况下，用于指示行政区划为全部变更或部分变更的第五元素。

[0316] 所述异常地址数据包括所述原始地址数据和所述最新地址数据之间的多个类型的映射关系；如图15所示，所述映射单元114，包括：

[0317] 查找单元151，用于逐个在每个类型的映射关系中，查找所述异常行政区划。

[0318] 第二获取单元152，用于在某个类型的映射关系中查找到所述异常行政区划的情况下，在该类型的映射关系中，获取与所述异常行政区划对应的所述正常行政区划。

[0319] 其中，所述异常地址数据的多个类型的映射关系，包括：

[0320] 在行政区划的名称发生变更的情况下，用于表示原始地址数据中变更前行政区划的名称，与，最新地址数据中变更后行政区划的名称之间的名称映射关系。

[0321] 在行政区划的ID发生变更的情况下，用于表示所述原始地址数据中变更前行政区划的ID，与，所述最新地址数据中变更后行政区划的ID之间的ID映射关系。

[0322] 在行政区划的级别发生变更的情况下，用于表示原始地址数据中级别变更前行政区划的ID，与，最新地址数据中级别变更后行政区划的ID之间的映射关系；和/或，用于表示原始地址数据中级别变更前行政区划的名称，与，最新地址数据中级别变更后行政区划的名称之间的映射关系。

[0323] 在行政区划有合并或分裂的情况下，用于表示原始地址数据中合并或分裂前行政区划的ID，与，最新地址数据中合并或分裂后行政区划的ID之间的映射关系；和/或，用于表示原始地址数据中合并或分裂前行政区划的名称，与，最新地址数据中合并或分裂后行政区划的名称之间的映射关系。

[0324] 所述异常地址数据的多个类型的映射关系，还包括：

[0325] 在行政区划的级别市级行政区划或县级行政区划的情况下，用于存储原始地址数据中行政区划的ID，与，表示该行政区划是否可进行级别提升的结果之间的映射关系；和/或，

[0326] 在行政区划的级别市级行政区划或县级行政区划的情况下，用于存储原始地址数据中行政区划的名称，与，表示该行政区划是否可进行级别提升的结果之间的映射关系。

[0327] 本申请实施例中，在地址数据信息集合的正常地址数据中，存储有所有行政区划的最新数据，在异常地址数据中存储有行政区划变更前的原始地址数据与行政区划变更后的最新地址数据之间的映射关系。所以，当待处理地址数据中包含变更后的正常行政区划时，依据正常地址数据均可进行处理。当待处理地址数据中包含变更前的异常行政区划时，将异常行政区划映射到正常行政区划，后续处理可以基于正常行政区划来处理。从而使控制器准确处理同一地点的具有行政区划变更的不同地址数据。

[0328] 本实施例方法所述的功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算设备可读取存储介质中。基于这样的理解，本申请实施例对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该软件产品存储在一个存储介质中，包括若干指令用以使得一台计算设备(可以是个人计算机，控制器，移动计算设备或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

[0329] 本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其它实施例的不同之处，各个实施例之间相同或相似部分互相参见即可。

[0330] 对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本申请。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本申请的精神或范围的情况下，在其它实施例中实现。因此，本申请将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。