Data processing method applied to webpage on-screen communication

Abstract

The invention provides a data processing method applied to webpage on-screen communication, and relates to the field of internet communication, and the method comprises the following steps: starting and loading a target webpage at a server or a first communication terminal, obtaining static webpage resource data corresponding to a certain webpage element in the target webpage from a network server, and based on the obtained static webpage resource data, displaying the static webpage resource data corresponding to the certain webpage element in the target webpage. And generating inline data for loading the webpage element in an inline form, generating the inline data into first synchronous data, and sending the first synchronous data. And at the second terminal, receiving the first synchronous data, extracting inline data contained in the first synchronous data, and loading corresponding webpage elements in the target webpage in an inline form. Visibly, according to the embodiment of the invention, by utilizing a method for acquiring and processing the static webpage resource data at the server side or one communication terminal and providing the static webpage resource data for other communication terminals, the problem that some communication terminals cannot normally acquire the external resource data due to network limitation in some webpage on-screen communication scenes is solved; and the same-screen effect of the webpage is effectively ensured.

Description

Technical Field

[0001] The embodiments of the present invention relate to the field of Internet communications, and in particular to a data processing method for same-screen communication of web pages. Background Art

[0002] In the actual application of web-based, on-screen communication technology, one party often encounters the problem of being unable to access static web page data. For example, in a scenario where a bank provides on-screen customer service, the customer service staff is located within the bank's local area network and, due to network access restrictions, cannot access external network resources. The customer, on the other hand, is accessing a site deployed by the bank on the external network. When a customer encounters a problem and calls customer service, and both parties engage in a web-based, on-screen communication, the customer collects web page data and sends it to the customer service staff. The customer service staff then receives the data and renders it through a browser, theoretically presenting the same web page content as the customer. However, due to network restrictions, the customer service staff cannot access the static web page resources contained in the web page. This can result in incorrect page display styles and image failures.

[0003] Therefore, the problems existing in the above web page same-screen communication technology urgently need to be solved using new technologies. Summary of the Invention

[0004] In response to the above problems, the present invention provides a data processing method for web page same-screen communication, which aims to solve the problem that one terminal on the same-screen web page communication cannot access external static web page resources due to network restrictions.

[0005] Analyzing the problematic same-screen application scenarios mentioned above, the main reason for the problem is that the customer service staff are in the bank's local area network and cannot access external network resources. The web page accessed by the customer, that is, the web page on the same screen for both parties, is also the target web page. This web page contains static web page resources that the customer service staff cannot obtain. However, the customer service staff cannot access external network resources due to physical limitations, and the bank cannot change its network environment and strategy because of the implementation of this technology. To this end, the present invention provides a new data processing method for same-screen communication of web pages. The method can be applied to a same-screen communication system, which is used to provide web page same-screen communication services for two or more parties, and includes a server and at least two communication terminals. The method includes: On the server side or the first communication terminal, a target webpage for same-screen communication is started and loaded, the target webpage including a first webpage element requiring loading of a static webpage resource, static webpage resource data corresponding to the first webpage element is obtained from a network server, inline data for loading the first webpage element in an inline form is generated based on the obtained static webpage resource data, and the inline data is generated and sent as first synchronization data; At the second terminal, the first synchronization data is received, and the inline data contained therein is extracted, and a target webpage is started and loaded, and the first webpage element in the target webpage is loaded inline using the extracted inline data; The types of the static web page resources include one or more of pictures, CSS style files, Javascript files, font files, video files, audio files, JSON files, XML files, SWF files, and PDF files.

[0006] Through the above implementation method, the data communication established between the first communication terminal and the second communication terminal due to the same-screen exchange of web pages is utilized to send the static web page resource data obtained by the first communication terminal to the second communication terminal, and the second communication terminal loads this part of the data in an inline form, thereby solving the problem that the second communication terminal cannot access external static web page resources.

[0007] In one possible implementation, the first web page element includes one or more web page elements of one or more types. After the first terminal starts and loads a specified target web page, multiple web page elements are obtained according to a preset static web page resource type, and web page resource data corresponding to each web page element is obtained. Inline data for each web page element is generated and loaded inline, and the inline data is generated and transmitted as first synchronization data. Typically, a web page includes multiple and various types of static web page resources. This implementation obtains multiple web page elements and their data according to the preset static web page resource type, thereby batch processing the problem of the second communication terminal being unable to access static web page resources of a specified type.

