数据处理方法、装置和服务器与流程

1.本说明书属于互联网金融技术领域，尤其涉及一种数据处理方法、装置和服务器。


背景技术：

2.在互联网金融技术领域，有时银行等金融机构的工作人员会通过访问机构内部网站来查询获取所关注的某些金融数据图片。而上述金融数据图片大多都是要求保密的，不允许流传到机构外部。
3.但是，基于现有的数据处理方法，往往无法有效地对上述图片进行数据保护。并且，基于现有的数据处理方法，如果图片流传到机构外部，也很难对泄露者进行溯源追踪。
4.针对上述问题，目前尚未提出有效的解决方案。


技术实现要素：

5.本说明书提供了一种数据处理方法、装置和服务器，能够高效且智能地响应用户发起的触发操作，生成并向用户展示携带有以该用户的用户信息作为水印信息的水印图片，进而可以有效地保护了图片的数据安全，使得后续即使图片遭到泄露，也能够根据水印图片的水印信息，对泄露图片的用户进行较为精准的溯源追踪。
6.本说明书实施例提供了一种数据处理方法，应用于服务器，包括：
7.接收目标用户通过用户终端发出的目标图片获取请求；其中，所述目标图片获取请求的请求头中至少包含有目标用户的用户信息；
8.根据所述目标图片获取请求，获取目标图片的图片标识，以及目标用户的用户信息；
9.根据所述目标图片的图片标识，获取目标图片；
10.调用预设的图片处理库，根据所述目标图片和目标用户的用户信息，生成目标水印图片；其中，所述目标水印图片所携带的水印信息为目标用户的用户信息；
11.将所述目标水印图片发送至用户终端。
12.在一些实施例中，所述目标图片获取请求还包含有url地址，其中，所述url地址携带有所请求的目标图片的图片标识。
13.在一些实施例中，根据所述目标图片获取请求，获取目标图片的图片标识，包括：解析所述目标图片获取请求中的url地址，以获取目标图片的图片标识。
14.在一些实施例中，所述请求头还包含有referer字段，其中，所述referer字段记载有来源页面的页面地址；所述目标用户通过在用户终端所展示的来源页面上发起针对目标图片的触发操作，以触发用户终端生成并发出所述目标图片获取请求。
15.在一些实施例中，在接收目标用户通过用户终端发起的目标图片获取请求之后，所述方法还包括：
16.从所述目标图片获取请求中提取referer字段；
17.根据所述referer字段，对所述目标图片获取请求进行风险验证。
18.在一些实施例中，在调用预设的图片处理库，根据所述目标图片和目标用户的用户信息，生成目标水印图片之后，所述方法还包括：
19.根据预设的lrd算法，将目标水印图片保存于预设的存储区域；并根据预设的lrd算法，管理预设的存储区域中所保存的水印图片。
20.在一些实施例中，根据预设的lrd算法，将目标水印图片保存于预设的存储区域，包括：
21.在预设的存储区域中保存所述目标水印图片，并记录目标水印图片的生成时间和文件大小；
22.根据所述目标水印图片的文件大小，更新预设的存储区域的文件大小。
23.在一些实施例中，根据预设的lrd算法，管理预设的存储区域中所保存的水印图片，包括：
24.在监测到预设的存储区域的文件大小发生更新的情况下，检测所述预设的存储区域的文件大小是否大于预设的触发阈值；
25.在确定所述预设的存储区域的文件大小大于预设的触发阈值的情况下，获取并根据预设的存储区域中水印图片的生成时间，确定出生成时间与当前时间差值最大的水印图片，作为超时图片；
26.删除预设的存储区域中的超时图片；并根据所述超时图片的文件大小，更新预设的存储区域的文件大小。
27.本说明书实施例还提供了一种数据处理方法，应用于用户终端，包括：
28.接收目标用户针对来源页面中的目标图片发起的触发操作；
29.响应所述触发操作，获取目标用户的用户信息；
30.将所述目标用户的用户信息添加至请求头中，以生成目标图片获取请求；
31.将所述目标图片获取请求发送至服务器。
32.在一些实施例中，获取目标用户的用户信息，包括：
33.检测用户终端所保存的cookie数据是否失效；
34.在确定所述cookie数据失效的情况下，生成预设的登录界面，以引导目标用户通过预设的登录方式重新登录；并将目标用户在重新登录时提供的用户信息保存于cookie数据中；
35.从所述cookie数据中提取目标用户的用户信息。
36.在一些实施例中，所述预设的登录方式包括扫码登录，或，基于手机验证码登录。
37.在一些实施例中，将所述目标图片获取请求发送至服务器之后，所述方法还包括：
38.接收服务器反馈的目标水印图片；
39.将所述目标水印图片保存于本地缓存中，并记录目标水印图片的目标图片的图片标识和目标用户的用户信息。
40.在一些实施例中，在生成目标图片获取请求之后，所述方法还包括：
41.根据所述目标图片获取请求，获取目标图片的图片标识和目标用户的用户信息；
42.根据所述目标图片的图片标识和目标用户的用户信息，检索本地缓存，以确定是否存在相匹配的目标水印图片；
43.在确定本地缓存中存在相匹配的目标水印图片的情况下，从所述本地缓存获取目
标水印图片。
44.本书明书实施例还提供了一种数据处理装置，包括：
45.接收模块，用于接收目标用户通过用户终端发出的目标图片获取请求；其中，所述目标图片获取请求的请求头中至少包含有目标用户的用户信息；
46.第一获取模块，用于根据所述目标图片获取请求，获取目标图片的图片标识，以及目标用户的用户信息；
47.第二获取模块，用于根据所述目标图片的图片标识，获取目标图片；
48.生成模块，用于调用预设的图片处理库，根据所述目标图片和目标用户的用户信息，生成目标水印图片；其中，所述目标水印图片所携带的水印信息为目标用户的用户信息；
49.发送模块，用于将所述目标水印图片发送至用户终端。
50.本书明书实施例还提供了一种数据处理装置，包括：
51.接收模块，用于接收目标用户针对来源页面中的目标图片发起的触发操作；
52.获取模块，用于响应所述触发操作，获取目标用户的用户信息；
53.生成模块，用于将所述目标用户的用户信息添加至请求头中，以生成目标图片获取请求；
54.发送模块，用于将所述目标图片获取请求发送至服务器。
55.本说明书实施例还提供了一种服务器，包括处理器以及用于存储处理器可执行指令的存储器，所述处理器执行所述指令时实现以下内容：接收目标用户通过用户终端发出的目标图片获取请求；其中，所述目标图片获取请求的请求头中至少包含有目标用户的用户信息；根据所述目标图片获取请求，获取目标图片的图片标识，以及目标用户的用户信息；根据所述目标图片的图片标识，获取目标图片；调用预设的图片处理库，根据所述目标图片和目标用户的用户信息，生成目标水印图片；其中，所述目标水印图片所携带的水印信息为目标用户的用户信息；将所述目标水印图片发送至用户终端。
56.本说明书实施例还提供了一种计算机可读存储介质，其上存储有计算机指令，所述指令被执行时实现：接收目标用户通过用户终端发出的目标图片获取请求；其中，所述目标图片获取请求的请求头中至少包含有目标用户的用户信息；根据所述目标图片获取请求，获取目标图片的图片标识，以及目标用户的用户信息；根据所述目标图片的图片标识，获取目标图片；调用预设的图片处理库，根据所述目标图片和目标用户的用户信息，生成目标水印图片；其中，所述目标水印图片所携带的水印信息为目标用户的用户信息；将所述目标水印图片发送至用户终端。
57.本说明书提供的一种数据处理方法、装置和服务器，基于该方法，用户终端在响应目标用户针对网站的来源页面中的目标图片发起的触发操作时，会先获取该目标用户的用户信息，并将用户信息添加到请求头中，以生成携带有目标用户的用户信息的目标图片获取请求；再将该目标图片获取请求发送至服务器；相应的，服务器可以根据目标图片获取请求先获取所请求的目标图片的图片标识，以及目标用户的用户信息；并根据目标图片的图片标识获取所请求的目标图片；同时，还会调用预设的图片处理库，根据目标图片和目标用户的用户信息，生成携带有以目标用户的用户信息作为水印信息的目标水印图片；再将该目标水印图片发送至用户终端，展示给目标用户。从而可以高效且智能地响应用户发起的
触发操作，生成并向用户展示出携带有以该用户的用户信息作为水印信息的水印图片，这样可以有效地保护图片的数据安全，使得后续即使图片遭到泄露，也能够根据水印图片的水印信息，对泄露图片的用户进行较为精准的溯源追踪，降低了图片遭泄露的风险。
附图说明
58.为了更清楚地说明本说明书实施例，下面将对实施例中所需要使用的附图作简单地介绍，下面描述中的附图仅仅是本说明书中记载的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
59.图1是本说明书的一个实施例提供的数据处理方法的流程示意图；
60.图2是在一个场景示例中，应用本说明书实施例提供的数据处理方法的一种实施例的示意图；
61.图3是在一个场景示例中，应用本说明书实施例提供的数据处理方法的一种实施例的示意图；
62.图4是本说明书的一个实施例提供的数据处理方法的流程示意图；
63.图5是本说明书的一个实施例提供的服务器的结构组成示意图；
64.图6是本说明书的一个实施例提供的数据处理装置的结构组成示意图；
65.图7是本说明书的一个实施例提供的数据处理装置的结构组成示意图；
66.图8是在一个场景示例中，应用本说明书实施例提供的数据处理方法的一种实施例的示意图；
67.图9是在一个场景示例中，应用本说明书实施例提供的数据处理方法的一种实施例的示意图；
68.图10是在一个场景示例中，应用本说明书实施例提供的数据处理方法的一种实施例的示意图；
69.图11是在一个场景示例中，应用本说明书实施例提供的数据处理方法的一种实施例的示意图；
70.图12是在一个场景示例中，应用本说明书实施例提供的数据处理方法的一种实施例的示意图；
71.图13是在一个场景示例中，应用本说明书实施例提供的数据处理方法的一种实施例的示意图；
72.图14是在一个场景示例中，应用本说明书实施例提供的数据处理方法的一种实施例的示意图；
73.图15是在一个场景示例中，应用本说明书实施例提供的数据处理方法的一种实施例的示意图；
74.图16是在一个场景示例中，应用本说明书实施例提供的数据处理方法的一种实施例的示意图；
75.图17是在一个场景示例中，应用本说明书实施例提供的数据处理方法的一种实施例的示意图。
具体实施方式
76.为了使本技术领域的人员更好地理解本说明书中的技术方案，下面将结合本说明书实施例中的附图，对本说明书实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本说明书一部分实施例，而不是全部的实施例。基于本说明书中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都应当属于本说明书保护的范围。
77.参阅图1所示，本说明书实施例提供了一种数据处理方法，其中，该方法具体应用于服务器一侧。具体实施时，该方法可以包括以下内容：
78.s101：接收目标用户通过用户终端发出的目标图片获取请求；其中，所述目标图片获取请求的请求头中至少包含有目标用户的用户信息；
79.s102：根据所述目标图片获取请求，获取目标图片的图片标识，以及目标用户的用户信息；
80.s103：根据所述目标图片的图片标识，获取目标图片；
81.s104：调用预设的图片处理库，根据所述目标图片和目标用户的用户信息，生成目标水印图片；其中，所述目标水印图片所携带的水印信息为目标用户的用户信息；
82.s105：将所述目标水印图片发送至用户终端。
83.通过上述实施例，可以高效且智能地响应用户在用户终端所展示的来源页面上针对目标图片所发起的触发操作，生成并向用户展示携带有以该用户的用户信息作为水印信息的水印图片，从而可以有效地保护了图片的数据安全，使得后续即使图片遭到泄露，也能够根据水印图片的水印信息，对泄露图片的用户进行较为精准的溯源追踪，降低了图片遭泄露的风险。
84.在一些实施例中，上述数据处理方法具体可以应用于某网站的服务器一侧。其中，所述服务器具体可以包括一种应用于网络平台一侧，能够实现数据传输、数据处理等功能的后台服务器或云端服务器。具体的，所述服务器例如可以为一个具有数据运算、存储功能以及网络交互功能的电子设备。或者，所述服务器也可以为运行于该电子设备中，为数据处理、存储和网络交互提供支持的软件程序。在本实施例中，并不具体限定所述服务器所包含的服务器数量。所述服务器具体可以为一个服务器，也可以为几个服务器，或者，由若干服务器形成的服务器集群。
85.在一些实施例中，上述目标图片获取请求具体可以理解为一种请求获取目标图片的请求数据。上述目标图片具体可以是指目标用户所请求获取的图片。其中，上述目标图片具体可以是一种网站上的页面图片，也可以是存储于服务器的资料图片等等。
86.具体的，上述目标图片可以是某金融机构内部网站上的涉及金融数据，且要求保密、不允许外传的图片数据。上述目标图片也可以是某教育机构内部网站上的涉及学生信息数据，且要求保密、不允许外传的图片数据。上述目标图片还可以是某服务机构内部网站上的涉及客户隐私数据，且要求保密、不允许外传的图片数据等等。
87.在一些实施例中，目标用户可以使用用户终端浏览某网站(可以记为目标网站)的某页面(可以记为来源页面)。当目标用户需要获取该来源页面上的某个具体目标图片时，可以对该来源页面上的目标图片发起触发操作，例如，点击来源页面上的用于指示目标图片的小图标。用户终端会响应上述触发操作，生成并向服务器发送相关的目标图片获取请
求。
88.其中，上述用户终端具体可以包括一种应用于用户一侧，能够实现数据采集、数据传输等功能的客户端。具体的，所述用户终端例如可以为台式电脑、平板电脑、笔记本电脑、智能手机等电子设备。或者，所述用户终端也可以为能够运行于上述电子设备中的软件应用。例如，可以是在智能手机上运行的某浏览器app等。
89.在一些实施例中，所述目标图片获取请求具体可以是一种get请求(或者http请求)。其中，上述目标图片获取请求至少包含有请求头这一结构。可以参阅图2所示，具体的，在上述请求头中至少可以包含有目标用户的用户信息。
90.其中，上述目标用户的用户信息具体可以理解为一种能够指示目标用户的身份信息。具体的，上述目标用户的用户信息可以包括以下至少之一：目标用户的用户名、目标用户的注册手机号、目标用户的身份id、目标用户的账户编号等等。当然，需要说明的是，上述所列举的目标用户的用户信息只是一种示意性说明。具体实施时，根据具体情况和处理需求，上述目标用户的用户信息还可以包括其他类型的信息。对此，本说明书不作限定。
91.在一些实施例中，参阅图2所示，所述目标图片获取请求具体还可以包含有url地址(或者称请求url)，其中，所述url地址具体可以携带有所请求的目标图片的图片标识。
92.上述目标图片的图片标识具体可以理解为一种用于指示所请求的目标图片的标识信息。具体的，上述目标图片的图片标识具体可以包括以下至少之一：目标图片的图片名、目标图片的图片编号、目标图片的存储地址等等。
93.通过上述实施例，可以利用目标图片获取请求中的url地址来携带所请求的目标图片的图片标识。
94.在一些实施例中，上述根据所述目标图片获取请求，获取目标图片的图片标识，具体实施时，可以包括以下内容：解析所述目标图片获取请求中的url地址，以获取目标图片的图片标识。
95.通过上述实施例，可以通过对目标图片获取请求中的url地址结构进行针对性的解析处理，以高效地提取出目标图片的图片标识。
96.在一些实施例中，上述根据所述目标图片获取请求，获取目标用户的用户信息，具体实施时，可以包括以下内容：在所述目标图片获取请求中定位出请求头；对所述请求头进行关键字段检索，以提取出目标用户的用户信息。
97.在一些实施例中，上述目标获取请求进一步还可以包含有响应头等结构。
98.在一些实施例中，参阅图3所示，所述请求头具体还可以包含有referer字段。其中，所述referer字段具体可以记载有来源页面的页面地址。具体实施时，所述目标用户可以通过在用户终端所展示的来源页面上发起触发操作，以生成并发出所述目标图片获取请求。
99.通过上述实施例，可以利用目标获取请求的请求头中的referer字段来携带来源页面的页面地址。
100.在一些实施例中，在接收目标用户通过用户终端发起的目标图片获取请求之后，所述方法具体实施时，还可以包括以下内容：从所述目标图片获取请求中提取referer字段；根据所述referer字段，对所述目标图片获取请求进行风险验证。
101.具体实施时，服务器可以从目标图片获取请求的请求头中检索并提取出referer
字段；同时，服务器还可以通过解析目标图片获取请求，得到该目标图片获取请求的发起地址；然后服务器可以将referer字段记载的来源页面的页面地址，与目标图片获取请求的发起地址进行比较，以对该目标图片获取请求进行相应的风险验证。
102.具体的，如果确定两个地址一致，则确定验证通过，进而可以触发进行后续的数据数据处理。相反，如果确定两个地址不一致，则确定验证不通过，进而可以暂停后续的数据处理，并生成风险提示信息，以提示该目标图片获取请求存在风险。
103.通过上述实施例，服务器可以较为准确、有效地识别并防止非法用户跨站伪造请求，消除相应的数据风险，从而更好地保护数据安全。
104.在一些实施例中，上述调用预设的图片处理库，根据所述目标图片和目标用户的用户信息，生成目标水印图片，具体实施时，可以包括以下内容：将目标图片的图片数据读取到预设的图片处理库中的gm函数中。根据预设的设置规则，自动进行如下参数设置：设置文字水印字体库(font)；设置文字水印的字体大小(font size)；设置文字水印的颜色。再根据上述设置和gm函数中的图片信息，基于预设的图片处理库，在目标图片上的预设位置处绘制以目标用户的用户信息作为水印信息的水印文字。从而可以得到携带有以目标用户的用户信息作为水印信息的水印图片。
105.具体的，可以基于预设的图片处理库，利用以下指令在目标图片上的预设位置处绘制水印文字：drawtext(x，y，content)。其中，x和y分别表示设置水印文字的预设位置的横坐标和纵坐标，content表示水印信息，具体可以是目标用户的用户信息。
106.其中，上述预设位置具体可以为目标图片上的不对图片的主要内容造成遮挡的位置。具体的，例如，可以是位于目标图片上的左下角位置。
107.在一些实施例中，在调用预设的图片处理库，根据所述目标图片和目标用户的用户信息，生成目标水印图片之后，所述方法具体实施时，还可以包括以下内容：根据预设的lrd算法，将目标水印图片保存于预设的存储区域；并根据预设的lrd算法，管理预设的存储区域中所保存的水印图片。
108.其中，上述预设的lrd算法具体可以是指一种基于lrd(least recently downloaded)数据结构的，用于保存和管理数据的算法模型。
109.上述预设的存储区域具体可以是位于服务器中的名称为“saved_files”的文件夹。预设的lrd算法负责具体执行述预设的存储区域中的水印图片的保存和管理。
110.具体的，基于上述预设的lrd算法，可以利用total_size字段来记录预设的存储区域的文件大小；利用key字段来记录保存于预设的存储区域中的各个水印图片的图片属性，包括：各个水印图片的生成时间(例如，key_time字段)、文件大小(例如，key_size字段)、存储路径(例如，key_path字段)等。进一步，基于预设的lrd算法可以根据预设的存储区域中所保存的各个水印图片的key_size字段，来确定并根据total_size字段。
111.通过上述实施例，引入并利用预设的lrd算法，可以充分且合理地利用服务器的存储资源对所生成的水印图片进行保存和管理。
112.在一些实施例中，上述根据预设的lrd算法，将目标水印图片保存于预设的存储区域，具体实施时，可以包括以下内容：在预设的存储区域中保存所述目标水印图片，并记录目标水印图片的生成时间和文件大小；根据所述目标水印图片的文件大小，更新预设的存储区域的文件大小。
113.此外，根据预设的lrd算法在预设的存储区域中保存目标水印图片的同时，还会一并保存下关于该目标水印图片的目标图片的图片标识和目标用户的用户信息。
114.通过上述实施例，利用预设的lrd算法可以将服务器新生成的水印图片有序、合理地保存于预设的存储区域中，进而后续如果接收到相同用户针对相同图片的获取请求，可以不需要再重新生成相应的水印图片，可以直接从预设的存储区域中所保存的已有的水印图片反馈给用户，降低了服务器侧的数据处理量，也提高了数据处理效率。
115.在一些实施例中，上述根据预设的lrd算法，管理预设的存储区域中所保存的水印图片，具体实施时，可以包括以下内容：
116.s1：在监测到预设的存储区域的文件大小发生更新的情况下，检测所述预设的存储区域的文件大小是否大于预设的触发阈值；
117.s2：在确定所述预设的存储区域的文件大小大于预设的触发阈值的情况下，获取并根据预设的存储区域中水印图片的生成时间，确定出生成时间与当前时间差值最大的水印图片，作为超时图片；
118.s3：删除预设的存储区域中的超时图片；并根据所述超时图片的文件大小，更新预设的存储区域的文件大小。
119.通过上述实施例，可以利用预设的lrd算法在监测到预设的存储区域所保存的水印图片的文件大小过大的情况下，自动且智能地筛选出生成时间相对较早、相对更有可能已经失效的水印图片作为超时图片，并及时进行地删除上述超时图片。从而可以智能地对预设的存储区域中所保存的水印图片进行删除和管理，避免预设的存储区域占用服务器过多的存储资源。
120.在一些实施例中，上述预设的触发阈值具体可以为20g。当然，上述所列举的预设的触发阈值只是一种示意性说明。具体实施时，可以根据具体情况和服务器的有效存储空间，灵活设置上述预设的触发阈值。对此，本说明书不作限定。
121.在一些实施例中，具体实施时，在确定所述预设的存储区域的文件大小大于预设的触发阈值的情况下，基于预设的lrd算法，可以将预设的存储区域中所保存的水印图片按照生成时间由早到晚的顺序进行排序操作，并优先对排序靠前的预设数量的水印图片进行删除操作。
122.在每完成一次删除操作后，基于预设的lrd算法可以根据本次被删除的超时图片的文件大小，计算并更新预设的存储区域的文件大小；并将更新后的预设的存储区的文件大小与预设的触发阈值进行比较。如果更新后的预设的存储区域的文件大小仍然大于预设的触发阈值则重复上述过程，继续进行上述的排序操作和删除操作。如果更新后的预设的存储区域的文件大小已经小于或等于预设的触发阈值，则暂停上述的排序操作和删除操作。
123.在一些实施例中，服务器可以将上述目标水印图片发送至用户终端。相应的，用户终端可以通过显示屏等结构向目标用户展示出上述携带该目标用户的用户信息作为水印信息的目标水印图片。
124.在这种情况下，当目标用户采用违规操作(例如，截屏、拍照等)违规获取目标图片，并将该目标图片泄露出去时，所泄露的目标图片上势必会携带有水印信息，而该水印信息正是目标用户的用户信息。相应的，服务器可以根据目标图片上所携带的水印信息获取
目标用户的用户信息；进而根据该目标用户的用户信息，精准地确定出泄露该目标图片的目标用户，并对该目标用户进行相应处理。从而可以有效地实现对泄露图片的用户进行较为精准的溯源追踪，降低了图片遭泄露的风险。
125.由上可见，基于本说明书实施例提供的数据处理方法，用户终端在响应目标用户针对来源页面中的目标图片发起的触发操作时，会先获取该目标用户的用户信息，并将用户信息添加到请求头中，以生成相应的目标图片获取请求；再将该目标图片获取请求发送至服务器；相应的，服务器可以根据目标图片获取请求先获取所请求的目标图片的图片标识，以及目标用户的用户信息；并根据目标图片的图片标识获取相应的目标图片；同时，还会调用预设的图片处理库，根据目标图片和目标用户的用户信息，生成携带有以目标用户的用户信息作为水印信息的目标水印图片；再将该目标水印图片发送至用户终端，以展示给目标用户。从而可以高效且智能地响应用户发起的触发操作，生成并向用户展示携带有以该用户的用户信息作为水印信息的水印图片，进而可以有效地保护了图片的数据安全，使得后续即使图片遭到泄露，也能够根据水印图片的水印信息，对泄露图片的用户进行较为精准的溯源追踪，降低了图片遭泄露的风险。
126.参阅图4所示，本说明书实施例还提供了另一种数据处理方法。其中，该方法应用于用户终端一侧，具体实施时，可以包括以下内容：
127.s401：获取第一数据和与所述第一数据关联的第二数据，并将所述第二数据存储至缓存中接收目标用户针对来源页面中的目标图片发起的触发操作；
128.s402：响应所述触发操作，获取目标用户的用户信息；
129.s403：将所述目标用户的用户信息添加至请求头中，以生成目标图片获取请求；
130.s404：将所述目标图片获取请求发送至服务器。
131.通过上述实施例，目标用户在需要获取目标图片时，可以通过用户终端进行较为简单的操作，就能高效地生成并向服务器发送包含有该目标用户的用户信息的目标图片获取请求，以便服务器可以响应并根据该目标图片获取请求生成并反馈对应的携带有目标用户的用户信息作为水印信息的目标水印图片。
132.在一些实施例中，上述获取目标用户的用户信息，具体实施时，可以包括以下内容：
133.s1：检测用户终端所保存的cookie数据是否失效；
134.s2：在确定所述cookie数据失效的情况下，生成预设的登录界面，以引导目标用户通过预设的登录方式重新登录；并将目标用户在重新登录时提供的用户信息保存于cookie数据中；
135.s3：从所述cookie数据中提取目标用户的用户信息。
136.通过上述实施例，可以有效地避免风险用户利用目标用户保存在coolie数据中的用户信息，以目标用户的名义获取目标图片，从而可以进一步保护图片的数据安全。
137.在一些实施例中，预设的登录方式具体可以为一种非免密登录的，安全度较高的登录方式。具体的，上述预设的登录方式可以包括扫码登录，或，基于手机验证码登录等。当然，上述所列举的预设的登录方式只是一种示意性说明。具体实施时，根据具体的应用场景和安全性要求，上述预设的登录方式还可以包括其他类型的登录方式，例如，人脸扫描登录或指纹验证登录等等。
138.通过上述实施例，使用预设的登录方式来引导目标用户重新登录，可以有效地避免风险用户使用免密登录的漏洞，以目标用户的名义登录，从而可以更好地保护数据安全。
139.在一些实施例中，上述cookie数据具体可以为用户终端(例如，用于访问目标网站的浏览器登)上的cookie数据。通常在目标用户成功通过预设的登录方式成功登录目标网站时，会获取目标用户在登录时使用的用户信息，并将上述用户信息保存在cookie数据中，以便后续可以重复使用。
140.在一些实施例中，上述cookie数据中的配置字段expire/max
‑
age字段预先可以通过配置有预设的有效期字段，例如“session”，来设置cookie数据的有效期。自用户通过预设的登录方式成功登录，并将该用户的用户信息保存至cookie数据之后，用户终端会开始自动计时，计算累计时长。
141.在上述累计时长属于有效期的情况下，cookie数据处于有效状态，这时当用户再次通过用户终端发起触发操作时，用户终端可以直接从cookie数据中获取该用户的用户信息，不需要用户再通过预设的登录方式进行重新登录，从而可以简化用户侧的操作。
142.相反，在上述累计时长超过有效的情况下，cookie数据处于失效状态，这时当用户再次通过用户终端发起触发操作时，用户终端无法直接从cookie数据获取用户的用户信息，需要用户通过预设的登录方式进行重新登录，才能获取用户在重新登录时所使用的用户信息，从而可以保护数据安全。
143.在一些实施例中，在将所述目标图片获取请求发送至服务器之后，所述方法具体实施时，还可以包括以下内容：
144.s1：接收服务器反馈的目标水印图片；
145.s2：将所述目标水印图片保存于本地缓存中，并记录目标水印图片的目标图片的图片标识和目标用户的用户信息。
146.通过上述实施例，用户终端在接收到服务器所提供的携带有用户信息作为水印信息的目标水印图片之后，除了向目标用户展示出该目标水印图片外，还可以将该目标水印图片保存在用户终端的本地缓存，以便后续目标用户重新获取相同的目标图片时，不需要再请求服务器重新生成相同的目标水印图片，而可以直接使用之前保存在本地缓存中的目标水印图片。从而可以有效地减少服务器侧的数据处理负担，提高整体的数据处理效率。
147.在一些实施例中，在将目标水印图片保存于本地缓存中的同时，还会记录关于该目标水印图片的目标图片的图片标识和目标用户的用户信息，并建立该目标水印图片与目标图片的图片标识和目标用户的用户信息组合的对应关系。
148.相应的，在生成目标图片获取请求之后，所述方法具体实施时，还可以包括以下内容：
149.s1：根据所述目标图片获取请求，获取目标图片的图片标识和目标用户的用户信息；
150.s2：根据所述目标图片的图片标识和目标用户的用户信息，检索本地缓存，以确定是否存在相匹配的目标水印图片；
151.s3：在确定本地缓存中存在相匹配的目标水印图片的情况下，从所述本地缓存获取目标水印图片。
152.通过上述实施例，当同一个目标用户请求获取之前已经请求过的相同的目标图片
时，用户终端可以不需要请求服务器重新生成对应的目标水印图片，而是可以根据目标图片获取请求中所包含的目标图片的图片标识和目标用户的用户信息，在本地缓存所保存的已有水印图片中进行检索，找出与目标图片的图片标识和目标用户的用户信息对应的水印图片，作为所请求的目标水印图片，直接展示给目标用户。从而可以进一步减轻服务器的数据处理负担，进一步提高数据处理效率。
153.在一些实施例中，本地缓存中所保存的水印图片配置有有效期。自水印图片保存在本地缓存时候起，开始计时，得到累计时长。当累计时长超过有效期时，用户终端可以根据失效的水印图片的目标图片的图片标识和目标用户的用户信息，自动生成一个包含有上述图片标识和用户信息的目标图片更新请求，并将该目标图片更新请求发送至服务器。服务器可以响应该目标图片更新请求重新生成针对该图片标识和用户信息的新的一个目标水印图片，反馈给用户终端。用户终端可以根据该新的目标水印图片，更新本地缓存中所保存的失效的水印图片。
154.由上可见，本说明书实施例提供的数据处理方法，可以有效地简化用户侧的操作，高效地生成包含有目标用户的用户信息和目标图片的图片标识的目标图片获取请求，并将该目标图片获取请求发送至服务器，以获取携带有以目标用户的用户信息作为水印信息的目标水印图片，从而可以有效地保护了图片的数据安全，使得后续即使图片遭到泄露，也能够根据水印图片的水印信息，对泄露图片的用户进行较为精准的溯源追踪，降低了图片遭泄露的风险。
155.本说明书实施例还提供一种服务器，包括处理器以及用于存储处理器可执行指令的存储器，所述处理器具体实施时可以根据指令执行以下步骤：接收目标用户通过用户终端发出的目标图片获取请求；其中，所述目标图片获取请求的请求头中至少包含有目标用户的用户信息；根据所述目标图片获取请求，获取目标图片的图片标识，以及目标用户的用户信息；根据所述目标图片的图片标识，获取目标图片；调用预设的图片处理库，根据所述目标图片和目标用户的用户信息，生成目标水印图片；其中，所述目标水印图片所携带的水印信息为目标用户的用户信息；将所述目标水印图片发送至用户终端。
156.为了能够更加准确地完成上述指令，参阅图5所示，本说明书实施例还提供了另一种具体的服务器，其中，所述服务器包括网络通信端口501、处理器502以及存储器503，上述结构通过内部线缆相连，以便各个结构可以进行具体的数据交互。
157.其中，所述网络通信端口501，具体可以用于接收目标用户通过用户终端发出的目标图片获取请求；其中，所述目标图片获取请求的请求头中至少包含有目标用户的用户信息。
158.所述处理器502，具体可以用于根据所述目标图片获取请求，获取目标图片的图片标识，以及目标用户的用户信息；根据所述目标图片的图片标识，获取目标图片；调用预设的图片处理库，根据所述目标图片和目标用户的用户信息，生成目标水印图片；其中，所述目标水印图片所携带的水印信息为目标用户的用户信息；将所述目标水印图片发送至用户终端。
159.所述存储器503，具体可以用于存储相应的指令程序。
160.在本实施例中，所述网络通信端口501可以是与不同的通信协议进行绑定，从而可以发送或接收不同数据的虚拟端口。例如，所述网络通信端口可以是负责进行web数据通信
的端口，也可以是负责进行ftp数据通信的端口，还可以是负责进行邮件数据通信的端口。此外，所述网络通信端口还可以是实体的通信接口或者通信芯片。例如，其可以为无线移动网络通信芯片，如gsm、cdma等；其还可以为wifi芯片；其还可以为蓝牙芯片。
161.在本实施例中，所述处理器502可以按任何适当的方式实现。例如，处理器可以采取例如微处理器或处理器以及存储可由该(微)处理器执行的计算机可读程序代码(例如软件或固件)的计算机可读介质、逻辑门、开关、专用集成电路(application specific integrated circuit，asic)、可编程逻辑控制器和嵌入微控制器的形式等等。本说明书并不作限定。
162.在本实施例中，所述存储器503可以包括多个层次，在数字系统中，只要能保存二进制数据的都可以是存储器；在集成电路中，一个没有实物形式的具有存储功能的电路也叫存储器，如ram、fifo等；在系统中，具有实物形式的存储设备也叫存储器，如内存条、tf卡等。
163.本说明书实施例还提供了一种基于上述数据处理方法的计算机可读存储介质，所述计算机可读存储介质存储有计算机程序指令，在所述计算机程序指令被执行时实现：接收目标用户通过用户终端发出的目标图片获取请求；其中，所述目标图片获取请求的请求头中至少包含有目标用户的用户信息；根据所述目标图片获取请求，获取目标图片的图片标识，以及目标用户的用户信息；根据所述目标图片的图片标识，获取目标图片；调用预设的图片处理库，根据所述目标图片和目标用户的用户信息，生成目标水印图片；其中，所述目标水印图片所携带的水印信息为目标用户的用户信息；将所述目标水印图片发送至用户终端。
164.在本实施例中，上述存储介质包括但不限于随机存取存储器(random access memory,ram)、只读存储器(read
‑
only memory,rom)、缓存(cache)、硬盘(hard disk drive,hdd)或者存储卡(memory card)。所述存储器可以用于存储计算机程序指令。网络通信单元可以是依照通信协议规定的标准设置的，用于进行网络连接通信的接口。
165.在本实施例中，该计算机可读存储介质存储的程序指令具体实现的功能和效果，可以与其它实施方式对照解释，在此不再赘述。
166.参阅图6所示，在软件层面上，本说明书实施例还提供了一种数据处理装置，该装置具体可以包括以下的结构模块：
167.接收模块601，具体可以用于接收目标用户通过用户终端发出的目标图片获取请求；其中，所述目标图片获取请求的请求头中至少包含有目标用户的用户信息；
168.第一获取模块602，具体可以用于根据所述目标图片获取请求，获取目标图片的图片标识，以及目标用户的用户信息；
169.第二获取模块603，具体可以用于根据所述目标图片的图片标识，获取目标图片；
170.生成模块604，具体可以用于调用预设的图片处理库，根据所述目标图片和目标用户的用户信息，生成目标水印图片；其中，所述目标水印图片所携带的水印信息为目标用户的用户信息；
171.发送模块605，具体可以用于将所述目标水印图片发送至用户终端。
172.需要说明的是，上述实施例阐明的单元、装置或模块等，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。为了描述的方便，描述以上装置时以功能分
为各种模块分别描述。当然，在实施本说明书时可以把各模块的功能在同一个或多个软件和/或硬件中实现，也可以将实现同一功能的模块由多个子模块或子单元的组合实现等。以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
173.参阅图7所示，在软件层面上，本说明书实施例还提供了另一种数据处理装置，该装置具体可以包括以下的结构模块：
174.接收模块701，具体可以用于接收目标用户针对来源页面中的目标图片发起的触发操作；
175.获取模块702，具体可以用于响应所述触发操作，获取目标用户的用户信息；
176.生成模块703，具体可以用于将所述目标用户的用户信息添加至请求头中，以生成目标图片获取请求；
177.发送模块704，具体可以用于将所述目标图片获取请求发送至服务器。
178.由上可见，基于本说明书实施例提供的数据处理装置，可以高效且智能地响应用户发起的触发操作，生成并向用户展示携带有以该用户的用户信息作为水印信息的水印图片，进而可以有效地保护了图片的数据安全，使得后续即使图片遭到泄露，也能够根据水印图片的水印信息，对泄露图片的用户进行较为精准的溯源追踪，降低了图片遭泄露的风险。
179.在一个具体的场景示例中，可以应用本说明书实施例提供的数据处理方法实现自动对图片添加文字水印(例如，水印信息)，并将用户信息以文字水印的形式添加到图片上，同时还可以实现用户信息防篡改、水印图片缓存配置和水印图片删除算法，以提升用户加载水印图片(例如，目标水印图片)的处理性能，减少图片泄露风险，保护企业图片版权。具体实施过程可以包括以下内容。
180.在本场景示例中，考虑到网站获取图片的图片请求(例如，目标图片获取请求)都是get请求，并且通常图片请求中一般都没有其他参数信息(例如，用户信息)，即网站直接请求某个图片。而在本场景示例中，目标是要给图片添加用户信息作为水印信息，例如，用户姓名和用户id等。因此，图片请求中需要包含有用户信息。考虑到http请求通常包括请求头和请求体两部分。其中，请求头通常说明本请求接收格式、编码格式等信息，请求体一般为本次请求的数据。而针对一个图片的图片请求通常只有请求头，没有请求体。因此，可以将用户信息等数据需要放在请求头中。
181.其中，上述请求头可以通过cookie(例如，cookie数据)机制获取并携带用户信息。但是，又考虑到cookie信息容易被篡改，因此，还可以进一步采用以下措施来防止用户信息被篡改。
182.具体的，用户登录网站方式通常可以分为密码登录、手机验证码登录和手机扫码登录。其中，密码登录的账号为用户注册时的账户，注册账户一般为英语或者邮箱，密码登录一般可以保存密码，后续登录时可以免密登录。
183.使用免登陆的好处是用户非首次登录(如上图间隔时间内登录)，不需要输入密码，当用户输入账户名称内容后，浏览器根据之前用户输入的密码内容自动填充到密码框，
用户登录操作更加快速，提升用户体验。
184.但是，在需要保护图片内容的场合使用免密登录显然是不合适的。例如，用户a使用自己的电脑或者公共电脑(用户终端)登录网站，此时密码在一段时间内有效，若用户b使用用户a的电脑或者公共电脑登录网站，此时可以使用用户a的账号登录成功，若用户b对图片保存到本地或者对图片拍照外传的造成图片泄露，这样势必会对网站信息泄露的溯源会造成很大的难度。
185.在本场景示例中，对用户登录方式的限制为手机验证码或者手机扫码登录(预设的登录方式)；并且登录成功后，服务端(例如，服务器)可以将用户的信息(用户名和用户id)返回在请求的响应头的cookie中，浏览器将用户信息保存在cookie中。当网站请求图片时会自动携带cookie信息(里面包括用户信息，如用户姓名和用户id)。
186.其中，参阅图8所示，所采用的手机验证码登录流程具体可以包括以下步骤：
187.(1)用户输入手机号，并获取短信验证码；
188.(2)服务端检测手机号是否注册，若手机号已经注册服务端生成短信验证码：使用random对象生成随机4位或6位的数字串，这个数字串就是短信验证码；
189.(3)服务端将手机号、验证码、创建时间存入服务端redis缓存；
190.(4)服务端调用短信平台接口发送验证码短信到用户的手机；
191.(5)用户收到短信后填写验证码，并提交登录表单；
192.(6)服务端对比用户提交的验证码与redis中的验证码是否一致，同时判断提交动作是否在有效期内；
193.(7)验证码正确且在有效期内，登录请求成功，在响应头中的cookie中写入用户姓名和用户id信息。
194.在本场景示例中，cookie中可以配置expire/max
‑
age字段配置用户信息有效期。具体的，可以将expire/max
‑
age配置为“session”，表示cookie会和session一起失效，当浏览器关闭(关闭整个浏览器，而不是浏览器的标签页)后，此时cookie失效。设置为“session”的好处是当用户关闭浏览器时cookie自动失效，防止后续登录操作时之前用户信息还有效。同时将cookie的http only属性设置为true，因此通过javascript脚本将无法读取和修改到cookie信息，这样能有效的防止用户信息的篡改，增加了cookie的安全性。其中，cookie配置用户姓名和用户id可以参阅图9所示。
195.在本场景示例中，在http协议的请求头中有一个字段是referer(例如，referer字段)。其中，referer包含了当前请求页面的来源页面的地址，用于表示当前页面是通过此来源页面里的链接进入的。服务端可以先通过解析referer请求头信息识别访问来源，对于非指定来源服务端不做处理，这个主要用来防止非法用户跨站伪造请求。
196.在本场景示例中，服务端验证referer请求头的原因是：考虑到由于图片水印需要的用户信息(用户姓名和用户id)是通过请求头的cookie传递给服务端，非法用户打开浏览器后可以查看到这个网页的cookie信息，非法用户可以复制用户信息和用户id在另外一个站点伪造请求，此时服务端需要验证请求来源，对于非本站的图片请求不做处理，因此非法用户就获取不到图片，就不会造成图片的泄露。
197.因此，通过服务端可以对所有请求的请求来源都会验证(即验证referer)，对于不符合请求来源的请求提示用户网址错误。其中，请求来源的验证流程具体可以参阅图10所
示。
198.在本场景示例中，图片请求的用户信息可以保存在请求头的cookie中，服务端使用node开发语言，也可以使用java等开发语言实现。具体的，可以使用koa2 web开发框架获取图片请求用户信息的核心代码为：获取用户姓名：ctx.cookies.get('user_name')，获取用户id:ctx.cookies.get('user_id')，若用户姓名和用户id获取不到或者为空，对请求不处理(说明用户没有登录)。获取到用户信息(用户姓名和用户id)后就可以添加到图片上形成水印图片。其中，获取用户信息主要流程具体可以参阅图11所示。
199.在本场景示例中，通过上述方式已经获取到了用户信息(用户姓名和用户id)后，可以从url这种获取请求的图片，并使用gm图片处理库(例如，预设的图片处理库，https://www.npmjs.com/package/gm)来生成相应的水印图片。参阅图12所示，生成水印图片的主要流程具体可以包括：
200.(1)从图片请求中获取图片名称，例如，请求http://127.0.0.1:8080/static/test.jpg就是获取test.jpg。
201.(2)将图片信息读取到gm函数。
202.(3)设置文字水印字体库(font)。
203.(4)设置文字水印的字体大小(fontsize)。
204.(5)设置文字水印的颜色(fill)。
205.(6)绘制文字，drawtext(x,y,content),其中x和y表示横坐标和纵坐标，content表示文字内容。
206.(7)将文字水印图片保存到水印图片目录，保存时会执行lrd算法(例如，预设的lrd算法)。
207.(8)将文字水印图片返回浏览器。
208.其中，所返回的水印图片(例如，目标水印图片)具体可以参阅图13所示，用户姓名和用户id在右下角显示。
209.在本场景示例中，考虑到浏览器缓存(例如，本地缓存)通常可以将浏览器将用户最近请求过的静态资源(图片、样式文件、javascript文件)存储在本地磁盘，当用户再次访问相同静态资源时，浏览器就可以直接从本地磁盘加载文档。又考虑到水印图片相对特别适合配置缓存，当用户非首次登录时直接从本地浏览器加载资源，加载速度快，可以提升用户体验。
210.因此，采用浏览器缓存存储水印图片有以下的优点：(1)减少冗余的网络数据传输；(2)减轻服务器负担，服务器处理的请求减少，服务器负担小；(3)浏览器直接从本地加载资源，加快浏览器加载网页的速度(4)浏览器缓存是web性能优化的重要方式。(可以对缓存进行自动更新)。
211.进一步，又考虑到缓存可以分为强缓存和协商缓存。
212.通过在请求响应的响应头中配置expires和cache
‑
control字段，可以实现强缓存。expires是一个时间戳，如expires:mon,09sep 2030 08:04:43gmt，expires使用的是绝对时间，这会存在一个问题，即客户端(一般是指浏览器)会使用本地时间与expires的值比较。但是客户端和服务端时间可能不一致，同时客户端的时间是可以被用户自行修改的，所以使用expires与本地时间比较得出文件是否过期，这样做会存在一定的误差。
213.而强缓存的另外一种方案则是设置响应头的cache
‑
control字段，如cache
‑
control:max
‑
age＝31536000，单位是秒，即31536000/60/60/24＝365天小时后过期。
214.当客户端浏览器请求的资源命中了强缓存，客户端直接请求本地资源，不需要发送网络请求给服务器。可以参阅图14所示。其中，请求vue.css，响应码是200，size是disk cache，即没有大小，直接从本地磁盘读取。
215.当强缓存失效时，即静态资源过期，这时浏览器就会发送请求到服务器，服务器可以设置协商缓存。协商缓存是需要浏览器发送请求，服务器根据相关信息确定静态资源文件是否有效。服务器一般通过设置etag来处理协商缓存，etag类似文件的md5，每个文件有一个有唯一的etag，只要文件内容改变了，这个文件的etag就改变。浏览器在请求资源时，在请求头中设置if
‑
none
‑
match，if
‑
none
‑
matched的值就是上次响应头中的etag值，服务器接收到请求后，重新生成文件的etag值，服务器比较新生成的etag与if
‑
none
‑
matched值是否相同，若两者相同说明文件没有变化，直接返回304状态码，浏览器还是从本地获取样式文件；若etag与if
‑
none
‑
matched值不相同，说明静态资源有变化，服务器将新的静态资源文件返回会给浏览器。
216.在本场景示例中，每个文字水印图片文件内容都不会改变(因为是一个图片，图片内容包括用户信息都是不会改变)。因此，可以不需要采用协商缓存(协商缓存判断文件是否变化)，而是直接使用cache
‑
control强缓存，并将有效期max
‑
age设置为一个较大的值(如365天)。缓存核心配置代码为response.set('cache
‑
control',`max
‑
age＝31536000`)。max
‑
age值为31536000，单位是秒，即365天有效期。具体设置时，可以参阅图15所示。
217.在本场景示例中，考虑到假设网站有n张图片需要水印处理，网站有m个注册用户，那么网站生成的水印图片数量就是n*m。如果这n*m张图片都需要保存在服务器上，大量图片会占用很多的磁盘空间。若对文字水印图片不执行删除操作，则会导致图片占用的服务器硬盘资源越来越大，当图片资源占满服务器硬盘资源时，会导致服务器崩溃。因此，除了对水印图片做了缓存配置，当浏览器请求的水印图片资源在有效期内时，会直接从浏览器本地请求，不需要从服务端获取资源外；同时，还支持服务器资源的可删除，若浏览器的水印图片超出有效期，浏览器发起请求水印图片，服务端重新生成水印图片到服务器，并返回文字水印图片到浏览器。
218.具体的，可以构造lrd(least recently downloaded)算法数据结构(例如，预设的lrd算法)。
219.具体的，基于lrd算法数据结构，服务端存储中存储一个值saved_files来保存生成的水印图片信息，其中：total_size：total_size是saved_files的一个属性，用来记录水印图片总大小，当文件总大小大于20g(这个值是可以配置的，需要根据服务器硬盘磁盘大小确定)时，触发删除水印图片算法。key_path：key_path是saved_files的每个水印图片的子属性，记录水印图片保存路径，当删除水印图片文件，需要指定水印图片文件的路径，key_path就是这个文件路径。key_time：key_time是saved_files的每个水印图片文件的子属性，记录水印文件生成时间，删除算法策略不是删除所有水印文件，而是递归删除最早生成文件，key_time的值与删除水印文件先后有密切关系。key_size：key_size是saved_files的每个水印文件的子属性，记录水印文件大小，当水印文件生成成功时将key_size的值与total_size之和赋值到total_size，更新水印图片总大小；当水印文件被删除时，将
total_size的值减去文件的key_size的值赋值到total_size中，更新水印图片总大小。
220.其中，上述lrd算法数据结构具体可以参阅图16所示。
221.具体运行时，参阅图17所示，基于上述lrd算法数据结构，具体清除缓存文件时主要流程可以包括以下内容：
222.(1)新生成文字水印图片文件大小和total_size值的和小于服务端规定的存储文件空间(如20g)，将文字水印图片文件保存到服务器。若文字水印图片保存成功，将本文字水印图片的大小保存到本文件的key_size中，文件的路径保存到key_path中，文件的写入时间保存到key_time中。更新total_size的值为total_size与本文件的key_size之和。
223.(2)当文字水印图片文件大小和total_size值的和大于服务端规定的存储文件空间(如20g)，服务端读取saved_files对象，将total_size的值保存到临时变量totalsize中，删除total_size，方便后续文件排序。
224.(3)根据saved_files中每个文件的key_time，对文字水印图片文件进行排序，生成时间早的文件在前，生成时间晚的文件在后，排序结果是形成按照生成时间先后顺序的文件数组。
225.(4)循环排序后的文件，将totalsize减去第一个文件的大小key_size赋值给totalsize，将第一个文件存储到待删除文件数组pathsshoulddelete中，删除saved_files中第一个文件信息。判断此时totalsize和待保存文件大小是否小于20gb，若totalsize和待保存文件大小大于20gb，将totalsize减去第二个文件的大小key_size赋值给totalsize，将第二个文件存储到待删除文件数组pathsshoulddelete中，删除saved_files中第二个文件信息，继续判断此时totalsize和待保存文件大小是否小20gb，以此类推，直到totalsize和待保存文件大小之和小于20gb。
226.(5)将totalsize赋值到saved_files的total_size上(因第三步骤删除了，现在重新加上)。
227.(6)删除pathsshoulddelete数组中的文件，即按照生成水印图片时间删除水印图片文件。
228.(7)更新saved_files信息。
229.在本场景示例中，强制删除文字水印图片文件方法是文字水印图片文件保存异常执行的操作，保证程序健壮性。强制删除水印图片文件方法具体的流程可以包括以下步骤：
230.(1)读取文字水印图片文件目录。
231.(2)递归删除目录中的每一个文字水印图片文件。
232.(3)将saved_files值赋值为空对象(即重置)。
233.(4)重新保存文字水印图片。
234.通过上述场景示例，验证了本说明书实施例所提供的数据处理方法可以实现以下优点：生成含有用户信息的文字水印图片；对用户信息防篡改；浏览器请求文字水印图片使用缓存机制，性能更好；引入并使用了水印图片文件删除算法(lrd)，能够优先删除保存时间早的文件，保证不会因大量文件影响服务器性能。
235.虽然本说明书提供了如实施例或流程图所述的方法操作步骤，但基于常规或者无创造性的手段可以包括更多或者更少的操作步骤。实施例中列举的步骤顺序仅仅为众多步骤执行顺序中的一种方式，不代表唯一的执行顺序。在实际中的装置或客户端产品执行时，
可以按照实施例或者附图所示的方法顺序执行或者并行执行(例如并行处理器或者多线程处理的环境，甚至为分布式数据处理环境)。术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、产品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、产品或者设备所固有的要素。在没有更多限制的情况下，并不排除在包括所述要素的过程、方法、产品或者设备中还存在另外的相同或等同要素。第一，第二等词语用来表示名称，而并不表示任何特定的顺序。
236.本领域技术人员也知道，除了以纯计算机可读程序代码方式实现控制器以外，完全可以通过将方法步骤进行逻辑编程来使得控制器以逻辑门、开关、专用集成电路、可编程逻辑控制器和嵌入微控制器等的形式来实现相同功能。因此这种控制器可以被认为是一种硬件部件，而对其内部包括的用于实现各种功能的装置也可以视为硬件部件内的结构。或者甚至，可以将用于实现各种功能的装置视为既可以是实现方法的软件模块又可以是硬件部件内的结构。
237.本说明书可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构、类等等。也可以在分布式计算环境中实践本说明书，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机可读存储介质中。
238.通过以上的实施例的描述可知，本领域的技术人员可以清楚地了解到本说明书可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解，本说明书的技术方案本质上可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如rom/ram、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，移动终端，服务器，或者网络设备等)执行本说明书各个实施例或者实施例的某些部分所述的方法。
239.本说明书中的各个实施例采用递进的方式描述，各个实施例之间相同或相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。本说明书可用于众多通用或专用的计算机系统环境或配置中。例如：个人计算机、服务器计算机、手持设备或便携式设备、平板型设备、多处理器系统、基于微处理器的系统、置顶盒、可编程的电子设备、网络pc、小型计算机、大型计算机、包括以上任何系统或设备的分布式计算环境等等。
240.虽然通过实施例描绘了本说明书，本领域普通技术人员知道，本说明书有许多变形和变化而不脱离本说明书的精神，希望所附的权利要求包括这些变形和变化而不脱离本说明书的精神。