CN103207877B - 解码方法及装置 - Google Patents

Abstract

本申请提供了一种解码方法及装置，其中，解码方法包括：接收浏览器发送的包含有非ASCII码字符的统一资源定位符URL，其中，所述URL中携带有所述非ASCII码字符所采用的编码方式的信息；根据所述URL中的所述编码方式的信息，对所述URL进行解码。通过本申请，可以确定URL采用的编码方式，并对其进行正确地解码，从而有效提高了URL解码的准确率。

Description

解码方法及装置

技术领域

本申请涉及网络技术领域，特别是涉及一种解码方法及装置。

背景技术

目前随着互联网技术应用的越来越广泛，人们很多的日常工作和娱乐都通过在网络上传输数据进行。在网络上传输的数据均是二进制的0、1代码，用户向服务器所请求的资源都会被应用或者浏览器进行编码之后发送到服务端，服务端再对数据进行解码。其中，目前对于英文字母和数字采用的都是ASCII编码，而对于类似中文等的特殊字符，不同的系统会采用不同的编码方式，因此跨系统间互访问就需要知道对方所采用的编码方式，才能够对接收到的中文字符等特殊字符进行正确的解码，进而提供用户所需的服务。

例如，移动设备用户在访问移动搜索应用时，一种方式是直接访问，即直接在移动设备上输入移动搜索应用的服务器所在的地址(URL)，进而访问移动搜索应用；另一种方式是先访问桌面搜索应用，然后再跳转到移动搜索应用，即用户通过移动设备输入的是桌面搜索应用的服务器所在的地址(URL)，此时服务器会判断出访问用户的设备类型是移动设备，进而将该访问请求转移至移动搜索应用所在的服务器。其中，桌面搜索应用是一套基于PC上B/S架构的应用系统，可以为用户提供产品，公司和资讯等海量站内电子商务信息的搜索服务；移动搜索应用是桌面搜索应用的移动版本改造，提供适合手机等移动终端访问的电子商务信息搜索以及更多基于地理位置信息的服务。这两种应用采用了不同的编码方式，其中，桌面搜索应用采用了GBK的编码方式，而移动搜索应用则采用的是UTF-8的编码方式。当用户使用移动设备直接访问桌面搜索应用时，会将使用移动设备用户访问桌面搜索应用的这部分访问请求，自动切换到移动搜索应用，这样，移动搜索应用会接收到来自移动搜索应用自身的用户访问以及从桌面搜索应用切换过来的用户访问两个来源的访问，而两个应用由于都采用了URL重写，将URL进行了静态化处理，对于其中的中文等特殊字符进行了编码处理，而桌面搜索应用和移动搜索应用分别采用了GBK和UTF-8两种不同的编码方式，URL中的中文分别按照GBK和UTF-8进行编码，而移动搜索应用由于无法识别所接收到的URL的编码方式从而无法对中文参数进行正确解码。

为了解决上述问题，相关技术中提供了一种用于确定用来解码请求的字符编码的方法，包括：(a)接收请求；(b)确定该请求对应于多个应用程序中的哪一个；(c)识别出与所确定的应用程序相关联的字符编码；(d)使用识别出的字符编码检查该请求。可见，在该方案中，采用了建立并维护特定系统与编码方式的映射关系来判断特定来源URL(统一资源定位符)的编码方式，进而进行解码的措施。

然而，如果通过建立并维护特定系统与编码方式的映射关系来判断特定来源URL的编码方式，进而进行解码，需要事先知道特定系统是什么系统，以及该系统采用了什么方式的编码，而当事先没有获取到这些信息时，则会对阻碍正确解码，降低解码判断的准确率和系统的扩展性。

因此，如何能够对于未知编码方式的URL中的非ASCII码字符，如中文字符或其它特殊字符的编码方式进行自适应处理，进而进行正确解码，以提高解码准确率成为极需解决的一个问题。

发明内容

本申请提供了一种解码方法及装置，以解决现有对于未知编码方式的URL中的非ASCII码字符，如中文字符或其它特殊字符的编码方式无法进行正确解码，解码准确率低的问题。

