地址输入控制方法及装置与流程

本申请涉及地址信息输入技术领域，特别是涉及地址输入控制方法及装置。

背景技术：

在通过电子商务销售平台购买实体货品的过程中，需要买家用户在其订单中填写收货地址信息，以便为买家用户提供送货上门服务。为了减少用户输入收货地址时的信息输入量，也为了尽可能保证地址信息的准确性，一般会预先建立地址库，用户在填写收货地址时，对于上述三级地址段，可以根据系统提供的候选项来进行选择。例如，如图1所示，在用户选择了某个省之后，可以显示出该省内各个市的名称供用户选择，用户选择了某个市之后，又可以显示出该市内各个区的名称供用户选择。对于其他更为详细的信息，包括街道、小区、门牌号、楼栋号、楼层号、房间号等信息，则由用户进行手动输入。

在现有技术中，地址库一般是根据国家行政区划的公共地址库建立的，包括了省、市、区三级信息。并且，以上三个级别均为必选项，也即必须在已经全部选择了前三级行政区划的确切信息之后，用户才可以进入到后续的流程继续进行操作，包括更详细地址信息的输入，提交或者保存其填写的收货地址，等等。但是，在实际应用中，可能会出现以下情况：出于各种原因，用户可能并不知晓或者不确定其收货地址具体应该属于哪个区。因此，对于这部分用户而言，其在线购物的过程可能会被中断，或者，只能通过其他途径(包括使用搜索引擎进行搜索、询问他人等)来确定出其所属的区，然后再回到收货地址编辑界面继续进行选择操作。这无疑会造成对用户时间成本的浪费，效率很低，甚至很可能会造成部分用户的流失。

技术实现要素：

本申请提供了地址输入控制方法及装置，可以提高地址的输入效率，有利 于降低由于强制性的限制导致的用户流失情况的发生概率。

本申请提供了如下方案：

一种地址输入控制方法，在预置的地址库中，如果某区县具有别名，则所述地址库中还包括虚拟区县名称；所述虚拟区县名称根据对应行政区县的别名确定；

所述方法包括：

接收地址输入请求；

根据所述地址库提供各级地址段的可选列表，其中，在区县级别的列表中提供行政区县名称以及虚拟区县名称；

当目标虚拟区县名称被选中时，触发进入到下一步继续进行地址的输入，并根据该虚拟区县名称对应的行政区县名称确定当前输入地址的区县名称。

一种地址输入控制装置，在预置的地址库中，如果某区县具有别名，则所述地址库中还包括虚拟区县名称；所述虚拟区县名称根据对应行政区县的别名确定；

所述装置包括：

请求接收单元，用于接收地址输入请求；

可选列表提供单元，用于根据所述地址库提供各级地址段的可选列表，其中，在区县级别的列表中提供行政区县名称以及虚拟区县名称；

触发单元，用于当目标虚拟区县名称被选中时，触发进入到下一步继续进行地址的输入，并根据该虚拟区县名称对应的行政区县名称确定当前输入地址的区县名称。

根据本申请提供的具体实施例，本申请公开了以下技术效果：

通过本申请实施例，对于存在别名(包括某些区县被划定为高新区、开发区，或者区县合并等情况下发生的区县名称变更等)的区县，可以在地址库中 增加虚拟区县信息，该虚拟区县的名称根据行政区县的别名而定。这样，在进行地址输入控制的过程中，在展示区县列表时，可以将实际的行政区县信息以及虚拟区县信息全部提供给用户，这样，当用户无法确定其地址所属的行政区县名称时，可以通过虚拟区县进行选择，从而保证用户可以继续进行后续级别地址段的选择以及详细地址的输入等操作，避免用户的地址输入被中断，并且可以提高地址的输入效率，有利于降低由于强制性的限制导致的用户流失情况的发生概率。

在优选的实现方式下，地址库可以为四级地址库，除了省、市、区县，还可以包括街道级别的地址段，虚拟区县也可以关联有具体的街道列表，该列表可以是由对应行政区县的下辖街道来确定的。

当然，实施本申请的任一产品并不一定需要同时达到以上所述的所有优点。

附图说明

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

图1是现有技术中的用户界面示意图；

图2是本申请实施例提供的方法的流程图；

图3、4、5-1、5-2是本申请实施例中的用户界面示意图；

图6是本申请实施例提供的装置的示意图。

具体实施方式

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

