WO2013010369A1 - 一种获取网页中音/视频链接地址的方法及装置 - Google Patents

一种获取网页中音/视频链接地址的方法及装置 Download PDF

Info

Publication number
WO2013010369A1
WO2013010369A1 PCT/CN2011/084171 CN2011084171W WO2013010369A1 WO 2013010369 A1 WO2013010369 A1 WO 2013010369A1 CN 2011084171 W CN2011084171 W CN 2011084171W WO 2013010369 A1 WO2013010369 A1 WO 2013010369A1
Authority
WO
WIPO (PCT)
Prior art keywords
link address
video
audio
data packet
request
Prior art date
Application number
PCT/CN2011/084171
Other languages
English (en)
French (fr)
Inventor
祝剑
Original Assignee
深圳市万兴软件有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 深圳市万兴软件有限公司 filed Critical 深圳市万兴软件有限公司
Publication of WO2013010369A1 publication Critical patent/WO2013010369A1/zh

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/95—Retrieval from the web
    • G06F16/955—Retrieval from the web using information identifiers, e.g. uniform resource locators [URL]
    • G06F16/9558—Details of hyperlinks; Management of linked annotations

Definitions

  • the present invention relates to the field of computer technologies, and in particular, to a method and apparatus for acquiring an audio/video link address in a webpage. Background technique
  • the inventors wish to use the hook program to help the user find the real link address of the audio and video.
  • Hook a platform for Windows message processing, allows applications to set up subroutines to monitor certain messages in a given window, and the monitored windows can be created by other processes. When the message arrives, it is processed before the target window processes the message.
  • the hook mechanism allows the application to intercept processing Windows messages or specific events.
  • the hook program is actually a program segment that processes the message and injects it into the system through a system call. Whenever a specific message is sent, the hook program captures the message before reaching the destination window. At this time, the hook program can process (change) the message, or continue to deliver the message without processing, and can also force the end. The delivery of the message.
  • the hook program can also be understood as the back door that Windows leaves us.
  • the user wants to control the keyboard.
  • DOS era it is very simple to pass the INT, and the Windows era does not allow us to directly operate the hardware.
  • Windows is a message driver, we can pass Pull the keyboard message to reach the control keyboard Purpose.
  • the message that the program controls its own process is very simple.
  • the technical problem to be solved by the embodiments of the present invention is to provide a method and a device for acquiring an audio/video link address in a webpage, and using the hook program, the user can not download the audio/video file in the webpage, and can not find the audio/video.
  • the real link address is used, it can help the user to find the real link address of the audio and video.
  • an embodiment of the present invention provides a method for obtaining an audio/video link address in a webpage, including:
  • the injecting a hook program into the web browser process of the terminal, and acquiring the request data packet sent by the web browser to the server includes:
  • the hook program has a dynamic database for obtaining a request data packet sent by the web browser to the server;
  • the hook program is injected into the process of the web browser to obtain a request data packet sent by the web browser to the server.
  • the simulating the webpage browser to send a page request to the server according to the request data packet including:
  • the webpage browser simulating, by the webpage protocol, the webpage browser to send a page request to the server according to the information in the request data packet and the network protocol adopted by the request data packet; the page request is a request for a file attribute.
  • the receiving the response data packet fed back by the server, and determining whether the link address in the response data packet is a link address of the audio/video data includes:
  • the response data packet includes: a server status code, a content length Content-Length, a content type Content-Type, and a link address; Determining whether the Content-Type carried in the response data packet is an audio/video type; if the determination is yes, determining that the response data packet carries a link address whose address is audio/video data; otherwise, determining the response The link address in the data packet is not the link address of the audio/video data.
  • the receiving the response data packet fed back by the server, and determining whether the link address in the response data packet is a link address of the audio/video data includes:
  • the server Receiving a response data packet fed back by the server, where the response data packet includes: a server status code, a content length Content-Length, a content type Content-Type, and a link address;
  • the determination is yes, it is further determined whether the Content-Length is greater than a preset value; if the determination is yes, determining that the response data packet carries a link address whose address is audio/video data; otherwise, determining that the The link address in the response packet is not the link address of the audio/video data.
  • the obtaining the audio/video link address includes:
  • the audio/video link address is provided to the user.
  • an embodiment of the present invention further provides an apparatus for acquiring an audio/video link address in a webpage, including:
  • a request packet obtaining module configured to inject a hook program into a web browser process of the terminal, and obtain a request data packet sent by the web browser to the server;
  • An analog requesting module configured to simulate, according to the request data packet acquired by the request data packet acquiring module, the webpage browser to send a page request to the server;
  • a link analysis and acquisition module configured to receive a response data packet fed back by the server, and determine whether the link address in the response data packet is a link address of the audio/video data; if the determination is yes, acquire the audio/video link address.
  • the simulation request module includes:
  • a packet classification unit configured to classify the request data packets acquired by the request packet obtaining module according to respective network protocols adopted by the request packet;
  • an analog requesting unit configured to simulate, according to the information in the request data packet and a network protocol used by the request data packet, the webpage browser to send a page request to the server.
  • the link analysis and acquisition module includes: a data packet receiving unit, configured to receive a response data packet fed back by the server, where the response data packet includes: a server status code, a content length Content-Length, a content type Content-Type, and a link address;
  • a first determining unit configured to determine whether the Content-Type carried in the response data packet is a sound/video type; if the determination is yes, determining that the response data packet carries a link address whose address is audio/video data Otherwise, it is determined that the response packet carries a link address that is not a link address of audio/video data.
  • the link analysis and acquisition module includes:
  • a data packet receiving unit configured to receive a response data packet fed back by the server, where the response data packet includes: a server status code, a content length, a content-Length, a content type, a content-type, and a link address;
  • a second determining unit determining whether the Content-Type carried in the response packet is an audio/video type; if the determination is no, determining that the link address in the response packet is not a link address of audio/video data; If the determination is yes, the third determination unit further determines;
  • a third determining unit configured to determine whether the Content-Length is greater than a preset value; if the determination is yes, determining that the link address in the response data packet is a link address of the audio/video data;
  • the response packet carries a link address that is not a link address of audio/video data.
  • the method and device for obtaining an audio/video link address in a webpage can accurately be obtained when a user wants to download an audio/video file in a webpage and cannot find a real link address of the audio/video. Help users find the real link address of audio and video.
  • FIG. 1 is a schematic flow chart of a first embodiment of a method for obtaining an audio/video link address in a webpage according to the present invention
  • FIG. 2 is a schematic flow chart of a second embodiment of a method for obtaining an audio/video link address in a webpage according to the present invention
  • 3 is a schematic structural diagram of a first embodiment of an apparatus for acquiring an audio/video link address in a webpage according to the present invention
  • FIG. 4 is a schematic structural view of a second embodiment of an apparatus for acquiring an audio/video link address in a webpage according to the present invention
  • FIG. 5 is a schematic structural diagram of a third embodiment of an apparatus for acquiring an audio/video link address in a webpage according to the present invention. detailed description
  • the method and device for obtaining an audio/video link address in a webpage using a hook program, can accurately be obtained when a user wants to download an audio/video file in a webpage and cannot find a real link address of the audio/video. Help users find the real link address of audio and video.
  • FIG. 1 a first embodiment of a method for obtaining a sound/video link address in a webpage according to the present invention is shown in FIG. 1 , which includes:
  • step S100 a hook program is injected into the web browser process of the terminal, and the hook program is used to obtain a request packet sent by the web browser to the server.
  • step S101 the web browser is simulated to send a page request to the server according to the obtained request data packet.
  • step S102 a response packet fed back by the server is received. And determining whether the link address in the response packet is a link address of the audio/video data, and if the determination is yes, executing step S103; otherwise, ending the process.
  • step S103 the audio/video link address is obtained for use when the user needs to download the corresponding audio/video data.
  • the method for obtaining the audio/video link address in the webpage uses the hook program to obtain the real link address of the audio/video file in the webpage, which is convenient for the user to download.
  • FIG. 2 is a schematic flowchart of a second embodiment of a method for obtaining an audio/video link address in a webpage according to the present invention.
  • the audio/video link address of the obtained webpage will be described in more detail.
  • Method flow As shown in FIG. 2, the method process includes:
  • a hook program is established, and the hook program has a dynamic database for acquiring a request packet sent by the web browser to the server. More specifically, Hook is a platform for Windows message processing. Applications can set up subroutines to monitor certain messages in a specified window, and the monitored windows can be created by other processes. When the message arrives, it is processed before the target window processes the message. The hook mechanism allows applications to intercept Windows messages or specific events.
  • the hook program established in the embodiment of the present invention has a dynamic database for intercepting request packets sent by the web browser to the server.
  • step S201 the hook program is injected into the process of the web browser to obtain a request data packet sent by the web browser to the server. More specifically, use the windows hook to inject the browser process (such as IE, Chrome, Safari, Opera, Firefox, etc.), hook the browser process request packet function (send WSASend), the hook program is actually a message processing
  • the program segment through the system call, injects it into the process of the web browser.
  • the hook program first captures the request packet. At this time, the hook program can process (change) the request packet, or continue to deliver the request packet without processing, and can forcibly end the delivery of the request packet. In the embodiment of the present invention, the hook program continues to deliver the request packet sent by the server without processing, but only copies the same request packet itself.
  • the request packets are classified according to their respective adopted network protocols. More specifically, the request data packet is classified according to different network protocols used by the obtained request data packet, and the network protocol for requesting data includes: http request data packet, mms request data packet, rtmp request data packet, rtsp request data Package and more.
  • the reason for classifying the request packet is that it facilitates the subsequent step of parsing the information carried by the request packet according to the corresponding network protocol.
  • step S203 the web browser is simulated to send a page request to the server according to the information in the request data packet and the network protocol adopted by the request data packet. More specifically, this step is to parse the request packet according to the network protocol used by the request packet, and obtain the information of the request packet. The web browser is then simulated to send a page request to the server based on the information in the request packet and the network protocol that the request packet originally employed.
  • the page request is a request for a file attribute, which is far more than the original request data package.
  • the page request in this embodiment is sent to the server, and only requests the file attribute information such as the link address, the server status code, the Content-Length (Content Length), and the Content-Type (Content Type), and is not Requesting additional information such as handshake signals and cookies saves bandwidth between the terminal and the server, and makes subsequent processing more convenient and convenient (because the server feedbacks less information).
  • step S204 the response data packet fed back by the server is received, where the response data packet includes: a server status code, a content length Content-Length, a content type Content-Type, a link address, and a content and a page request in the response data packet.
  • the content requested to be obtained is corresponding, because the content requested in the page request is more than the normal request packet, so the content in the response packet is also less than the content in the normal response packet.
  • the Content-Type record in the response packet is the internal type of the file corresponding to the link address in the response packet
  • the Content-Length record is the size of the file corresponding to the link address in the response packet.
  • step S205 it is determined whether the Content-Type carried in the response packet is a sound/video type; if the determination is yes, step S206 is performed; otherwise, step S207 is performed. More specifically, by determining whether the content/type carried in the response packet is a sound/video type, it can be determined whether the file corresponding to the link address carried in the response packet is an audio/video file.
  • audio and video types include audio, video, flv, mp4, mp3, audio/x-mpeg, audio/x-wav, audio/x-ms-wma, video/x-msvideo, video/mpeg, video/quicktime , video/x-flv , video/mp4 , video/x-ms-asf, video/x-ms-wmv , application/x-octet-stream , binary/octet-stream , application/octet-stream , application/x -shockwave-flash , text/plain , application/x-rhapsodycontent , flv-application/octet-stream, etc.
  • step S206 it is determined that the response data packet carries a link address whose link address is audio/video data; the audio/video link address is obtained and stored locally; when the user needs to download the corresponding audio/video, the user is provided The audio/video link address.
  • the step S206 may also be:
  • step S207 is performed.
  • step S207 it is determined that the response packet carries a link address whose link address is not audio/video data, discards the link address, and searches for the real link address of the audio/video.
  • the method for obtaining the audio/video link address in the webpage provided by the embodiment of the present invention uses the hook program to intercept the request data packet sent by the browser, and then sends the page request through the simulated browser, analyzes the response data packet fed back by the server, and finds The real link address of the audio/video file in the webpage is provided to the user when the user needs to download the corresponding audio/video, which is convenient for the user to operate and save user time.
  • FIG. 3 is a schematic structural diagram of a first embodiment of an apparatus for obtaining a sound/video link address in a webpage according to the present invention. As shown in FIG. 3, the apparatus includes:
  • the request packet obtaining module 1 is configured to inject a hook program into the web browser process of the terminal, and obtain a request data packet sent by the web browser to the server.
  • the simulation requesting module 2 is configured to simulate, according to the request packet, the request data packet acquired by the module 1 to send the page request to the server by the web browser.
  • the link analysis and acquisition module 3 is configured to receive the response data packet fed back by the server, and determine whether the link address in the response data packet is a link address of the audio/video data; if the determination is yes, acquire the audio/video link address.
  • the device for obtaining the audio/video link address of the webpage provided by the embodiment of the present invention uses the hook program to obtain the real link address of the audio/video file in the webpage, which is convenient for the user to download.
  • FIG. 4 is a schematic structural diagram of a second embodiment of an apparatus for acquiring an audio/video link address in a webpage according to the present invention.
  • the structure of the apparatus will be described in more detail, and the apparatus is as shown in FIG. , including: request packet acquisition module 1, simulation request module 2, link analysis and acquisition module 3.
  • the request packet obtaining module 1 is configured to inject a hook program into the web browser process of the terminal, and obtain a request data packet sent by the web browser to the server. More specifically, Hook is a platform for Windows message processing. Applications can set up subroutines to monitor certain messages in a specified window, and the monitored windows can be created by other processes. When the message arrives, it is processed before the target window processes the message. The hook mechanism allows applications to intercept Windows messages or specific events.
  • the hook program established by the request packet obtaining module 1 has a dynamic database for intercepting the request packet sent by the web browser to the server.
  • the request packet obtaining module 1 injects a browser process (such as IE, Chrome, Safari, Opera, Firefox, etc.) with a Windows hook, and requests a packet function (send WSASend) in the browser process.
  • a browser process such as IE, Chrome, Safari, Opera, Firefox, etc.
  • the hook program first captures the request packet.
  • the hook program can process (change) the request packet, or continue to deliver the request packet without processing, and can forcibly end the delivery of the request packet.
  • the hook program of the request packet acquisition module 1 continues to deliver the request packet sent by the server without processing, but copies the same request packet by itself and sends it to the simulation request module 2.
  • the simulation requesting module 2 is configured to simulate, according to the request packet, the request data packet acquired by the module 1 to send the page request to the server by the web browser. More specifically, the analog request module 2 includes:
  • the packet classification unit 21 is configured to classify the request data packets acquired by the request packet obtaining module according to their respective network protocols. More specifically, the packet classification unit 21 classifies the request data packet according to different network protocols used by the obtained request data packet, and the network protocol for requesting the data includes: htt request data packet, mms request data packet, rtmp request data Packages, rtsp request packets, and more.
  • the reason why the packet classification unit 21 classifies the request packet is that the analog request unit 22 parses the information carried by the request packet according to the corresponding network protocol.
  • the simulation requesting unit 22 is configured to simulate, according to the information in the request data packet and the network protocol adopted by the request data packet, the web browser to send a page request to the server. More specifically, the simulation requesting unit 22 parses the request packet according to the classification of the request packet by the packet classification unit 21, and obtains the information of the request packet by using the corresponding network protocol. The simulation request unit 22 then simulates the web browser to send a page request to the server based on the information in the request packet and the network protocol originally used by the request packet.
  • the page request sent by the simulation request unit 22 is a request for a file attribute, which is much larger than the original request data package.
  • the simulation requesting unit 22 sends a page request to the server, and only requests to obtain file attribute information such as a link address, a server status code, a Content-Length (Content Length), and a Content-Type (Content Type), and Do not request to obtain additional information such as handshake signals, cookies, etc., thus saving bandwidth between the terminal and the server, and making the subsequent processing more simple and convenient (because the information fed back by the server is small).
  • the link analysis and acquisition module 3 is configured to receive the response data packet fed back by the server, and determine whether the link address in the response data packet is a link address of the audio/video data; if the determination is yes, acquire the audio/video link address. More specifically, the link analysis and acquisition module 3 includes:
  • the data packet receiving unit 31 is configured to receive a response data packet fed back by the server, where the response data packet includes: a server status code, a content length Content-Length, a content type Content-Type, a link address, and a content in the response data packet.
  • the response data packet includes: a server status code, a content length Content-Length, a content type Content-Type, a link address, and a content in the response data packet.
  • the Content-Type record in the response packet is the internal type of the file corresponding to the link address in the response packet
  • the Content-Length record is the size of the file corresponding to the link address in the response packet.
  • the first determining unit 32 is configured to determine whether the Content-Type carried in the response data packet is a sound/video type; if the determination is yes, determining that the response data packet carries a link whose link address is audio/video data Addressing, and obtaining the audio/video link address; otherwise, determining that the response packet carries a link address that is not a link address of audio/video data.
  • the first determining unit 32 determines whether the file corresponding to the link address carried in the response data packet is audio/video by determining whether the content/type in the response data packet is a sound/video type.
  • Audio and video types include audio, video, flv, mp4, mp3, audio/x-mpeg, audio/x-wav, audio/x-ms-wma, video/x-msvideo, video/mpeg, video/quicktime, video/ X-flv , video/mp4 , video/x-ms-asf , video/x-ms-wmv , application/x-octet-stream , binary/octet-stream , application/octet-stream , application/x-shockwave- Flash , text/plain , application/x-rhapsodycontent , flv-application/octet-stream, etc.
  • the first determining unit 32 if it is determined that the link address of the response data packet is the link address of the audio/video data, acquires the audio/video link address and stores it locally; when the user needs to download the corresponding audio/video, The audio/video link address is provided to the user. If the first determining unit 32 determines that the link address in the answer packet is not the link address of the audio/video data, the link address is discarded, and the real link address of the audio/video is re-searched.
  • the embodiment of the present invention further provides a third embodiment of the device for acquiring the audio/video link address in the webpage.
  • the apparatus for obtaining the audio/video link address of the webpage includes: The packet acquisition module 4, the simulation request module 5, the link analysis and acquisition module 6, and the request packet acquisition module 4 and the simulation request module 5 have the same data packet acquisition module 1 and simulation request module 2 as in the previous embodiment.
  • the link analysis and acquisition module 6 is configured to receive a response packet fed back by the server, and determine that the response packet carries a link. Whether the address is the link address of the audio/video data; if the determination is yes, the audio/video link address is obtained. More specifically, the link analysis and acquisition module 6 includes:
  • a data packet receiving unit 61 configured to receive a response data packet fed back by the server, where the response data packet It includes: server status code, content length Content-Length, content type Content-Type, link address.
  • the second determining unit 62 is configured to determine whether the Content-Type carried in the response data packet is of a sound/video type; if the determination is no, determining that the response data packet carries a link address that is not a link address of the audio/video data; If the determination is YES, the third determination unit 63 further determines.
  • the third determining unit 63 is configured to further determine whether the Content-Length is greater than a preset value (for example, 1K); if the determination is yes, the third determining unit 63 determines that the response packet carries the link address as a tone/ The link address of the video data is stored locally; when the user needs to download the corresponding audio/video, the audio/video link address is provided to the user.
  • a preset value for example, 1K
  • the third determining unit 63 determines that the link address in the response packet is not the link address of the audio/video data, discards the link address, and searches for the real link of the audio/video. address.
  • the device for obtaining the audio/video link address of the webpage provided by the embodiment of the present invention intercepts the request data packet sent by the browser by using the hook program, and then sends the page request through the simulated browser, analyzes the response data packet fed back by the server, and finds The real link address of the audio/video file in the webpage is provided to the user when the user needs to download the corresponding audio/video, which is convenient for the user to operate and save user time.
  • the storage medium may be a magnetic disk, an optical disk, a read-only memory (ROM), or a random access memory (RAM).