为了解决上述问题，本申请公开了一种解码方法，包括：接收浏览器发送的包含有非ASCII码字符的统一资源定位符URL，其中，所述URL中携带有所述非ASCII码字符所采用的编码方式的信息；根据所述URL中的所述编码方式的信息，对所述URL进行解码。

优选地，所述接收浏览器发送的包含有非ASCII码字符的统一资源定位符URL的步骤包括：移动搜索应用接收移动终端通过其浏览器直接访问所述移动搜索应用时发送的包含有非ASCII码字符的URL，和/或，所述移动搜索应用接收所述移动终端经由桌面搜索应用跳转访问所述移动搜索应用时的包含有非ASCII码字符的URL。

优选地，所述直接访问所述移动搜索应用时发送的URL中的非ASCII码字符经过第一编码方式编码，所述经由桌面搜索应用跳转访问所述移动搜索应用时的URL中的非ASCII码字符经过第二编码方式编码；所述直接访问所述移动搜索应用时发送的URL中加入了所述第一编码方式的信息，所述经由桌面搜索应用跳转访问所述移动搜索应用时的URL中未加入编码方式信息；所述第一编码方式与所述第二编码方式为不同的编码方式。

优选地，根据所述URL中的所述编码方式的信息，对所述URL进行解码的步骤包括：判断接收到的URL中是否携带有编码方式信息；若是，则使用所述第一编码方式对所述URL进行解码；若否，则使用所述第二编码方式对所述URL进行解码。

优选地，所述非ASCII码字符所采用的编码方式的信息为设定的非ASCII码字符的编码值；在所述接收浏览器发送的包含有非ASCII码字符的统一资源定位符URL的步骤之前，还包括：在系统中存储所述设定的非ASCII码字符在多种编码方式下的编码值与所述多种编码方式的对应关系；所述根据所述URL中的所述编码方式的信息，对所述URL进行解码的步骤包括：根据所述URL中的所述设定的非ASCII码字符的编码值，查找存储的所述对应关系，确定与该编码值对应的编码方式；使用确定的所述编码方式对所述URL进行解码。

为了解决上述问题，本申请还公开了一种解码装置，包括：接收模块，用于接收浏览器发送的包含有非ASCII码字符的统一资源定位符URL，其中，所述URL中携带有所述非ASCII码字符的所采用的编码方式的信息；解码模块，用于根据所述URL中的所述编码方式的信息，对所述URL进行解码。

优选地，所述接收模块包括：第一接收模块，用于移动搜索应用接收移动终端通过其WEB浏览器直接访问所述移动搜索应用时发送的包含有非ASCII码字符的URL，和/或，第二接收模块，用于所述移动搜索应用接收所述移动终端经由桌面搜索应用跳转访问所述移动搜索应用时的包含有非ASCII码字符的URL。

优选地，所述直接访问所述移动搜索应用时发送的URL中的非ASCII码字符经过第一编码方式编码，所述经由桌面搜索应用跳转访问所述移动搜索应用时的URL中的非ASCII码字符经过第二编码方式编码；所述直接访问所述移动搜索应用时发送的URL中加入了所述第一编码方式的信息，所述经由桌面搜索应用跳转访问所述移动搜索应用时的URL中未加入编码方式信息；所述第一编码方式与所述第二编码方式为不同的编码方式。

优选地，所述解码模块包括：判断模块，用于判断接收到的URL中是否携带有编码方式信息；执行模块，用于若所述判断模块的判断结果为是，则使用所述第一编码方式对所述URL进行解码；若所述判断模块的判断结果为否，则使用所述第二编码方式对所述URL进行解码。

优选地，所述非ASCII码字符所采用的编码方式的信息为设定的非ASCII码字符的编码值；所述装置还包括：存储模块，用于在所述接收模块接收浏览器发送的包含有非ASCII码字符的统一资源定位符URL之前，在系统中存储所述设定的非ASCII码字符在多种编码方式下的编码值与所述多种编码方式的对应关系；所述解码模块，用于根据所述URL中的所述设定的非ASCII码字符的编码值，查找存储的所述对应关系，确定与该编码值对应的编码方式；使用确定的所述编码方式对所述URL进行解码。