本申请发明人在实现本申请的过程中发现：在实际应用中，之所以会出现有些用户不知道自己所在的区的情况，一方面的原因是：销售平台系统建立的“基础地址库”是一个行政区域的基础性数据，但是出于经济活动等目的，政府可能会在其辖区内建设一些工业领域的工业区，例如，高新区、开发区等等。例如，陕西省西安市政府将雁塔区和长安区设立为高新区，等等。在日常生活中，用户在描述自己的地址时可能更多使用的是这种“高新区”、“开发区”，尤其是一些非常住的用户或者新来的用户，这种情况更是常见。但是，这种被用户常用的区域名称，如“高新区”等并是不属于行政区域，因此，在用户从区县列表中选择器所属的区县时，会发现没有“高新区”、“开发区”等选项，因此，无法判断自己所属区县，只能终止地址的书写或选择。

另外，还有一些市政府可能会将一些区县合并，并将原有区县名称撤销，行政地址库中仅保存合并后的区县信息。例如，江苏省苏州市撤销沧浪区、平江区、金阊区，并设立苏州市姑苏区，等等，在一段时间内，可能并不是所有用户都知晓该合并情况。例如，原来居住在沧浪区的用户可能仍然认为自己所在的曲线是沧浪区，但是在填写收货地址时，却发现可选的区县列表中，却找不到“沧浪区”，此时，也可能会终止地址的书写或选择。

总之，对于同一地理位置所在的区域而言，在行政区划中对该区域的命名，与用户认知的该区域的名称可能会存在不一致的情况，因此导致在填写收货地址的过程中，作为必选项的区县名称由于无法得到选择，而只能终止后续的收获地址书写或者选择过程，影响正常的交易达成，甚至还可能会导致用户的流失。

为了解决上述问题，在本申请实施例中，针对可能存在用户认知错误的区域，在地址库中除了记录其行政意义上的行政区县信息之外，还可以记录对应的虚拟区县信息，具体可以包括在工业领域被划定为高新区、开发区等区县，此时，高新区、开发区等可以称为这种区县在工业领域的别名。例如，西安市的雁塔区和长安区被划定为高新区，则该雁塔区和长安区的别名为“高新区”，因此，对应的虚拟区县可以为“高新区(雁塔区，长安区)”。对于由于合并得到的区县，合并前的原有区县名称就可以称为该合并后区县的别名。例如，沧 浪区、平江区、金阊区合并而成的姑苏区，其别名可以包括沧浪区、平江区、金阊区三个，相应的，对应的虚拟区县可以为三个，分别为“沧浪区(姑苏区)”、“平江区(姑苏区)”、“金阊区(姑苏区)”。可见，虚拟区县与行政区县之间可能是一对多或者多对一的关系。虚拟区县信息的存在，使得在用户不确定其所属行政区县名称的情况下，区县名称这一必选项能够被有效的占位，后续的地址输入操作得以继续进行。

另外，在优选的实现方式下，本申请实施例中的地址库可以为四级地址库，其中包括省、市、区县、街道四个地址级别，也就是说，对于前四个级别的地址段信息，都可以由用户进行选择。关于第四级也即街道级别的地址信息，可以通过多种方式获得，其中，对于每个实际的行政区县下辖的各个街道名称信息，可以通过对销售平台的大数据进行分析获得，或者，还可以通过线下收集等方式获得。而对于虚拟区县关联的街道信息，可以通过其对应的实际行政区县的下辖街道信息而确定。

例如，对于前述西安市的高新区，由于包括雁塔区、长安区两个行政区县，因此，“高新区(雁塔区，长安区)”这一虚拟区县，其关联的街道就可以由雁塔区的下辖街道以及长安区的下辖街道两部分组成。而对于“沧浪区(姑苏区)”这一虚拟区县，其关联的街道可以是姑苏区原来属于沧浪区的各条街道，等等。

总之，本申请实施例中使用的地址库可以包括四级地址段，分别为省、市、区县、街道四个地址级别，其中，在区县级别，如果某区县具有别名，则地址库中还包括虚拟区县名称，以及该虚拟区县关联的街道信息；其中，虚拟区县名称根据对应行政区县的别名确定，虚拟区县关联的街道信息根据对应行政区县的下辖街道信息确定。在建立了上述地址库的情况下，就可以基于该地址库帮助用户进行地址的输入。其中，当用户不确定其所属的具体行政区县的名称时，可以通过虚拟区县信息的选择，使得用户可以进入到后续的步骤进行选择或者填写，也即整个地址输入流程得以继续进行，而不至于中断。