Landscapes

  • Engineering & Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

本发明实施例公开了一种获取网页中音/视频链接地址的方法及装置，该方法包括：向终端的网页浏览器进程中注入钩子程序，获取所述网页浏览器向服务器发送的请求数据包；根据所述请求数据包，模拟所述网页浏览器向所述服务器发送页面请求；接收所述服务器反馈的应答数据包，判断所述应答数据包中携带链接地址是否为音/视频数据的链接地址；若判断为是，则获取该音/视频链接地址。本发明实施例所提供的获取网页中音/视频链接地址的方法及装置，利用钩子程序，在用户想下载网页中的音/视频文件，又找不到音/视频真实的链接地址时，能准确帮助用户找到音视频真实的链接地址。

Description

一种获取网页中音 /视频链接地址的方法及装置
本申请要求于 2011年 7月 21 日提交中国专利局、申请号为 2011102052416, 发明名称为 "一种获取网页中音 /视频链接地址的方法及装置" 的中国专利申请 的优先权， 其全部内容通过引用结合在本申请中。 技术领域
本发明涉及计算机技术领域， 尤其涉及一种获取网页中音 /视频链接地址的 方法及装置。 背景技术
随着互联网的发展， 越来越多的网站为增加网页总的信息量或者为了使用 户更加感兴趣， 而在网页中增加一些音频或视频， 通常的做法是在文字页面中 开一个播放窗口 ,内嵌的媒体播放器, ^口 real player, windows media player和 flash player等， 用户可以直接通过该窗口播放可定的音频或视频。
但是， 这些播放器在播放视频音频或视频时， 通常会隐藏正在播放的音视 频真实的链接地址， 用户想下载这些音视频文件时， 通常找不到音视频真实的 链接地址。
基于上述问题， 本发明人希望利用钩子程序帮助用户找到音视频真实的链 接地址。
钩子 (Hook), 是 Windows消息处理机制的一个平台， 应用程序可以在上面 设置子程以监视指定窗口的某种消息， 而且所监视的窗口可以是其他进程所创 建的。 当消息到达后， 在目标窗口处理消息之前处理它。 钩子机制允许应用程 序截获处理 Windows消息或特定事件。
钩子程序实际上是一个处理消息的程序段， 通过系统调用， 把它注入系统。 每当特定的消息发出， 在没有到达目的窗口前， 钩子程序就先捕获该消息， 这 时钩子程序即可以加工处理（改变）该消息， 也可以不作处理而继续传递该消 息， 还可以强制结束消息的传递。
钩子程序也可以理解为 Windows留给我们的后门， 比如用户想控制键盘， 在 DOS时代很筒单通过 INT即可， 而 Windows时代不允许我们直接操作硬件； 由于 Windows是消息驱动， 所以我们可以通过拉截键盘消息以达到控制键盘的 目的。 但是， 程序控制自己进程的消息固然很筒单， 要控制所有程序进程的消 息要利用钩子程序了。 将钩子程序放在 DLL中， 这样所有的有关键盘的消息都 必须经过钩子程序过滤了。 发明内容
本发明实施例所要解决的技术问题在于， 提供一种获取网页中音 /视频链接 地址的方法及装置， 利用钩子程序， 在用户想下载网页中的音 /视频文件， 又找 不到音 /视频真实的链接地址时， 能准确帮助用户找到音视频真实的链接地址。
为了解决上述技术问题， 本发明实施例提供了一种获取网页中音 /视频链接 地址的方法， 包括：
向终端的网页浏览器进程中注入钩子程序， 获取所述网页浏览器向服务器 发送的请求数据包；
根据所述请求数据包， 模拟所述网页浏览器向所述服务器发送页面请求； 接收所述服务器反馈的应答数据包， 判断所述应答数据包中携带链接地址 是否为音 /视频数据的链接地址； 若判断为是， 则获取该音 /视频链接地址。
其中， 所述向终端的网页浏览器进程中注入钩子程序， 获取所述网页浏览 器向服务器发送的请求数据包， 包括：
建立钩子程序， 所述钩子程序中具有获取所述网页浏览器向服务器发送的 请求数据包的动态数据库；
将所述钩子程序注入所述网页浏览器的进程中， 获取所述网页浏览器向服 务器发送的请求数据包。
其中， 所述根据所述请求数据包， 模拟所述网页浏览器向所述服务器发送 页面请求， 包括：
将所述请求数据包按照其各自采用的网络协议进行分类；
根据所述请求数据包中的信息， 以及该请求数据包采用的网络协议， 模拟 所述网页浏览器向所述服务器发送页面请求； 所述页面请求为文件属性的请求。
其中， 所述接收所述服务器反馈的应答数据包， 判断所述应答数据包中携 带链接地址是否为音 /视频数据的链接地址， 包括：
接收所述服务器反馈的应答数据包， 所述应答数据包中包括： 服务器状态 码、 内容长度 Content-Length, 内容类型 Content-Type、 链接地址； 判断所述应答数据包中携带的 Content-Type是否为音 /视频类型； 若判断为是， 则判定所述应答数据包中携带链接地址为音 /视频数据的链接 地址； 否则， 判定所述应答数据包中携带链接地址不是音 /视频数据的链接地址。
其中， 所述接收所述服务器反馈的应答数据包， 判断所述应答数据包中携 带链接地址是否为音 /视频数据的链接地址， 包括：
接收所述服务器反馈的应答数据包， 所述应答数据包中包括： 服务器状态 码、 内容长度 Content-Length、 内容类型 Content-Type、 链接地址；
判断所述应答数据包中携带的 Content-Type是否为音 /视频类型； 若判断为 否， 则判定所述应答数据包中携带链接地址不是音 /视频数据的链接地址；
若判断为是， 则进一步判断所述 Content-Length是否大于预设的数值； 若判 断为是， 则判定所述应答数据包中携带链接地址为音 /视频数据的链接地址； 否 则， 判定所述应答数据包中携带链接地址不是音 /视频数据的链接地址。
其中， 所述获取该音 /视频链接地址包括：
获取该音 /视频链接地址， 并存储在本地；
当用户需要下载对应的音 /视频时， 向用户提供所述音 /视频链接地址。
相应的， 本发明实施例还提供一种获取网页中音 /视频链接地址的装置， 包 括：
请求数据包获取模块， 用于向终端的网页浏览器进程中注入钩子程序， 获 取所述网页浏览器向服务器发送的请求数据包；
模拟请求模块， 用于根据所述请求数据包获取模块所获取的请求数据包， 模拟所述网页浏览器向所述服务器发送页面请求；
链接分析及获取模块， 用于接收所述服务器反馈的应答数据包， 判断所述 应答数据包中携带链接地址是否为音 /视频数据的链接地址； 若判断为是， 则获 取该音 /视频链接地址。
其中， 所述模拟请求模块包括：
数据包分类单元， 用于将所述请求数据包获取模块所获取的请求数据包按 照其各自采用的网络协议进行分类；
模拟请求单元， 用于根据所述请求数据包中的信息， 以及该请求数据包采 用的网络协议， 模拟所述网页浏览器向所述服务器发送页面请求。
其中， 所述链接分析及获取模块包括： 数据包接收单元， 用于接收服务器反馈的应答数据包， 所述应答数据包中 包括： 服务器状态码、 内容长度 Content-Length, 内容类型 Content-Type、 链接 地址；
第一判断单元， 用于判断所述应答数据包中携带的 Content-Type是否为音 / 视频类型； 若判断为是， 则判定所述应答数据包中携带链接地址为音 /视频数据 的链接地址； 否则， 判定所述应答数据包中携带链接地址不是音 /视频数据的链 接地址。
其中， 所述链接分析及获取模块包括：
数据包接收单元， 用于接收服务器反馈的应答数据包， 所述应答数据包中 包括： 服务器状态码、 内容长度 Content-Length, 内容类型 Content-Type、 链接 地址；
第二判断单元， 判断所述应答数据包中携带的 Content-Type是否为音 /视频 类型； 若判断为否， 则判定所述应答数据包中携带链接地址不是音 /视频数据的 链接地址； 若判断为是， 则交由第三判断单元进一步判断；
第三判断单元，用于判断所述 Content-Length是否大于预设的数值； 若判断 为是， 则判定所述应答数据包中携带链接地址为音 /视频数据的链接地址； 否贝J , 判定所述应答数据包中携带链接地址不是音 /视频数据的链接地址。
本发明实施例提供的获取网页中音 /视频链接地址的方法及装置， 利用钩子 程序，在用户想下载网页中的音 /视频文件，又找不到音 /视频真实的链接地址时， 能准确帮助用户找到音视频真实的链接地址。 附图说明 例或现有技术描述中所需要使用的附图作筒单地介绍， 显而易见地， 下面描述 中的附图仅仅是本发明的一些实施例， 对于本领域普通技术人员来讲， 在不付 出创造性劳动性的前提下， 还可以根据这些附图获得其他的附图。
图 1为本发明提供的获取网页中音 /视频链接地址的方法第一实施例流程示 意图；
图 2为本发明提供的获取网页中音 /视频链接地址的方法第二实施例流程示 意图； 图 3为本发明提供的获取网页中音 /视频链接地址的装置第一实施例结构示 意图；
图 4为本发明提供的获取网页中音 /视频链接地址的装置第二实施例结构示 意图；
图 5为本发明提供的获取网页中音 /视频链接地址的装置第三实施例结构示 意图。 具体实施方式
本发明实施例提供的获取网页中音 /视频链接地址的方法及装置， 利用钩子 程序，在用户想下载网页中的音 /视频文件，又找不到音 /视频真实的链接地址时， 能准确帮助用户找到音视频真实的链接地址。
下面将结合本发明实施例中的附图， 对本发明实施例中的技术方案进行清 楚、 完整地描述， 显然， 所描述的实施例仅仅是本发明一部分实施例， 而不是 全部的实施例。 基于本发明中的实施例， 本领域普通技术人员在没有作出创造 性劳动前提下所获得的所有其他实施例， 都属于本发明保护的范围。
参见图 1 , 为本发明提供的获取网页中音 /视频链接地址的方法第一实施例 流程示意图， 如图 1所示， 包括：
在步骤 S100, 向终端的网页浏览器进程中注入钩子程序， 并利用所述钩子 程序， 获取网页浏览器向服务器发送的请求数据包。
在步骤 S101 , 根据获取的所述请求数据包， 模拟所述网页浏览器向所述服 务器发送页面请求。
在步骤 S102, 接收所述服务器反馈的应答数据包。 并判断所述应答数据包 中携带链接地址是否为音 /视频数据的链接地址，若判断为是，则执行步骤 S103; 否则结束本流程。
在步骤 S103 ,获取该音 /视频链接地址，供用户需要下载对应的音 /视频数据 时使用。
本发明实施例提供的获取网页中音 /视频链接地址的方法， 利用钩子程序， 获取网页中的音 /视频文件真实的链接地址， 方便用户下载。
参见图 2, 为本发明提供的获取网页中音 /视频链接地址的方法第二实施例 流程示意图。 在本实施例中， 将更为详细的描述该获取网页中音 /视频链接地址 的方法流程。 如图 2所示， 该方法流程包括：
在步骤 S200, 建立钩子程序， 所述钩子程序中具有获取所述网页浏览器向 服务器发送的请求数据包的动态数据库。 更为具体的，钩子 (Hook),是 Windows 消息处理机制的一个平台， 应用程序可以在上面设置子程以监视指定窗口的某 种消息， 而且所监视的窗口可以是其他进程所创建的。 当消息到达后， 在目标 窗口处理消息之前处理它。 钩子机制允许应用程序截获处理 Windows消息或特 定事件。 在本发明实施例中建立的钩子程序具有一个动态数据库， 用于截获网 页浏览器向服务器发送的请求数据包。
在步骤 S201 , 将所述钩子程序注入所述网页浏览器的进程中， 获取所述网 页浏览器向服务器发送的请求数据包。 更为具体的， 用 windows钩子注入浏览 器进程 (如 IE、 Chrome, Safari, Opera, Firefox等）， 挂接浏览器进程中请求数 据包函数（ send WSASend )该钩子程序实际上是一个处理消息的程序段， 通过 系统调用， 把它注入网页浏览器的进程中。 每当网页浏览器有请求数据包发出， 钩子程序就先捕获该请求数据包。 这时钩子程序即可以加工处理 （改变）该请 求数据包， 也可以不作处理而继续传递该请求数据包， 还可以强制结束请求数 据包的传递。 在本发明实施例中， 钩子程序对服务器发送的请求数据包不作处 理而继续传递， 只是自身再复制一个相同的请求数据包。
在步骤 S202, 将所述请求数据包按照其各自采用的网络协议进行分类。 更 为具体的， 根据获取的请求数据包所采用的不同网络协议， 对请求数据包进行 分类， 请求数据的网络协议包括： http请求数据包， mms请求数据包， rtmp请 求数据包， rtsp请求数据包等等。 对请求数据包进行分类的原因在于， 利于后续 步骤根据对应的网络协议解析出所述请求数据包所携带的信息。
在步骤 S203 , 根据所述请求数据包中的信息， 以及该请求数据包采用的网 络协议， 模拟所述网页浏览器向所述服务器发送页面请求。 更为具体的， 本步 骤为根据所述请求数据包所采用的网络协议， 解析该请求数据包， 获取所述请 求数据包的信息。 然后根据所述请求数据包中的信息， 以及该请求数据包原本 采用的网络协议， 模拟所述网页浏览器向所述服务器发送页面请求。
进一步的， 所述页面请求为文件属性的请求， 远比原本的请求数据包筒单。 本实施例中的页面请求发送给服务器， 仅请求获取链接地址、 服务器状态码、 Content-Length (内容长度）、 Content-Type (内容类型 )等文件属性信息， 并不 请求获取握手信号、 Cookie 等附加信息， 既节约终端与服务器之间的带宽， 又 使后续的处理更加筒单、 方便（因为服务器反馈的信息少）。
在步骤 S204, 接收服务器反馈的应答数据包， 所述应答数据包中包括： 服 务器状态码、 内容长度 Content-Length, 内容类型 Content-Type、 链接地址； 该 应答数据包中的内容与页面请求中请求获取的内容是对应的， 因为页面请求中 请求获取的内容比正常的请求数据包筒单， 所以应答数据包中的内容也比正常 的应答数据包中的内容更少。
进一步的， 应答数据包中 Content-Type记录的是应答数据包中链接地址所 对应的文件的内型， Content-Length记录的则是应答数据包中链接地址所对应的 文件的大小。
在步骤 S205 , 判断应答数据包中携带的 Content-Type是否为音 /视频类型； 若判断为是， 则执行步骤 S206; 否则， 执行步骤 S207。 更为具体的， 通过判断 应答数据包中携带的 Content-Type中的是否是音 /视频类型， 就可以判断应答数 据包中携带的链接地址所对应的文件是否是音 /视频文件。 进一步的， 音视频类 型包括 audio, video, flv, mp4, mp3 , audio/x-mpeg, audio/x-wav, audio/x-ms-wma , video/x-msvideo , video/mpeg , video/quicktime , video/x-flv , video/mp4 , video/x-ms-asf, video/x-ms-wmv , application/x-octet-stream , binary/octet-stream , application/octet-stream , application/x-shockwave-flash , text/plain , application/x-rhapsodycontent , flv-application/octet-stream等。
在步骤 S206, 判定所述应答数据包中携带链接地址为音 /视频数据的链接地 址； 获取该音 /视频链接地址， 并存储在本地； 当用户需要下载对应的音 /视频时， 向用户提供所述音 /视频链接地址。
优选的， 为了提高判断的准确定， 本步骤 S206还可以是：
进一步判断所述 Content-Length是否大于预设的数值 (例如 1K ); 若判断为 是， 则判定所述应答数据包中携带链接地址为音 /视频数据的链接地址， 获取该 音 /视频链接地址， 并存储在本地； 当用户需要下载对应的音 /视频时， 向用户提 供所述音 /视频链接地址。 若所述 Content-Length小于预设的数值， 则执行步骤 S207。
在步骤 S207, 判定所述应答数据包中携带链接地址不是音 /视频数据的链接 地址， 丢弃该链接地址， 重新寻找音 /视频的真实链接地址。 本发明实施例提供的获取网页中音 /视频链接地址的方法， 利用钩子程序， 截获浏览器发送的请求数据包， 再通过模拟浏览器发送页面请求后， 分析服务 器反馈的应答数据包， 找到载网页中的音 /视频文件的真实链接地址， 当用户需 要下载对应的音 /视频时向用户提供， 方便用户操作节约用户时间。
参见图 3 , 为本发明提供的获取网页中音 /视频链接地址的装置第一实施例 结构示意图， 如图 3所示， 该装置包括：
请求数据包获取模块 1 , 用于向终端的网页浏览器进程中注入钩子程序， 获 取所述网页浏览器向服务器发送的请求数据包。
模拟请求模块 2,用于根据所述请求数据包获取模块 1所获取的请求数据包， 模拟所述网页浏览器向所述服务器发送页面请求。
链接分析及获取模块 3 , 用于接收所述服务器反馈的应答数据包， 判断所述 应答数据包中携带链接地址是否为音 /视频数据的链接地址； 若判断为是， 则获 取该音 /视频链接地址。
本发明实施例提供的获取网页中音 /视频链接地址的装置， 利用钩子程序， 获取网页中的音 /视频文件真实的链接地址， 方便用户下载。
参见图 4, 为本发明提供的获取网页中音 /视频链接地址的装置第二实施例 结构示意图， 在本实施例中， 将更为详细的描述该装置的结构， 该装置如图 4 所示， 包括： 请求数据包获取模块 1、 模拟请求模块 2、 链接分析及获取模块 3。
请求数据包获取模块 1 , 用于向终端的网页浏览器进程中注入钩子程序， 获 取所述网页浏览器向服务器发送的请求数据包。 更为具体的， 钩子 (Hook), 是 Windows 消息处理机制的一个平台， 应用程序可以在上面设置子程以监视指定 窗口的某种消息， 而且所监视的窗口可以是其他进程所创建的。 当消息到达后， 在目标窗口处理消息之前处理它。 钩子机制允许应用程序截获处理 Windows消 息或特定事件。 在本发明实施例中请求数据包获取模块 1 建立的钩子程序具有 一个动态数据库， 用于截获网页浏览器向服务器发送的请求数据包。
进一步的， 请求数据包获取模块 1用 windows钩子注入浏览器进程 (如 IE、 Chrome, Safari, Opera, Firefox等)， 挂接浏览器进程中请求数据包函数（ send WSASend )。每当网页浏览器有请求数据包发出， 钩子程序就先捕获该请求数据 包。 这时钩子程序即可以加工处理（改变） 该请求数据包， 也可以不作处理而 继续传递该请求数据包， 还可以强制结束请求数据包的传递。 在本发明实施例 中， 请求数据包获取模块 1 的钩子程序对服务器发送的请求数据包不作处理而 继续传递， 只是自身再复制一个相同的请求数据包发送给模拟请求模块 2。
模拟请求模块 2,用于根据所述请求数据包获取模块 1所获取的请求数据包， 模拟所述网页浏览器向所述服务器发送页面请求。 更为具体的，模拟请求模块 2 包括：
数据包分类单元 21 , 用于将所述请求数据包获取模块所获取的请求数据包 按照其各自采用的网络协议进行分类。 更为具体的， 数据包分类单元 21根据获 取的请求数据包所采用的不同网络协议， 对请求数据包进行分类， 请求数据的 网络协议包括： htt 请求数据包， mms请求数据包， rtmp请求数据包， rtsp请求 数据包等等。 数据包分类单元 21对请求数据包进行分类的原因在于， 利于模拟 请求单元 22根据对应的网络协议解析出所述请求数据包所携带的信息。
模拟请求单元 22, 用于根据所述请求数据包中的信息， 以及该请求数据包 采用的网络协议， 模拟所述网页浏览器向所述服务器发送页面请求。 更为具体 的， 模拟请求单元 22根据数据包分类单元 21对请求数据包的分类， 采用对应 的网络协议解析请求数据包， 获取所述请求数据包的信息。 然后模拟请求单元 22根据所述请求数据包中的信息， 以及该请求数据包原本采用的网络协议， 模 拟所述网页浏览器向所述服务器发送页面请求。
进一步的， 模拟请求单元 22发送的页面请求为文件属性的请求， 远比原本 的请求数据包筒单。 本实施例中， 模拟请求单元 22将页面请求发送给服务器， 仅请求获取链接地址、月良务器状态码、 Content-Length (内容长度）、 Content-Type (内容类型）等文件属性信息， 并不请求获取握手信号、 Cookie 等附加信息， 如此， 既节约终端与服务器之间的带宽， 又使后续的处理更加筒单、 方便（因 为服务器反馈的信息少）。
链接分析及获取模块 3 , 用于接收所述服务器反馈的应答数据包， 判断所述 应答数据包中携带链接地址是否为音 /视频数据的链接地址； 若判断为是， 则获 取该音 /视频链接地址。 更为具体的， 该链接分析及获取模块 3包括：
数据包接收单元 31 , 用于接收服务器反馈的应答数据包， 所述应答数据包 中包括： 服务器状态码、 内容长度 Content-Length, 内容类型 Content-Type、 链 接地址； 该应答数据包中的内容与模拟请求单元 22发送的页面请求中请求获取 的内容是对应的， 因为页面请求中请求获取的内容比正常的请求数据包筒单， 进一步的， 应答数据包中 Content-Type记录的是应答数据包中链接地址所 对应的文件的内型， Content-Length记录的则是应答数据包中链接地址所对应的 文件的大小。
第一判断单元 32 , 用于判断所述应答数据包中携带的 Content-Type是否为 音 /视频类型； 若判断为是， 则判定所述应答数据包中携带链接地址为音 /视频数 据的链接地址， 并获取该音 /视频链接地址； 否则， 判定所述应答数据包中携带 链接地址不是音 /视频数据的链接地址。
更为具体的， 第一判断单元 32通过判断应答数据包中携带的 Content-Type 中的是否是音 /视频类型， 就可以判断应答数据包中携带的链接地址所对应的文 件是否是音 /视频文件。 音视频类型包括 audio , video , flv , mp4 , mp3 , audio/x-mpeg , audio/x-wav , audio/x-ms-wma , video/x-msvideo , video/mpeg , video/quicktime , video/x-flv , video/mp4 , video/x-ms-asf , video/x-ms-wmv , application/x-octet-stream , binary/octet-stream , application/octet-stream , application/x-shockwave-flash , text/plain , application/x-rhapsodycontent , flv-application/octet-stream等。
第一判断单元 32 若判定所述应答数据包中携带链接地址为音 /视频数据的 链接地址， 则获取该音 /视频链接地址， 并存储在本地； 当用户需要下载对应的 音 /视频时， 向用户提供所述音 /视频链接地址。 第一判断单元 32若判定所述应 答数据包中携带链接地址不是音 /视频数据的链接地址， 则丢弃该链接地址， 重 新寻找音 /视频的真实链接地址。
优选的， 为了提高判断的准确定， 本发明实施例还提供获取网页中音 /视频 链接地址的装置第三实施例， 在本实施例中， 获取网页中音 /视频链接地址的装 置包括： 请求数据包获取模块 4、 模拟请求模块 5、 链接分析及获取模块 6, 且 请求数据包获取模块 4、 模拟请求模块 5与上一实施例中的数据包获取模块 1、 模拟请求模块 2具有相同的结构， 不同之处在于链接分析及获耳 ^莫块 6, 在本实 施例中， 该链接分析及获取模块 6用于接收所述服务器反馈的应答数据包， 判 断所述应答数据包中携带链接地址是否为音 /视频数据的链接地址；若判断为是， 则获取该音 /视频链接地址。 更为具体的， 该链接分析及获取模块 6包括：
数据包接收单元 61 , 用于接收服务器反馈的应答数据包， 所述应答数据包 中包括： 服务器状态码、 内容长度 Content-Length, 内容类型 Content-Type、 链 接地址。
第二判断单元 62, 判断所述应答数据包中携带的 Content-Type是否为音 /视 频类型； 若判断为否， 则判定所述应答数据包中携带链接地址不是音 /视频数据 的链接地址； 若判断为是， 则交由第三判断单元 63进一步判断。
第三判断单元 63 , 用于进一步判断所述 Content-Length是否大于预设的数 值（例如 1K ); 若判断为是， 则第三判断单元 63判定所述应答数据包中携带链 接地址为音 /视频数据的链接地址， 并存储在本地； 当用户需要下载对应的音 /视 频时， 向用户提供所述音 /视频链接地址。
若所述 Content-Length小于预设的数值， 则第三判断单元 63判定所述应答 数据包中携带链接地址不是音 /视频数据的链接地址， 丢弃该链接地址， 重新寻 找音 /视频的真实链接地址。
本发明实施例提供的获取网页中音 /视频链接地址的装置， 利用钩子程序， 截获浏览器发送的请求数据包， 再通过模拟浏览器发送页面请求后， 分析服务 器反馈的应答数据包， 找到载网页中的音 /视频文件的真实链接地址， 当用户需 要下载对应的音 /视频时向用户提供， 方便用户操作节约用户时间。
本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程， 是可以通过计算机程序来指令相关的硬件来完成， 所述的程序可存储于一计算 机可读取存储介质中， 该程序在执行时， 可包括如上述各方法的实施例的流程。 其中， 所述的存储介质可为磁碟、 光盘、 只读存储记忆体（Read-Only Memory, ROM )或随机存储记忆体（Random Access Memory, RAM )等。
以上所揭露的仅为本发明一种较佳实施例而已， 当然不能以此来限定本发 明之权利范围， 因此依本发明权利要求所作的等同变化， 仍属本发明所涵盖的 范围。