与现有技术相比，本申请具有以下优点：

本申请的解码方案通过对接收的URL中的编码方式信息进行分析，获取该URL中的非ASCII码字符在发送时采用的编码方式，进而对该URL进行相应地解码。这样，不管采用何种编码方式的应用或浏览器发送来URL，接收端都可以确定该URL采用的编码方式，并对其进行正确地解码，从而有效提高了URL解码的准确率。可见，通过本申请的解码方案，有效解决了现有对于未知编码方式的URL中的非ASCII码字符如中文字符或其它特殊字符的编码方式无法进行正确解码，解码准确率低的问题。

附图说明

图1是根据本申请实施例一的一种解码方法的步骤流程图；

图2是根据本申请实施例二的一种解码方法的步骤流程图；

图3是根据本申请实施例三的一种解码方法的步骤流程图；

图4是图3所示解码方法的时序图；

图5是根据本申请实施例四的一种解码装置的结构框图。

具体实施方式

为使本申请的上述目的、特征和优点能够更加明显易懂，下面结合附图和具体实施方式对本申请作进一步详细的说明。

实施例一

参照图1，示出了根据本申请实施例一的一种解码方法的步骤流程图。

本实施例的解码方法包括以下步骤：

步骤S102：接收浏览器发送的包含有非ASCII码字符的URL。

其中，不同情况下WEB浏览器发送的URL中，可能对非ASCII码字符，如中文或其它特殊字符，采用了不同的编码方式，因此，该URL中携带有其包含的非ASCII码字符所采用的编码方式的信息。

在用户通过WEB浏览器向服务端发送包含非ASCII码字符的URL时，该URL中的非ASCII码字符会被编码，然后再发送包含有编码后的非ASCII码字符的URL。然而，不同的应用或浏览器采用的非ASCII码字符编码方式不同，因此，即使是同一个URL，在其包含的非ASCII码字符被编码后，发送到服务端的URL也不相同，只有准确获知了非ASCII码字符的编码方式，也可以称为URL的编码方式，才能对URL进行正确的解码。本实施例中，通过在URL中携带其包含的非ASCII码字符的编码方式信息，使接收到URL的服务端能够准确获知该URL的编码方式。其中，编码方式的信息可以是任意适当形式的信息，只要能标识出URL的编码方式即可。比如，在有两种以上采用不同编码方式的情况下，可以在URL中携带明确的指示信息，指示该URL采用的编码方式；而在只有两种不同编码方式的情况下，则可以使一种URL携带其编码方式信息，这时，即使另一种URL不携带编码方式信息，服务端也可确定其编码方式。

步骤S104：根据URL中的编码方式的信息，对URL进行解码。

在URL携带了编码方式信息的情况下，服务端可以明确确定其编码方式，进而进行相应地解码。

通过本实施例，对接收的URL中的编码方式信息进行分析，获取该URL中的非ASCII码字符的编码方式，进而进行相应地解码。这样，不管采用何种编码方式的应用或浏览器发送来URL，接收端都可以确定该URL采用的编码方式，并对其进行正确地解码，这一方面提高了对URL解码的准确率，另一方面，接收端无需在意采用不同编码方式的不同应用或浏览器的种类和数量，也无需存储编码方式与应用或浏览器间的对应关系，只根据URL即可实现正确解码，不会对系统的扩展性造成影响。可见，通过本申请的解码方案，有效解决了现有对于未知编码方式的URL中的非ASCII码字符，如中文字符或其它特殊字符的编码方式无法进行正确解码，解码准确率低的问题。并且，不会对系统的扩展性造成影响。

实施例二

参照图2，示出了根据本申请实施例二的一种解码方法的步骤流程图。

本实施例的解码方法包括以下步骤：

步骤S202：移动终端运行其浏览器。

此时，因用户并未输入任何非ASCII码字符，因此，首次启动运行WEB浏览器时的URL并不需要进行非ASCII码字符编码。