[0008] In one possible implementation, generating inline data for loading the first web page element in an inline form at the first terminal also includes modifying the HTML of the first web page element in the target web page, changing the form of loading it from an external resource to loading it from inline data, and embedding the corresponding inline data therein to generate a modified new target web page, generating second synchronization data for the modified target web page and sending it. At the second terminal, the second synchronization data is received, the data is extracted, and the new target web page is loaded. This implementation transmits the new target web page content, in which the web page element has been modified to load static web page resource data in an inline form. At the same time, the web page element also contains static web page resource data, which is directly loaded after receiving by the second communication terminal.

[0009] In one possible implementation, based on the acquired static webpage resource data, inline data for loading the first webpage element in an inline form is generated, and the inline data is encoded using Base64. Loading static resources in a webpage using Base64 encoding essentially converts a binary file into an ASCII string format that can be embedded in HTML / CSS.

[0010] In a possible implementation, when the static resource is a JS file, the method further includes obtaining the content of the JS file and adding the content of the file to the tag of the page in the form of an inline script. <script> 标签引入外部 JS 文件‌和‌直接使用 <script> 标签内联编写 JS 代码‌，其本质上都是执行 JavaScript，虽然二者在加载机制、作用域、性能优化等方面存在差异，但逻辑上具有等同效果。

[0011] 在一种可能的实现方式中，当所述静态资源为CSS文件时，还包括，获取外部CSS文件文本内容，在页面现有的<style>元素中插入所述CSS文本内容，或者，创建<style>元素，在所述<style>元素中插入所述CSS文本内容，将所述<style>元素增加到页面的 <head>标签中。该实现方式中，在网页中引入外部 CSS 文件（通过 <link> 标签）与使用 <style>标签内联编写样式，虽然两者在加载机制、作用域、维护性和性能优化等方面存在差异，但最终效果都是为页面添加样式，两种方式可以通过技术手段相互转换。因此，该实现方式可以解决所述第二交流终端无法访问外部CSS文件的问题。

[0012] 在一种可能的实现方式中，通过读取配置以控制在所述第一交流终端是否将外部静态网页资源数据转化为内联数据，以及控制所述第二交流终端直接加载外部静态网页资源数据还是内联数据。该实现方式还包括第一配置数据，所述配置数据包括是否切换为内联加载静态网络资源的配置项，在服务端或第一交流终端，读取配置数据，在确定为使用内联方式加载时，生成以内联形式加载所述第一网页元素的内联数据，并将其生成为第一同步数据发送；当确定不使用内联方式加载时，不生成内联数据以及所述第一同步数据。该实现方式通过读取配置来控制静态网页资源的加载方式。

[0013] 在一种可能的实现方式中，将所述第一网页元素由外部资源加载的形式修改为内联数据加载的形式，在确定所述外部资源为图片时，还包括，创建Canvas，读取所述图片数据并在所述Canvas上绘制，基于所述Canvas获取base64数据。该实现方式中，将 Canvas 绘制的图像转换为 Base64 编码的 Data URL，无需依赖服务端处理。

[0014] 在一种可能的实现方式中，将所述第一网页元素由外部资源加载的形式修改为内联数据加载的形式，在确定所述外部资源为图片时，还包括，获取图片元素，获取图片的二进制数据，转换为Base64编码的字符串。该实现方式中，图片的二进制数据和 Base64 转换完全在浏览器端完成，无需依赖服务端。该方法使用 fetch API实现数据转换，fetch API是现代浏览器提供的更简洁的异步数据获取方式，结合 FileReader 可实现图片转换为Base64 编码。

[0015] 在一种可能的实现方式中，当确定所述第一网页元素对应的静态网页资源类型为图片时，还包括， 使用 FileReader 和 XMLHttpRequest获取所述图片的base64数据，具体为，创建 XMLHttpRequest 对象并设置请求参数，指定响应类型为 blob；发送请求并在请求成功后获取图片的 Blob 对象；创建 FileReader 对象，读取 Blob 并将其转换为Base64 数据。此方法通过 XMLHttpRequest 获取图片的二进制数据（Blob 对象），再使用FileReader 将其转换为 Base64 编码。

[0016] 通过以上实现方式，可获得的有益效果是，所述第二交流终端在无法访问外部网络资源得到情况下，利用其和第一交流终端所建立的数据通信获取以内联方式加载所述外部网络资源的数据并加载，从而在不改变所述第二交流终端网络环境的情况下实现了对外部网络资源的访问，保证了网页同屏的效果。附图说明