下面对具体的输入控制过程进行详细介绍。

参见图2，该实施例首先提供了一种地址输入控制方法，该方法可以包括 以下步骤：

S201：接收地址输入请求；

本申请实施例中，具体的应用场景可以有多种，例如，在其中一种场景下，可以是在电子商务销售平台的买家用户在下单某件商品对象时，需要在交易订单中填写收货地址。或者，在另一种场景下，还可以是在快递服务的用户在线预约上门取件服务时，需要输入取件的地址，等等。

S202：根据所述地址库提供各级地址段的可选列表，其中，在区县级别的列表中提供行政区县名称以及虚拟区县名称；

在接收到地址输入请求后，由于预先设置了地址库，因此，可以向用户提供各级地址段的可选列表。例如，如图3所示，301处示出了四个地址级别(对应四级地址库)，分别为省、市、区县、街道。用户可以首先选择地址的省份，然后可以在市级的地址段名称列表中提供该省份下辖的各个市，在选择了某个市之后，又可以显示出该市下辖的各个区县。其中，在区县级别的列表中，如果存在虚拟区县，则将这种虚拟区县信息也展示出来。例如，图3中，用户已经选择了在省列表中选择了“陕西”，在市列表中选择了“西安”，此时，根据地址库中的记录，发现“西安”对应的区县信息中包括虚拟区县信息，因此，在就可以在区县列表中，将这种虚拟区县信息也进行展示。如图3所示，302区域所示的各个区县名称为行政区县名称，也即按照实际的行政区划信息确定出的西安市下辖的各个区县；303区域所示的区县名称即为虚拟区县名称，也即“高新区(雁塔区，长安区)”。为了能够对用户起到提醒的作用，在用户界面上展示上述区县信息时，可以将行政区县信息与虚拟区县信息分割开来，例如，图3所示中是利用一条横线隔开，在实际应用中，还可以通过其他方式实现。并且，在虚拟区县名称展示区，还可以提供帮助信息，例如304所示的问号按钮，当用户该按钮被操作时，可以提供提示信息，例如图3中所示的“如您无法站到原地址所属的区域，可能该区已被合并或者属于虚拟行政区(地方经济开发区非国家三级行政区)，请根据提示选择正确的区县”。

S203：当目标虚拟区县名称被选中时，触发进入到下一步继续进行地址的 输入，并根据该虚拟区县名称对应的行政区县名称确定当前输入地址的区县名称。

在进行区县信息选择时，如果用户能够确定其地址所属的行政区县名称，则可以在图3中的302区域进行行政区县名称的选择，相应的，在街道级别的地址段列表中，就可以展示出该行政区县下辖的各个街道的名称。而如果用户不能确定其地址所属的行政区县名称，则可以根据其认知的所属区县的别名等信息，在303区域选择虚拟区县。当虚拟区县名称被选择之后，就可以进行后续的地址输入过程。例如，可以展示出该虚拟区县关联的各个街道名称的列表，用户可以基于该虚拟区县关联的街道名称进行后续的地址选择，之后还可以进行更详细地址信息的填写等等。总之，使得地址输入过程得以继续进行，而不会因为用户不确定其地址所属的行政区域名称而中断。

需要说明的是，前述步骤S201至S203各个步骤的执行主体可以是指客户端，也可以是服务器。其中，如果是客户端，则可以预先将地址库信息下载到客户端所在的终端设备本地。如果是服务器，则步骤S201中接收到的地址输入请求，可以是由客户端接收到用户的请求后转发到服务器的。

如前文所述，一个虚拟区县可能会对应多个行政区县，例如，图3所示的高新区，其对应的行政区县包括雁塔区和长安区这两个行政区县。此时，在使用四级地址库的情况下，该高新区关联的街道列表中包括了雁塔区下辖的各条街道以及长安区下辖的各条街道。因此，在用户选择了某条具体的目标街道之后，还可以根据该目标街道实际所属的行政区县，将该行政区县的名称确定为当前输入地址的区县地址段的名称。具体实现时，对于客户端而言，在用户选择了某虚拟区县后，可以在已选地址展示栏显示出该虚拟区县名称，也即图3中的305所示的“陕西/西安/高新区(雁塔区，长安区)”。在用户选择了其中某条目标街道，例如，长延堡街道，系统根据地址库确定出该街道应该属于雁塔区，于是，可以将该行政区县的名称回填到用户界面中的已选地址展示栏，也即将305中的内容替换为：“陕西/西安/雁塔/长延堡街道”。如果用户选择的街道是东大街道，系统根据地址库确定出该街道应该属于长安区，于是，可以将该行政区县的名称回填到用户界面中的已选地址展示栏，也即将305中的内 容替换为：“陕西/西安/长安/东大街道”，等等。