步骤S204：用户输入非ASCII码字符，进行网页搜索。

本实施例中，以用户输入中文字符“手机”为例，在移动终端的WEB浏览器启动运行后，用户输入“手机”二字，搜索与“手机”有关的网页。

步骤S206：浏览器向用户返回与输入的非ASCII码字符相关的多个网页，包括桌面搜索应用提供的网页和移动搜索应用提供的网页。

在用户输入“手机”进行搜索后，浏览器向用户返回多个与“手机”相关的网页，这其中可能既包括桌面搜索应用提供的网页，也包括移动搜索应用提供的网页。

步骤S208：若用户访问桌面搜索应用，则桌面搜索应用判断用户是否是使用移动终端访问，如果是，则执行步骤S210，将用户请求跳转到移动搜索应用。

步骤S210：桌面搜索应用对用户访问请求中的URL进行静态化重写，将其中的非ASCII码字符进行编码，使该URL携带其非ASCII码字符所采用的编码方式的信息，向服务端发送编码后的URL，执行步骤S214。

用户通过桌面搜索应用访问与“手机”有关的的网页时，由桌面搜索应用对“手机”二字进行编码(第二编码方式)，然后跳转到相应的移动搜索应用上。本实施例中，桌面搜索应用采用GBK编码方式对非ASCII码字符进行编码，GBK编码方式是一种桌面搜索应用常用的编码方式，但不限于此，还可以采用任意其它适当的编码方式。对于用户点击提交的原始的动态URL，桌面搜索应用会对其进行静态化重写和编码。URL重写是首先获得一个进入的URL请求，然后把它重新写成网站可以处理的另一个URL的过程。因不同的桌面搜索应用采用不同的编码方式，因此，重写和编码后的URL的编码方式也不相同。通过桌面搜索应用的编码，使URL携带相应的编码方式信息，以标识其非ASCII码字符的编码方式。

当然，通过桌面搜索应用编码，使URL携带相应的编码方式信息仅为一种优选的方式，这种方式最大程度地利用了现有技术，对现有流程的改动小，节约了实现成本，不影响现有系统的性能。然而，不限于此，在实际使用中，本领域技术人员可以根据实际情况，采用任意其它适当的方式使URL携带编码方式信息，如在URL的HTTP/TCP协议数据包的相关报文中添加编码方式信息等，本申请对此不作限制。

步骤S212：移动终端的浏览器对用户访问请求中的URL进行编码，使该URL携带其非ASCII码字符所采用的编码方式的信息，向服务端发送编码后的URL，然后执行步骤S214。

当用户访问的是移动搜索应用的网页，则移动终端通过其WEB浏览器直接访问移动搜索应用，这时，移动终端的WEB浏览器会对包含非ASCII码字符的URL进行编码(第一编码方式)，本实施例中，采用UTF-8编码方式，但不限于此，还可采用任意其它适当的编码方式。

步骤S214：服务端接收浏览器发送的编码后的URL，获取该URL中携带的编码方式的信息。

步骤S216：服务端根据获取的该URL的编码方式的信息，采用相应的解码方式对该URL进行解码。

通过本实施例，有效解决了现有对于未知编码方式的URL中的中文字符或其它特殊字符等非ASCII码字符的编码方式无法进行正确解码，解码准确率低的问题，提高了对URL解码的准确率，且不影响系统的扩展性，实现成本低。

实施例三

参照图3，示出了根据本申请实施例三的一种解码方法的步骤流程图。

本实施例以移动终端用户直接访问移动搜索应用和通过桌面搜索应用跳转访问移动搜索应用为例，对本实施例的解码方法进行说明。其中，设定直接访问移动搜索应用时的URL中的非ASCII码字符采用UTF-8编码(第一编码方式)，通过桌面搜索应用访问移动搜索应用时的URL中的非ASCII码字符采用GBK编码(第二编码方式)，本实施例中设定非ASCII码字符均为中文字符。为了让移动终端用户访问搜索服务能够获得更好的用户体验，需要将访问桌面搜索系统的移动终端用户自动切换到访问移动搜索系统，由于两个独立的系统分别采用了UTF-8和GBK两种不同的编码方式，因此两个系统对于URL中的中文字符的编解码方式不同，在流量的切换时，可能出现用户使用GBK编码的URL来访问采用UTF-8解码的移动搜索系统，从而导致乱码的问题。