Claims

权 利 要 求
1、 一种获取网页中音 /视频链接地址的方法， 其特征在于， 包括：
向终端的网页浏览器进程中注入钩子程序， 获取所述网页浏览器向服务器 发送的请求数据包；
根据所述请求数据包， 模拟所述网页浏览器向所述服务器发送页面请求； 接收所述服务器反馈的应答数据包， 判断所述应答数据包中携带链接地址 是否为音 /视频数据的链接地址； 若判断为是， 则获取该音 /视频链接地址。
2、 如权利要求 1所述的获取网页中音 /视频链接地址的方法， 其特征在于， 所述向终端的网页浏览器进程中注入钩子程序， 获取所述网页浏览器向服务器 发送的请求数据包， 包括：
建立钩子程序， 所述钩子程序中具有获取所述网页浏览器向服务器发送的 请求数据包的动态数据库；
将所述钩子程序注入所述网页浏览器的进程中， 获取所述网页浏览器向服 务器发送的请求数据包。
3、 如权利要求 1所述的获取网页中音 /视频链接地址的方法， 其特征在于， 所述根据所述请求数据包， 模拟所述网页浏览器向所述服务器发送页面请求， 包括：
将所述请求数据包按照其各自采用的网络协议进行分类；
根据所述请求数据包中的信息， 以及该请求数据包采用的网络协议， 模拟 所述网页浏览器向所述服务器发送页面请求； 所述页面请求为文件属性的请求。
4、 如权利要求 1所述的获取网页中音 /视频链接地址的方法， 其特征在于， 所述接收所述服务器反馈的应答数据包， 判断所述应答数据包中携带链接地址 是否为音 /视频数据的链接地址， 包括：
接收所述服务器反馈的应答数据包， 所述应答数据包中包括： 服务器状态 码、 内容长度 Content-Length, 内容类型 Content-Type、 链接地址；
判断所述应答数据包中携带的 Content-Type是否为音 /视频类型；
若判断为是， 则判定所述应答数据包中携带链接地址为音 /视频数据的链接 地址； 否则， 判定所述应答数据包中携带链接地址不是音 /视频数据的链接地址。
5、 如权利要求 1所述的获取网页中音 /视频链接地址的方法， 其特征在于， 所述接收所述服务器反馈的应答数据包， 判断所述应答数据包中携带链接地址 是否为音 /视频数据的链接地址， 包括：
接收所述服务器反馈的应答数据包， 所述应答数据包中包括： 服务器状态 码、 内容长度 Content-Length, 内容类型 Content-Type、 链接地址；
判断所述应答数据包中携带的 Content-Type是否为音 /视频类型； 若判断为 否， 则判定所述应答数据包中携带链接地址不是音 /视频数据的链接地址；
若判断为是， 则进一步判断所述 Content-Length是否大于预设的数值； 若判 断为是， 则判定所述应答数据包中携带链接地址为音 /视频数据的链接地址； 否 则， 判定所述应答数据包中携带链接地址不是音 /视频数据的链接地址。
6、 如权利要求 1至 5中任一项所述的获取网页中音 /视频链接地址的方法， 其特征在于， 所述获取该音 /视频链接地址包括：
获取该音 /视频链接地址， 并存储在本地；
当用户需要下载对应的音 /视频时， 向用户提供所述音 /视频链接地址。
7、 一种获取网页中音 /视频链接地址的装置， 其特征在于， 包括： 请求数据包获取模块， 用于向终端的网页浏览器进程中注入钩子程序， 获 取所述网页浏览器向服务器发送的请求数据包；
模拟请求模块， 用于根据所述请求数据包获取模块所获取的请求数据包， 模拟所述网页浏览器向所述服务器发送页面请求；
链接分析及获取模块， 用于接收所述服务器反馈的应答数据包， 判断所述 应答数据包中携带链接地址是否为音 /视频数据的链接地址； 若判断为是， 则获 取该音 /视频链接地址。
8、 如权利要求 7所述的获取网页中音 /视频链接地址的装置， 其特征在于， 所述模拟请求模块包括：
数据包分类单元， 用于将所述请求数据包获取模块所获取的请求数据包按 照其各自采用的网络协议进行分类；
模拟请求单元， 用于根据所述请求数据包中的信息， 以及该请求数据包采 用的网络协议， 模拟所述网页浏览器向所述服务器发送页面请求。
9、 如权利要求 7所述的获取网页中音 /视频链接地址的装置， 其特征在于， 所述链接分析及获取模块包括：
数据包接收单元， 用于接收服务器反馈的应答数据包， 所述应答数据包中 包括： 服务器状态码、 内容长度 Content-Length, 内容类型 Content-Type、 链接 地址；
第一判断单元， 用于判断所述应答数据包中携带的 Content-Type是否为音 / 视频类型； 若判断为是， 则判定所述应答数据包中携带链接地址为音 /视频数据 的链接地址； 否则， 判定所述应答数据包中携带链接地址不是音 /视频数据的链 接地址。
10、如权利要求 7所述的获取网页中音 /视频链接地址的装置， 其特征在于， 所述链接分析及获取模块包括：
数据包接收单元， 用于接收服务器反馈的应答数据包， 所述应答数据包中 包括： 服务器状态码、 内容长度 Content-Length, 内容类型 Content-Type、 链接 地址；
第二判断单元， 判断所述应答数据包中携带的 Content-Type是否为音 /视频 类型； 若判断为否， 则判定所述应答数据包中携带链接地址不是音 /视频数据的 链接地址； 若判断为是， 则交由第三判断单元进一步判断；
第三判断单元，用于判断所述 Content-Length是否大于预设的数值； 若判断 为是， 则判定所述应答数据包中携带链接地址为音 /视频数据的链接地址； 否贝J , 判定所述应答数据包中携带链接地址不是音 /视频数据的链接地址。
PCT/CN2011/084171 2011-07-21 2011-12-17 一种获取网页中音/视频链接地址的方法及装置 WO2013010369A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201110205241.6 2011-07-21
CN201110205241.6A CN102360349B (zh) 2011-07-21 2011-07-21 一种获取网页中音/视频链接地址的方法及装置