[0017] 图1为本申请实施例提供的一种应用于网页同屏交流的数据处理流程示意图；图2为本申请实施例提供的一种应用于网页同屏交流的多网页元素数据处理流程示意图；图3为本申请实施例提供的一种应用于网页同屏交流的同步新目标网页数据的处理流程示意图；图4为本申请实施例提供的一种应用Base64编码数据生成第一同步数据的流程示意图；图5为本申请实施例提供的一种应用Base64编码数据生成新目标网页数据执行同步的流程示意图；图6为本申请实施例提供的一种应用于网页同屏交流的处理JS文件数据的流程示意图；图7为本申请实施例提供的一种应用于网页同屏交流的处理CSS文件数据的流程示意图；图8为本申请实施例提供的一种应用于网页同屏交流的根据配置执行静态网页资源加载的流程示意图；图9为本申请实施例提供的一种使用Canvas获取base64数据的流程示意图；图10为本申请实施例提供的一种使用fetch API获取base64数据的流程示意图；图11为本申请实施例提供的一种使用FileReader和XMLHttpRequest获取base64数据的流程示意图。具体实施方式

[0018] 本申请的实施方式部分仅用于对本申请进行解释，而非旨在限制本申请。

[0019] 以下，对本申请的实施例进行描述，显然，所描述的实施例仅仅是本申请一部分的实施例，而不是全部的实施例。本领域普通技术人员可知，随着技术的发展和新场景的出现，本申请实施例提供的技术方案对于类似的技术问题，同样适用。

[0020] 本申请实施例提供的网页同屏交流数据处理方法，旨在解决网页同屏交流场景下，参与交流的一方因网络访问受限，无法获取静态网页资源的问题。

[0021] 在本申请中，所述需加载静态网页资源的网页元素例如：<script>标签：用于加载外部 JavaScript 脚本文件，例如：<script src="https: / / example.com / js / main.js">< / script> .

[0022] <link> Tag: Mainly used to load external CSS style sheet files, for example: <link rel="stylesheet" href="https: / / example.com / css / style.css"> .

[0023] Tag: used to insert external image resources, for example: wait, For example, loading background images in CSS body { background-image: url('https: / / example.com / images / background.jpg'); } It should be noted that the above types of web page tags are only used as examples, and their common feature is that they need to load web page resources from the outside.

[0024] Please refer to Figure 1 The following is a schematic diagram of a data processing flow for web page on-screen communication provided by an embodiment of the present application, including a first communication terminal 01 and a second communication terminal 02. The second communication terminal 02 does not have access to external static web resources due to network access restrictions, while the first communication terminal 01 can load external web resources normally. The main execution steps are as follows: In the first communication terminal 01: S101, loading a target web page, loading a first web page element; S102, obtaining static web page resource data corresponding to the first web page element; S103, generating inline data for loading the first web page element in an inline form based on the acquired static web page resource data, and generating the inline data as first synchronization data; S104, sending first synchronization data; In the second communication terminal 02: S105 , receiving first synchronization data, starting and loading a target webpage, extracting inline data from the first synchronization data, and utilizing the inline data to load the first webpage element in the target webpage in an inline form.

[0025] In the above implementation steps, data communication is conducted between the first communication terminal 01 and the second communication terminal 02, including through server-side forwarding and direct communication. In the scenario of web page on-screen communication, preferably, the communication terminals communicate using WebSockets. Compared to traditional HTTP long polling or short polling methods, WebSockets reduces the transmission of unnecessary request and response header information. WebSockets offer significant advantages in data transmission efficiency, especially when frequently transmitting small amounts of data. In this embodiment of the present application, the second communication terminal 02 is unable to access external web resources due to limited network access. However, the established on-screen communication data communication connection between the first communication terminal 01 and the second communication terminal 02 provides a ready-made communication channel. Therefore, the above embodiment utilizes this data connection, with the first communication terminal 01 providing static web resource data to the second communication terminal 02. In web page development, inlining and externally loading resources are two common ways to introduce resources. Therefore, obtaining web resource data in S102 and converting it into inline loaded data in S103 is a good option, as it also utilizes the web page's ability to load web resources. In a specific implementation scenario, optionally, inline data for loading the first web page element in an inline form is generated in S103. In step S105, when it is determined that a certain web page element needs to load external web page resource data, the web page element is modified to load the web page resource data inline, and at the same time, the inline data is obtained from the first synchronization data for loading.