为此，本实施例提供了一种解码方法，包括以下步骤：

步骤S302：持有第一移动终端的第一用户访问桌面搜索应用。

桌面搜索应用是一套基于PC上B/S架构的应用系统，可以为用户提供产品，公司和资讯等海量站内电子商务信息的搜索服务。整个应用采用GBK编码，并进行URL静态化重写，因此所有URL中的中文参数都会被进行GBK编码。

本步骤中，持有第一移动终端的第一用户在搜索引擎(例如google)中搜索非ASCII编码的关键词，点击所收录的桌面搜索应用的超链接，或者在其他有桌面搜索应用的搜索框的页面中输入非ASCII编码的关键词，进行搜索，页面跳转到桌面搜索应用。

步骤S304：桌面搜索应用对第一移动终端提交的动态URL进行静态化重写，将包括中文在内的所有参数进行GBK编码，发送给移动搜索应用。

例如，把类似http://domainName/xxx？k1＝v1&k2＝v2.html形式的动态URL重写为类似http://domainName/xxx/k1-v1_k2-v2.html格式的静态URL，然后判断如果第一用户使用的为移动终端设备，则利用301跳转，通知浏览器使用重写后的静态URL重新访问移动搜索应用。此时，第一用户输入的所有中文字符的查询条件都通过GBK编码加入到了重写后的静态URL中。以用户查询的中文关键词为“手机”为例，用户使用iPhone手机访问桌面搜索应用，输入关键词“手机”进行搜索，桌面搜索系统进行URL静态化重写，将第一用户发起的动态URL重写为静态化的URL：http://domainName/xxx/k-％CA％D6％BB％FA.html，并跳转到移动搜索应用，其中用户查询的中文关键字“手机”被采用GBK编码为％CA％D6％BB％FA。

本实施例中，因只涉及两种不同的应用，因此，只需一种URL携带编码信息即可，具体到本实施例，GBK编码后的URL中并未携带编码方式信息，仅在UTF-8编码后的URL中携带编码方式信息。但本领域技术人员应当明了，在实际使用中，也可以使GBK编码后的URL携带GBK编码信息。只在一种URL携带编码信息，提高了URL编码速度和效率，节省了URL编码时间，也提高了URL解码效率和速度。

步骤S306：持有第二移动终端的第二用户直接访问移动搜索应用，向移动搜索应用发送编码后的URL。

第二移动终端直接访问移动搜索应用时，可以通过第二移动终端的WEB浏览器直接对发送给移动搜索应用的URL中的非ASCII码字符进行编码，然后发送给移动搜索应用。

移动搜索应用是桌面搜索应用的移动版本改造，提供适合手机等移动终端访问的电子商务信息搜索以及更多基于地理位置信息的服务。整个应用采用UTF-8编码，在移动搜索应用内部的URL中都会默认添加URL所采用的UTF-8的编码方式信息，以此告诉移动搜索应用采用正确的方式对URL进行解码。

本实施例中，移动搜索应用采用了同样的URL静态化方案，唯一的区别是编码方式变为了UTF-8，并在静态化URL的同时，在URL中加入了编码方式信息，形成了类似http://domainName/k1-v1_k2-v2_en-utf8.html格式的带有编码方式信息的静态URL。

需要说明的是，步骤S302-S304和步骤S306的执行可以不分先后顺序。另外，第一移动终端和第二移动终端可以为不同的移动终端，也可以为相同的移动终端；同样，第一用户和第二用户可以为不同的用户，也可以为相同的用户。

步骤S308：移动搜索应用获取URL中的编码方式信息，根据该编码方式信息对URL进行解码。