另外，如前文所述，虚拟区县与实际行政区县之间的关系还可能是多对一，此时对应的一般是将多个原有区县进行合并的情况，如图4所示，苏州下辖的虚拟区县包括：“沧浪区(姑苏区)”、“平江区(姑苏区)”、“金阊区(姑苏区)”，此时，在用户选择了这其中任一个虚拟区县的情况下，都可以直接将该虚拟区县对应的行政区县的名称(也即姑苏区)，回填到已选地址展示栏，而不用等到用户选择具体的街道之后。

当然，还存在虚拟区县与行政区县为一对一的情况，例如，如图4所示的“高新区(虎丘区)”，对于这种情况，该虚拟区县关联的街道列表与虎丘区实际下辖的街道列表是相同的，因此，用户可以选择该虚拟区县，也可以根据该虚拟区县名称中的提示，直接从行政区县中选择虎丘区，都可以继续进行后续的街道名称的选择，以及更详细地址信息的填写。

需要说明的是，无论是虚拟区县与行政区县之间是一对多，还是多对一，或者一对一，在展示虚拟区县名称时，都可以是将行政区县名称与别名同时进行展示，这样，这种信息都可以对用户起到提示作用，使得用户在顺利进行地址输入的同时，还对自己所填地址实际所属的行政区县名称有所了解。

另外需要说明的是，在本申请实施例中，用户选择完区县信息之后，还可以对街道信息进行选择，但在实际应用中，仍然可能存在用户不确定其地址所属街道名称的情况。为避免用户选择错误，也避免该必选项的存在导致地址输入过程的中断，本申请实施例中在提供街道级地址段列表时，还可以提供用于暂时将该步骤跳过的操作选项，例如，图5-1所示的501所示处展示有“稍后再说”字样，该字样为操作选择，如果用户不确定具体的街道名称时，可以点击“稍后再说”。此时，已选地址展示栏502中也可以将街道地址段的名称暂时展示为“稍后再说”。之后，用户就可以在后续503所示的详细地址输入栏输入更为详细的地址，例如，“天通苑东一区60号楼1207”。此时，系统可以以该详细地址信息为待检索地址文本，从预置的详细地址信息数据库中搜索相似地址文本。其中，详细地址信息数据库可以是根据销售平台中的大数据库建立的，例如，可以是由用户在历史交易过程中填写过的收货地址信息组成，等 等。搜索出相似的地址文本后，其中就可能包括街道信息，通过统计可以预测出当前输入的详细地址所属的街道名称，然后就可以根据该街道名称，确定当前输入地址的街道名称。具体实现时，还可以将该确定出的街道名称回填到已选地址展示栏中街道地址段。

当然，上述预测出的街道名称可能会存在误判等情况，因此，在实际应用中，预测得到街道名称后，还可以根据该相似地址文本中包含的街道名称信息提供推荐信息，当该推荐信息被接受时，再将相似地址文本中包含的街道名称信息确定为当前输入地址的街道名称。例如，提示信息可以为“您的地址是否在北京/北京/昌平/天通苑南街道”，并且可以提供用于接受该推荐的操作选项，如提供显示有“确认使用”等字样的按钮等。如果用户接受该推荐，则还可以将确认后的街道名称信息回填到已选地址展示栏中。

另外，为了进一步帮助用户判断推荐出的街道名称是否准确，还可以根据相似地址以及预置的地图信息数据库，确定该相似地址在地图中的位置，并进行标注，然后提供该带有标注结果的地图数据，以便用户确定是否接受所述推荐信息。例如，对于图5-1中所示的例子，展示的地图信息可以如图5-2中的504处所示。