[0026] The above implementation solves the problem of the second communication terminal accessing external web resources under network restrictions. This implementation also has the following advantages: without changing the network environment of the web page same-screen technology application scenario, it solves the problem of users on one side being unable to obtain static web page resources due to network restrictions; it reduces network requests and loads static web page resources inline, reducing multiple request interactions between the second communication terminal and the server; it improves synchronization efficiency, and by converting static web page resources into inline data and sending them as synchronization data, it can ensure that the second communication terminal can quickly and accurately obtain the required resources, and achieve efficient same-screen communication with the server or the first communication terminal; data transmission is carried out through the existing web page same-screen data connection, without adding additional network overhead; it supports multiple types of static web page resources, such as images, CSS, JavaScript, etc., can adapt to the complex resource requirements of different web pages, and has good versatility and compatibility.

[0027] In one possible implementation scenario, a server replaces the functionality of the first communication terminal 01. Specifically, the server browser loads the target webpage, loads the first webpage element, obtains static webpage resource data, and then generates inline data based on the data to load the first webpage element inline. This inline data is then sent to the second communication terminal 02, which cannot directly load external communication resources. The second communication terminal 02 then uses the received inline data to load the first webpage element inline within the target webpage.

[0028] In one possible implementation, Figure 2 The schematic diagram of a data processing flow for multiple web page elements applied to web page same-screen communication is shown. The inline data is collected in the first communication terminal 01 or the server. The steps are as follows: S201, starting and loading a specified target web page on the first terminal; S202, obtaining multiple web page elements according to a preset static resource type, obtaining web page resource data corresponding to each web page element, and generating inline data for loading each web page element in an inline form; S203: Generate the inline data into first synchronous data and send it.

[0029] Through the above implementation, the technical effects that can be achieved are as follows: Resource loading has been optimized to enable on-demand resource loading, that is, elements are retrieved according to preset types, enabling on-demand loading. In same-screen communication, only necessary resources can be loaded according to specific needs to speed up page loading. For example, when synchronous video playback on a page does not make sense, the conversion and transmission of video data can be eliminated through the preset static resource type to improve efficiency; when only the page layout and simple interaction need to be displayed, only CSS and JavaScript resources are obtained so that the page can be presented to the user quickly; JavaScript resources are excluded when loading JavaScript on both sides of the same-screen communication may cause repeated interactions with the server and confusion in synchronization functions. From another perspective, the above implementation method batches and transmits inline data of multiple web page elements, which can significantly reduce unnecessary network requests, reduce bandwidth usage, and improve resource acquisition efficiency.

[0030] In one possible implementation, Figure 3 The schematic diagram of a processing flow for synchronizing new target web page data for web page sharing on the same screen is shown, and the main execution steps are as follows: In the first communication terminal 01: S301, loading a target web page, loading a first web page element; S302, obtaining static web page resource data corresponding to the first web page element; S303, modifying the first webpage element in the target webpage from being loaded in an external resource to being loaded in an inline data format, embedding the corresponding inline data in the target webpage to generate a modified new target webpage, generating second synchronization data for the modified target webpage, and sending the second synchronization data; S304, sending second synchronization data; In the second communication terminal 02: S305: Receive second synchronization data, start and load the target web page.

[0031] In the above implementation, the first communication terminal 01 modifies the first web page element from being loaded from external resources to being loaded from inline data, and at the same time modifies the web page to be a new target web page. Figure 1 In the illustrated embodiment, this implementation method is characterized by generating new target web page data, such as new HTML data, which includes inline data for loading the web page's static resource data. This implementation method has the advantage that the second communication terminal 02 does not need to determine or modify the method for loading static resources into web page elements; it can simply load the web page data sent by the first communication terminal 01 to achieve static web page resource data loading.

[0032] In one possible implementation, Figure 4 The flowchart shown uses Base64 encoded data as inline data and generates the first synchronization data. The steps are as follows: S401, obtaining static web page resource data; S402, generating inline data for loading the first web page element in a Base64 encoded inline form; S403: Generate the inline data into first synchronous data and send it.