此时，移动搜索应用接收到的用户访问请求有两个来源，一个是直接访问移动搜索应用系统的第二用户的用户访问，另一个是持有移动设备访问桌面搜索应用后自动跳转到移动搜索应用的第一用户的用户访问。由于两种不同来源访问的URL中的中文字符分别采用了GBK和UTF-8两种不同的编码方式，移动搜索应用需要对URL的来源进行识别，因此移动搜索应用在接收到用户请求的URL后，尝试获取URL中所携带的编码方式信息，具体到本实施例，移动搜索应用判断接收到的URL中是否携带有编码方式信息，如果能够从静态URL中获取到参数en-utf8，则为移动搜索应用自身生成的URL，采用UTF-8编码方式进行解码；如果检测不到编码信息，则判断为桌面搜索应用生成的静态URL，采用GBK编码方式对URL中的参数进行解码，从而解决了对于未知编码方式URL中的中文字符的编码自适应问题。

例如，移动搜索应用接收到对第一用户的URL进行重写后的静态URL即http://domainName/xxx/k-％CA％D6％BB％FA.html后，检测其中是否包含编码方式信息“en-utf8”，由于没有检测到，则识别为跳转URL，采用桌面搜索应用的GBK编码方式对URL中的参数进行解码，将手机的GBK编码％CA％D6％BB％FA正确地进行了解码。

具体地，以用户搜索关键词为“手机”为例，本实施例中通过桌面搜索应用访问移动搜索应用的时序如图4所示，包括：

步骤(a)：用户通过桌面搜索应用搜索关键词“手机”。

步骤(b)：桌面搜索应用进行URL静态化重写处理，对中文参数进行GBK编码。

步骤(c)：桌面搜索应用判断用户是否是使用移动终端输入搜索关键词“手机”。

步骤(d)：在判断结果为是的情况下，进行访问请求切换，即301跳转，切换到移动搜索应用。

301跳转也称为301重定向，当用户或搜索引擎向网站服务器发出浏览请求时，服务器返回的HTTP数据流中头信息(header)中的状态码的一种，表示本网页永久性转移到另一个地址。

步骤(e)：移动搜索应用检测URL中是否包含编码信息“en-utf8”。

步骤(f)：移动搜索应用按照URL中指定的编码方式对URL参数进行解码。

即，若URL中包含编码信息“en-utf8”，则按照UTF-8编码方式对该URL进行解码；若URL中不包含编码信息“en-utf8”，则按照GBK编码方式对该URL进行解码。因本时序中，桌面搜索应用发送来的URL是经过GBK编码的，其中不包含编码信息“en-utf8”，因此按照GBK编码方式对该URL进行解码。

步骤(g)：根据解码后的URL进行业务处理，并向用户返回处理结果。

至此，一个通过桌面搜索应用访问移动搜索应用的业务处理完成。

需要说明的是，本实施例中以URL携带明文的编码方式信息为例，但在实际实现中，编码方式信息的携带还可以通过URL携带特定字符(事先设定的字符)的编码来实现，进而通过该特定字符的编码来判断URL所采用的编码方式，进行相应地解码。在这种情况下，URL中的非ASCII码字符所采用的编码方式的信息为设定的非ASCII码字符(特定字符)的编码值；并且，在系统中还事先存储有设定的非ASCII码字符在多种编码方式下的编码值与多种编码方式的对应关系；在确定编码方式时，先根据URL中的设定的非ASCII码字符的编码值，查找存储的对应关系，确定与URL中的编码值对应的编码方式，然后再使用确定的编码方式对该URL进行解码。

例如，系统中存储有“中文”二字在多种编码方式下的编码值，仍以UTF-8编码和GBK编码为例，“中文”的UTF-8和GBK编码分别为％E4％B8％AD％E6％96％87和％D6％D0％CE％C4。当用户搜索“手机”时，应用或浏览器会同时在URL加入“中文”的编码值，如：

URL1：http://domainName/xxx/k-％E6％89％8B％E6％9C％BA_en-％E4％B8％AD％E6％96％87.html；

URL2：http://domainName/xxx/k-％CA％D6％BB％FA_en-％D6％D0％CE％C4.html；