总之，通过本申请实施例，对于存在别名(包括某些区县被划定为高新区、开发区，或者区县合并等情况下发生的区县名称变更等)的区县，可以在地址库中增加虚拟区县信息，该虚拟区县的名称根据行政区县的别名而定。这样，在进行地址输入控制的过程中，在展示区县列表时，可以将实际的行政区县信息以及虚拟区县信息全部提供给用户，这样，当用户无法确定其地址所属的行政区县名称时，可以通过虚拟区县进行选择，从而保证用户可以继续进行后续级别地址段的选择以及详细地址的输入等操作，避免用户的地址输入被中断，并且可以提高地址的输入效率，有利于降低由于强制性的限制导致的用户流失情况的发生概率。

与本申请实施例提供的地址输入控制方法相对应，本申请实施例还提供了 一种地址输入控制装置，其中，在预置的地址库中，如果某区县具有别名，则所述地址库中还包括虚拟区县名称；所述虚拟区县名称根据对应行政区县的别名确定；

参见图6，该装置可以包括：

请求接收单元601，用于接收地址输入请求；

可选列表提供单元602，用于根据所述地址库提供各级地址段的可选列表，其中，在区县级别的列表中提供行政区县名称以及虚拟区县名称；

触发单元603，用于当目标虚拟区县名称被选中时，触发进入到下一步继续进行地址的输入，并根据该虚拟区县名称对应的行政区县名称确定当前输入地址的区县名称。

在优选的实现方式下，所述地址库为四级地址库，四级地址段分别包括省、市、区县以及街道；所述地址库中还保存有虚拟区县关联的街道信息，所述虚拟区县关联的街道信息根据对应行政区县的下辖街道信息确定。

其中，所述具有别名的区县包括在工业领域具有别名的区县，所述虚拟区县名称为该工业领域的别名。

当一个工业别名对应至少两个行政区县时，虚拟区县的下辖街道包括该至少两个行政区县的下辖街道；

所述触发单元包括：

行政区县确定子单元，用于当所述虚拟区县的下辖街道列表中，目标下辖街道被选中时，确定该目标下辖街道所属的行政区县；

区县名称确定子单元，用于将该目标下辖街道所属的行政区县名称，确定为当前输入地址的区县名称。

或者，所述具有别名的区县包括由至少两个原有区县合并得到的区县，则所述至少两个原有区县分别对应一个虚拟区县，所述虚拟区县的名称根据各自对应的原有区县名称确定，对应的行政区县名称为所述合并后得到的区县的名 称。

在具体实现时，该装置还可以包括：

操作选项提供单元，用于在提供街道级地址段列表时，提供用于暂时将该步骤跳过的操作选项；

搜索单元，用于当该操作选项被操作时，以后续接收到的详细地址信息为待检索地址文本，从预置的详细地址信息数据库中搜索相似地址文本；

街道名称确定单元，用于根据所述相似地址文本中包含的街道名称信息，确定当前输入地址的街道名称。

其中，所述街道名称确定单元包括：

推荐信息提供子单元，用于根据所述相似地址文本中包含的街道名称信息提供推荐信息；

街道名称确定子单元，用于当所述推荐信息被接受时，将所述相似地址文本中包含的街道名称信息，确定为当前输入地址的街道名称。

另外，为了帮助用户确定推荐的街道信息是否准确，该装置还可以包括：

标注单元，用于根据所述相似地址以及预置的地图信息数据库，确定该相似地址在地图中的位置，并进行标注；

地图数据提供单元，用于提供带有标注结果的地图数据，以便用户确定是否接受所述推荐信息。

总之，通过本申请实施例，对于存在别名(包括某些区县被划定为高新区、开发区，或者区县合并等情况下发生的区县名称变更等)的区县，可以在地址库中增加虚拟区县信息，该虚拟区县的名称根据行政区县的别名而定。这样，在进行地址输入控制的过程中，在展示区县列表时，可以将实际的行政区县信息以及虚拟区县信息全部提供给用户，这样，当用户无法确定其地址所属的行政区县名称时，可以通过虚拟区县进行选择，从而保证用户可以继续进行后续级别地址段的选择以及详细地址的输入等操作，避免用户的地址输入被中断， 并且可以提高地址的输入效率，有利于降低由于强制性的限制导致的用户流失情况的发生概率。

通过以上的实施方式的描述可知，本领域的技术人员可以清楚地了解到本申请可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例或者实施例的某些部分所述的方法。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统或系统实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的系统及系统实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

以上对本申请所提供的地址输入控制方法及装置，进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处。综上所述，本说明书内容不应理解为对本申请的限制。