[0033] Combining the above implementation steps, for example, to generate Base64 encoding on the server, the main steps are as follows: On the server side, obtain the path of static resource files, such as images, CSS files, and JavaScript files; read the contents of the static resource files according to the file path (usually also handling exceptions such as file not found); convert the read resource data into Base64-encoded inline data based on different resource types; encapsulate the inline data into synchronous data and return it to the client in JSON format.

[0034] In one possible implementation, corresponding to Figure 3 For the implementation method of generating and transmitting new target web page data in the embodiment, please refer to Figure 5The flowchart shown in the figure shows a method for using Base64-encoded inline data to generate a new target web page and perform synchronization by transmitting the web page data. The steps are as follows: S501, obtaining static web page resource data; S502, generating inline data for loading the first web page element in a Base64 encoded inline form, and embedding the corresponding inline data in the target web page to generate a modified new target web page; S503: Generate second synchronization data from the modified target webpage and send the data.

[0035] The implementation is Figure 3 and Figure 4 The content of the web page elements in the transmitted new target web page is as follows: In a possible implementation, the first communication terminal 01 and the second communication terminal 02 communicate on the same screen on a web page. The second communication terminal 02 cannot load external network resource data due to network restrictions. When determining that the external network resource data is a js file, refer to Figure 6 The process diagram shown is as follows: In the first communication terminal 01: S601A, when it is determined that the static webpage resource is a JS file, obtain the file content of the JS file; S602A, sending the file content of the JS file as first synchronization data; In the second communication terminal 02: S603A, creating an inline script web page element to load the file content of the JS file; For example, WebSocket can be used to implement real-time communication between two communication terminals. For example, in the first communication terminal: - Use the `fetch` method to obtain the contents of the `example.js` file. Use the WebSocket connection to send the JS file contents to the server. In the second communication terminal: - Establish a connection with the WebSocket server; receive the JS file contents forwarded by the server and create an inline ` <script>` 元素来加载该内容。而WebSocket 服务器通过监听端口 8080，处理客户端的连接， 把第一交流终端发送的消息转发给第二交流终端。

[0036] 另外，图6中还包括另一种生成新目标网页数据的实现方式，步骤如下：在第一交流终端01中：S601B，确定静态网页资源为JS文件时，获取JS文件的文件内容；S602B，将文件内容以内联脚本的形式添加到页面的 <head> 标签中,以生成修改后的新目标网页；S603B，将修改后的目标网页生成第二同步数据并发送；在第二交流终端02中：S604B，加载所述新的目标网页；根据以上步骤，实现第一交流终端和第二交流终端网页同屏交流的具体示例如下：使用 WebSocket 来完成两个终端之间的通信，同时结合 HTML 和 JavaScript来处理网页内容的修改与加载。

[0037] 在第一交流终端，获取 JS 文件内容，例如借助 `fetch` 方法获取 `example.js` 文件的内容。

[0038] 内联添加到 `<head>` 标签：创建一个 `<script>` 元素，将 JS 文件内容赋值给其 `textContent` 属性，然后添加到页面的 `<head>` 标签中。

[0039] 生成并发送新网页：获取修改后的整个页面的 HTML内容，通过 WebSocket 连接将其作为新的同步数据发送到服务器。

[0040] 在第二交流终端：接收新网页内容：与 WebSocket 服务器建立连接，接收服务器转发的新网页内容。

[0041] 加载新网页：使用 `DOMParser` 解析接收到的 HTML 内容，然后通过 `document.write` 方法将新网页加载到当前页面。

[0042] 在WebSocket 服务器：监听端口 8080，处理客户端的连接；把第一交流终端发送的新网页内容转发给第二交流终端。

[0043] 可选的，结合以上实现方式，为避免增加的JavaScript 代码与已有变量冲突，使用立即执行函数表达式（IIFE）进行处理，使用 IIFE 包裹所增加的JavaScript代码，形式如下：(function() { / / 以下为所增加的JavaScript代码内容console.log('');}());该实现方式中，IIFE 会创建一个新的函数作用域，在该作用域内定义的变量不会影响外部作用域。

[0044] 可选的，采用 ES6 模块系统来避免增加的JavaScript 代码与已有变量冲突。该实现方式中，ES6 模块为每个模块提供了独立的作用域，模块内部的变量不会泄露到全局作用域。

