文件代理方法和装置与流程

本发明涉及互联网领域，具体而言，涉及一种文件代理方法和装置。

背景技术：

在现有的前端开发的日程工作中，如果程序员发现服务器上某个页面文件(例如，html、shtml文件)或者资源文件(例如，css、js文件)有问题，则需要进行修改。通常情况下，在对文件进行修改之后，需要重新发布再验证，这样就很容易影响到生产环境的稳定性。为了解决上述问题，程序研发人员想到利用前端代理工具(例如，Fiddler)可以修改HTTP数据的特性，来进行本地的调试，这样就可以敏捷地基于生产环境修改并验证，确认之后再发布，避免在生产过程中产生程序漏洞，或者未进过调试的代码污染了线上环境。

在现有技术中，程序人员开发调试网页时可以通过文件代理工具(例如Fiddler、LinrFiddler或者shtml2html)在本地看到修改的页面之后所呈现的效果。上述文件代理工具可以对请求的response执行各种规则，还可以将请求指向到本地文件。这样一来就可以将页面中的静态资源请求指向到本地文件，本地文件修改后刷新页面马上就可以看到效果，避免了频繁上传FTP和网络延迟的麻烦，大大提升效率。每个程序开发人员既可以专心调试自己的代码，也可以任意修改他人的代码，不用担心影响他人或被他人影响。本地测试完成再提交服务器，避免提交不稳定代码及debugger泛滥的代码。

但是上述现有的方案，例如，Fiddler或者LinrFiddler(基于Fiddler的文件代理工具)都只能代理普通页面文件(例如，html静态页面)和资源文件(例如，css，js，图片等)。但是，对于现在各大网站常用的shtml页面文件或者使用SSI指令包含代码片段的页面，却并无法顺利地代理。也就是说，对于现有的Fiddler或者LinrFiddler等文件代理工具，仅能代理html静态页面或者css，js，图片等，不能代理shtml页面文件，同时也无法解析shtml中的SSI指令。

针对上述的问题，目前尚未提出有效的解决方案。

技术实现要素：

本发明实施例提供了一种文件代理方法和装置，以至少解决现有技术中文件代理工具所代理的文件局限性较大的技术问题。

根据本发明实施例的一个方面，提供了一种文件代理方法，包括：将获取到的线上文件路径转换为本地文件路径；从所述本地文件路径上获取第一页面文本；从所述第一页面文本中获取到第一文本代码和第一文件路径，其中，所述第一文件路径用于获取第二文件；根据所述第一文件路径查找本地是否存储有所述第二文件；若查找到所述本地存储有所述第二文件，则从本地获取所述第二文件的第二文本代码；将所述第一文本代码和所述第二文本代码进行拼接，得到第二页面文本。

根据本发明实施例的另一方面，还提供了一种文件代理装置，包括：转换单元，用于将获取到的线上文件路径转换为本地文件路径；第一获取单元，用于从所述本地文件路径上获取第一页面文本；第二获取单元，用于从所述第一页面文本中获取到第一文本代码和第一文件路径，其中，所述第一文件路径用于获取第二文件；查找单元，用于根据所述第一文件路径查找本地是否存储有所述第二文件；第三获取单元，用于若查找到所述本地存储有所述第二文件，则从本地获取所述第二文件的第二文本代码；拼接单元，用于将所述第一文本代码和所述第二文本代码进行拼接，得到第二页面文本。

在本发明实施例中，采用将获取到的线上文件路径转换为本地文件路径；从所述本地文件路径上获取第一页面文本；从所述第一页面文本中获取到第一文本代码和第一文件路径，其中，所述第一文件路径用于获取第二文件；根据所述第一文件路径查找本地是否存储有所述第二文件；若查找到所述本地存储有所述第二文件，则从本地获取所述第二文件的第二文本代码；将所述第一文本代码和所述第二文本代码进行拼接，得到第二页面文本的方式，首先依据线上文件路径获取第一页面文本，然后，根据第一页面文本中的第一文件路径查找第二文件，其中，如果查找到第二文件，则将第二文件的第二文件代码与第一文本代码进行拼接，得到第二页面文本，通过上述方法能够实现对shtml页面的代理，达到了能够代理shtml页面的目的，进而解决了现有技术中文件代理工具所代理的文件局限性较大的技术问题。