由于“中文”的UTF-8和GBK编码分别为％E4％B8％AD％E6％96％87和％D6％D0％CE％C4，因此，当移动搜索应用接收到上述URL1和URL2时，会查找存储的“中文”的编码值与编码方式的对应关系，经过查验后可以确定URL1采用了UTF-8编码，URL2采用了GBK编码方式，然后，根据确定的编码方式对URL1或URL2进行解码。

通过本实施例，在URL中携带原始访问系统所采用的编码方式信息来准确捕获特定系统的编码方式，从而准确地进行URL中的中文字符等特殊字符的正确解码，实现了对于未知编码方式的URL中的中文字符编码方式的自适应处理，解决了现有对于未知编码方式的URL中的中文字符或其它特殊字符的编码方式无法进行正确解码，解码准确率低的问题。

另外，本领域技术人员应当明了，本实施例中的编码方式仅为示例性说明，任意其它URL编码方式的解码均可参照本实施例进行。

实施例四

参照图5，示出了根据本申请实施例四的一种解码装置的结构框图。

本实施例的解码装置包括：接收模块502，用于接收浏览器发送的包含有非ASCII码字符的URL，其中，URL中携带有其包含的非ASCII码字符所采用的编码方式的信息；解码模块504，用于根据URL中的编码方式的信息，对URL进行解码。

优选地，接收模块502包括：第一接收模块5022，用于移动搜索应用接收移动终端通过其浏览器直接访问移动搜索应用时发送的包含有非ASCII码字符的URL，和/或，第二接收模块5024，用于移动搜索应用接收移动终端经由桌面搜索应用跳转访问移动搜索应用时的包含有非ASCII码字符的URL。

优选地，直接访问移动搜索应用时发送的URL中的非ASCII码字符经过第一编码方式编码，如UTF-8编码方式编码，经由桌面搜索应用跳转访问移动搜索应用时的URL中的非ASCII码字符经过第二编码方式编码，如GBK编码方式编码；直接访问移动搜索应用时发送的URL中加入了第一编码方式的信息，经由桌面搜索应用跳转访问移动搜索应用时的URL中未加入编码方式信息；第一编码方式与第二编码方式为不同的编码方式。

优选地，解码模块504包括：判断模块5042，用于判断接收到的URL中是否携带有编码方式信息；执行模块5044，用于若判断模块5042的判断结果为是，则使用第一编码方式对URL进行解码；若判断模块5042的判断结果为否，则使用第二编码方式对URL进行解码。

优选地，非ASCII码字符所采用的编码方式的信息为设定的非ASCII码字符的编码值；本实施例的解码装置还包括：存储模块(图中未示出)，用于在接收模块502接收浏览器发送的包含有非ASCII码字符的URL之前，在系统中存储设定的非ASCII码字符在多种编码方式下的编码值与多种编码方式的对应关系；解码模块504，用于根据URL中的设定的非ASCII码字符的编码值，查找存储的对应关系，确定与该编码值对应的编码方式；使用确定的编码方式对URL进行解码。

本实施例的解码装置用于实现前述多个方法实施例中的解码方法，并具有相应的方法实施例的有益效果，在此不再赘述。

本申请的解码方案通过在URL中添加编码方式的信息来告知目标应用URL所采用的编码方式，实现了对采用不同编码方式的URL的准确解码。

本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。对于装置实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

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

Claims (8)

1.一种解码方法，其特征在于，包括：

接收浏览器发送的包含有非ASCII码字符的统一资源定位符URL，进一步包括以下方式中的至少一者：移动搜索应用接收移动终端通过其浏览器直接访问所述移动搜索应用时发送的包含有非ASCII码字符的URL，所述移动搜索应用接收所述移动终端经由桌面搜索应用跳转访问所述移动搜索应用时的包含有非ASCII码字符的URL；其中，所述URL中携带有所述非ASCII码字符所采用的编码方式的信息；所述直接访问所述移动搜索应用时发送的URL中的非ASCII码字符与所述经由桌面搜索应用跳转访问所述移动搜索应用时的URL中的非ASCII码字符采用不同的编码方式；