[0045] 在一种可能的实现方式中，第一交流终端001与第二交流终端002进行网页同屏交流，所述第二交流终端002因网络限制无法加载外部的网络资源数据，在确定所述外部网络资源数据为CSS文件时，参考图7所示的流程示意图，步骤如下：S701A，确定静态网页资源为CSS文件时，获取CSS文件的文件内容；S702A，将所述CSS文件的文件内容作为第一同步数据发送；在第二交流终端02中：S703A，创建内联样式网页元素以加载所述CSS文件的文件内容；其中，在第一交流终端01中，外联CSS链接，通常为 <link> 标签，例如<link rel="stylesheet" href="styles.css">。在S703A步骤中，创建内联样式网页元素即创建内联样式标签，将复制的 CSS 代码包裹在 <style> 标签中，例如：<style> / * 粘贴所接收的 CSS 内容 * / body { margin: 0;}.container { max-width: 1200px;}< / style>另外，图7还包括另一种生成新目标网页数据的实现方式，步骤如下：在第一交流终端01中：S701B， 确定静态网页资源为CSS文件时，获取CSS文件的文件内容；S702B，将文件内容以内联样式的形式添加到页面的 <head> 标签中,以生成修改后的新目标网页；S703B，将修改后的目标网页生成第二同步数据并发送；在第二交流终端02中：S704B，加载所述新的目标网页。

[0046] 以上实现方式为一种先生成新的网页数据而后根据网页数据执行同步的方式。

[0047] 根据以上实现方式，在具体的实现场景中，如果有多个 CSS 文件需要合并，或这当前目标网页中已包括<style> 标签和部分css内容，还需要处理样式优先级问题。

[0048] 在一种可能的实现方式中，请参考图8所示流程示意图，本申请实施例还提供一种根据配置处理静态网页资源数据加载方式的方法，具体步骤包括：在第二交流终端01中：S801，加载目标网页；S802，读取配置；S803，判断静态网页资源加载方式；根据判断结果，当不要求使用内联方式时：S808，根据目标网页指定方式加载静态网页资源；根据S803判断结果，当要求使用内联方式时：S804，根据目标网页指定方式加载静态网页资源；S805，加载目标网页，加载第一网页元素；S806，获取第一网页元素对应的静态网页资源数据；S807，基于所获取的静态网页资源数据生成以内联形式加载所述第一网页元素的内联数据，将所述内联数据生成为第一同步数据发送；以上实现方式通过读取配置，根据所述配置中对网页静态资源数据处理方式的设定，当判断为当不要求使用内联方式时，则不改变现有网页资源数据的加载方式，在所述第一交流终端中不做处理以及不发送对所述静态网页资源处理的相关同步数据，对应的，在第二交流终端02中，根据目标网页所指定方式加载静态网页资源数据，该处理方式适用于所述第二交流终端能够获取到外部静态资源数据的情形，或者，在所述第二交流终端无法获取到外部静态资源数据但该数据在同屏交流中属于不必要的情形。在S803步骤中判断为使用内联方式加载时，则在所述第一交流终端中的对所述静态网页资源数据进行处理以生成以内联方式加载的网页数据，相应的，在所述第二交流终端02中以内联方式加载所述第一网页元素。在具体的实施场景中，S802中读取的所述配置，其内容包含是否转换为内联方式加载网页资源数据的开关配置，可选的，在所述第一交流终端01与所述第二交流终端02进入同屏交流状态后读取所述配置。可选的，在第二交流终端02中，设置对某网页元素转换为以内联方式加载，并生成加载请求，在所述第一交流终端01接收和处理该请求，所述请求等价于一种该实现方式中的配置，然后，对所述静态网页资源执行S804~S807步骤。

[0049] 在一种可能的实现方式中，在第一交流终端01中，当需转换为内联加载的静态网页资源类型为图片时，请参考图9所示的处理步骤：S901，获取页面上的img元素；S902，创建canvas元素；S903，将图片绘制到canvas上；S904，使用toDataURL方法获取canvas内容的Base64编码数据；这种方式的核心是将图片绘制到 <canvas> 上，然后利用 <canvas> 的方法将内容转换为 Base64 编码。