附图说明

此处所说明的附图用来提供对本发明的进一步理解，构成本申请的一部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：

图1是根据本发明实施例的终端和服务器所构成的硬件环境的架构图；

图2是根据本发明实施例的一种可选的fidder代理的shtml页面样式的示意图；

图3是根据本发明实施例的一种可选的SSI Proxy插件代理的shtml页面样式的示意图；

图4是根据本发明实施例的一种SSI Proxy插件和fidder之间的UML关系图；

图5是根据本发明实施例的一种设置第二文件获取方式的显示界面的示意图；

图6是根据本发明实施例的一种文件代理方法的流程图；

图7是根据本发明实施例的一种文件代理装置的示意图；

图8是根据本发明实施例的终端的硬件结构图。

具体实施方式

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

需要说明的是，本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本发明的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

本申请中涉及到的专业术语的解释：

Fiddler：是位于客户端和服务器端的HTTP代理，也是目前最常用的http抓包工具之一。它能够记录客户端和服务器之间的所有HTTP请求，可以针对特定的HTTP请求，分析请求数据、设置断点、调试web应用、修改请求的数据，甚至可以修改服务器返回的数据，功能非常强大，是web调试的利器。

C#语言：是运行于.NET Framework之上的高级程序设计语言，是一种面向对象的编程语言。Fiddler是用C#写出来的,它包含一个简单而功能强大的基于JScript.NET事件脚本子系统，它的灵活性很棒，可以支持众多的http调试任务，并且能够使用.net框架语言进行扩展。本插件就是使用C#语言，基于Fiddler所写的扩展。

SHTML：包含有嵌入式服务器方包含命令的HTML文本。在被传送给浏览器之前，服务器会对SHTML文档进行完全地读取、分析以及修改。SHTML文件中会引用SSI指令引用其他html文件，服务器传送给客户端的文件，是已经解释的SHTML。

SSI(Server Side Include)：在内容发送到浏览器之前，使用SSI命令，将文本、图形或应用程序信息包含到网页中。对于多个文件中重复出现的文本或图片，将其放在SSI文件中插入不同的文件中，可以提高代码的重用率。因为SSI指令的文件要求特殊处理，所以必须所有SSI文件赋予SSI文件扩展名，默认扩展名是.stm、.shtml和.shtm。

根据本发明实施例，提供了一种可以通过本申请装置实施例执行的方法实施例，需要说明的是，在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行，并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。

根据本发明实施例，提供了一种文件代理方法。

可选地，在本实施例中，上述文件代理方法可以应用于如图1所示的终端102和服务器104所构成的硬件环境中。如图1所示，终端102通过网络与服务器104进行连接，上述网络包括但不限于：移动通信网络、广域网、城域网或局域网，终端102可以是手机终端，也可以是PC终端、笔记本终端或平板电脑终端。

图1中示出的硬件环境系统的主要工作原理是：

在本发明实施例中，终端102中安装有文件代理工具Fiddler，其中，该文件代理工具安装有SSI Proxy插件。上述文件代理工具Fiddler用于获取来自终端102的请求(Request)数据包，然后，文件代理工具Fiddler将获取到的请求(Request)数据包转发给服务器104，服务器104再将应答(Response)数据包发给文件代理工具Fiddler。文件代理工具Fiddler再将应答(Response)数据包转发给终端102。因此，在本发明中，所以不管是Request还是Response数据包都经过了Fiddler，也就是说，能够对数据包进行截获和分析。因此，在本发明实施例中，可以依据Fiddler的截获数据包的特性，在Fiddler获取到Request数据包之后，无需再向服务器104转发该数据包，而是在终端102本地获取数据，其中，在终端102中获取到的数据与服务器104发送的Response数据包相同。

