本申请提供一种补丁发放和获取方法、装置，该补丁发放方法包括：根据客户端发送的补丁获取请求，从补丁平台数据库中提取相应的补丁数据；将所述补丁数据返回所述客户端；其中，所述补丁数据包括补丁代码和与所述补丁代码对应的校验信息，以由所述客户端根据所述校验信息对所述补丁代码进行校验。通过本申请的技术方案，可以简化补丁的管理与维护过程，提升了补丁的传输安全性。
根据客户端发送的补丁获取请求，从补丁平台数据库中提取相应的补丁数据，其中，基于对开发人员所上传的未打包的补丁数据的属性信息进行读取，使得所述未打包的补丁数据维护于所述补丁平台数据库中，经过读取所述补丁获取请求中的系统类型信息和应用程序版本信息，将从所述补丁平台数据库中提取的与所述系统类型信息和所述应用程序版本信息相匹配的最新版本补丁数据作为所述补丁数据；
将所述补丁数据返回所述客户端；其中，所述补丁数据包括补丁代码和与所述补丁代码对应的校验信息，以由所述客户端根据所述校验信息对所述补丁代码进行校验。
2.根据权利要求1所述的方法，其特征在于，所述校验信息为经由所述补丁平台数据库处的私钥进行签名的摘要信息，所述摘要信息是根据预设摘要算法对所述补丁代码进行计算得到。
3.根据权利要求1所述的方法，其特征在于，还包括：
接收网页访问请求，所述网页访问请求由开发人员通过本地浏览器发起；
返回对应于所述补丁平台数据库中的补丁状况的网页数据，以使所述本地浏览器根据所述网页数据生成对所述补丁平台数据库的管理界面；
接收所述开发人员通过所述管理界面发送的补丁维护指令，对所述补丁平台数据库进行补丁维护。
接收所述服务端返回的补丁数据，所述补丁数据包括补丁代码和校验信息，其中，基于服务端对开发人员所上传的未打包的补丁数据的属性信息进行读取，使得所述未打包的补丁数据维护于所述补丁平台数据库中，经过服务端读取所述补丁获取请求中的系统类型信息和应用程序版本信息，将服务端从所述补丁平台数据库中提取的与所述系统类型信息和所述应用程序版本信息相匹配的最新版本补丁数据作为所述补丁数据；
根据所述校验信息对所述补丁代码进行校验，并在通过校验的情况下执行所述补丁代码。
5.根据权利要求4所述的方法，其特征在于，还包括：
当存在所述补丁更新需求时，遍历本地是否存在补丁数据；
当本地存在补丁数据时，通过本地补丁数据解决所述补丁更新需求；当本地不存在补丁数据时，向所述服务端发送所述补丁获取请求，以从所述服务端获取补丁数据。
6.根据权利要求5所述的方法，其特征在于，所述校验信息为经由所述补丁平台数据库处的私钥进行签名的摘要信息，所述摘要信息是根据预设摘要算法对所述补丁代码进行计算得到。
7.根据权利要求6所述的方法，其特征在于，所述根据所述校验信息对所述补丁代码进行校验，包括：根据所述预设摘要算法计算出所述补丁代码对应的实时摘要信息；
当所述校验信息满足下述条件时，判定所述补丁代码通过了所述校验信息的校验：由本地公钥对所述校验信息进行签名解码，且得到的解码信息与所述实时摘要信息一致。
提取单元，根据客户端发送的补丁获取请求，从补丁平台数据库中提取相应的补丁数据，其中，基于对开发人员所上传的未打包的补丁数据的属性信息进行读取，使得所述未打包的补丁数据维护于所述补丁平台数据库中，经过读取所述补丁获取请求中的系统类型信息和应用程序版本信息，将从所述补丁平台数据库中提取的与所述系统类型信息和所述应用程序版本信息相匹配的最新版本补丁数据作为所述补丁数据；
返回单元，将所述补丁数据返回所述客户端；其中，所述补丁数据包括补丁代码和与所述补丁代码对应的校验信息，以由所述客户端根据所述校验信息对所述补丁代码进行校验。
9.根据权利要求8所述的装置，其特征在于，所述校验信息为经由所述补丁平台数据库处的私钥进行签名的摘要信息，所述摘要信息是根据预设摘要算法对所述补丁代码进行计算得到。
10.根据权利要求8所述的装置，其特征在于，还包括：
请求接收单元，接收网页访问请求，所述网页访问请求由开发人员通过本地浏览器发起；
数据返回单元，返回对应于所述补丁平台数据库中的补丁状况的网页数据，以使所述本地浏览器根据所述网页数据生成对所述补丁平台数据库的管理界面；
补丁维护单元，接收所述开发人员通过所述管理界面发送的补丁维护指令，对所述补丁平台数据库进行补丁维护。
接收单元，接收所述服务端返回的补丁数据，所述补丁数据包括补丁代码和校验信息，其中，基于服务端对开发人员所上传的未打包的补丁数据的属性信息进行读取，使得所述未打包的补丁数据维护于所述补丁平台数据库中，经过服务端读取所述补丁获取请求中的系统类型信息和应用程序版本信息，将服务端从所述补丁平台数据库中提取的与所述系统类型信息和所述应用程序版本信息相匹配的最新版本补丁数据作为所述补丁数据；
校验单元，根据所述校验信息对所述补丁代码进行校验，并在通过校验的情况下执行所述补丁代码。
12.根据权利要求11所述的装置，其特征在于，还包括：检测单元，检测是否存在补丁更新需求；
遍历单元，当存在所述补丁更新需求时，遍历本地是否存在补丁数据；
处理单元，当本地存在补丁数据时，通过本地补丁数据解决所述补丁更新需求；当本地不存在补丁数据时，向所述服务端发送所述补丁获取请求，以从所述服务端获取补丁数据。
13.根据权利要求11所述的装置，其特征在于，所述校验信息为经由所述补丁平台数据库处的私钥进行签名的摘要信息，所述摘要信息是根据预设摘要算法对所述补丁代码进行计算得到。
14.根据权利要求13所述的装置，其特征在于，所述校验单元具体用于：根据所述预设摘要算法计算出所述补丁代码对应的实时摘要信息；
当所述校验信息满足下述条件时，判定所述补丁代码通过了所述校验信息的校验：由本地公钥对所述校验信息进行签名解码，且得到的解码信息与所述实时摘要信息一致。
其中，所述处理器被配置为可执行指令以实现如权利要求1-3中任一项所述的方法。
16.一种计算机可读存储介质，其上存储有计算机指令，其特征在于，该指令被处理器执行时实现如权利要求1-3中任一项所述方法的步骤。
其中，所述处理器被配置为可执行指令以实现如权利要求4-7中任一项所述的方法。
18.一种计算机可读存储介质，其上存储有计算机指令，其特征在于，该指令被处理器执行时实现如权利要求4-7中任一项所述方法的步骤。
补丁发放和获取方法、装置
技术领域
[0001] 本申请涉及互联网技术领域，尤其涉及补丁发放和获取方法、装置。
背景技术
[0002] 用户可以通过在智能设备上安装应用程序，可以实现相应的操作或控制功能。然而，应用程序在开发过程中往往无法兼顾到各个方面，可能会存在一些错误或新功能的添加，但不希望对该应用程序做整个版本的更新(即覆盖安装更新版本的应用程序)，此时可以通过安装补丁，相当于对原本应用程序的“修补”，即可纠正错误或实现新功能。
发明内容
[0003] 有鉴于此，本申请提供一种补丁发放和获取方法、装置，可以简化补丁的管理与维护过程，提升了补丁的传输安全性。
[0004] 为实现上述目的，本申请提供技术方案如下：
[0005] 根据本申请的第一方面，提出了一种补丁发放方法，包括：
[0006] 根据客户端发送的补丁获取请求，从补丁平台数据库中提取相应的补丁数据；
[0007] 将所述补丁数据返回所述客户端；其中，所述补丁数据包括补丁代码和与所述补丁代码对应的校验信息，以由所述客户端根据所述校验信息对所述补丁代码进行校验。
[0008] 根据本申请的第二方面，提出了一种补丁获取方法，包括：
[0009] 向服务端发送补丁获取请求；
[0010] 接收所述服务端返回的补丁数据，所述补丁数据包括补丁代码和校验信息；
[0011] 根据所述校验信息对所述补丁代码进行校验，并在通过校验的情况下执行所述补丁代码。
[0012] 根据本申请的第三方面，提出了一种补丁发放装置，包括：
[0013] 提取单元，根据客户端发送的补丁获取请求，从补丁平台数据库中提取相应的补丁数据；
[0014] 返回单元，将所述补丁数据返回所述客户端；其中，所述补丁数据包括补丁代码和与所述补丁代码对应的校验信息，以由所述客户端根据所述校验信息对所述补丁代码进行校验。
[0015] 根据本申请的第四方面，提出了一种补丁获取装置，包括：
[0016] 发送单元，向服务端发送补丁获取请求；
[0017] 接收单元，接收所述服务端返回的补丁数据，所述补丁数据包括补丁代码和校验信息；
[0018] 校验单元，根据所述校验信息对所述补丁代码进行校验，并在通过校验的情况下执行所述补丁代码。
[0019] 由以上技术方案可见，本申请通过补丁平台数据库来管理补丁数据，使得开发人员无需对补丁数据进行打包为补丁文件、无需客户端对补丁文件进行解析，还便于补丁平台数据库对补丁文件的系统类型、版本号等属性进行读取和管理。通过在补丁数据中同时包含补丁代码和校验信息，使客户端可以据此进行校验，识别出补丁来源被替代、补丁代码被篡改等风险状况，有助于提升补丁安装的安全性。
附图说明
[0020] 图1是根据本申请一示例性实施例提供的一种补丁发放方法的流程图；
[0021] 图2是根据本申请一示例性实施例提供的一种补丁获取方法的流程图；
[0022] 图3是根据本申请一示例性实施例提供的一种应用场景示意图；
[0023] 图4是根据本申请一示例性实施例提供的一种补丁数据的维护结构的示意图；
[0024] 图5A-5D是根据本申请一示例性实施例提供的一种对补丁数据进行维护的界面示意图；
[0025] 图6是根据本申请一示例性实施例提供的一种补丁发放及获取方法的流程图；
[0026] 图7是根据本申请一示例性实施例提供的一种基于服务端的电子设备的结构示意图；
[0027] 图8是根据本申请一示例性实施例提供的一种补丁发放装置的框图；
[0028] 图9是根据本申请一示例性实施例提供的一种基于服务端的电子设备的结构示意图；
[0029] 图10是根据本申请一示例性实施例提供的一种补丁获取装置的框图。
具体实施方式
[0030] 在相关技术中，开发人员需要将补丁代码等数据打包成文件形式后，将该补丁文件存储于服务器中。由于补丁文件已经过打包处理，因而服务器无法读取该补丁文件的属性信息，使得开发人员需要访问补丁文件以实现查看或编辑操作时，只能够通过从服务器中下载相应的补丁文件来实现。
[0031] 此外，当用户从服务器下载补丁文件进行安装时，相关技术中并未提供对补丁文件的校验手段，导致黑客很容易对补丁文件进行篡改等，造成严重的安全性风险。
[0032] 因此，本申请通过对补丁维护方式的改进和内容校验，以改进相关技术中存在的上述技术问题。为对本申请进行进一步说明，提供下列实施例：
[0033] 图1是根据本申请一示例性实施例提供的一种补丁发放方法的流程图，如图1所示，该方法应用于服务端(即服务器或服务器端)，可以包括以下步骤：
[0034] 步骤102，根据客户端发送的补丁获取请求，从补丁平台数据库中提取相应的补丁数据。
[0035] 在本实施例中，读取所述补丁获取请求中的系统类型信息和应用程序版本信息；从所述补丁平台数据库中提取与所述系统类型信息和所述应用程序版本信息相匹配的最新版本补丁数据。
[0036] 步骤104，将所述补丁数据返回所述客户端；其中，所述补丁数据包括补丁代码和与所述补丁代码对应的校验信息，以由所述客户端根据所述校验信息对所述补丁代码进行校验。
[0037] 在本实施例中，校验信息为经由所述补丁平台数据库处的私钥进行签名的摘要信息，所述摘要信息是根据预设摘要算法对所述补丁代码进行计算得到。通过计算补丁代码对应的摘要信息，使用于私钥签名的数据长度可控，解决了补丁代码数据过多而无法直接签名或签名效率低的问题。
[0038] 与图1所示实施例相对应地，图2是根据本申请一示例性实施例提供的一种补丁获取方法的流程图，如图2所示，该方法应用于客户端(即安装有该客户端的应用程序的终端，如电脑、手机、平板等设备)，可以包括以下步骤：
[0039] 步骤202，向服务端发送补丁获取请求。
[0040] 步骤204，接收所述服务端返回的补丁数据，所述补丁数据包括补丁代码和校验信息。
[0041] 在本实施例中，校验信息可以为经由所述补丁平台数据库处的私钥进行签名的摘要信息，所述摘要信息是根据预设摘要算法对所述补丁代码进行计算得到。
[0042] 步骤206，根据所述校验信息对所述补丁代码进行校验，并在通过校验的情况下执行所述补丁代码。
[0043] 在本实施例中，客户端可以根据所述预设摘要算法计算出所述补丁代码对应的实时摘要信息；当所述校验信息满足下述条件时，判定所述补丁代码通过了所述校验信息的校验：由本地公钥对所述校验信息进行签名解码，且得到的解码信息与所述实时摘要信息一致。在该实施例中，通过本地公钥对校验信息进行签名解码，可以验证该补丁数据的来源是否正确，即是否存在黑客通过如DNS拦截、设置代理等方式向客户端发送不安全的补丁数据；同时，通过对摘要信息的验证，可以避免补丁代码在数据传输过程中发生错误或被篡改，从而进一步确保了补丁数据的有效性和安全性。
[0044] 在本申请的技术方案中，涉及到服务端与客户端之间的交互与配合，比如图3所示，在一示例性实施例的应用场景下，服务器配置有服务端、终端上安装有作为客户端的应用程序，则服务器可以对补丁数据进行维护，而终端通过向服务器发起请求，以获取相应的补丁数据并安装。
[0045] 1、补丁维护
[0046] 服务端接收到开发人员上传的补丁代码后，通过对该补丁代码的属性读取和生成相应的校验信息后，即可生成相应的补丁数据，并建立对应的数据结构，以便于维护。
[0047] 图4为一示例性实施例的补丁维护的数据结构，该数据结构可以包括三个层次：系统类型、应用程序版本和补丁版本。
[0048] 系统类型。系统类型是指终端采用的操作系统类型，不同类型的操作系统需要采用不同类型的应用程序，相应的补丁也不相同。比如系统类型可以包括iOS、Android、Win(即Windows Phone)等。
[0049] 应用程序版本。每种系统类型下可能存在一个或多个应用程序版本，应用程序的版本更新意味着应用程序的整体更新和重新安装，需要用户重新下载整个应用程序的安装文件并更新；而如果仅为了较小错误的修正或功能添加，则往往不需要对应用程序进行版本更新，而是通过补丁的方式进行修补。不同版本之间通过版本号进行区分，比如图4所示的系统类型为iOS的情况下，存在版本号为“1.0.0”、“1.0.1”等多个版本的应用程序。
[0050] 补丁版本。同一个版本的应用程序可能存在一个或多个补丁，比如图4所示的系统类型为iOS、版本号为1.0.1的应用程序下，包括2个补丁：补丁1和补丁2。
[0051] 由于服务端采用数据库的形式对补丁数据进行维护，即开发人员在上传补丁时不会进行打包处理，使得服务端可以直接读取补丁数据的属性信息，并通过图4所示的补丁数据结构进行归类和管理。相应地，开发人员无需采用“下载”的形式，即可对数据库中的补丁数据进行访问。比如，开发人员可以通过本地浏览器向服务端发起网页访问请求，则服务端在验证了开发人员的身份和访问权限后，返回对应于所述补丁平台数据库中的补丁状况的网页数据，使本地浏览器可以生成图5A所示的系统类型管理界面；然后，开发人员可以通过该管理界面发出补丁维护指令，则服务端根据接收到的补丁维护指令，即可对补丁平台数据库进行补丁维护。
[0052] 在图5A所示的系统类型管理界面中，开发人员可以直观地查看已有的每种系统类型的补丁状况，还可以通过“新增”来添加更多的系统类型。假定开发人员点击了“iOS”对应的“进入”操作，则转入图5B所示的应用程序版本管理界面。
[0053] 在图5B所示的应用程序版本管理界面中，开发人员可以直观地查看在系统类型为iOS的情况下，已有的应用程序版本以及每个版本下已有的补丁数量；如“1.0.1”、“1.0.2”、“2.0.1”等。同时，开发人员还可以通过“新增”来添加更多的应用程序版本。假定开发人员选中了某个已有版本，则转入图5C所示的补丁管理界面。
[0054] 在图5C所示的补丁管理界面中，开发人员可以直观地查看在系统类型为iOS的情况下，每个应用程序版本下的补丁详情。比如在版本号为3.3.0的应用程序下，包括编号为1和2的两个补丁，且开发人员可以对已有的补丁进行“编辑”或“删除”等形式的管理。
[0055] 假定开发人员点击了补丁2的“编辑”操作，则转入图5D所示的补丁编辑界面，可以对“补丁描述”、“补丁代码”等进行编辑。此外，图5D中还示出了补丁的“Override(强制覆盖)”选项，当开发人员选中该选项后，客户端将强制从服务端获取该补丁并进行覆盖安装，而无论本地是否已经存在同样编号的补丁，该选项用于对已发放的补丁进行补救性的强制更正。
[0056] 由于开发人员可以直接通过如浏览器等形式，对服务端中的补丁进行访问和在线编辑等操作，无需对补丁进行下载、打包等操作，有助于简化补丁的维护和管理操作。
[0057] 2、补丁获取
[0058] 图6是根据本申请一示例性实施例提供的一种补丁发放及获取方法的流程图，如图6所示，该方法可以包括以下步骤：
[0059] 步骤602，服务端获取补丁代码。
[0060] 在本实施例中，补丁代码由开发人员生成并存储至服务端；例如，开发人员可以通过浏览器转入图5A-5D所示的管理界面，并对每种系统类型、每个应用程序版本下的补丁进行管理，包括新补丁的生成或对已有补丁的编辑等。
[0061] 步骤604，服务端计算补丁代码对应的摘要信息。
[0062] 在本实施例中，由于校验信息与补丁代码一一对应，则对于新生成的补丁代码或经过编辑后的已有补丁代码，服务端均需要重新生成对应的校验信息。
[0063] 在本实施例中，服务端可以通过如MD5等算法，计算得到补丁代码对应的摘要信息。比如当补丁代码为“Hello World”时，对应的MD5值即摘要信息为“b10a8db164e0754105b7a99be72e3fe5”。
[0064] 步骤606，服务端采用私钥对摘要信息进行签名，得到校验信息。
[0065] 在本实施例中，在服务端处保存有私钥，该私钥与客户端处的公钥之间相互匹配。通过私钥对摘要信息的签名，则客户端采用公钥对该签名进行验证时，即可识别出相应的补丁数据的来源是否确实为服务端，比如对上述的“b10a8db164e0754105b7a99be72e3fe5”摘要信息进行签名后，得到签名串为“PAzf7S/eT/IUOm7LLqXx”。
[0066] 在本实施例中，由于不同的补丁代码的长度不确定，则如果补丁代码过长，可能导致私钥进行签名的时间长、效率低，不利于服务端的补丁维护；同时，一些情况下，私钥进行签名时还存在对被签名内容的长度限制，则内容过多、长度过长的补丁代码很可能无法被有效签名。因此，本申请中通过将长度不可控的补丁代码转换为固定长度的摘要信息后，可以避免补丁代码的长度过长而无法签名或签名效率低下的问题，从而有助于服务端的补丁维护，以及客户端在后续阶段对补丁数据的安全校验。
[0067] 步骤608，服务端将补丁代码与校验信息作为补丁数据进行关联存储。
[0068] 步骤610，服务端接收到客户端发送的补丁获取请求。
[0069] 在本实施例中，客户端在检测到补丁更新需求时，可以首先遍历本地是否存在补丁数据。如果本地存在补丁数据，可以通过本地补丁数据解决所述补丁更新需求；如果本地不存在补丁数据，才通过向服务端发起补丁获取请求，以从服务端获取补丁数据。
[0070] 步骤612，服务端读取补丁获取请求中的系统类型信息和应用程序版本信息。
[0071] 步骤614，服务端从数据库中提取与系统类型信息、应用程序版本信息相匹配的补丁数据。
[0072] 在本实施例中，根据系统类型信息和应用程序版本信息，服务端可以选取相应的最新补丁并返回客户端。比如对于图5C所示的情况下，如果客户端发送的系统类型信息为iOS、应用程序版本信息为3.3.0，则服务端可以查询并返回最新的补丁2。
[0073] 步骤616，服务端向客户端返回提取的补丁数据。
[0074] 步骤618，客户端获取补丁数据中的补丁代码和校验信息。
[0075] 步骤620，客户端执行数据校验。
[0076] 在本实施例中，客户端的数据校验可以包括两个部分：
[0077] 1、签名校验。客户端处存储有公钥，该公钥与服务端处的私钥相匹配，客户端通过公钥对接收到的校验信息进行签名解码，如果成功解码得到摘要信息，则确定补丁数据来自服务端，否则说明补丁数据的来源可能存在风险，比如黑客可能通过DNS拦截等方式篡改了服务端的地址，使客户端从假的服务端获取了不安全的补丁数据。
[0078] 假定校验信息为“PAzf7S/eT/IUOm7LLqXx”，则如果顺利解码，即可得到相应的摘要信息“b10a8db164e0754105b7a99be72e3fe5”。
[0079] 2、数据篡改校验。客户端与服务端预先了解采用的摘要信息算法，比如MD5算法，则客户端通过MD5算法计算出补丁代码对应的实时摘要信息。如果补丁代码数据在传输过程中发生了缺失、篡改等情况，则实时摘要信息与“签名校验”中解码出的摘要信息必然不同，说明补丁代码存在安全风险，不应当安装；而如果补丁数据通过了签名校验和数据篡改校验，则说明补丁数据安全可靠，可以执行补丁代码来完成安装。
[0080] 换言之，如果客户端接收到的补丁代码仍然为“Hello World”，则生成的MD5值必然为“b10a8db164e0754105b7a99be72e3fe5”，与“签名校验”中解码出的摘要信息相同，从而通过校验。
[0081] 步骤622，若通过数据校验，则客户端执行补丁代码，否则不执行。
[0082] 由以上技术方案可见，本申请通过补丁平台数据库来管理补丁数据，使得开发人员无需对补丁数据进行打包为补丁文件、无需客户端对补丁文件进行解析，还便于补丁平台数据库对补丁文件的系统类型、版本号等属性进行读取和管理。通过在补丁数据中同时包含补丁代码和校验信息，使客户端可以据此进行校验，识别出补丁来源被替代、补丁代码被篡改等风险状况，有助于提升补丁安装的安全性。
[0083] 图7示出了根据本申请的一示例性实施例的电子设备的示意结构图。请参考图7，在硬件层面，该电子设备包括处理器、内部总线、网络接口、内存以及非易失性存储器，当然还可能包括其他业务所需要的硬件。处理器从非易失性存储器中读取对应的计算机程序到内存中然后运行，在逻辑层面上形成补丁发放装置。当然，除了软件实现方式之外，本申请并不排除其他实现方式，比如逻辑器件抑或软硬件结合的方式等等，也就是说以下处理流程的执行主体并不限定于各个逻辑单元，也可以是硬件或逻辑器件。
[0084] 请参考图8，在软件实施方式中，该补丁发放装置可以包括提取单元和返回单元。其中：
[0085] 提取单元，根据客户端发送的补丁获取请求，从补丁平台数据库中提取相应的补丁数据；
[0086] 返回单元，将所述补丁数据返回所述客户端；其中，所述补丁数据包括补丁代码和与所述补丁代码对应的校验信息，以由所述客户端根据所述校验信息对所述补丁代码进行校验。
[0087] 可选的，所述校验信息为经由所述补丁平台数据库处的私钥进行签名的摘要信息，所述摘要信息是根据预设摘要算法对所述补丁代码进行计算得到。
[0088] 可选的，所述提取单元具体用于：
[0089] 读取所述补丁获取请求中的系统类型信息和应用程序版本信息；
[0090] 从所述补丁平台数据库中提取与所述系统类型信息和所述应用程序版本信息相匹配的最新版本补丁数据。
[0091] 可选的，还包括：
[0092] 请求接收单元，接收网页访问请求，所述网页访问请求由开发人员通过本地浏览器发起；
[0093] 数据返回单元，返回对应于所述补丁平台数据库中的补丁状况的网页数据，以使所述本地浏览器根据所述网页数据生成对所述补丁平台数据库的管理界面；
[0094] 补丁维护单元，接收所述开发人员通过所述管理界面发送的补丁维护指令，对所述补丁平台数据库进行补丁维护。
[0095] 图9示出了根据本申请的一示例性实施例的电子设备的示意结构图。请参考图9，在硬件层面，该电子设备包括处理器、内部总线、网络接口、内存以及非易失性存储器，当然还可能包括其他业务所需要的硬件。处理器从非易失性存储器中读取对应的计算机程序到内存中然后运行，在逻辑层面上形成补丁获取装置。当然，除了软件实现方式之外，本申请并不排除其他实现方式，比如逻辑器件抑或软硬件结合的方式等等，也就是说以下处理流程的执行主体并不限定于各个逻辑单元，也可以是硬件或逻辑器件。
[0096] 请参考图10，在软件实施方式中，该补丁获取装置可以包括发送单元、接收单元和校验单元。其中：
[0097] 发送单元，向服务端发送补丁获取请求；
[0098] 接收单元，接收所述服务端返回的补丁数据，所述补丁数据包括补丁代码和校验信息；
[0099] 校验单元，根据所述校验信息对所述补丁代码进行校验，并在通过校验的情况下执行所述补丁代码。
[0100] 可选的，还包括：
[0101] 检测单元，检测是否存在补丁更新需求；
[0102] 遍历单元，当存在所述补丁更新需求时，遍历本地是否存在补丁数据；
[0103] 处理单元，当本地存在补丁数据时，通过本地补丁数据解决所述补丁更新需求；当本地不存在补丁数据时，向所述服务端发送所述补丁获取请求，以从所述服务端获取补丁数据。
[0104] 可选的，所述校验信息为经由所述补丁平台数据库处的私钥进行签名的摘要信息，所述摘要信息是根据预设摘要算法对所述补丁代码进行计算得到。
[0105] 可选的，所述校验单元具体用于：
[0106] 根据所述预设摘要算法计算出所述补丁代码对应的实时摘要信息；
[0107] 当所述校验信息满足下述条件时，判定所述补丁代码通过了所述校验信息的校验：由本地公钥对所述校验信息进行签名解码，且得到的解码信息与所述实时摘要信息一致。
[0108] 在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。
[0109] 内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。
[0110] 计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。
[0111] 还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。
[0112] 以上所述仅为本申请的较佳实施例而已，并不用以限制本申请，凡在本申请的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本申请保护的范围之内。