根据所述URL中的所述编码方式的信息，对所述URL进行解码。

2.根据权利要求1所述的方法，其特征在于，所述直接访问所述移动搜索应用时发送的URL中的非ASCII码字符经过第一编码方式编码，所述经由桌面搜索应用跳转访问所述移动搜索应用时的URL中的非ASCII码字符经过第二编码方式编码；所述直接访问所述移动搜索应用时发送的URL中加入了所述第一编码方式的信息，所述经由桌面搜索应用跳转访问所述移动搜索应用时的URL中未加入编码方式信息；所述第一编码方式与所述第二编码方式为不同的编码方式。

3.根据权利要求2所述的方法，其特征在于，根据所述URL中的所述编码方式的信息，对所述URL进行解码的步骤包括：

判断接收到的URL中是否携带有编码方式信息；

若是，则使用所述第一编码方式对所述URL进行解码；若否，则使用所述第二编码方式对所述URL进行解码。

4.根据权利要求1所述的方法，其特征在于，所述非ASCII码字符所采用的编码方式的信息为设定的非ASCII码字符的编码值；

在所述接收浏览器发送的包含有非ASCII码字符的统一资源定位符URL的步骤之前，还包括：在系统中存储所述设定的非ASCII码字符在多种编码方式下的编码值与所述多种编码方式的对应关系；

所述根据所述URL中的所述编码方式的信息，对所述URL进行解码的步骤包括：根据所述URL中的所述设定的非ASCII码字符的编码值，查找存储的所述对应关系，确定与该编码值对应的编码方式；使用确定的所述编码方式对所述URL进行解码。

5.一种解码装置，其特征在于，包括：

接收模块，用于接收浏览器发送的包含有非ASCII码字符的统一资源定位符URL，其中，所述URL中携带有所述非ASCII码字符的所采用的编码方式的信息；

解码模块，用于根据所述URL中的所述编码方式的信息，对所述URL进行解码；

其中，所述接收模块包括：

第一接收模块，用于移动搜索应用接收移动终端通过其WEB浏览器直接访问所述移动搜索应用时发送的包含有非ASCII码字符的URL，

和/或，

第二接收模块，用于所述移动搜索应用接收所述移动终端经由桌面搜索应用跳转访问所述移动搜索应用时的包含有非ASCII码字符的URL；所述直接访问所述移动搜索应用时发送的URL中的非ASCII码字符与所述经由桌面搜索应用跳转访问所述移动搜索应用时的URL中的非ASCII码字符采用不同的编码方式。

6.根据权利要求5所述的装置，其特征在于，所述直接访问所述移动搜索应用时发送的URL中的非ASCII码字符经过第一编码方式编码，所述经由桌面搜索应用跳转访问所述移动搜索应用时的URL中的非ASCII码字符经过第二编码方式编码；所述直接访问所述移动搜索应用时发送的URL中加入了所述第一编码方式的信息，所述经由桌面搜索应用跳转访问所述移动搜索应用时的URL中未加入编码方式信息；所述第一编码方式与所述第二编码方式为不同的编码方式。

7.根据权利要求6所述的装置，其特征在于，所述解码模块包括：

判断模块，用于判断接收到的URL中是否携带有编码方式信息；

执行模块，用于若所述判断模块的判断结果为是，则使用所述第一编码方式对所述URL进行解码；若所述判断模块的判断结果为否，则使用所述第二编码方式对所述URL进行解码。

8.根据权利要求5所述的装置，其特征在于，所述非ASCII码字符所采用的编码方式的信息为设定的非ASCII码字符的编码值；

所述装置还包括：存储模块，用于在所述接收模块接收浏览器发送的包含有非ASCII码字符的统一资源定位符URL之前，在系统中存储所述设定的非ASCII码字符在多种编码方式下的编码值与所述多种编码方式的对应关系；

所述解码模块，用于根据所述URL中的所述设定的非ASCII码字符的编码值，查找存储的所述对应关系，确定与该编码值对应的编码方式；使用确定的所述编码方式对所述URL进行解码。