例如，当测试人员在终端102中访问任一个浏览器时，文件代理工具Fiddler截获终端102发送的请求数据包，然后，Fiddler再依据请求数据包在本地查找对应的数据，而不是将该请求数据包发送至服务器104，来获取服务器104的Response数据包。

进一步地，在本发明实施例的文件代理工具Fiddler中安装有SSI Proxy插件。该插件就是在Fiddler的基础上进行的扩展，是一个Visual C#Class Library类库项目，其中，该插件的开发语言为C#语言。在该插件的开发前期在解决方案资源管理器中添加Fiddler.exe引用，调用Fiddler的各类接口进行开发。同时添加Fiddler.Required Version特性，设置插件所基于的Fiddler的最低版本为2.2.7.5。

如图4所示的为一种SSI Proxy插件和Fiddler的统一建模语言(Unified Modeling Language，UML)的关系图，从图4中可以看出，SSI Proxy和Fiddler.IAutoTamper接口之间的关系，以及Fiddler和Fiddlerproxy与Fiddler.IAutoTamper接口之间关系。

SSI Proxy插件在开发完成之后，只需编译出程序集dll文件，然后，将该dll文件复制到Fiddler安装目录下的script目录中，重新启动Fiddler之后就可以使用了。该插件安装方便快捷，而且不需要依赖任何库或者安装任何环境。

SSI Proxy插件与现有技术中其他的文件代理工具相比，具有以下优点：

1、SSI Proxy插件支持多种文件代理，其中，包括页面文件(shtml、html、cgi)，资源文件(js、css、jpg、png、gif、htm等)，以及其他类型的文件；

2、SSI Proxy插件支持shtml页面代理，现有技术中的Fiddler工具或者LinrFiddler工具都无法代理shtml页面，具体地，当使用Fiddler工具或者LinrFiddler工具代理shtml时，得到的shtml页面样式如图2所示；当使用SSI Proxy插件代理shtml时，得到的shtml页面样式如图3所示，从图2和图3中可以看出，采用传统的Fiddler工具或者LinrFiddler工具代理shtml页面时，无法显示页面中的静态图片和动态图片等，然而，当通过SSI Proxy插件代理shtml时，即可以显示静态图片和动态图片等信息；