[0050] 以上步骤中，主要实现代码如下所示：<body><script>const img = document.getElementById('myImage');img.onload = function () {const canvas = document.createElement('canvas');canvas.width = img.width;canvas.height = img.height;const ctx = canvas.getContext('2d');ctx.drawImage(img, 0, 0);const base64Data = canvas.toDataURL('image / png');console.log(base64Data);};< / script> In another possible implementation, in the first communication terminal 01, when the type of static webpage resource to be converted to inline loading is a picture, please refer to Figure 10 The processing steps shown are: S1001, use fetch to request image resources; S1002, convert the response into a Blob object; S1003, create a FileReader object, read the Blob and convert it into Base64 data; The above is an implementation method using the fetch API. The fetch API is a simpler asynchronous data acquisition method provided by modern browsers. Combined with FileReader, it can convert images into Base64 encoding.

[0051] The main implementation code examples are as follows: <script>const img = document.getElementById('myImage');fetch(img.src).then(response => response.blob()).then(blob => {const reader = new FileReader();reader.onloadend = function () {const base64Data = reader.result;console.log(base64Data);};reader.readAsDataURL(blob);}).catch(error => console.error('Error:', error));< / script> Note that if the image's source domain is different from the current page's domain, you may encounter cross-domain issues. This can be resolved by setting CORS headers on the server or using a proxy server.

[0052] In another possible implementation, in the first communication terminal 01, when the type of static webpage resource to be converted to inline loading is a picture, please refer to Figure 11 The processing steps shown are: S1101, create an XMLHttpRequest object and set the request parameters, specifying the response type as blob; S1102, sending a request and obtaining the Blob object of the image after the request is successful; S1103, create a FileReader object, read the Blob and convert it into Base64 data; The above method obtains the binary data of the image (Blob object) through XMLHttpRequest and then converts it into Base64 encoding using FileReader.

[0053] The following are examples of the main implementation steps of the above method: <script>const img = document.getElementById('myImage');const xhr = new XMLHttpRequest();xhr.open('GET', img.src, true);xhr.responseType = 'blob';xhr.onload = function () {if (xhr.status === 200) {const blob = xhr.response;const reader = new FileReader();reader.onloadend = function () {const base64Data = reader.result;console.log(base64Data);};reader.readAsDataURL(blob);}};xhr.send();< / script> In summary, the present application obtains external static web page resource data and generates data for loading the static web page resource in an inline manner at a first communication terminal, and uses the communication channel established between the first communication terminal and the second communication terminal in the same-screen web page communication to send the data to the second communication terminal, and the second communication terminal loads the corresponding web page elements in the web page in an inline manner based on the received data. The beneficial effects produced by the embodiments of the present application can be summarized as follows: it solves the problem of being unable to load external network resources due to limited network access on one side in the same-screen web page communication scenario, solves the above-mentioned problem of limited access to external network resources without changing the network environment, thereby ensuring a good same-screen effect and enhancing the user experience.

[0054] In the above embodiments of the present application, static webpage resource data is obtained in the first communication terminal (a communication terminal that can normally obtain external network resource data), converted into inline data, and provided to the second communication terminal. In the second communication terminal (a same-screen communication terminal that cannot obtain external network resource data due to limited network access), the previously inaccessible static webpage resource data is loaded inline. The embodiments of the present application achieve this purpose by changing the loading method of static webpage data, that is, using the inline loading method instead of the external loading method. In specific implementation scenarios, the following implementation methods are also included: On the server side or the first communication terminal, start and load a target web page for same-screen communication, wherein the target web page includes a first web page element that requires loading static web page resources, obtain static web page resource data corresponding to the first web page element from a network server, store the static web page resource data in a second network server, and generate a new access path, wherein the second server is a server to which the second terminal has access rights.

[0055] The target webpage accessed by the second terminal is modified, and the static webpage resource path corresponding to the first webpage element is modified to a new access path.

[0056] At the second communication terminal, a target webpage is started and loaded, and static webpage resources are acquired from the new access path to load the first webpage element in the target webpage.

[0057] In the above implementation, if the second communication terminal is unable to access an external resource due to restricted network access, the first communication terminal or the server obtains and relocates the external resource so that the second communication terminal can access it. In actual implementations, optionally, after generating a new access path for the external resource, the server or the first communication terminal simultaneously modifies the external resource access path in the first webpage element and updates the HTML of the first webpage element. Synchronous data is generated and sent based on this information. The second communication terminal receives the synchronization data, loads the first webpage element, and obtains the external resource through the new access path. Optionally, the server or the first communication terminal stores the static webpage resource corresponding to the first webpage element at a pre-specified network address, and the second communication terminal modifies the static webpage resource in the first webpage element to load the network path corresponding to the pre-specified network address. Preferably, when the server or the first communication terminal transfers the external resource data, its file name remains unchanged. Optionally, after the server or the first communication terminal completes transferring the external resource data, it sends a notification. Upon receiving the notification, the second communication terminal begins loading the new external resource data.