Publications (1)

Publication Number Publication Date
WO2013010369A1 true WO2013010369A1 (zh) 2013-01-24

Family

ID=45585678

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2011/084171 WO2013010369A1 (zh) 2011-07-21 2011-12-17 一种获取网页中音/视频链接地址的方法及装置

Country Status (2)

Country Link
CN (1) CN102360349B (zh)
WO (1) WO2013010369A1 (zh)

Families Citing this family (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102857575B (zh) * 2012-09-21 2016-12-21 深圳市宜搜科技发展有限公司 一种互联网资源的下载方法及系统
CN103024044B (zh) * 2012-12-14 2016-07-06 北京奇虎科技有限公司 网页下载方法及装置
CN102984275B (zh) * 2012-12-14 2016-09-21 北京奇虎科技有限公司 进行网页下载的方法及浏览器
CN103825783A (zh) * 2014-03-10 2014-05-28 珠海市君天电子科技有限公司 一种测试方法及装置
CN104080016B (zh) * 2014-06-25 2018-08-17 北京奇虎科技有限公司 一种浏览器中进行音视频信息显示的方法和装置
CN105721387A (zh) * 2014-12-01 2016-06-29 北京蓝光引力网络股份有限公司 防止网络劫持的方法
CN107292165B (zh) * 2016-03-30 2020-05-01 无锡天脉聚源传媒科技有限公司 一种函数处理方法及装置
CN106649531A (zh) * 2016-10-24 2017-05-10 福建中金在线信息科技有限公司 一种网页检测方法及装置
CN107256276A (zh) * 2017-08-01 2017-10-17 北京合天智汇信息技术有限公司 一种基于云平台的移动App内容安全获取方法及设备
CN111565336B (zh) * 2020-05-22 2022-12-27 郑州阿帕斯科技有限公司 一种视频播放方法和装置

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2005056286A (ja) * 2003-08-07 2005-03-03 Nec Engineering Ltd ウェブブラウザにおける拡大表示方法および拡大表示プログラム
CN101212485A (zh) * 2006-12-28 2008-07-02 中国科学院计算技术研究所 一种获取流媒体链接地址的方法
CN101645815A (zh) * 2008-08-06 2010-02-10 百度在线网络技术（北京）有限公司 音视频文件下载提示方法
CN102098327A (zh) * 2010-12-15 2011-06-15 百度在线网络技术（北京）有限公司 在线视频嗅探下载方法及装置

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101715004B (zh) * 2009-11-12 2013-01-09 中国科学院计算技术研究所 面向网络视频的分布式采集方法和系统
CN101916283B (zh) * 2010-08-17 2012-08-08 奇诺光瑞电子(深圳)有限公司 由动态网页上获取链接信息的方法及其服务器

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2005056286A (ja) * 2003-08-07 2005-03-03 Nec Engineering Ltd ウェブブラウザにおける拡大表示方法および拡大表示プログラム
CN101212485A (zh) * 2006-12-28 2008-07-02 中国科学院计算技术研究所 一种获取流媒体链接地址的方法
CN101645815A (zh) * 2008-08-06 2010-02-10 百度在线网络技术（北京）有限公司 音视频文件下载提示方法
CN102098327A (zh) * 2010-12-15 2011-06-15 百度在线网络技术（北京）有限公司 在线视频嗅探下载方法及装置

Also Published As

Publication number Publication date
CN102360349B (zh) 2014-12-03
CN102360349A (zh) 2012-02-22

Similar Documents

Publication Publication Date Title
WO2013010369A1 (zh) 一种获取网页中音/视频链接地址的方法及装置
US11095710B2 (en) Detecting virtual private network usage
KR101807677B1 (ko) 연결된 미디어 환경 내 사용용 미디어 장치를 테스트하고 인증하는 시스템 및 방법
US10051013B2 (en) Method and apparatus for streaming multimedia content of server by using cache
US8732274B2 (en) Method and apparatus for generating and handling streaming media quality-of-experience metrics
CN105100172B (zh) 一种http协议的缓存状态更新方法和设备、处理机
WO2014015738A1 (zh) 播放流媒体的方法、装置及系统
US20160366461A1 (en) Method and Device for Mobile Communication Terminal to Control Smart TV to Play Video File
WO2014059650A1 (zh) 一种音频管理方法及装置
WO2012113260A1 (zh) 一种视频播放方法及其装置
TW201317799A (zh) 網路資源下載資訊的分享控制系統和方法
KR20180004093A (ko) 인스턴트 메시징 동안의 미디어 콘텐츠의 전송
WO2017097039A1 (zh) 一种视频可播放性的检测方法和装置
WO2020133608A1 (zh) 一种拖拉视频数据的处理方法及代理服务器
WO2015070796A1 (zh) 智能电视向移动通信终端推送资源的方法和装置
JP6655093B2 (ja) 部分的セグメント用の表示
JP2016509802A (ja) ビデオ品質のユーザ体験値を評価するための方法、デバイス、及びシステム
US20220417577A1 (en) Video stream transmission method and system
WO2017198023A1 (zh) 音视频碎片分享方法、系统及电子设备
WO2015143854A1 (zh) 数据获取及交互方法、机顶盒、服务器、多媒体系统
CN114827670A (zh) 一种视频播放方法、装置及电子设备
CN112565877B (zh) 投屏方法、系统、电子设备及存储介质
CN108200452A (zh) 一种防止下载的web视频在线播放系统及其控制方法
US10148388B1 (en) Digital data mutation detector and controller in web application interface
US20120191837A1 (en) Method for automatically identifying potential issues with the configuration of a network

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 11869546

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 11869546

Country of ref document: EP

Kind code of ref document: A1