3、SSI Proxy插件支持include指令引用文件。使用Fiddler的AutoResponder代理，或者LinrFiddler代理也都无法解析shtml中的SSI指令(#include)；然而，使用SSI Proxy插件代理文件，可以解析include标签；

4、基于正式环境快速开发。在实现文件的代理shtml页面过程中，现有技术中Shtml2html的转换方式与插件SSI Proxy的转换方式一样，同样是将shtml中的include内容替换为真实调用的内容，并且在同级目录生成.html文件。但是shtml2html是在本地将shtml文件转换变成html，并没有代理的功能，无法实现敏捷地基于正式环境修改并验证是否有问题，同时它的安装必须建立在python环境2.x版本的基础上。

综上，SSI Proxy插件能的安装简单得多只需要将现有的dll文件复制进Fiddler安装目录下的script目录中，重新启动Fiddler之后就可以使用了。安装该插件之后的Fiddler工具，具备了上述描述的SSI Proxy插件的全部优点和功能。同时，该插件安装方便快捷，不需要依赖任何库或者安装任何环境，能够基于正式环境进行快速开发。

通过上述背景技术的描述可知，当发现服务器中某个页面文件、或者资源文件需要进行修改时，可以利用Fiddler工具修改HTTP数据的特性，来进行本地调试。因此，Fiddler工具可以对客户端发送的请求指向到本地文件，避免了频繁上传FFT和网络延迟的麻烦。

本发明实施例中提供的文件代理方法主要包括两个阶段，第一阶段为一轮代理阶段，第二阶段为二轮代理阶段，其中，一轮代理阶段可以通过一轮代理处理器来完成，二轮代理阶段可以通过二轮代理处理器来完成。下面将具体介绍上述两个代理阶段。

一轮代理阶段：

在本发明实施例中，一轮代理处理器将Fiddler工具抓取到的链接筛选出需要代理的第一shtml文件，然后，对第一shtml文件进行编辑，得到第二shtml文件，并将第二shtml文件放入本地代理文件池中。然后，通过一轮页面文件过滤器对本地代理文件池中的第二shtml文件进行过滤分离，分离得到第一页面文本，并将分离得到的第一页面文本进行存储，以Fiddler工具进行查询。具体地，可以判断本地代理文件池中第二shtml文件的文件类型是否同时满足shtml、html、htm类型的文件，其中，如果判断出本地代理文件池中的文件类型为shtml、html或者htm类型中的任一种，则将该代理文件放入页面文件处理池中，如果判断出本地代理文件池中的文件类型不是shtml、html或者htm类型中的任一种，则将该代理文件放入资源文件处理池中。

二轮代理阶段：

在二轮代理阶段，二轮代理处理器获得线上文件路径，然后，将获取到的线上文件路径输入至路径处理模块，以对该线上文件路径进行过滤替换处理，得到转转之后的本地文件路径，并依据该获取到的本地文件路径在本地查找待代理的第一页面文本。在获取到第一页面文本之后，在文本内容处理器中对第一页面文本的文本内容进行过滤和筛选，得到两部分，分别为无需解析的第一文本代码和需再次解析的第一文件路径(例如，include文件路径)。

从第一页面文本中获取第一文件路径的方式有很多种，在本发明的一个可选实施方式中，可以在第一页面文本中查找include标签，然后，获取由查找到的include标签所在的代码片段所指示的第一文件路径。

在本发明实施例中，通过上述实施例中的描述可知，相对于现有技术中文件代理工具，安装有SSI Proxy插件的Fiddler工具可以解析include标签，然后，依据查找到的include标签获取第一文件路径，并在获取第一文件路径之后，查找第二文件，其中，在本发明实施例中，第一文件路径又可以称为include路径。

在获取到上述第一文件路径之后，就可以依据该第一文件路径在本地目录中查找本地文件(即，第二文件)，如果在本地文件中查找到第二文件，则可以从本地获取第二文件的文本代码。最后，将得到的第二文件的文本代码输入至用于生成代理文件的处理器中进行文件代码的拼接，得到第二页面文本。

将第一文本代码和第二文本代理进行拼接的方式有很多种，在本发明实施例中，可以将第一页面文本中包含的第一文件路径删除，在删除第二文件路径之后，再将第二文本代码添加在第一页面文件中第一文件路径所在的位置上，得到第二页面文本。

需要说明的是，在本发明上述实施例中，是在文件代理工具Fiddler在本地查找到第二文件的情况下，直接从本地获取第二文件的文件代码(即，第二文件代码)，而无需再向服务器发送请求，以使服务器向终端发送第二文件，进而避免了网络延迟或者频繁上传数据导致的卡顿等现象的发生。

但是，如果文件代理工具Fiddler在本地没有查找到第二文件，那么可以通过网络获取第二文件的第二文件代码。例如，文件代理工具Fiddler向服务器发送请求，其中，该请求为用于请求第二文件的请求。服务器在获取该请求之后，向文件代理工具Fiddler发送响应信息，然后，文件代理工具根据服务器回复的响应信息获取第二文件的第二文件代码。

需要说明的是，在本发明实施例中，对于在本地未查找到第二文件的情况，用户可以自己进行多种配置，如图5所示，可以进行的设置分别有：若无本地文件(即，第二文件)，从线上读取(不下载)；若无本地文件(即，第二文件)，从线上读取并下载到硬盘；全部从线上读取文件(不下载)；全部从本地硬盘读取。

在将第一文本代码和第二文本代码进行拼接，得到第二页面文本之后，就可以在本地的浏览器中加载显示所述第二页面文本。

例如，程序调试人员通过本发明实施例中提供的Fiddler工具修改HHTP数据的特性，并进行本地调试，然后，通过Fiddler工具在本地显示修改的页面之后所呈现的效果。假设，在通过Fiddler工具在本地显示修改的页面之后所呈现的效果时，可以首先获取所测试的网页的线上文件路径，www.xx.xx.com，然后，将该线上文件路径转换为本地文件路径，例如“C:\Documents and Settings\XX\XX”；接下来，在该本地文件路径上获取待代理的第一页面文件，并从第一页面文件中获取第一文件代码和第一文件路径。根据第一文件路径在本地查找是否存储有第二文件，其中，如果查找到第二文件，则获取第二文件中的第二文本代码，并将第一文本代码和第二文本代码进行拼接，得到该网页的第二页面文本。在获取到第二页面文本之后，就可以将第二页面文本显示在本地浏览器中，以使程序人员观察修改的页面之后所呈现的效果。

需要说明的是，在本发明上述实施例中，一轮代理处理器和二轮代理处理器、路径处理模块、文本内容处理器、代理文件处理器均为文件代理工具Fiddler中的组成部分。

在本发明实施例中提供的文件代理方法中，Fiddler工具中安装有SSI Proxy插件之后，该Fiddler工具具有SSI Proxy插件的全部特性和功能。其中，SSI Proxy插件是基于Fiddler开发的插件工具，是业界内首个用于解析SSI include指令的代理工具，主要亮点是HTML页面模块化开发，使HTML页面支持include指令，支持本地开发，并且在开发调试过程中SHTML页面无需搭建服务器，简化代理文件的操作步骤，提高效率。

在通过设置有SSI Proxy插件的Fiddler工具进行文件的代理时，总共需要经过两个处理器进行处理，即上述一轮代理处理器和二轮代理处理器，其中，一轮代理处理器的输入是直接代理文件的代理(即包含include标签的代码片段的父级页面的代理)，二轮代理处理器的输入是include文件的代理。这两轮代理处理器对于用户来说并不可见，用户操作只需将需要代理的文件粘贴进代理列表中，系统自动进行精确或者模糊匹配。

图6是根据本发明实施例的一种文件代理方法的流程图，以下结合图6对本发明实施例所提供的文件代理方法做具体介绍，如图6所示，该文件代理方法主要包括如下步骤S602至步骤S608：

步骤S601：获取线上文件路径；其中，可以通过安装有SSI Proxy插件的Fiddler工具获取线上文件路径，例如，待测试的网页的域名URL。

步骤S602：将获取到的线上文件路径转换为本地文件路径；其中，可以将获取到的线上文件路径输入至路径处理模块中，以使路径处理模块对其线上文件路径进行过滤替换处理，输出本地文件路径，其中，本地文件路径为本地终端中的文件路径。

步骤S603：从本地文件路径上获取第一页面文本；其中，在转换得到本地文件路径之后，可以依据该本地文件路径在本地读取本地文件内容，即第一页面文本。在本发明实施例中，第一页面文本为预先存储的页面文本，可以通过以下方式进行获取：对待处理的第一shtml文件进行编辑，得到第二shtml文件，然后，从第二shtml文件中分离出第一页面文本，并进行存储。

步骤S604：从第一页面文本中获取到第一文本代码和第一文件路径；其中，在获取到第一页面文本之后，可以通过文本内容处理器，对第一页面文本的文本内容进行文本的过滤和筛选，产生两部分内容，其中一部分是无需解析的文本代码(即第一文本代码)；另外一部分是需再次解析的include文件路径(即第一文件路径)。

步骤S605：根据第一文件路径查找本地是否存储有第二文件；其中，在步骤S604中获取include文件路径之后，可以对该include文件路径在本地目录进行查找，以查找第二文件。如果查找到第二文件，则执行步骤S606，如果未查找到第二文件，则执行步骤S607。

步骤S606：从本地获取第二文件的第二文本代码；

步骤S607：通过网络获取第二文件的第二文本代码；

如果有本地文件(即，第二文件)，则读取本地文件的文件内容；如果没有，则直接通过网络获取第二文件的文件内容。最后，执行下述步骤S608，即将得到的第二文件代码输入生成代理文件处理器中，与第一文本代码进行拼合，得到最终可代理的页面文件，即第二页面文本。

步骤S608：将第一文本代码和所述第二文本代码进行拼接，得到第二页面文本。

在本发明实施例中，首先依据线上文件路径获取第一页面文本，然后，根据第一页面文本中的第一文件路径查找第二文件，其中，如果查找到第二文件，则将第二文件的第二文件代码与第一文本代码进行拼接，得到第二页面文本，通过上述方法能够实现对shtml页面的代理，达到了能够代理shtml页面的目的，进而解决了现有技术中文件代理工具所代理的文件局限性较大的技术问题。

需要说明的是，对于前述的各方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本发明并不受所描述的动作顺序的限制，因为依据本发明，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定是本发明所必须的。

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

根据本发明实施例，还提供了一种用于实施上述文件代理方法的文件代理装置，该文件代理装置主要用于执行本发明实施例上述内容所提供的文件代理方法，以下对本发明实施例所提供的文件代理装置做具体介绍：

图7是根据本发明实施例的一种文件代理装置的示意图，如图7所示，该文件代理装置主要包括：转换单元71、第一获取单元73、第二获取单元75、查找单元77、第三获取单元79和拼接单元711，其中：

转换单元71，用于将获取到的线上文件路径转换为本地文件路径；

第一获取单元73，用于从本地文件路径上获取第一页面文本；

第二获取单元75，用于从第一页面文本中获取到第一文本代码和第一文件路径，其中，第一文件路径用于获取第二文件；

查找单元77，用于根据第一文件路径查找本地是否存储有第二文件；

第三获取单元79，用于若查找到本地存储有第二文件，则从本地获取第二文件的第二文本代码；

拼接单元711，用于将第一文本代码和第二文本代码进行拼接，得到第二页面文本。

可选地，装置还包括：编辑单元，用于在将获取到的线上文件路径转换为本地文件路径之前，对待处理的第一shtml文件进行编辑，得到第二shtml文件；分离单元，用于从第二shtml文件中分离出第一页面文本；存储单元，用于存储第一页面文本。

本发明实施例中提供的文件代理方法主要包括两个阶段，第一阶段为一轮代理阶段，第二阶段为二轮代理阶段，其中，一轮代理阶段可以通过一轮代理处理器来完成，二轮代理阶段可以通过二轮代理处理器来完成。下面将具体介绍上述两个代理阶段。

一轮代理阶段：

在本发明实施例中，一轮代理处理器将Fiddler工具抓取到的链接筛选出需要代理的第一shtml文件，然后，对第一shtml文件进行编辑，得到第二shtml文件，并将第二shtml文件放入本地代理文件池中。然后，通过一轮页面文件过滤器对本地代理文件池中的第二shtml文件进行过滤分离，分离得到第一页面文本，并将分离得到的第一页面文本进行存储，以Fiddler工具进行查询。具体地，可以判断本地代理文件池中第二shtml文件的文件类型是否同时满足shtml、html、htm类型的文件，其中，如果判断出本地代理文件池中的文件类型为shtml、html或者htm类型中的任一种，则将该代理文件放入页面文件处理池中，如果判断出本地代理文件池中的文件类型不是shtml、html或者htm类型中的任一种，则将该代理文件放入资源文件处理池中。

二轮代理阶段：

在二轮代理阶段，二轮代理处理器获得线上文件路径，然后，将获取到的线上文件路径输入至路径处理模块，以对该线上文件路径进行过滤替换处理，得到转转之后的本地文件路径，并依据该获取到的本地文件路径在本地查找待代理的第一页面文本。在获取到第一页面文本之后，在文本内容处理器中对第一页面文本的文本内容进行过滤和筛选，得到两部分，分别为无需解析的第一文本代码和需再次解析的第一文件路径(例如，include文件路径)。

从第一页面文本中获取第一文件路径的方式有很多种，在本发明的一个可选实施方式中，可以在第一页面文本中查找include标签，然后，获取由查找到的include标签所在的代码片段所指示的第一文件路径。

在本发明实施例中，通过上述实施例中的描述可知，相对于现有技术中文件代理工具，安装有SSI Proxy插件的Fiddler工具可以解析include标签，然后，依据查找到的include标签获取第一文件路径，并在获取第一文件路径之后，查找第二文件，其中，在本发明实施例中，第一文件路径又可以称为include路径。

在获取到上述第一文件路径之后，就可以依据该第一文件路径在本地目录中查找本地文件(即，第二文件)，如果在本地文件中查找到第二文件，则可以从本地获取第二文件的文本代码。最后，将得到的第二文件的文本代码输入至用于生成代理文件的处理器中进行文件代码的拼接，得到第二页面文本。

可选地，拼接单元包括：删除模块，用于从第一页面文本中删除第一文件路径，其中，第一页面文本包括第一文本代码和第一文件路径；添加模块，用于将第二文本代码添加到第一页面文本中第一文件路径所在的位置上，得到第二页面文本。

将第一文本代码和第二文本代理进行拼接的方式有很多种，在本发明实施例中，可以将第一页面文本中包含的第一文件路径删除，在删除第二文件路径之后，再将第二文本代码添加在第一页面文件中第一文件路径所在的位置上，得到第二页面文本。

可选地，该装置还包括：第四获取单元，用于在根据第一文件路径查找本地是否存储有第二文件之后，若查找到本地没有存储第二文件，则通过网络获取第二文件的第二文本代码。

需要说明的是，在本发明上述实施例中，是在文件代理工具Fiddler在本地查找到第二文件的情况下，直接从本地获取第二文件的文件代码(即，第二文件代码)，而无需再向服务器发送请求，以使服务器向终端发送第二文件，进而避免了网络延迟或者频繁上传数据导致的卡顿等现象的发生。

但是，如果文件代理工具Fiddler在本地没有查找到第二文件，那么可以通过网络获取第二文件的第二文件代码。例如，文件代理工具Fiddler向服务器发送请求，其中，该请求为用于请求第二文件的请求。服务器在获取该请求之后，向文件代理工具Fiddler发送响应信息，然后，文件代理工具根据服务器回复的响应信息获取第二文件的第二文件代码。

需要说明的是，在本发明实施例中，对于在本地未查找到第二文件的情况，用户可以自己进行多种配置，如上述图5所示，可以进行的设置分别有：若无本地文件(即，第二文件)，从线上读取(不下载)；若无本地文件(即，第二文件)，从线上读取并下载到硬盘；全部从线上读取文件(不下载)；全部从本地硬盘读取。

可选地，装置还包括：加载显示单元，用于在将第一文本代码和第二文本代码进行拼接，得到第二页面文本之后，在本地的浏览器中加载显示第二页面文本。

在将第一文本代码和第二文本代码进行拼接，得到第二页面文本之后，就可以在本地的浏览器中加载显示所述第二页面文本。

例如，程序调试人员通过本发明实施例中提供的Fiddler工具修改HHTP数据的特性，并进行本地调试，然后，通过Fiddler工具在本地显示修改的页面之后所呈现的效果。假设，在通过Fiddler工具在本地显示修改的页面之后所呈现的效果时，可以首先获取所测试的网页的线上文件路径，www.xx.xx.com，然后，将该线上文件路径转换为本地文件路径，例如“C:\Documents and Settings\XX\XX”；接下来，在该本地文件路径上获取待代理的第一页面文件，并从第一页面文件中获取第一文件代码和第一文件路径。根据第一文件路径在本地查找是否存储有第二文件，其中，如果查找到第二文件，则获取第二文件中的第二文本代码，并将第一文本代码和第二文本代码进行拼接，得到该网页的第二页面文本。在获取到第二页面文本之后，就可以将第二页面文本显示在本地浏览器中，以使程序人员观察修改的页面之后所呈现的效果。

需要说明的是，在本发明上述实施例中，一轮代理处理器和二轮代理处理器、路径处理模块、文本内容处理器、代理文件处理器均为文件代理工具Fiddler中的组成部分。

根据本发明实施例，还提供了一种用于实施上述文件代理方法的终端(服务器)，如图8所示，该终端(服务器)主要包括处理器801、显示器802、数据接口803、存储器804和网络接口805，其中：

显示器802主要用于显示第二页面文件。

数据接口803则主要通过数据传输的方式将拼接得到的第二页面文件传输给处理器801。

存储器804主要用于存储第一页面文件。

网络接口805主要用于与服务器进行网络通信，为文件代理提供数据支持。

处理器801主要用于执行如下操作：

将获取到的线上文件路径转换为本地文件路径；从本地文件路径上获取待代理的第一页面文本；从第一页面文本中获取到第一文本代码和第一文件路径，其中，第一文件路径用于获取第二文件；根据第一文件路径查找本地是否存储有第二文件；若查找到本地存储有第二文件，则从本地获取第二文件的第二文本代码；将第一文本代码和第二文本代码进行拼接，得到第二页面文本。

处理器801还用于从第一页面文本中删除第一文件路径，其中，第一页面文本包括第一文本代码和第一文件路径；将第二文本代码添加到第一页面文本中第一文件路径所在的位置上，得到第二页面文本。

处理器801还用于根据第一文件路径查找本地是否存储有第二文件之后，若查找到本地没有存储第二文件，则通过网络获取第二文件的第二文本代码。

处理器801还用于在将第一文本代码和第二文本代码进行拼接，得到第二页面文本之后，在本地的浏览器中加载显示第二页面文本。

处理器801还用于在将获取到的线上文件路径转换为本地文件路径之前，对待处理的第一shtml文件进行编辑，得到第二shtml文件；从第二shtml文件中分离出第一页面文本；存储第一页面文本。

可选地，本实施例中的具体示例可以参考上述实施例中所描述的示例，本实施例在此不再赘述。

本发明的实施例还提供了一种存储介质。可选地，在本实施例中，上述存储介质可以用于存储本发明实施例的文件代理方法的程序代码。

可选地，在本实施例中，上述存储介质可以位于移动通信网络、广域网、城域网或局域网的网络中的多个网络设备中的至少一个网络设备。

可选地，在本实施例中，存储介质被设置为存储用于执行以下步骤的程序代码：

S1，将获取到的线上文件路径转换为本地文件路径；

S2，从所述本地文件路径上获取第一页面文本；

S3，从所述第一页面文本中获取到第一文本代码和第一文件路径，其中，所述第一文件路径用于获取第二文件；

S4，根据所述第一文件路径查找本地是否存储有所述第二文件；

S5，若查找到所述本地存储有所述第二文件，则从本地获取所述第二文件的第二文本代码；

S6，将所述第一文本代码和所述第二文本代码进行拼接，得到第二页面文本。

可选地，在本实施例中，上述存储介质可以包括但不限于：U盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。

可选地，本实施例中的具体示例可以参考上述实施例中所描述的示例，本实施例在此不再赘述。

上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。

上述实施例中的集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在上述计算机可读取的存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在存储介质中，包括若干指令用以使得一台或多台计算机设备(可为个人计算机、服务器或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。

在本发明的上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。

在本申请所提供的几个实施例中，应该理解到，所揭露的客户端，可通过其它的方式实现。其中，以上所描述的装置实施例仅仅是示意性的，例如所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，单元或模块的间接耦合或通信连接，可以是电性或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

以上所述仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。