[0058] The above is only a specific implementation of the embodiment of the present application, but the scope of protection of the embodiment of the present application is not limited to this. Any changes or substitutions that can be easily conceived by a person skilled in the art within the technical scope disclosed in the embodiment of the present application should be included in the scope of protection of the embodiment of the present application. Therefore, the scope of protection of the embodiment of the present application should be based on the scope of protection of the claims.

Claims

1. A data processing method for web page same-screen communication, the method being applied to a same-screen communication system comprising a server and at least two communication terminals, characterized in that: include: On the server side or the first communication terminal, a target webpage for same-screen communication is started and loaded, the target webpage including a first webpage element requiring loading of a static webpage resource, static webpage resource data corresponding to the first webpage element is obtained from a network server, inline data for loading the first webpage element in an inline form is generated based on the obtained static webpage resource data, and the inline data is generated and sent as first synchronization data; At the second terminal, the first synchronization data is received, and the inline data contained therein is extracted, and a target webpage is started and loaded, and the first webpage element in the target webpage is loaded inline using the extracted inline data; The types of the static web page resources include one or more of pictures, CSS style files, js files, font files, video files, audio files, JSON files, XML files, SWF files, and PDF files.

2. The method according to claim 1, characterized in that It also includes that the first web page element includes one or more or one or more types of web page elements. After the first terminal starts and loads the specified target web page, multiple web page elements are obtained according to the preset static web page resource type, and the web page resource data corresponding to each web page element is obtained, inline data for loading each web page element in an inline form is generated, and the inline data is generated as the first synchronization data and sent.

3. The method according to claim 1, characterized in that Generating inline data for loading the first webpage element in an inline form on the first terminal further includes: Modifying the first webpage element in the target webpage from an external resource loading form to an inline data loading form, and embedding corresponding inline data therein to generate a modified new target webpage, generating second synchronization data from the modified target webpage and sending the second synchronization data; At the second terminal, the second synchronization data is received, data is extracted, and the new target webpage is loaded.

4. The method according to claim 1, wherein Based on the acquired static web page resource data, inline data for loading the first web page element in an inline form is generated, and the inline data is also encoded using Base64.

5. The method according to claim 1, wherein When the static web page resource is a JS file, the method further includes obtaining the content of the JS file and adding the content of the file to the tag of the page in the form of an inline script.

6. The method according to claim 1, characterized in that When determining that the static web page resource is a CSS file, the method further includes obtaining the text content of the external CSS file and <style>元素中插入所述CSS文本内容，或者，创建<style>元素，在所述<style>元素中插入所述CSS文本内容，将所述<style>元素增加到页面的<head>标签中。7.根据权利要求1所述的方法，其特征在于，所述服务端或第一交流终端还包括读取第一配置数据，所述第一配置数据包括是否配置为使用内联方式加载静态网页资源的配置项，在服务端或第一交流终端，读取所述第一配置数据，在确定为使用内联方式加载时，生成以内联形式加载所述第一网页元素的内联数据，并将其生成为所述第一同步数据发送；当确定不使用内联方式加载时，不生成内联数据以及所述第一同步数据。8.根据权利要求1所述的方法，其特征在于，将所述第一网页元素由外部资源加载的形式修改为内联数据加载的形式，在确定所述外部资源为图片时，还包括，创建Canvas，读取所述图片数据并在所述Canvas上绘制，基于所述Canvas获取base64数据。9.根据权利要求1所述的方法，其特征在于，将所述第一网页元素由外部资源加载的形式修改为内联数据加载的形式，在确定所述外部资源为图片时，还包括，获取图片元素，获取所述图片元素所对应图片的二进制数据并将其转换为Base64编码的字符串。10.根据权利要求1所述的方法，其特征在于，当确定所述第一网页元素对应的静态网页资源类型为图片时，还包括，使用FileReader和XMLHttpRequest获取所述图片的base64数据，具体为，创建XMLHttpRequest对象并设置请求参数，指定响应类型为blob；发送请求并在请求成功后获取图片的Blob对象；创建FileReader对象，读取Blob并将其转换为Base64数据。< / style>

Images