• 混沌系统
  • 引言
  • 二义性发散问题带来的不可靠
    • 经典“二义性”需求示例
    • 二义性程序逻辑叠加示例
  • 复杂度的经典例子
    • 单摆
    • 双摆
    • 三摆（多摆）
  • 最后

混沌系统

引言

一个系统或流程功能的设计，应该尽量收敛到可靠状态。

当多个不可靠状态不断叠加，便会逐渐变成混沌系统 --- 事态变的不可控。

导致人们难以理解、分不清是 Feature 还是 Bug。

也自然对系统未来的迭代，悄悄地预埋上了随时崩溃的风险。

二义性发散问题带来的不可靠

经典“二义性”需求示例

老婆：“老公你去买一斤包子回来，如果看到卖西瓜的，就买一个”。

然后，看到老公买了一个包子回来。

二义性程序逻辑叠加示例

// 似乎粗看没什么问题
if (num === 1 || num !== 2) { ...any... }

// 也许未来有一天会变成
num2 = 2;
if (num === 1 || num !== num2) { ...any... }

// 再继续来一次无脑迭代
num2 = 1 || 2;
if (num === 1 || num !== num2) { ...any... }

// 经典问题
num = top.undefined;
num2 = self.undefined;
if (num === num2) { ...any... }

复杂度的经典例子

单摆

一个具备「可靠&可预知」轨迹状态的系统功能。

其运行过程中有1个动态的状态节点控制，可以推演解释任意时刻轨迹状态。

双摆

一个具备「不可靠&难以预知」轨迹状态的系统功能。

其运行过程中有2个动态的状态节点，想要推演解释任意时刻的状态值结论，已经非常艰难。

三摆（多摆）

一个具备「不可靠&不可预知」轨迹状态的系统功能。

其运行过程中有多个动态的状态节点，任意时刻的状态值恐怕不是有生之年能解释的清楚推演明白的。

最后

所以，一个好的系统或程序设计，应该具备可归纳可收敛、数据信息可沉淀可二次迭代创作的一些基本特征。

• 几个文件文件夹数据交互途径及技术方案及各自的弊端
  • 1、点击按钮或菜单项的“选择文件”发送
    • 技术原理
    • 技术实现
    • 特殊情况
    • 典型弊端
  • 2、点击按钮或菜单项的“选择文件夹”发送
    • 技术原理
    • 技术实现
    • 特殊情况
    • 典型弊端
  • 3、从磁盘拖拽文件或文件夹到APP
    • 技术原理
    • 技术实现
    • 特殊情况
    • 典型弊端
  • 4、在 APP 中 CtrlOrCmd+V 从 磁盘 CtrlOrCmd+C 复制的文件和文件夹
    • 技术原理
    • 技术实现
    • 特殊情况
    • 典型弊端
  • 5、在 APP 的消息输入框右键“粘贴” 从 磁盘 CtrlOrCmd+C 复制的文件和文件夹
    • 技术原理
    • 技术实现
    • 特殊情况
    • 典型弊端
  • 使用JsZip进行文件夹压缩打包
  • 以上方案的大前提
  • 后续优化

几个文件文件夹数据交互途径及技术方案及各自的弊端

1、点击按钮或菜单项的“选择文件”发送

技术原理

使用浏览器原生的文件输入框 HTMLInputElement，用户选择文件后可以再 onChange 检测输入框内容变化、从 HTMLInputElement.files 获取FileList。

文档可参考： https://developer.mozilla.org/zh-CN/docs/Web/HTML/Element/input/file

技术实现

支持多选（multiple="true"）、未限制类型。

在onChange 获取并校验后得到合法 FileList 后，使用 sendFiles 组件打开文件发送框或直接执行发送（用户选择了“选择文件直接发送”的）。

特殊情况

按浏览器和操作系统不同，选择的内容会有特殊问题，比如：

• Mac端选择 “xxx.app”会实际往输入框输入一个“xxx.app.zip”
• 文件和文件夹混选时
  • 先选文件还是先选文件夹、windows还是Mac都会有差异、不能读到文件夹对象或指针。
  • 综上，业务逻辑中会忽略文件夹，防止旧版里"误把文件夹当文件发送，最终消息发送失败"的问题发生。

典型弊端

• FileList 是一维数组，不知道文件夹包含关系，文件量大浏览器Native层面可能就会响应很长时间。
• “xxx.app”特殊文件变“xxx.app.zip”的情形，浏览器Native层面会响应很长时间（处理时长取决于.app包大小）。
• 用户选择文件的量不可控，比如用户有个 /Logs 目录，里面的 “*.log”很多并且体量很大，时间空间复杂度一定会很高。

2、点击按钮或菜单项的“选择文件夹”发送

技术原理

使用浏览器原生的文件输入框 HTMLInputElement，并设置实验性的“webkitdirectory”属性，用户选择文件夹后可以再 onChange 检测输入框内容变化、从 HTMLInputElement.files 获取 FileList（一个被递归扁平化的一维文件对象数组），通过 File.webkitRelativePath 判定是否在同一个文件夹下。

文档可参考： https://developer.mozilla.org/zh-CN/docs/Web/API/HTMLInputElement/webkitdirectory

技术实现

支持多选（multiple="true"）、未限制类型。

在onChange 获取并校验后得到合法 FileList 后，转换成“文件夹对象”、使用 sendFiles 组件打开文件发送框、执行文件夹压缩、或直接执行发送（用户选择了“选择文件直接发送”的）。

特殊情况

虽然设置了多选，但目前看并不能多选。

典型弊端

• 不能多选文件夹（浏览器API层面设置了多选没用）、不能文件文件夹混选。
• FileList 是扁平化的文件一维数组：
  • 文件量大浏览器Native层面可能就会响应很长时间。
  • 要得到树状文件夹包含关系，就必须枚举遍历，根据 File.webkitRelativePath 做出判定，文件量大循环响应的时长也自然会长。
• “xxx.app”特殊文件变“xxx.app.zip”的情形，浏览器Native层面会响应很长时间（处理时长取决于.app包大小）。
• 用户选择文件夹里的内容量不可控，比如用户直接选/Windows系统安装包目录，时间空间复杂度一定会很高。

3、从磁盘拖拽文件或文件夹到APP

技术原理

使用浏览器原生的 doucument.onDrop 监听拖入事件，从 event.dataTransfer.items 读取拖入的内容（可以是多个文件夹或文件的混合内容），再 DataTransferItem.webkitGetAsEntry() 得到 entry、再 entry.isDirectory 判定是否文件夹，是文件夹的递归得到目录内容（用于判断超限、文件夹压缩）；最终得到一个一维的 FileList 供 sendFile 组件走后续交互逻辑。

文档和官方示例参考： https://developer.mozilla.org/zh-CN/docs/Web/API/DataTransferItem/webkitGetAsEntry#%E7%A4%BA%E4%BE%8B

技术实现

支持多选&混选。

特殊情况

能得到树状目录结构。

典型弊端

• 从 DataTransferItems 到 FileList 流程偏长，存在异步IO读取，耗时长短取决于内容量（参见下图）。
• 用户拖拽内容量不可控，比如用户直接在C盘下全选、拖拽，时间空间复杂度一定会很高。

4、在 APP 中 CtrlOrCmd+V 从 磁盘 CtrlOrCmd+C 复制的文件和文件夹

技术原理

使用浏览器原生的 doucument.onPaste 监听粘贴事件，然后复用上面拖拽的FileList获得逻辑：

• 从 event.dataTransfer.items 读取拖入的内容（可以是多个文件夹或文件的混合内容）。
• 再 DataTransferItem.webkitGetAsEntry() 得到 entry、再 entry.isDirectory 判定是否文件夹，是文件夹的递归得到目录内容（用于判断超限、文件夹压缩）
• 最终得到一个一维的 FileList 供 sendFile 组件走后续交互逻辑。

文档参考： https://developer.mozilla.org/en-US/docs/Web/API/Document/paste_event

技术实现

理论上支持多选&混选，然后 Ctrl+C 写入剪切板，读取时得到。

特殊情况

• 剪切板有可能会是截图、纯文本、HTML、文件、文件夹，所以必须要做各CASE分支处理、并达成各自的需求。
• 这里纯粹靠浏览器onPaste事件的DataTransfer，如果有文件或文件夹读取不到的情况，首先需要确定是否权限问题、被浏览器滤掉等等。

典型弊端

• 从 DataTransferItems 到 FileList 流程偏长，存在异步IO读取，耗时长短取决于内容量。
• 用户复制内容量不可控，比如用户直接在C盘下全选、Ctrl+C，时间空间复杂度一定会很高。

5、在 APP 的消息输入框右键“粘贴” 从 磁盘 CtrlOrCmd+C 复制的文件和文件夹

技术原理

使用 Electron 的 NodeJS 能力，读取剪切板里的文件或文件夹路径、最终转换得到 FileList：

• 先通过NodeJS读取剪切板中的文件或文件夹路径
• 再通过NodeJS按路径递归读取得到 FIle 对象，传递给渲染进程进行UI展现、发送服务端。

文档参考： https://github.com/electron/electron/issues/9035

技术实现

读取剪切板中的文件或文件夹路径：

通过文件路径得到目录关系、文件数据，并进行超限判定：

将Native层的数据，转为渲染进程可用的FileList：

粘贴按钮按下后，插入文件或文本或HTML到编辑器或sendFile 组件：

特殊情况

getClipboardPaths 不可靠，比如windows端，无法读取到多个路径，如果 Ctrl+C 了多个，这里只能拿到其中的一个。

典型弊端

• 从剪切板路径读取 到 FileList 流程更长，也存在异步IO读取，耗时长短取决于内容量，且更突出。
• 用户Ctrl+C复制内容量、或文件夹里的内容量不可控，时间空间复杂度一定会很高。

使用JsZip进行文件夹压缩打包

以上方案的大前提

目前是考虑最快方案：不考虑各种复杂的UI和产品交互设计、减少各场景CASE分支的定制化开发、尽量保证 Web端&Electron端 尽快先跑起来达成基本需求。

后续优化

• 将异步IO，放在UI展示之后，需要UI先展示Loading或“文件夹大小计算中”等中间状态。
  • 对交互体验肯定有优化效果，但对交互流程的时长，只可能会消耗更多。
• 将文件读取压缩的能力放 Native NodeJS 层。
  • 需要考虑拖拽、Ctrl+V 怎么从渲染进程拿到 NodeJS，去做监听响应。
  • 需要考虑清楚怎么解决UI交互、文件发送时在渲染层的问题。
  • 会增加跨进程数据通讯或异步数据更新的数据交互频次（耗时增加）。

• 先看个效果
• 最简单的护眼实现代码
• 让是否开启“护眼模式”可控
• 配合离线存储，记住用户设置
• 支持微调亮度对比度（修改文档流上下文的CSS规则）
• 如何监听系统主题色调变化
• 不带UI的，“完整”效果代码
• CSS中的其他可用方案

先看个效果

默认模式：

护眼模式：

对于需要长时间盯着屏幕同学，后面这个“护眼模式”相对“默认模式”的亮底，应该算是更舒适、不那么容易引起视觉疲劳的一个选择。

在当下，作为Web前端开发者，要在网页上添加这么个护眼模式，其实可能并不需要定制化的去针对暗色调写一套完整皮肤样式。

最简单的护眼实现代码

要在任意网站启用上图的“护眼模式”，其实你只需要打开浏览器控制台，执行以下代码就可以了：

    const cssEl = document.createElement('style')
    cssEl.innerHTML = `
        html.cye-enabled {
          filter: contrast(0.96) brightness(0.9) invert(1);
        }
        html.cye-enabled img {
          filter: brightness(0.9) invert(1);
        }
    `;
    document.head.appendChild(cssEl);
    document.documentElement.classList.add('cye-enabled');

很简单对不对。

其实就是给 documentElement 添加一个样式类，相应的，也就是添加个反色滤镜（让亮色变成暗色）。

不想让img图片变成反色而导致肉眼无法识别，则可以再通过滤镜反转回来。

让是否开启“护眼模式”可控

配合离线存储，记住用户设置

支持微调亮度对比度（修改文档流上下文的CSS规则）

如何监听系统主题色调变化

不带UI的，“完整”效果代码

可以复制以下代码到浏览器控制台执行，然后通过 window.setCyeFilter(enabled, contrast, brightness)设置护眼模式开关方式、对比度、亮度。

(() => {
    const cssEl = document.createElement('style')
    cssEl.innerHTML = `
        html.cye-enabled {
          background: #fff; /* 如果有自己的背景色，那么去掉这行 */
          filter: contrast(0.96) brightness(0.9) invert(1);
        }
        html.cye-enabled img {
          filter: brightness(0.9) invert(1);
        }
        html.cye-enabled body {
            filter: none !important; /* 防止三方浏览器插件等重复的护眼样式生效 */
        }
    `;
    document.head.appendChild(cssEl);
    // document.documentElement.classList.add('cye-enabled');

    /***** 一些JS设置逻辑 ****/
    // 护眼模式
    const getLV = (k) => JSON.parse(localStorage.getItem(k));
    const setLV = (k, v) => localStorage.setItem(k, JSON.stringify(v));

    let cyeMediaQueryList = null;
    try {
      cyeMediaQueryList = window.matchMedia('(prefers-color-scheme: dark)');
      cyeMediaQueryList.addListener(setDocCyeByLS); // 通过浏览器API监听系统层面的主题模式配置变换
    } catch(e) {
      console.warn('当前环境可能不支持 matchMedia');
    }
    window.setCyeFilter = (enabled, contrast, brightness) => {
      setLV('cyeEnabled', enabled); // true 开启护眼模式，false 关闭护眼模式，2 跟随系统主题是否黑暗模式动态设定
      setLV('cyeContrast', contrast); // 对比度，可微调视觉效果
      setLV('cyeBrightness', brightness); // 亮度，可微调视觉效果

      // 护眼模式为“开启”或“跟随系统”且系统是开启的
      const isOpen = enabled === true || (enabled == 2 && cyeMediaQueryList && cyeMediaQueryList.matches);
      const { classList } = document.documentElement || {};
      classList && classList[isOpen ? 'add' : 'remove']('cye-enabled');

      if (!isOpen) return;
      const sss = document.styleSheets;
      if (!sss) return;
      let csss = null;
      for (let i = 0; i < sss.length; i++) {
        const cssi = sss[i];
        if (cssi && cssi.ownerNode && cssi.ownerNode.id == 'ghdef') {
          csss = cssi;
          break;
        }
      }
      if (!csss) return;
      const ruls = csss.rules;
      if (!ruls) return;
      let clsObj = null;
      for (let j = 0; j < ruls.length; j++) {
        const rulj = ruls[j];
        if (rulj && rulj.selectorText === 'html.cye-enabled') {
          clsObj = rulj;
          break;
        }
      }
      if (!clsObj) return;
      clsObj.style.filter = 'contrast(' + contrast + ') brightness(' + brightness + ') invert(1)';
      return true;
    };
    // 根据本地存储，判断是否开启护眼模式
    function setDocCyeByLS() {
      setCyeFilter(
        getLV('cyeEnabled'),
        getLV('cyeContrast') || 0.96,
        getLV('cyeBrightness') || 0.9
      );
    };
    setDocCyeByLS();
})()

CSS中的其他可用方案

mix-blend-mode: difference

https://blog.csdn.net/weixin_44733660/article/details/121958062

• 前言
• 剪切板富文本的应用
  • 剪切板HTML内容的读取
  • HTML内容特定场景的二次利用
  • 主动写HTML内容到剪切板
• 网页中通过拖拽分享数据
  • 网页中接收文件拖入
  • 从网页中拖出文本内容
  • 网页中接收拖入的文本内容
  • 查看拖入网页的各种内容数据
  • 单次拖出多种类型数据
  • 设置拖拽图标
  • 从网页中拖出文件
    • File 拖出
    • 文件拖出结论
  • 拖拽下载
• 写在最后

前言

我在前面一篇文章《记一个网页端IM文本编辑器的演进过程 （https://blog.pyzy.net/post/editor.html ）》虽然没有提到 DataTransfer，但实际也涉及到了从剪切板（clipboardData）或拖拽元素（dataTransfer）来读取内容、插入编辑区的功能。

而在更早的另一篇文章《Web前端剪切板文本分享到文件发送 （ https://blog.pyzy.net/post/clipboard.html ）》一文里，也有涉及到过剪切板（clipboardData）或拖拽磁盘文件（dataTransfer）读取识别内容达成文件上传发送相关的介绍。

今天，再通过具体示例，接续前面两篇文章内容，来聊一聊“通过DataTransfer 读取使用剪切板HTML富文本、以及通过拖拽分享数据内容”的两个场景化应用。

剪切板富文本的应用

先接续上最近的、也就是上一篇编辑器相关的能力拓展。

剪切板HTML内容的读取

在《Web前端剪切板文本分享到文件发送 》一文的《认识剪切板中的内容》一节中，有介绍通过监听 document 的 paste 粘贴事件来读取剪切版内容，通过当时的 Demo工具 也可以直接在线看到能从剪切板读取的内容。

比如复制前面正在看到的这段文字，到Demo工具页粘贴，可以看到能读取到text/plain和text/html两种类型的内容：

简化后的“通过对粘贴事件的监听读到剪切板中的HTML内容”代码如下：

document.addEventListener('paste', (evt) => {
  const { clipboardData } = evt;
  const html = clipboardData.getData('text/html');
  console.log('html:', html);
});

HTML内容特定场景的二次利用

我们在之前《记一个网页端IM文本编辑器的演进过程 （https://blog.pyzy.net/post/editor.html ）》中有介绍，当时实现的这个“富文本编辑器”，并不是能接受任意HTML的，有按照场景化需求特意定制的能力实现。

所以还需要给编辑器添加一个 editor.insertHTML(html)的能力，将HTML内容还原成符合编辑器需要的内容就可以了「这里需要留意是否可能产生XSS风险、而需要过滤防范」。

这其实也简单，因为之前实现的“富文本与正文数据互转 ”中已经实现了对普通HTML节点树进行过滤、转换为编辑器所需JSON描述内容的能力 richTextNodes2MsgData(richTextEl)，最后再通过 insertNodes 插入编辑器即可。

所以这里只要从任意三方复制的 html 内容是能符合编辑器合法输入元素规则的，都可以很方便的还原成可二次使用的数据。

同理，如果从Execl复制一个表格，要在自己的WEB网页应用中粘贴还原出表格，自然也可以做到，只要做好特定场景的HTML内容格式化转换能力就够了。

主动写HTML内容到剪切板

有时候我们也会遇到主动写HTML富文本内容到剪切板的情况，按最新API能力可以如下实现：

const type = 'text/html';
navigator.clipboard.write([
  new ClipboardItem({
    [type]: new Blob(
        [`<span>html content...</span>`],
        { type }
    ),
  }),
]).then(
  () => console.log('ok'), 
  (err) => console.log('err', err)
);

但当下（撰写本文时）各浏览器对 Clipboard API 能力的支持程度还不够理想。

比如：支持clipboard.write的浏览器，也未必支持write text/html内容到剪切板；而支持text/html的浏览器可能也未必开启了剪切板操作权限等等。

如果要考虑兼容性降级支持，来实现一个 HTMLElement 的复制，不妨试一下下面这个方案：

<!DOCTYPE html>
<html>
<head>
  <meta charset="utf-8">
  <meta name="robots" content="noindex">
  <meta name="viewport" content="width=device-width">
  <title>复制HTML元素</title>
</head>
<body>
  <div id="el">
    <button id="btn">复制</button>
    <p id="ret">点击复制试试</p>
  </div>
  <script>
    btn.onclick = async () => {
      const ret = await copyElement(el);
      ret.innerText = (
        ret === true ? '复制成功' : `复制失败: ${ret}`
      );
    };

    async function copyElement(el) {
      try {
        const type = 'text/html';
        const text = 'text/plain';
        const ret = await navigator.clipboard.write([
          new ClipboardItem({
            [type]: new Blob([el.outerHTML], { type }),
            [text]: new Blob([el.innerText], { type: text }),
          }),
        ]).then(() => true, (err) => {
          console.log('[clipboard.write] err:', err);
          return false;
        });
        if (ret) return ret;
      } catch (err) {
        // 忽略异常，走下面的备用方案
        console.log('[Error] Clipboard write:', err);
      }
      try {
        // 【注意】目标元素CSS属性user-select 不能是禁用选择的

        /* 选中目标元素 sta */
        const pEl = el.parentElement;
        const idx = [...pEl.childNodes].indexOf(el);
        const ra = document.createRange();
        ra.setStart(pEl, idx);
        ra.setEnd(pEl, idx + 1);
        const sel = window.getSelection();
        sel.removeAllRanges();
        sel.addRange(ra);
        /* 选中目标元素 end */

        /* 复制选中内容 */
        document.execCommand('Copy');

        /* 移除选择状态 */
        sel.removeAllRanges();

        return true;
      } catch (err) {
        return '[Error] Set Selection And Copy' + err;
      }
    };
  </script>
</body>
</html>

上面的复制HTML元素到剪切板的代码实现，你也可以点这里在线试一下。

网页中通过拖拽分享数据

HTML5中Drag、Drop相关的API能力，早已经不是个新的话题了。

通过拖拽文件放置到网页中来达成上传、网页中通过拖拽商品放置购物车实现购买等等，很多具体应用场景，大家也许早就不知不觉中有过相关的交互体验。

而Drag、Drop又完全可以分开了单独使用。

网页中接收文件拖入

比如可以通过监听 document 的 drop 事件，感知到文件的放入，通过 event.dataTransfer 拿到拖入的数据信息：

document.addEventListener('drop', (e) => {
  e.preventDefault();
  console.log(e.dataTransfer)
});
document.addEventListener('dragover', (e) => {
  e.preventDefault();
});

而浏览器对文件拖入是有默认行为的，比如HTML会直接被打开，所以当你想自己接管数据拖入的后续行为时，必须知道 preventDefault 是必须的。

而在文件上传的场景中，如果对用户拖入文件夹展开，以实现对文件逐个上传，往往也是必须的（文件拖入监听的在线demo）：

<!DOCTYPE html>
<html>
<head>
  <meta charset="utf-8">
  <meta name="robots" content="noindex">
  <meta name="viewport" content="width=device-width">
  <title>JS Bin</title>
  <style id="jsbin-css">
    h2 {
      border-bottom: solid 1px #eee;
      font-size: 16px;
      padding: 10px;
    }
    #container {
      border: solid 1px #eee;
      padding: 10px;
      background: #f9fdff;
    }
    #container:empty:after {
      content: '试试从磁盘拖拽文件或文件夹到这里';
      color: #aaa;
      font-size: 14px;
    }
    .item {
      line-height: 22px;
      font-size: 14px;
      margin: 10px 0;
      border-bottom: 1px solid #ccc;
    }
  </style>
</head>
<body>
  <h2>文件列表：</h2>
  <div id="container"></div>
  <script>
    document.addEventListener('drop', (e) => {
      e.stopPropagation();
      e.preventDefault();
      const entrys = items2Entrys(e.dataTransfer.items);
      getFileListByEntrys(entrys).then((fileList) => {
        container.innerHTML = fileList.map((file, i) => {
          const { fullPath, type, name, size } = file;
          return `
            <div class="item">
              序号: ${i}; <br />
              path: ${fullPath || name}; <br />
              type: ${type}; <br />
              size: ${size}
            </div>
          `;
        }).join('');
      });
    });

    document.addEventListener('dragover', (e) => {
      e.stopPropagation();
      e.preventDefault();
    });

    // 获取 fileList
    async function getFileListByEntrys(entrys) {
      const fileList = [];
      await Promise.all(
        [...entrys].map(async (entry) => {
          if (entry.isDirectory) {
            // 子文件夹内容
            const subEntries = await unfoldDirectory(entry);
            // 递归展开
            const subItems = await getFileListByEntrys(subEntries);
            fileList.push(...subItems);
          } else {
            // 读取文件信息
            await new Promise((resolve) => {
              const errCbk = (err) => {
                console.warn(err);
                resolve();
              };
              try {
                entry.file((file) => {
                  if (file) {
                    file.fullPath = entry.fullPath;
                    fileList.push(file);
                  }
                  resolve();
                }, errCbk);
              } catch (err) {
                errCbk(err);
              }
            });
          }
        })
      );
      return fileList;
    }

    // DataTransferItem 转 FileSystemEntry
    function items2Entrys(items) {
      return [...items].map((item) => {
        return (
          (item.getAsEntry && item.getAsEntry()) ||
          (item.webkitGetAsEntry && item.webkitGetAsEntry())
        );
      }).filter((item) => !!item);
    }

    // 展开文件列表
    function unfoldDirectory(item) {
      return new Promise((resolve) => {
        item.createReader().readEntries(resolve, () => resolve([]));
      });
    }
  </script>
</body>
</html>

而更多的场景可能还需要记录下文件所处文件夹信息，也可以基于上面代码自己试着修改实现一下，怎么还原出拖拽内容的树状目录结构。

从网页中拖出文本内容

按惯例，从简入繁，后面介绍文件拖拽前，我们先试验一下文本的拖拽应用。

在网页里创建个<span />，为其增加 draggable="true" 配置为可拖拽的元素，然后再监听其被拖拽的行为事件，并写一段自定义数据到 dataTransfer中。

大致代码如下（自定义文本内容拖拽DEMO）：

<!DOCTYPE html>
<html>
<head>
  <meta charset="utf-8">
  <title>可拖拽内容页</title>
  <style>
    body {
      padding: 50px;
    }
    #draggable {
      border: solid 1px #ccc;
      padding: 10px 20px;
    }
  </style>
</head>
<body>
  <span id="draggable" draggable="true">可拖拽元素块</span>
  <script>
    const el = document.getElementById('draggable');
    el.addEventListener('dragstart', (e) => {
      e.dataTransfer.setData(
        'text',
        '这是一段拖拽内容 wakakaka~ '
      );
    });
  </script>
</body>
</html>

效果截图：

这时候，就可以通过拖拽“可拖拽文本”将自定义内容拖拽到任意三方APP里了，比如拖拽到一个本地文本编辑器中正编辑内容中的话，你就会看到放入位置多出了我们设置的 '这是一段拖拽内容 wakakaka~ ' 文案内容。

需要注意的是：如果拖拽文本内容到系统磁盘或桌面，可以得到一个扩展名为textClipping、内容为自定义文本内容的文本文件。

这有时候并不是想要的，比如拖拽一个商品到购物车的应用场景。

如果又刚好是单页应用内部的拖拽（非垮页、垮应用交互），可能放弃使用 dataTransfer.getData，而选择走内存变量的方式更符合应用场景（这不会干扰浏览器或WebView原有默认拖拽行为）。

网页中接收拖入的文本内容

当然，我们自然可以实现一个接受拖入文案的网页，来对上面场景的文本拖拽做相关应用，大致代码实现和“网页中接收文件拖入类似”，不同的是只用来读取数据。

也可以通过打开 网页中接收拖入文本内容Demo 来在线试验：

document.addEventListener('drop', (e) => {
  e.preventDefault();
  const text = e.dataTransfer.getData('text');
  document.body.innerText = `[${+new Date()}] 您拖入了内容：${text}`;
});
document.addEventListener('dragover', (e) => {
  e.preventDefault();
});

这里为了方便演示垮应用数据分享，将“从网页中拖出文本内容”、“网页中接收拖入的文本内容”分成了两个独立网页来分别实现。

如果是单页应用内的交互能力，当然也可以放到一个页面里去实现。

查看拖入网页的各种内容数据

综合上面各种交互能力，为了方便观察拖拽数据内容。

类似之前剪切板内容读取Demo ，我们也先实现一个拖拽内容读取Demo工具。

<!DOCTYPE html>
<html>
<head>
  <meta charset="utf-8">
  <meta name="robots" content="noindex">
  <meta name="viewport" content="width=device-width">
  <title>拖拽dataTransfer内容读取试验</title>
  <style id="jsbin-css">
    h2 {
      border-bottom: solid 1px #eee;
      font-size: 16px;
      padding: 10px;
    }
    #container {
      border: solid 1px #eee;
      padding: 10px;
      background: #f9fdff;
    }
    #container:empty:after {
      content: '试试拖拽任意内容到当前页面中看看。';
      color: #aaa;
      font-size: 14px;
    }
    h3 {
      border-bottom: solid 1px #eee;
      font-size: 16px;
      padding: 0 0 10px;
      margin: 10px 0;
    }
    textarea {
      display: block;
      width: 95%;
      height: 200px;
      padding: 8px 10px;
      box-shadow: 1px 1px 3px rgb(0 0 0 / 20%) inset;
      border-radius: 4px;
    }
    img {
      display: block;
      width: 100%;
    }
    p {
      margin: -10px -10px 0;
      display: block;
      background: #d4f2ff;
      padding: 10px;
      border-bottom: solid 1px #cde0e9;
      text-shadow: 1px 1px 0px #fff;
    }
  </style>
</head>
<body>
  <h2>拖拽dataTransfer内容：</h2>
  <div id="container"></div>
  <script>
    document.addEventListener('drop', (evt) => {
      evt.preventDefault();
      container.innerHTML = '';
      const items = Array.from((evt.dataTransfer || {}).items || []);
      const countEl = document.createElement('p');
      countEl.innerText = 'event.dataTransfer.items.length: ' + items.length;
      container.appendChild(countEl);
      items.forEach((item, i) => {

        const { kind, type } = item;
        const entry = item.webkitGetAsEntry && item.webkitGetAsEntry();
        const isDirectory = entry && entry.isDirectory;

        const hdEl = document.createElement('h3');
        hdEl.innerText = `序号：${i}；kind：${kind}; type：${type};`;
        container.appendChild(hdEl);

        let previewEl = null;

        if (isDirectory) {
          previewEl = document.createElement('a');
          previewEl.innerText = '文件夹：' + entry.fullPath;
        } else if (kind === 'file') {
          const file = item.getAsFile();
          const url = URL.createObjectURL(file);
          if (/image/i.test(type)) {
            previewEl = document.createElement('img');
            previewEl.src = url;
          } else {
            previewEl = document.createElement('a');
            previewEl.href = url;
            previewEl.download = file.name;
            previewEl.innerText = file.name;
          }
        } else {
          previewEl = document.createElement('textarea');
          item.getAsString((str, ...args) => {
            console.log('str', str, ...args)
            previewEl.value = str;
          });
        }

        container.appendChild(previewEl);
      });
    });
    document.addEventListener('dragover', (e) => {
      e.preventDefault();
    });
  </script>
</body>
</html>

现在如果从磁盘上拖入以下内容到上面网页：

大致能看到如下读取到的文件或目录信息：

单次拖出多种类型数据

前面我们只试验了单次拖出一段文本内容，实际上现有API能力已经允许单次拖拽得到多种不同类型的数据，到达目标APP后再自行选择要使用的数据。

有点类似从Excel复制一段表格内容，能得到截图、文本、HTML数据内容。

具体实现可以点这里在线试验"单次拖出多种类型数据"，也可以参考下面代码对前面的文本数据拖拽进行修改：

const el = document.getElementById('draggable');
el.addEventListener('dragstart', (e) => {
  const { items } = e.dataTransfer;
  items.add('text plain test', 'text/plain');
  items.add("<p>... html test ...</p>", "text/html");
  items.add("https://blog.pyzy.net","text/uri-list");
  items.add("hzj custom content","custom-hzj");
});

设置拖拽图标

如果你有留意API文档，会发现还提供了一个 dataTransfer.setDragImage 方法。 可以用来设置拖拽内容时跟随鼠标的图标。

另外，为了对比试验，我们在页面里使用一个img元素，来对比一下浏览器原生图片拖拽与通过JS API setDragImage 的差异（打开试验图片文件拖拽）：

<!DOCTYPE html>
<html>
<head>
  <meta charset="utf-8">
  <meta name="robots" content="noindex">
  <meta name="viewport" content="width=device-width">
  <title>图片拖拽</title>
  <style>
    body {
      padding: 50px;
    }
    #draggable {
      border: solid 1px #ccc;
      padding: 10px 20px;
    }
  </style>
</head>
<body>
  <span
    id="draggable"
    draggable="true"
  >
    可拖拽元素块
  </span>
  <br /><br/>
  <h3>原生IMG标签</h3>
  <img id="img" src="https://p4.ssl.qhimg.com/t0157fa323b319adac4.png" />
  <script>
    const el = document.getElementById('draggable');
    el.addEventListener('dragstart', (e) => {
      e.dataTransfer.setDragImage(img, 20, 20);
    });
  </script>
</body>
</html>

这里值得注意的是，设置拖拽图和单纯图片文件拖拽不是一回事；这一点可能会比较容易混淆。

其次，原生img元素拖拽时，实际也是HTMLElement元素的拖拽，目标接收者能得到图片资源对应的 text/uri-list、以及图片的outerHTML text/html 两种类型的具体数据，并没能得到预期的File数据。

从网页中拖出文件

前文中从网页中拖出文本使用的是dataTransfer.setData(...args)，这个方法接收的两个参数均为字符串，也就是只能往dataTransfer里写字符串。

但我们想直接让用户从网页上拖拽一个真正的文件（比如一个 new File(...args)对象）到磁盘或桌面，基于现有API是否能实现呢？

我们看到 event.dataTransfer.items 是有为前端开发者暴露了一个 add 方法的， 对应MDN文档DataTransferItemList.add(...args)。

File 拖出

不妨来创建个网页拖拽文件Demo试验一下自定义 File 拖出的思路：

<!DOCTYPE html>
<html>
<head>
  <meta charset="utf-8">
  <title>可拖拽文件</title>
  <style>
    body {
      padding: 50px;
    }
    #draggable {
      border: solid 1px #ccc;
      padding: 10px 20px;
    }
  </style>
</head>
<body>
  <span id="draggable" draggable="true">可拖拽元素块</span>
  <script>
    const el = document.getElementById('draggable');
    el.addEventListener('dragstart', (e) => {
      const file = new File(['text content'], 'filename.txt', {
         type: 'text/plain',
      });
      e.dataTransfer.items.add(file);
    });
  </script>
</body>
</html>

可以拖拽到前文拖拽内容读取Demo工具中看看数据内容。

经试验你会发现，目前（2021-11-25）还是无法达成预期的文件拖拽的：其表现和个别浏览器中剪切板复制粘贴文件类似，只能拿到文件名...

文件拖出结论

虽然看起来API设计上允许 add一些File 到DataTransferItemList或setDragImage来写入图片，但还是跟理想的“文件拖拽”的预期结果存在巨大差异；目前来看，也就没有靠谱方案基于浏览器端 JS API 直接实现文件拖出了。

但不妨发散一下脑洞，如果是被拖出和接收拖入的目标APP都是可控范围内的，也许可以 dataTransfer.setData('my-cus-type', DataURL) 的方案，通过自定义字符串数据的类型和内容来自行解决。

如果刚好是Electron中的网页应用，那就方便的多了，可以通过原生文件拖拽相关API，达成Electron场景中的网页内拖拽文件给三方APP或桌面的能力。

拖拽下载

另外，想要拖拽触发浏览器的下载并将文件存储到磁盘目标位置，还有下面这个非标准方案：

<a id="btnDownload" draggable="true">拖拽下载</a>
<script>
const TYPE = 'image/png';
const NAME = 'name.png';
const URL = 'https://example.com/tmpname.ext';
btnDownload.onDragStart = (evt) => {
    event.dataTransfer.setData('DownloadURL', `${TYPE}:${NAME}:${URL}`);
};
</script>

写在最后

首先，感谢您的阅读关注。

还是如同往常一样，请读者注意：以上所有示例代码更侧重在思路示意，甚至可以说是伪代码，如果要在正式业务场景应用，请一定酌情调整、增加严谨性、健壮性、兼容性相关考量。

另外，相关API能力也是日新月异，本文的方案只是基于时下的形式考虑，如果发现不符欢迎随时指正，以免误导。

有更具体和拓展思路的应用场景，欢迎联系作者补充进来，一起拓展Web前端的能力边界，达成更多实用的业务能力。

• 背景
• 基础效果
• 历史问题
• 精简提效
• 隐含功能
• 新需求-“图文混发”
  • "需求文档"：
  • 最终实现效果
  • 最终达成功能概要
• “图文混发”关键技术环节
  • 技术选型
  • insert 方法改造
  • 富文本与正文数据互转
  • 光标位置读写
  • 编辑器内容插入的入口方法
  • 草稿存储改造（含插入图片存储）
  • 兼容性
  • 特殊内容相关
• 后记

背景

前端项目开发中，为用户输入内容提供一个编辑框是非常常见的基础交互需求。 比如博客文章下面的评论区、可视化富文本编辑、在线代码编辑器...

根据不同的业务场景，我们应该做怎么样的调研？怎么决定选型？相关技术点又有哪些？

基础效果

比如某个历史项目里，有下图这么一个编辑器。

通过示意可以看到，大致功能：

1. 可以输入文本。
2. 编辑器外点击表情图，插入类似“[微笑]”的方括号定界描述符。
3. 编辑器外点击人名，可以插入“@xxx ”。

历史问题

通过读源码，发现这个项目编辑器的选型是基于开源的Slate、以及依赖的一些模块 slate-react、slate-plug-xxx等实现的。

继续读代码发现，原来除了需要 insertText 到目标光标位置，并且输入“@xx”后，还需要按照光标在文档流中坐标位置，展示备选菜单。

基于Slate的API和插件，确实可以很方便的实现插入内容到光标位置、光标坐标获取，但也很明显带来了新的问题：

1. 三方依赖包体量过大。
2. 对中文输入法兼容不友好：会意外多出现类似“zhong'wen'xxx”的内容。
3. 编辑器自带个别能力与上下文环境冲突，会导致JS崩溃、React渲染空白等。
4. ...

参考前文功能需求描述，这选型无疑是高射炮打蚊子了。 而且带来的问题确实不能容忍。

精简提效

相对Slate来说更换成原生HTML元素 <textarea>，是更轻量级、更稳妥可靠的一个方案。这里就不具体赘述了，一个简化的实现效果可到 https://lab.pyzy.net/txt_editor.html 查看。

隐含功能

除了直观上看到的纯文本编辑，额外还有看不到的能力：

1. 被@人员列表数据。
2. 草稿存储。
3. 消息撤回重新编辑。

除了(1)，只能用额外数据列表记录，2和3基于纯文本都比较好实现，2直接存储String到localStorage，3直接insertText(String)全文就可以了。

新需求-“图文混发”

"需求文档"：

最终实现效果

相对前面的纯文本编辑，区别也很明显，这里@、表情是所见即所得了，同时另外支持了插入图片（图文混排）。

最终达成功能概要

通过前面截图，我们视觉能直观看到编辑时达成的功能，基本可归纳为：

1. 可以输入任意纯文本内容。
2. 通过表情面板，点击插入所见即所得的图片表情图。
3. 通过@面板，可以插入高亮的“@xxx ”HTML标记。
4. 通过工具栏文件选择或粘贴截图来插入图片。

而点击发送时，我们再将编辑器呈现的富文本，转换为符合发送需要的JSON描述符即可。比如：

1. 表情图转为"[微笑]"描述符;
2. 高亮的“@xxx”转为纯本文，并提取被@人uid、uname，生成JSON数据;
3. 将插入的图片上传服务端，得到文件唯一标识，放入JSON描述体中，并对应到文本中应该在的位置。
4. ...

“图文混发”关键技术环节

1. 技术选型
2. insertText 改造。
3. 富文本与正文数据互转。
4. 光标位置。
5. 草稿存储改造（含插入图片存储）。
6. 兼容性。

技术选型

基于前文考虑，如果我们使用现成的开源编辑器，自然开发成本最低，但稳定性和维护成本无法估量。

这里，最终选择了基于原生的 <div contenteditable="true" /> 为业务量身打造一个编辑器。

insert 方法改造

在基于<textarea>实现编辑时，insertText的实现我们基于 textareaHTMLElement.value、textareaHTMLElement.selectionStart、textareaHTMLElement.selectionEnd便可以得到输入的完整文本内容、选中区间，然后进行替换、重写，基于textareaHTMLElement.setSelectionRange(sta, end)重新设置选中内容区间。（详见示例源码 ）

基于<div contenteditable="true" />时，insertText的实现，需要转换为 insertNodes，对应到基础层各Nodes类型的insert方法代码片段如下：

// 注意：下面代码仅是示意，包含缺少定义的环境变量

// 创建一个文本节点
function createTextNode(text) {
  return document.createTextNode(String(text));
}
function createBrEl() {
  return document.createElement('br');
}
// 创建一个 At El
function createAtEl(uid, name) {
  const atEl = document.createElement('span');
  atEl.className = atCls;
  atEl.innerText = '@' + name + _atSuffix;
  setAttributes(atEl, {
    'data-uid': uid,
    'data-name': name,
    contenteditable: false, // 不可编辑修改Span内容
  });
  return atEl;
}

// 创建一个表情图 El
function createEmojiEl(tips, src) {
  const emojiEl = document.createElement('img');
  emojiEl.className = emojiCls;
  setAttributes(emojiEl, {
    src,
    alt: `[${tips}]`,
    'data-tips': tips,
  });
  return emojiEl;
}
// 创建一个插图 El
function createImgEl(file, width, height) {
  let src = '';
  let title = '';
  let draftFid = '';
  if (file) {
    draftFid = getDraftFidByFile(file);
    title = file.name;
    try {
      src = URL.createObjectURL(file);
    } catch (err) {}
  }
  const imgEl = document.createElement('img');
  imgEl.className = picCls;
  setAttributes(imgEl, {
    src,
    title,
    alt: '[图片]',
    'data-width': width,
    'data-height': height,
    'data-draft-fid': draftFid,
  });
  /*
  这里的图片产品需求中要支持双击打开图片查看器预览，
  但用户是否预览、是否多图、什么时机预览不确定的，
  所以不可以 revokeObjectURL 掉。
  if (src) {
    imgEl.onload = () => {
      try {
        URL.revokeObjectURL(src);
      } catch (err) {}
    };
  }*/
  return imgEl;
}

富文本与正文数据互转

首先，看信息字串转为富文本节点数组。

归根核心，也就是怎么将类似"测试文本 [微笑] @xxx 等等等"的消息字串，转为能使用insertNodes插入富文本编辑器的节点数组。

具体实现，依赖一个名为 rich2nodeRegExp 的正则变量，将文本中内容按定界符提取并替换为对应HTMLNode。

// 注意：下面代码仅是示意，包含缺少定义的环境变量
function richText2Nodes(richText) {
    const rtelNodes = [];
    const rtelTexts = String(richText)
      .replace(rich2nodeRegExp, (str, br, atName, emojiTips) => {
        if (br) {
          rtelNodes.push(createBrEl());
          return rtelSplitter;
        } else if (atName) {
          const atUser = at && _.find(at, ({ name }) => name === atName);
          if (atUser) {
            const { uid, name } = atUser;
            rtelNodes.push(createAtEl(uid, name));
            return rtelSplitter;
          }
        } else if (emojiTips) {
          const emojiItem = emojiMaps[emojiTips];
          if (emojiItem) {
            rtelNodes.push(createEmojiEl(emojiTips, emojiItem.url));
            return rtelSplitter;
          }
        }
        return str;
      })
      .split(rtelSplitter);
    _.forEach(rtelTexts, (txt, i) => {
      rtelNodes.push(createTextNode(txt));
    });
    return rtelNodes;
}

接下来，再看怎么将富文本编辑器内，用户输入的内容转为消息JSON数据。

// 注意：下面代码仅是示意，包含缺少定义的环境变量

function richTextNodes2MsgData(richTextEl) {
  const ret = {
    txt: '', // 用于纯文本展示需求
    at: [], // 用于记录at人员名单 [{ uid, name }]
    msgs: [], // 用于支持图文混排 [{ key: 'txt', val: '' }, { key: 'img', width: 123, height: 456, file: File }]
  };
  if (!_.get(richTextEl, 'childNodes.length')) {
    // 输入框是空的，直接返回空消息体内容
    return ret;
  }
  /* 图、文（含At文本）、表情提取 sta */
  const picEls = richTextEl.getElementsByClassName(picCls);
  // 生成图文混排中的图片定界符
  const picSplitter = `[IMG:${getUuid()}]`;
  const tmpEl = getTransCodeEl();
  // 用定界符替换用户插入图片产生的DOM元素
  tmpEl.innerHTML = richTextEl.innerHTML
    // 去除用来便于光标移动的0宽字符
    .replace(blankRegExp, '')
    // 插图转为定界符
    .replace(picTagRegExp, picSplitter)
    // 表情图转未文本标记符如“[微笑]”
    .replace(emojiTagRegExp, (str) => (emojiTipsRegExp.exec(str) || '')[1]);

  const { msgs } = ret;
  // 格式化消息内容
  const txts = tmpEl.innerText.split(picSplitter);
  const maxI = txts.length - 1;
  _.forEach(txts, (val, i) => {
    const picEl = picEls[i];
    if (val) {
      if (i === 0) {
        // 对第一条文本消息的前面换行符进行过滤; 不可以做trim处理
        val = val.replace(/^[\r\n]+/, '');
      }
      if (i === maxI && !picEl) {
        // 对最后一条文本消息的末尾换行符进行过滤; 不可以做trim处理
        val = val.replace(/[\r\n]+$/, '');
      }
      if (val) {
        ret.txt += val;
        msgs.push({ key: 'txt', val });
      }
    }
    if (picEl) {
      ret.txt += '[图片]';
      const {
        'data-width': width,
        'data-height': height,
        'data-draft-fid': draftFid,
      } = getAttributes(picEl, ['data-width', 'data-height', 'data-draft-fid']);
      msgs.push({
        key: 'img',
        height,
        width,
        file: getFileByDraftfId(draftFid),
      });
    }
  });
  /* 图、文（含At文本）、表情提取 end */

  /* At列表提取 sta */
  const { at } = ret;
  const atEls = richTextEl.getElementsByClassName(atCls);
  _.forEach(atEls, (el) => {
    const { 'data-uid': uid, 'data-name': name } = getAttributes(el, [
      'data-uid',
      'data-name',
    ]);
    at.push({ uid, name });
  });
  /* At列表提取 end */
  tmpEl.innerHTML = '';
  return ret;
}
`

富文本内容转消息JSON，后便可以进行草稿存储、提交服务端了，大体格式如下：

 {
    txt: '', // 用于纯文本展示需求
    at: [], // 用于记录at人员名单 [{ uid, name }]
    msgs: [], // 用于支持图文混排 [{ key: 'txt', val: '' }, { key: 'img', width: 123, height: 456, file: File }]
  }

光标位置读写

这里按基础能力需要，也需要拆分多个核心基础方法。

首先，需要最基本的光标选取读写能力。

function getSel() {
  return (window.getSelection && window.getSelection()) || {};
}

// 更换选中内容
function replaceRange(opts) {
  try {
    const { staNode, staOffset, endNode, endOffset } = opts;
    if (!staNode.parentNode || !endNode.parentNode) {
      return;
    }
    const ra = document.createRange();
    ra.setStart(staNode, amendChildOffset(staNode, staOffset));
    ra.setEnd(endNode, amendChildOffset(endNode, endOffset));
    const sel = getSel();
    sel.removeAllRanges();
    sel.addRange(ra);
  } catch (err) {
    console.log('[Errror] replaceRange', opts, err);
  }
}
// 修正子元素定位下标值
function amendChildOffset(pEl, childOffset) {
  return Math.min(
    childOffset,
    _.get(pEl, 'childNodes.length') || _.get(pEl, 'length') || 0
  );
}
// 移动光标到目标元素的第几个子内容后面
function moveOffset(targetNode, idx = 0) {
  if (!targetNode) return;
  replaceRange({
    staNode: targetNode,
    staOffset: idx,
    endNode: targetNode,
    endOffset: idx,
  });
}
// 移动光标到目标节点前后 @isAfter 是否定位到目标后面
function moveOffset2Node(nodeEl, isAfter = false) {
  try {
    const parentNd = nodeEl.parentNode;
    if (parentNd) {
      const idx = _.indexOf(parentNd.childNodes, nodeEl) + (isAfter ? 1 : 0);
      moveOffset(parentNd, idx);
    }
  } catch (err) {
    console.log('[Errror] moveOffset2Node：', nodeEl, isAfter, err);
  }
}

按光标所在位置获取左侧文本内容及文本节点对象。

getCursorLeftObj = () => {
  this.focus(); // 先保证光标在输入框里
  const sel = getSel();
  const ret = { sel };
  const { anchorNode, focusNode, anchorOffset, focusOffset } = sel;
  // 光标不在一个独立的文本节点内，或者用户有在主动选取文本内容，则不做At文案提取
  if (
    focusNode &&
    anchorNode === focusNode &&
    isTxtNode(focusNode) &&
    !isNaN(focusOffset) &&
    anchorOffset === focusOffset
  ) {
    const { data } = focusNode;
    if (data) {
      ret.node = focusNode;
      ret.offset = focusOffset;
      // 光标左侧文本内容
      ret.txt = data.substring(0, focusOffset);
    }
  }
  return ret;
};

获取光标在文档流中的坐标位置。

getRangePosition = () => {
  this.focus(); // 先保证光标在输入框里
  const sel = getSel();
  let ret = {};
  if (sel.getRangeAt) {
    const ra = sel.getRangeAt(0);
    if (ra && ra.getBoundingClientRect) {
      ret = ra.getBoundingClientRect();
    }
  }
  return ret;
};

编辑器内容插入的入口方法

结合上文的各种方法，还需要再实现一个可以一次批量插入多个节点到编辑器的 insertNodes 方法，作为内容插入的总入口：

  // 插入多个HTML节点元素到光标区域
  insertNodes = (nodes) => {
    // this.focus(); // 让编辑器输入区为焦点获取状态
    try {
      const sel = getSel();
      const richEl = document.getElementById('richTextEl');
      const fnode = sel.focusNode;
      if (!fnode || (fnode !== richEl && !richEl.contains(fnode))) {
        return; // 防止内容插入到编辑器区域外
      }
      let ra = null;
      if (sel.rangeCount) {
        ra = sel.getRangeAt(0);
        ra.deleteContents();
      } else {
        ra = document.createRange();
        sel.removeAllRanges();
        sel.addRange(ra);
      }
      const nodeCount = _.get(nodes, 'length');
      if (nodeCount) {
        const fragment = document.createDocumentFragment();
        const atEls = [];
        _.forEach(nodes, (el, i) => {
          isAtNode(el) && atEls.push(el);
          fragment.appendChild(el);
        });
        ra.insertNode(fragment); // 关键就是这里

        // autoAddBlank(atEls);  // 为Element补全光标占位符
        // 光标到最后一个元素后
        moveOffset2Node(nodes[nodeCount - 1], true);
      }
    } catch (err) {
      console.log('insertNode Err：可能是浏览器环境兼容问题。', err);
    }
    // 触发变更事件
    // this.onChangeHandler();
  };

草稿存储改造（含插入图片存储）

原有草稿存储，是基于本地存储的 localStorage.set localStorage.get；如果要进行图片文件存储，肯定是不合适的，所以这里又引入了 indexedDB，写了一个 ttIndexedDb 操作对象。

const ttIndexedDb = ((win) => {
  let { _ttIndexedDb } = win;
  if (_ttIndexedDb) return _ttIndexedDb;

  win._hzj_idx_db_log = 0;

  idxDbPolyfill(win);

  // 打开并连接的 database 对象
  let db = null;

  // 草稿文件存储对象名称
  const draftFilesStoreName = 'draft_files';
  _ttIndexedDb = win._ttIndexedDb = {
    /* 读草稿文件从本地数据存储
     * @sid 会话ID
     * 返回 Promise
     */
    async readDraftFiles(sid) {
      return await this.readwriteStore({
        storeName: draftFilesStoreName,
        action: 'get',
        data: sid,
      });
    },
    /* 写草稿文件到本地数据存储
     * @data 草稿数据，示例： {
        sid: '123', 
        files: {
         'b456': new File(['123333'], 'test33.txt'),
         'b4563': new File(['123333'], 'test33.txt'),
        }
      }
     * 返回 Promise
     */
    async writeDraftFiles(data) {
      return await this.readwriteStore({
        storeName: draftFilesStoreName,
        action: 'put',
        data,
      });
      // if (req.error) console.log('写草稿文件失败！');
    },
    /* 删除草稿文件从本地数据存储
     * @sid 会话ID
     * 返回 Promise
     */
    async delDraftFiles(sid) {
      return await this.readwriteStore({
        storeName: draftFilesStoreName,
        action: 'delete',
        data: sid,
      });
    },
    /* 按名称、行为、参数，读写存储对象中对应数据
     * @storeName 存储对象名称
     * @action    操作行为，可选值：get、put、...
     * @data    行为对应的参数们
     * 返回 Promise
     */
    readwriteStore({ storeName, action = 'get', data }) {
      return new Promise(async (resolve) => {
        const isRead = action === 'get';
        const { db, error } = await this.openDb();
        if (error) {
          return resolve({ error });
        }
        try {
          const store = db
            .transaction(storeName, isRead ? 'readonly' : 'readwrite')
            .objectStore(storeName);
          const req = store[action](data);
          req.onsuccess = () => resolve(req);
          req.onerror = (error) => resolve({ error });
        } catch (error) {
          win._hzj_idx_db_log &&
            console.log('[Error] indexedDB.readwriteStore', error);
          resolve({ error });
        }
      });
    },
    // 打开数据库
    openDb() {
      return new Promise((resolve) => {
        if (db) {
          resolve({ db });
          return;
        }
        const { indexedDB } = win;
        if (!indexedDB) {
          win._hzj_idx_db_log &&
            console.log('[OpenError] Does not support with indexedDB!');
          resolve({ error: '[OpenError] Does not support with indexedDB!' });
        }
        const req = indexedDB.open('TX_IM', 1);
        req.onupgradeneeded = (e) => {
          win._hzj_idx_db_log &&
            console.log('[onupgradeneeded] indexedDB.open', e);
          // 创建草稿文件存储对象
          db = e.target.result;
          const store = db.createObjectStore(
            draftFilesStoreName, // 草稿文件存储对象
            // 按会话ID作为主键
            { keyPath: 'sid', autoIncrement: false }
          );
          // 支持按会话ID去索引
          store.createIndex('sid', 'sid', { unique: true });
        };
        req.onerror = (e) => {
          db = null;
          win._hzj_idx_db_log && console.log('[Error] indexedDB.open', e);
          resolve({ error: '[OpenError]' + req.error });
        };
        req.onsuccess = (e) => {
          win._hzj_idx_db_log && console.log('[onsuccess] indexedDB.open', e);
          db = e.target.result;
          db.onerror = (e) => {
            win._hzj_idx_db_log &&
              console.log('[onerror] creating/accessing IndexedDB database', e);
          };
          db.onclose = (e) => {
            win._hzj_idx_db_log && console.log('[onclose] indexedDB.open', e);
            db = null;
          };
          // 数据库版本变化，则关闭之（下次调用再开启）
          db.onversionchange = (e) => {
            win._hzj_idx_db_log &&
              console.log('[onversionchange] indexedDB.open', e);
            db.close();
          };
          resolve({ db });
        };
      });
    },
  };
  return _ttIndexedDb;
})(window);

// API兼容抹平问题
function idxDbPolyfill(win) {
  if (!win.indexedDB) {
    win.indexedDB =
      win.webkitIndexedDB ||
      win.mozIndexedDB ||
      win.OIndexedDB ||
      win.msIndexedDB;
  }
  if (
    win.indexedDB &&
    IDBObjectStore &&
    IDBObjectStore.prototype &&
    typeof IDBObjectStore.prototype.getAll !== 'function'
  ) {
    IDBObjectStore.prototype.getAll = (...args) => {
      const ret = {};
      const req = this.openCursor(...args);
      req.onerror = (...errArgs) => {
        const { onerror } = ret;
        if (typeof onerror == 'function') {
          onerror(...errArgs);
        }
      };
      const retArr = [];
      req.onsuccess = (...sucArgs) => {
        const { onsuccess } = ret;
        if (typeof onsuccess == 'function') {
          const { target } = sucArgs[0] || {};
          const cursor = target.result;
          if (cursor) {
            retArr.push(cursor.value);
            cursor.continue();
          } else {
            ret.result = retArr;
            target.result = retArr;
            onsuccess(...sucArgs);
          }
        }
      };
      return ret;
    };
  }
}

export default ttIndexedDb;

兼容性

细节问题很多，先记录两个。

在Safari浏览器端，contenteditable的元素可能还是无法获取光标的不可编辑状态，一定记得添加CSS：

[contenteditable]{
    -webkit-user-select: text;
    user-select: text;
}

兼容性方面还要特别注意，focus到DIV并不能保证保持之前的光标选中状态，所以这里要自己做光标状态记录、和恢复。

onSelectionChange = () => {
    // 进一步保证focus方法无效的问题
    const { richTextEl } = this.refs;
    const {
      focusNode: staNode,
      focusOffset: staOffset,
      anchorNode: endNode,
      anchorOffset: endOffset,
    } = getSel();
    if (
      (endNode === richTextEl || richTextEl.contains(endNode)) &&
      (staNode === richTextEl || richTextEl.contains(staNode))
    ) {
      this._selCache = { staNode, staOffset, endNode, endOffset };
      // console.log('记录光标状态！', this._selCache)
    }
  };
  // 设置输入框为焦点元素
  focus = () => {
    if (this.state.draftReading) return;
    const { richTextEl } = this.refs;
    // 恢复光标选中状态
    const { focusNode } = getSel();
    if (
      !focusNode ||
      (focusNode !== richTextEl && !richTextEl.contains(focusNode))
    ) {
      const staOffset = richTextEl.childNodes.length;
      const rangeOpts = this._selCache || {
        staNode: richTextEl,
        staOffset,
        endNode: richTextEl,
        endOffset: staOffset,
      };
      // console.log('恢复光标状态', rangeOpts)
      replaceRange(rangeOpts);
    }
    richTextEl.focus();
  };

特殊内容相关

上文中反复有用到一个 getTransCodeEl()方法，该方法完整代码如下：

// 用临时容器来解析富文本消息内容为JSON数据体
function getTransCodeEl() {
  const tmpId = 'rich_text_trans';
  let tmpEl = document.getElementById(tmpId);
  if (!tmpEl) {
    tmpEl = document.createElement('div');
    tmpEl.id = tmpId;
    tmpEl.setAttribute('desc', '富文本与消息数据互转专用');
    // 必须添加到文档流才能保证正常得到换行符
    document.body.appendChild(tmpEl);
  }
  return tmpEl;
}

对应CSS如下：

#rich_text_trans {
    position: absolute;
    top: -9px;
    left: -9px;
    overflow: hidden;
    width: 1px;
    height: 1px;
    white-space: pre; // 保证空格、制表符正常渲染展示并能通过innerText 获取
}

所以不要忘了，基于 contentEditable 实现的编辑输入框，也要按自己需求添加 white-space: pre-wrap;或其他相同作用的设置。

后记

相关细节点还有很多，暂不逐一赘述了，以上先仅做流水记录，如果有所帮助、或拓展问题，欢迎沟通。

• 本文背景
• 面试原题描述
• 粗略解答思路
• 一点面试的心得感受
• 学霸式解题方法思路
• 逻辑推理式解题思路之一
• 必要参数值获取
  • 事件处理及对应值获取
  • DOM属性读取
  • 延展讨论
• 收个尾

本文背景

作为一个Web前端从业者，资深B/S架构的应用开发，通常我们负责的内容都是侧重的浏览器端比较多，即便目前Vue、React等各种框架库流行的年代，核心实现也依然是JS API操作DOM；如果资历更深一些的同学，还会熟知jQuery，更是因为各浏览器API不统一作为其解决的问题痛点。

在长期担任Web前端面试官的过程中，我归纳沉淀了一些有趣的面试题目，今天来聊其中一个与DOM操作相关的题，可以用于考察一个前端工程师的逻辑条理性、问题分析解决能力、纯Web前端（浏览器端）JS技术基础情况等。

面试原题描述

如图，红色矩形是网页中的一个DOM元素（比如是个普通DIV）。

需求：当用户鼠标在该DOM元素上移动时，判定光标相对于灰色对角线所处位置状态（左上、右下、刚好在线上）。

粗略解答思路

相信你一定已经看懂是个啥需求，需要做些啥了吧？

所以不需要赘述了，直接上解法：！！！

1. 首先，我们需要确定判定方法，以及需要传入的参数。

2. 然后，再通过DOM行为监听、事件&DOM属性读取，得到参数具体数值，传入上面实现的方法。

很简单对不对？让我想到了经典的“怎么画好一匹马”。

别急，具体处理方式容我再慢慢道来。

一点面试的心得感受

被我面试时聊过这个问题的人，不上几千肯定也过几百了。

所以，技术问题之外，也会有一些心得感悟。

比如我经常对新参加面试工作的同事说的一句话：“切记：面试不是拿你自己准备好的、或者熟悉的问题，创造出一个不公平的沟通场景，然后再跟被面试者比谁更聪明；面试官的职责是通过针对特定话题的沟通，来检验其过往经历的真实性、判定这个人特定方向的能力边界。”

如果一个被面试者，第一次遇到这个非纯知识考查的怪异问题，还能做到冷静思考、清晰表述思路，那么我们完全可以判定这个人的基本素质：临场应变、抽象变通都不错。

如果接下来还能提供代码实现过程的表述，那更是这个方向上，问题分析解决能力、编程经验丰富了。

能达到上述表现的，对心理抗压、临场应变、相关技能储备是个不小的挑战，往往是凤毛麟角。

而在我面试他人的经历中，还有两种非常有趣的极端情况会经常遇到：

1. 看完不假思索、或稍微思考一会，直接选择放弃的。
2. 缺乏思考或没有清晰的思路，强拉硬扯一通，然后提供一些牵强附会的结论。

当我作为面试官遇到上述极端情形时的感受往往是：

1. 是不是没太大必要继续浪费时间了。
2. 这个同学任用可一定得慎重。

当然，感受归感受，现实里面我并不会这么武断的定下结论。此时需要再回顾一下前文加粗的那点感想。

如果一个人的临场应变能力不是非常优秀，也不一定就是能力问题。

谁也难免会有紧张、脑筋卡壳的时候。我自己就经常这样啊 ----- 往往晚上睡觉时趟在床上，回想一天的过往，“嘿，我那个想法、那句话，简直就是SB至极”。

所以遇到上述两种极端情况，换到应聘者角色又或者是这样呢：

1. 问我这些？简直是羞辱，我不屑回答。
2. 怎么办，怎么办，好紧张，可我不能不要面子啊：“巴拉巴拉巴拉...”

所以如果我作为面试官遇到不太能给出思路的同学，会试图引导一下，强调“面试不一定非得纯问答题，也是个相互沟通、相互学习的过程，想到啥都可以说说看”。

而作为面试官通过进一步沟通，也可以更可靠、清晰的确认一下对被面试者能力范围的判定。

学霸式解题方法思路

如果面试中遇到数学基础不错的学霸，往往会直接甩出向量方案。

像下图三种状态代表性的点 P1、P2、P3，求其点坐标到对角线的向量值，根据正、负、零自然也就映射到要判定的状态了。

但是，像我这种连“向量：具有大小和方向的量”的基础概念都忘光光的学渣，肯定不会啊。

所以引导他人解题时候，更是不敢聊向量这个话题了，我经常用逻辑推理的方式。

逻辑推理式解题思路之一

毕竟是引导别人，我也要面子嘛：通常会先建议再想一想、确定一下参照坐标系、画一画辅助线试试。

比如，我们假设任意光标点为P1，DOM元素左下角为二维坐标系原点P0呢？有没有想到啥思路？

还没有思路的话，将P1-P0连线呢？跟对角线比较是啥关系，能不能映射到题目需求状态上？

对嘛，斜线P0-P1与底边的夹角如果大于、等于、小于对角线与底边或左边的夹角，不就判定出来了。

不过要计算角的大小好像也会很麻烦（我三角函数都忘光光了，太难了、不会啊）....

其实，刚刚我们已经不知不解决的假定了底边是x轴、左边是y轴（原点P0嚒 ლ(′◉❥◉｀ლ)），也就形成了一个二维坐标系。

在这个坐标系里，P1到左边的距离X、到底边的距离Y，跟矩形宽度boxWidth、boxHeight的比例关系刚好也可以映射到题目需求的三个位置状态上诶!!

即：

1. X/Y === boxWidth/boxHeight 那么点在对角线上。
2. X/Y < boxWidth/boxHeight 那么点在对角线左上。
3. X/Y > boxWidth/boxHeight 那么点在对角线右下。

到这里判定方法确定了，剩下就是怎么去获取这些参数值了。

必要参数值获取

现在我们需要获取4个数值：X、Y、boxWidth、boxHeight。

我就知道，你一定会觉得很简单，没错，这是算是基本JS API基础了。

事件处理及对应值获取

回到题目“当用户鼠标在该DOM元素上移动时”，不就是监听鼠标事件、然后取相关对象的目标属性值么，这有啥难点？

我也一直这么认为的，但经过那么多次面试，发现竟然很多人都不知道（╮(╯▽╰)╭），能通过筛选的怎么也是有几年前端工作经验的呢。

遇到过：“不知道”、 “onMouseover”、“onTouch”、“o(╯□╰)o”...

确定了事件监听方式，那么我们通过事件中的哪个对象啥属性获取X、Y呢？

曾经收到过的答案们（只拿X值关联属性示例）：不知道、div.x、event.x、evnet.left、event.offsetX、event.clientX、event.pageX、... ???

上面这些肯定有错误的或者存在问题的，聪明的你，一定想到了正确的方案了。

你拿到的值是相对哪个坐标系的？如果得到的是 pageX值，是不是还得换算一下，又进一步依赖哪个属性怎么获取？

DOM属性读取

X、Y坐标值能取到了，那么boxWidth、boxHeight怎么取呢？

曾经收到的答案们（只拿宽度值关联属性示例）：不知道、div.width、div.style.width、div.contentWidth、div.getAttribute('xxx')、div.offsetWidth、div.outerWidth、div.innerWidth、div.getBoundingClientRect().width....

上面这些还是存在错误的，聪明的你，又一定想到了正确的方案了。~O(∩_∩)O~

延展讨论

“既然聊到事件了，如果我页面里有好多元素，还存在懒加载动态插入的，都想达成这个题目的需求，事件绑定有没有一次绑定也都能生效的方案嘞？”、“是不是有个啥事件委托、事件代理？”

“事件可以自定义么？"

"如果我在JS代码里悄悄的自动触发一个元素的事件可以么，会不会有啥问题？”

“诶，上面你好像聊到了 div.style.width、div.offsetWidth，这俩货有啥区别啊？”、“浏览器里是不是有个盒模型的说法？”

“如果鼠标移动频度很高，会不会有性能问题？”、“可以怎么优化一下吗？”。

“如果要在DOM元素里绘制这个斜对角线，该怎么画？”

"你刚说用两个DOM元素分别实现上下三角区域，再绑定onClick判断？" “那这俩三角区域CSS咋写出来？”

收个尾

今天先想到啥写啥了，回头再想到啥再补充。

可能有同学会非常纳闷，“怎么会有这么个题目，前端工程师怎么可能用到？”。

首先这个问题，来自我11年前的一个真实项目经历中的产品需求：

如上图：“当某个WEB应用启用精简排版模式时，将第二行中俩功能按钮合并成第一行的那一个，按照点击位置判定并执行为独立按钮一样的目标行为。”

再后来，稍微了解了一点计算机图形学三角剖分法、纹理贴片，我勒个乖乖，全是三角形，太吓人了，果断放弃。

ﾚ(ﾟ∀ﾟ;)ﾍ=3=3=3

• 背景交代
• 解决方案
• 具体代码
• 补充配置
• 后记

背景交代

最近在做的一个基于Electron开发的Mac端项目，要进行产品更名。

但是如果直接修改编译打包后的应用名称，问题会比较大。

首先，类似上图里所有缓存资源、以及涉及鉴权的各种Cookie&Storage ，都是存放在类似/Users/huzunjie/Library/Application Support/旧名称目录下的。

其次，通过旧名称.dmg安装到启动台中的应用，对应物理目录为/Applications/旧名称.app。

如果直接对应用打包时更名，缓存必然全部失效，也会导致/Applications/目录下同时存在新旧2个不同名称的APP。

这显然不是想看到的结果。

解决方案

通过查询资料，我们发现实际MacOS是允许在不影响原/Applications/旧名称.app物理路径的基础上，给应用设置一系列语言包，用于告知MacOS的文件系统及启动台等地方，按本地化语言环境展示对应名字。

这么以来也就找到了一个“为编译打包旧名称.app中增加语言包来配置别名”的解决方案。

我是基于 electron-build进行编译打包的，所以按上面这个思路，给package.json增加语言配置，并另外基于electron-build的afterPack Hook实现了个补充语言包的脚本。

具体代码

首先 package.json 中要添加 electronLanguagesInfoPlistStrings 配置，及钩子脚本afterPack、并在extendInfo中添加LSHasLocalizedDisplayName字段:

{
  "name": "my-app-name",
  "productName": "旧名称",
  ....
  "electronLanguagesInfoPlistStrings": {
    "en": {
      "CFBundleDisplayName": "En新名称",
      "CFBundleName": "En新名称"
    },
    "zh_CN": {
      "CFBundleDisplayName": "新名称",
      "CFBundleName": "新名称"
    },
  },
  "build": {
    "afterPack": "./buildAfterPack.js",
    "mac": {
      "extendInfo": {
        "LSHasLocalizedDisplayName": true
      }
    }
    ....
  }
  ....
}

编译时的钩子脚本./buildAfterPack.js用于读取package.json中的语言配置，并生成语言包物理文件，实现如下 :

/* 基于 APP 打包后的钩子功能补充语言包配置，以满足类似“旧名字”在Mac文件系统中显示为“新名字”的需求 */
const fs = require('fs');

exports.default = async (context) => {
  const { electronPlatformName, appOutDir } = context;
  if (electronPlatformName !== 'darwin') {
    return;
  }
  const {
    productFilename,
    info: {
      _metadata: { electronLanguagesInfoPlistStrings },
    },
  } = context.packager.appInfo;

  const resPath = `${appOutDir}/${productFilename}.app/Contents/Resources/`;
  console.log(
    '\n> 基于 package.json 配置项 “electronLanguagesInfoPlistStrings” 创建语言包 Sta \n',
    '\n>  electronLanguagesInfoPlistStrings:\n',
    electronLanguagesInfoPlistStrings,
    '\n\n',
    '>  ResourcesPath:',
    resPath
  );

  // 创建APP语言包文件
  const createLangFilesPromise = await Promise.all(
    Object.keys(electronLanguagesInfoPlistStrings).map((langKey) => {
      const infoPlistStrPath = `${langKey}.lproj/InfoPlist.strings`;
      let infos = '';
      const langItem = electronLanguagesInfoPlistStrings[langKey];
      Object.keys(langItem).forEach((infoKey) => {
        infos += `"${infoKey}" = "${langItem[infoKey]}";\n`;
      });
      return new Promise((resolve) => {
        fs.writeFile(`${resPath}${infoPlistStrPath}`, infos, (err) => {
          resolve();
          if (err) throw err;
          console.log(`>  “{ResourcesPath}/${infoPlistStrPath}” 创建完毕。`);
        });
      });
    })
  );
  console.log(
    '\n> 基于 package.json 配置项 “electronLanguagesInfoPlistStrings” 创建语言包 End \n'
  );
  return createLangFilesPromise;
};

补充配置

以上解决了安装后的应用更名需求。

但编译打包后的文件还是“旧名称 1.2.3.dmg”、“旧名称 1.2.3.zip”。

用户安装过程中操作界面上大部分显示的也是“旧名称.app”。

如果要保证编译产生文件及上图中“旧名称”显示为新名称，还需要继续修改 package.json，按下面位置添加 artifactName 和 dmg.title:

{
  ....
  "build": {
    "artifactName": "新名称-${version}.${ext}",
    "dmg": {
      "title": "新名称 ${version}",
       ...
    }
    ....
  }
  ....
}

后记

这确实解决了我遇到的需求，但未必是最好的解决方案，如果发现有疏忽的地方或有更好的方案，欢迎回复。

• 前言
• 实现一个“复制”按钮，方便内容分享传播
• 修改将要写入剪切板的文本内容
• 认识剪切板中的内容
• 写一张图片到剪切板中
• 剪切板操作权限判断
• 将File上传到服务端
• 浏览器端能否通过复制发送文件或文件夹？
• Electron 场景能否通过复制发送文件或文件夹？
• 写在最后

前言 　

现在前端富交互能力越来越强，也有很多产品基于前端技术进行离线应用开发或在线应用体验增强；这其中剪切板操作也是一个经常会亮相客串的一个基础能力。

今天这篇文章我们就一起整理一下关于剪切板读写操作的一些实践。会包含浏览器端、Electron客户端两种不同的业务场景下，一些具体的需求实现示例。

实现一个“复制”按钮，方便内容分享传播

在网页上一段文本后添加一个“复制”按钮并不是啥新鲜的事情，比如“复制分享网址”、“帮我砍一刀”...，早先FLASH还红火的时候，也有很多是基于FLASH实现的。

实际基于浏览器自身JS能力实现也非常方便：

<textarea id="txt">这里是将要被复制的文案</textarea>
<button id="btn" type="button">点我复制</button>

<script>
  const iptEl = document.getElementById('txt');
  const btnEl = document.getElementById('btn');
  btn.onclick = function() {
    iptEl.select();
    document.execCommand('copy');
    alert('复制完毕。');
  };
</script>

点这里在线试验一下效果。

上面代码中复制文本框中的内容到剪切板，主要使用了 document.execCommand('copy')，我们 通过 Can I use 查看 目前各浏览器兼容都挺好，而且也非常方便，很多富文本编辑器厂商也还是在依赖这个API。

不过需要注意，在相关标准及浏览器厂商的WEB API文档中已经警告开发者这是个“已废弃”的API了。

在新的标准和JS API实现中，已经为我们提供了专门用于剪切板操作的Clipboard API。

当然我们也就可以基于这个新的API，来实现上面相同的功能。只需要将onclick响应中的代码改成下面这样：

btnEl.onclick = () => {
  navigator.clipboard.writeText(iptEl.value).then(() => {
    alert('复制完毕。');
  });
};

点这里在线试验一下效果。

修改后，主要是使用了 clipboard.writeText将文本写入剪切板。同样我们也可以去 Can I use 查看一下在各浏览器的兼容性 ；

和前一个方案比较，兼容性及浏览器覆盖率目前还是差一些；不过就API能力来说，clipboard可要比之前的 execCommand 更明确、更强大的多了。

修改将要写入剪切板的文本内容

前面介绍了怎么在网页里添加一个“复制”按钮，来让用户触发复制一段文案的操作。

不妨就这个功能再稍微发散考虑一下： 我们知道触发复制的行为当然不会只有这一种方式（比如也可以“Command+C || Ctrl + C”这种快捷键的形式），那么当用户复制一段文本内容的时候，我们能不能进行二次加工呢？

比如，你可能早就留意到，在某一些网页中复制一段选中文本，粘贴的时发现除了选择内容，后面还会有"原文出处、版权信息"等，是怎么做到的呢？

这里要修改将要写入剪切板的内容，可以将功能逻辑分成3部分：

1. 监听文本复制的操作行为，阻止浏览器默认行为。
2. 获取用户选择的目标文本内容，并追加内容。
3. 将文本内容写入剪切板。

第1步，监听document或目标元素的copy事件就可以。

第2步，要获取用户选中的内容，需要用到另外一个能力 Selection API ；下面示例代码中考虑兼容性实现了一个工具函数 getSelectionTxt。

第3步，我们在前面的示例中，已经实践过2种方案，这里我们再换一个方案，使用事件对象暴露的 clipboardData.setData 。

function getSelectionTxt() {
  if (document.selection) {
    return document.selection.createRange().text;
  } else {
    return String(window.getSelection());
  }
}

// 监听 copy 事件
document.addEventListener('copy', (evt) => {
  const { clipboardData } = evt;
  if (!clipboardData) return;

  // 获取选中文本
  let txt = getSelectionTxt();
  if (!txt) return;

  // 有要操作的目标内容，阻止浏览器默认行为
  evt.preventDefault();

  // 追加内容
  txt += '\n\n 【原文地址：https://blog.pyzy.net/post/clipboard.html 】';

  // 写入剪切板
  clipboardData.setData('text/plain', txt);
});

在线试验一下。

认识剪切板中的内容

上面我们都是基于纯文本的实践示例，实际剪切板里不止是可以用于文本内容的复制粘贴。

如果选中网页中一段带格式的富文本内容，在一个富文本编辑器粘贴，会连带格式粘贴过去。

如果我们使用微信等IM的截图功能、或者使用MacOS系统中的 Command+Shift+4+Control截图到剪切板，那么就可以在任意支持图片粘贴的地方粘贴一个图片过去，也可以在网页中粘贴实现上传。

另外在使用一些IM工具时候，通常也允许我们复制磁盘中的任意文件或文件夹，在会话交流界面粘贴发送出去。

更有代表意义的是：在Excel等Office编辑器中复制一段内容，下面也通过具体代码示例来逐步了解一下。

跟前面的示例监听 copy 类似地，可以通过监听 paste 粘贴事件，来读取剪切板中数据内容：

document.addEventListener('paste', (evt) => {
  const { clipboardData } = evt;
  console.log('clipboardData:', clipboardData);
});

可以将以上代码在网页中执行。

之后打开一个 Excel 表格，任意选中几个单元格，并“复制”内容。

再回到刚才执行paste事件监听的页面，Command+V(如果你是Windows系统需要Ctrl+V)。

可以看到控制台打印出的clipboardData中，types字段值数组长度为3，另外还有items、files等字段。

我们接下来对代码稍加改造，打印看一下types、items字段值中具体是什么内容：

document.addEventListener('paste', (evt) => {
  const { types = [], items=[] } = evt.clipboardData || {};
  console.log('clipboardData.types:', [...types]);
  console.log(
    'clipboardData.items:',
    [...items].map(
       ({ kind, type }) => ({ kind, type })
    )
  );
});

神奇的事情发生了，一次复制行为，原来是可能会产生多种不同类型可用于粘贴的数据的：

其中types字段的内容分别为 ["text/plain", "text/html", "Files"]，对应到 items字段中的数据，我们发现这里的Files类型是一个type为image/png的文件对象。

我们再改造一下示例代码，实现一个可以将"text/plain", "text/html", "image/png"这3种类型内容都分别打印到页面上的功能，看看剪切板里具体内容到底是什么东东：

<!DOCTYPE html>
<html>
  <head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width">
  <title>剪切板内容读取试验</title>
  <style>
    h2 {
      border-bottom: solid 1px #eee;
      font-size: 16px;
      padding: 10px;
    }

    #container {
      border: solid 1px #eee;
      padding: 10px;
      background: #f9fdff;
    }

    #container:empty:after {
      content: '请执行复制操作后，在当前页面尝试Command+V或Ctrl+V。';
      color: #aaa;
      font-size: 14px;
    }

    h3 {
      border-bottom: solid 1px #eee;
      font-size: 16px;
      padding: 0 0 10px;
      margin: 10px 0;
    }

    textarea {
      display: block;
      width: 95%;
      height: 200px;
      padding: 8px 10px;
      box-shadow: 1px 1px 3px rgb(0 0 0 / 20%) inset;
      border-radius: 4px;
    }

    img {
      display: block;
      width: 100%;
    }
  </style>
</head>
<body>
  <h2>剪切板内容：</h2>
  <div id="container"></div>
  <script>
    document.addEventListener('paste', (evt) => {
      container.innerHTML = '';
      const items = Array.from((evt.clipboardData || {}).items || []);
      items.forEach((item, i) => {
        const { kind, type } = item;
        const entry = item.webkitGetAsEntry && item.webkitGetAsEntry();
        const isDirectory = entry && entry.isDirectory;
        const h3 = document.createElement('h3');
        h3.innerText = `序号：${i}；kind：${kind}; type：${type};`;
        container.appendChild(h3);
        let previewEl = null;
        if (isDirectory) {
          previewEl = document.createElement('a');
          previewEl.innerText = '文件夹：' + entry.fullPath;
        } else if (kind === 'file') {
          const file = item.getAsFile();
          const url = URL.createObjectURL(file);
          if (/image/i.test(type)) {
            previewEl = document.createElement('img');
            previewEl.src = url;
          } else {
            previewEl = document.createElement('a');
            previewEl.href = url;
            previewEl.download = file.name;
            previewEl.innerText = file.name;
          }
        } else {
          previewEl = document.createElement('textarea');
          item.getAsString((str, ...args) => {
            console.log('str', str, ...args)
            previewEl.value = str;
          });
        }
        container.appendChild(previewEl);
      });
    });
  </script>
</body>
</html>

以上代码和之前一样，也可以“在线试验一下”。

将刚刚复制到剪切板的Execl单元格内容在这个页面中粘贴，可以看到如下效果：

右边内容展示区中，从上往下依次是：带有定界符的纯文本内容、带有CSS样式及table代码的HTML片段、一张对选择区域截图产生的图片文件。

我们再试验一下前面说到的使用微信截个图：

也还是打开上面的剪切板粘贴试验页，进行粘贴试验：

哇欧，我们在网页中通过剪切板API读取到了截取的图片 ---- 并且跟前面Excel复制行为比较仅有一个截图数据。

试试在文章左边Blog作者头像上右键复制图片：

也还是回到试验页，Command+V 粘贴试验：

哦，原来在网页里复制的图片，可以通过剪切板拿到一端富文本HTML代码和一个图片文件对象。

那么我们从任意磁盘目录中选择并Command+C复制一个图片呢？

剪切板粘贴试验页进行粘贴读取到的内容：

可以看到，我们在网页中拿到了被复制图片的一个text/plain类型的string文件名和一个image/png类型的File对象。

厉害了，通过上面的示例实现的代码能力，已经实现了剪切板资源读取、文件的File对象获取、图片预览。

如果能将File直接发送给服务端，那么一个通过剪切板的复制粘贴能力来上传分享图片、发送截图的能力就可以实现了。

写一张图片到剪切板中

上面是从页面或磁盘里复制图片资源，我们也可以让用户点一个按钮时，主动写一个图片到剪切板中：

<!DOCTYPE html>
<html>
<head>
  <meta charset="utf-8">
  <meta name="robots" content="noindex">
  <meta name="viewport" content="width=device-width">
  <title>图片复制</title>
</head>
<body>
  <!-- https://p3.ssl.qhimg.com/t01f8b7c8780afb7342.jpg -->
  <img id="img" src='https://p3.ssl.qhimg.com/t011e94f0b9ed8e66b0.png' /><br>
  <button id="btn" type="button">复制</button>
  <p id="ret">点击“复制”，再去粘贴试试</p>
  <script>
    btn.onclick = async () => {
      const res = await fetch(img.src);
      const blob = await res.blob();
      const item = new ClipboardItem({'image/png': blob});
      navigator.clipboard.write([item]).then(() => {
        ret.innerText = '复制完毕。';
      }, (err) => {
        console.error(err);
        ret.innerText = '复制失败！' + err;
      });
    };

    /*
    在被 iframe 的场景，记得增加 allow="clipboard-write" 属性，来设置好权限：
    ifrEl = document.querySelector('[src="https://code.h5jun.com/romi/edit?js,output"]');
    ifrEl.setAttribute('allow', 'clipboard-write')
    ifrEl.src = ifrEl.src;
    */
  </script>
</body>
</html>

剪切板操作权限判断

剪切板读写会涉及用户隐私问题，有可能默认是禁止站点进行该操作的，正式业务应用中，最好也做一下是否具备剪切板读写权限的判断

<!DOCTYPE html>
<html>
<head>
  <meta charset="utf-8">
  <meta name="robots" content="noindex">
  <meta name="viewport" content="width=device-width">
  <title>检查剪切板操作权限</title>
  <style>
    #box {
      padding: 10px 20px;
    }
    #box:empty:after {
      color: #999;
      content: '请稍候...'
    }
    #box h3 {
      font-weight: 400;
      margin: 0 0 4px;
      background: #eee;
      padding: 5px 10px;
    }
    p {
      margin: 10px 20px;
      color: #999;
    }
    #p:empty:after {
      content: '...操作结果将显示在这里...'
    }
  </style>
</head>
<body>
  <p>权限状态可能会是：prompt、granted、denied</p>
  <div id="box"></div>
  <p id="p"></p>
  <script>
    const confs = [
      { name: 'clipboard-read' },
      { name: 'clipboard-write' }
    ];

    Promise.all(
      confs.map(
        (conf) => navigator.permissions.query(conf)
      )
    ).then((pers) => {
      box.innerHTML = pers.map((status, i) => {
        const { name } = confs[i];
        const stateId = `state_${i}`;
        status.onchange = () => { 
          document.getElementById(stateId).innerText = status.state;
        };
        return `
          <h3>
            权限项：${name},<br />
            状态值：<span id="${stateId}">${status.state}</span>,<br />
            试一下：<button onclick="runTest('${name}')">点这里</button>
          </h3>
        `;
      }).join('');
    });

    const tests = {
      'clipboard-read': async () => {
        const txt = await navigator.clipboard.readText();
        p.innerText = '读取结果：' + txt;
      },
      'clipboard-write': async () => {
        await navigator.clipboard.writeText('test text');
        p.innerText = '写入完毕';
      },
    };
    window.runTest = (name) => tests[name]();
  </script>
</body>
</html>

将File上传到服务端

完整的文件上传示例，必须依赖服务端，这里只提供纯前端伪代码的几种方案：

首先，如果你的服务端有一个独立的用于文件上传的接口，基于XMLHttpRequest（也就是熟知的AJAX）方式发送File对象给服务端即可：

const xhr = new XMLHttpRequest();
xhr.onload = () => {
    console.log('上传结果：', xhr.responseText);
};
xhr.open('POST', './uploadFile', true);
xhr.send(file);

如果服务端接口在接受文件内容时，还要求有别的必填字段信息，往服务端send一个FormData对象即可：

const formData = new FormData();
formData.append('type', 'image');
formData.append('file', file);

const xhr = new XMLHttpRequest();
xhr.onload = () => {
    console.log('上传结果：', xhr.responseText);
};
xhr.open('POST', './uploadFile', true);
xhr.send(formData);

如果服务端接口还额外要求必须携带一些自定义请求头字段信息，也可以改成使用 Fetch API 来发送 formData 给服务端。

fetch('./uploadFile', {
   method: 'POST',
   body: formData,
   headers: new Headers({
     'Content-Type': 'application/json'
   })
}) .then((res) => { ... });

当然，文件上传并不会这么简单，比如还可能会涉及到传输进度同步、用户主动取消传输、大文件分片、文件秒传等等，不符合这里的主题，就不展开讨论了。

浏览器端能否通过复制发送文件或文件夹？

当剧情发展到这里，聪明的你也许已经意识到：好像哪里不太对劲，是不是刻意隐瞒了一些问题？

又或者，聪明的你早就发现了，前面基于剪切板传递的都是纯文本字串、富文本HTML、或者静态图片啊！

我们先来复制一个GIF动图，比如下面这个：

到前面的剪切板粘贴试验页粘贴一下，看看效果：

好的，类别kind: string 对应内容和前面示例中发现的规律表现一致，我们继续看。

诶呦，喂！不对啊，明明复制的是image/gif，图片内容咋也变成了和前面复制个png一样，你看它，不会动了嘿！

先暂且按下不管，我们干脆再多一些尝试、复制点别的文件试试，比如分别尝试粘贴一个CSS文件、粘贴一个JS文件、粘贴一个HTML文件、粘贴一组图片、粘贴一个文件夹、粘贴一组任意文件：

WTF！！ 什么烂七八糟的？拿不到文件信息？

对了（突然灵鸡一动），记得么？前面我们尝试打印clipboardData对象到控制台的时候，和items平级的有个files字段诶。

我们再在粘贴时多打印一下这个files字段，看看这里面会不会就是被复制的文件集合。

先来一组任意文件：

啥也没读出来啊。再来一组图片试试：

复制了3张图片，但 Files 里只读出了1张图片。

看来是根本无法像拖拽上传那样获得要使用的文件列表啊？！

【2021-11-24 作者注】：

旧有版本比如 Chrome 80 是无法按预期读取到FileList数据的；

但此刻(2021-11-24)类似 Chrome 95.0.4638.69 已经能按预期读取到文件列表。

所以如果你是 Electron 场景、又能切换到比较新的Chrome核，那么可以无视下一个章节内容、而直接使用WEB前端JS API的方案了。

Electron 场景能否通过复制发送文件或文件夹？

浏览器中看来无解了，但是WEB前端的魔爪可是早就已经不止于浏览器中了，比如我们是可以借助 Electron 开发离线应用，并拓展使用一些浏览器中不具备的 Native 能力。

而且，刚好笔者涉及当前需求的产品场景就是同时支持浏览器端和Electron包壳两种场景的，那么我们不妨也调研一下。

通过 Electron 剪贴板 API可以看到，当下开放的方法能力实际和浏览器端没有太大区别，文档告诉我们可以通过剪切板的读写的数据或文件资源也是比较基础的文本、富文本、特殊标记语言文本、静态Image资源数据。

在Electron社区有人说：通过Mac剪切板查看器示例程序发现应该能通过clipboard.read('NSFilenamesPboardType')读取到一个被复制的文件或文件夹列表的XML格式描述文本：

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
  <array>
    <string>/path/to/file1.ext</string>
    <string>/path/to/file2.ext</string>
  </array>
</plist>

该XML内容的plist节点下的信息就是描述了被复制文件或文件夹的路径。

虽然不能拿到文件对象，但这可是Electron端哦。既然能拿到文件路径，再在页面里通过路径读取到文件的buffer不也就能做很多后续文件操作能力了？

太棒了，不妨按照程序逻辑流程逐步试验一下！

首先，需要从剪切板中拿到的这个XML里提取出被复制的文件或文件夹的路径：

const { clipboard } = require('electron');

function getClipboardPaths() {
  const filePathsXML = clipboard.read('NSFilenamesPboardType') || '';
  return (filePathsXML.match(/<string>([^<]*)<\/string>/gim) || []).map(
    (filePath) => {
      return filePath
        .replace(/(^<string>|<\/string>$)/g, '')
        .replace(/&amp;/g, '&')
        .replace(/&lt;/g, '<')
        .replace(/&gt;/g, '>');
    }
  );
}

如果我们复制了2个文件和一个文件夹，上面的代码可以帮我们读取到如下数组：

[
  '/path/to/folder1',
  '/path/to/file1.ext',
  '/path/to/file2.ext',
]

上面的 /path/to/folder1 是一个文件夹，如果我们的目的是要复制粘贴文件，那么递归遍历展开文件夹也是必须的：

const fs = require('fs');
const path = require('path');

async function flatPaths(filePathsArr) {
  const filePaths = [];
  await Promise.all(
    filePathsArr.map((filePath) => {
      return new Promise((resolve) => {
        fs.stat(filePath, (err, stats) => {
          if (!err) {
            if (stats.isDirectory()) {
              fs.readdir(filePath, async (err, files) => {
                if (!err && files) {
                  const filesPaths = files.map((fileName) => {
                    return path.join(filePath, fileName);
                  });
                  const flatFilesPaths = await flatPaths(filesPaths);
                  filePaths.push(...flatFilesPaths);
                }
                resolve();
              });
              return;
            } else if (stats.isFile()) {
              filePaths.push(filePath);
            }
          }
          resolve();
        });
      });
    })
  );
  return filePaths;
}

接下来是重点了，我们先简单粗暴一些，直接循环将前面加工拿到的所有文件绝对路径通过fs.readFile读取出文件的buffer数据。

const fs = require('fs');
const path = require('path');

async function getClipboardFiles(fileAbsPathsArr) {
  const files = [];
  await Promise.all(
    fileAbsPathsArr.map((filePath) => {
      return new Promise((resolve) => {
        fs.readFile(filePath, (err, data) => {
          if (!err) {
            files.push({
              filePath,
              fileName: path.basename(filePath),
              data, // 可用于在Web端JS new File([data], fileName)
            });
          }
          resolve();
        });
      });
    })
  );
  return files;
}

这次经过getClipboardFiles之后我们拿到的是像下面这样，带有文件绝对路径、文件名、文件buffer数据的数组：

[
  {
    filePath: '/path/to/folder1/fileN.ext',
    fileName: 'fileN.ext',
    data: [...Uint8Array...],
  },
  {
    filePath: '/path/to/file1.ext',
    fileName: 'file1.ext',
    data: [...Uint8Array...],
  },
  ...,
]

现在可以回到我们熟悉的 Web 页面中JS交互逻辑里了。

document.addEventListener('paste', async (evt) => {
  const clipboardPaths = await flatPaths(getClipboardPaths());
  if (clipboardPaths.length) {
    evt.stopPropagation();
    evt.preventDefault();
  } else {
    return; // any ...
  }
  // 得到剪切板中文件数据们
  const clipboardFiles = await getClipboardFiles(clipboardPaths);
  // 使用 new File 生成可用于Web端的 File 对象
  const fileList = clipboardFiles.map(({ fileName, data }) => {
    return new File([data], fileName);
  });

  /* 文件预览、发送.... sendFiles(fileList); */
});

到这里，我们在Electron端发送文件的效果也就实现了。

拿到文件列表就可以后面的折腾了，比如用户发送前，给一个文件预览，二次确认的列表：

另外，Electron场景的NSFilenamesPboardType还有一个非常值得令人振奋的地方，不但可以读取剪切板文件列表，也可以写任意文件列表到剪切板了（注：笔者该试验仅限 MacOS 场景中）。

const { clipboard } = require('electron');

clipboard.writeBuffer(
  'NSFilenamesPboardType',
  Buffer.from(`
    <?xml version="1.0" encoding="UTF-8"?>
    <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
    <plist version="1.0">
      <array>
        <string>/path/to/file1.ext</string>
        <string>/path/to/file2.ext</string>
      </array>
    </plist>
  `)
)

写在最后

首先，请读者注意：以上所有示例代码更侧重在思路示意，甚至可以说是伪代码，如果要在正式业务场景应用，请一定酌情调整、增加严谨性、健壮性、兼容性相关考量。

另外，相关标准委员会、浏览器厂商（比如：Chrome）、Electron官方也都还在不断迭代扩展Clipboard API，本文的方案只是基于时下的形式考虑，如果发现不符欢迎随时指正，以免误导。

最后，郑重感谢您花时间在本文中，如果有哪些点描述不准确或需要讨论的，也欢迎评论留言。

新年快乐~

• 序言
• 正文
  • 1. 需求背景
    • 1.1 浏览器端HEVC的支持情况
    • 1.2 Web端解码方案
    • 1.3 浏览器端WebAssembly的支持情况
    • 1.4 HEVC播放器需求目标
  • 2. 架构设计
  • 3. 分解实现
    • 3.1 下载器
      • 线性的数据流的合并与拆分
      • 内部维护管理 range 状态
      • 不同媒体类型数据获取的差异
      • MOOV 前置或后置
      • 慎重并折中的控制内存消耗
    • 3.2 解码器
      • 启动解码前依赖数据量控制
      • 主动向下载器获取数据
      • 动态解码模式控制CPU消耗
      • 独立的音频、画面帧数据队列
      • 音频重新采样
    • 3.3 渲染器
      • 依赖解码、UI提供画布
      • 主动向解码器获取帧数据
      • 分缓存队列、渲染队列
      • 音画同步、倍速播放、Waiting
      • 动态码率变化
    • 3.4 UI
    • 3.5 控制层
      • 而WebWorker本身的设计存在各种不便：
      • 针对这个问题我们结合Promise 实现了PromiseWebWorker。
  • 4. 要点回顾
  • 5. 难点突破
  • 6. 未来展望

序言

前面给360视频云团队围绕HEVC前端播放及解密实现了一套基于WebAssembly、WebWorker的通用模块化Web播放器。

在LiveVideoStackCon2019深圳的演讲中对其架构设计、核心原理，具体痛点问题的解决方式进行了详细剖析分享。

这里整理为一篇技术文章，希望能更大范围的给大家带来一些帮助。

原分享PPT链接： https://ppt.baomitu.com/d/fcaa3a47

本分享实现播放器在线DEMO： http://lab.pyzy.net/qhww

参数API文档：https://zyun.360.cn/developer/doc?did=QHWWPlayer

正文

文 / 胡尊杰           整理 / LiveVideoStack

奇舞团是360集团最大的大前端团队，同样也是TC39和W3C会员，拥有Web前端、服务端、Android、iOS、设计、产品、运营等岗位人员，旗下的开源框架和技术品牌有SpriteJS、ThinkJS、MeshJS、Chimee、QiShare、声享、即视、奇字库、众成翻译、奇舞学院、奇舞周刊、泛前端分享等。

奇舞团支持的业务基本上涵盖了360大部分业务线。我个人最开始的时候也曾带队负责360核心安全平台的Web前端支持，包括大家耳熟能详的安全卫士、杀毒软件等。随着公司的业务发展，后面也负责了IoT业务前端支持，最近两年主要配合360视频云的一些Web前端支持工作。基于HEVC的播放器，实际上就是来源于我们最近做的一个叫QHWWPlayer的播放器。HEVC并不是一个新鲜事物，但对于我们团队来说，Web前端的HEVC播放器一直是个亟待优化的领域。虽然移动终端或PC端HEVC播放器已经遍地开花，但在Web端仍旧有很多地方需要改进。包括现存一系列智能硬件产品，也在固件采集端已经应用了HEVC的编码，不过如果想让其在Web端呈现并达到用户需求仍需加倍的努力。本次分享将从以下几个维度展开，希望能给大家带来一定的参考价值。

1. 需求背景

1.1 浏览器端HEVC的支持情况

上图展示了HEVC在浏览器端的支持情况，其中红色代表不支持的浏览器对应版本，绿色代表对HEVC具有良好的支持，青色代表无法保证浏览器可以很好地支持HEVC。总体上来说HEVC在浏览器端并不是一个得到广泛支持的靠谱方案。

一般情况下，PC端浏览器都给我们提供了相应的API，如果我们的业务场景是支持HEVC的浏览器，可尝试有效利用浏览器的原生能力。

基于浏览器原生video，配置source时指定解码器，告知浏览器当前视频采取的是哪一种编码方案。如果浏览器自身有能力进行解码那么其自然会走入“支持HEVC”的逻辑分支当中。

也可以另外通过JS实现检测功能，JS也提供了相应API——canPlayType来判断当前浏览器环境是否支持HEVC解码。

但如果以上流程无法得到有效支持呢？这也是本次分享我们讨论的重点。

1.2 Web端解码方案

浏览器端视频解码总共有以上三种方案，首先就是前文我们提到的基于浏览器原生能力的播放，例如基于video标签拉流、解码以及渲染播放，整个过程完全由浏览器实现。第二种方案是首先通过JS来下载视频流、对视频流进行解封装与转封装处理，最后再通过浏览器提供的相关API，交由浏览器原生video进行解码与渲染播放。如开源社区当中的HLS.JS或FLV.JS等就是基于该思路。

但是HEVC不能仅靠解封装与转封装来实现，因为其本质上在解码层就不支持。因此第三种方案就是：JS下载的视频流首先经由解封装（解密）处理，并在接下来进行解码，解码完成后渲染播放。如果我们这里转成浏览器普遍支持的解码格式并让video标签进行播放，尽管理论上可行，但成本显然是非常高的，并且中间存在一个无端的浪费。因此这里通常直接采用浏览器端Canvas+WebAudio API实现视频与音频的渲染，而不再使用浏览器原生video能力。这里如果使用纯浏览器原生的JS，由于 JS天生单线程执行的弱势，会导致整个处理的效率比较差。

近期，万维网标准化委员会正式推出了WebAssembly规范。一方面我们可以借助WebAssembly高于JS的能力，实现更加出色的大规模数据处理与解码，另一方面基于WebAssembly，我们也能方便地将传统媒体处理中基于C或C++开发的一些媒体处理能力集成在浏览器端执行，并且可通过JS来调用API。对于熟悉传统Web前端开发的我们来说，这也是一个值得我们坚持探索与实践的全新领域。有了WebAssembly之后，我们就可以让部门内擅长视频处理的专家级同事来配合实现更加出色的浏览器端视频播放，相对以往的开发流程来说，无论是能力、成本控制还是效率与灵活程度都有十分显著的提升。

1.3 浏览器端WebAssembly的支持情况

上图展现了浏览器端WebAssembly的支持情况，尽管个别低版本的浏览器有一些支持限制，但随着标准化委员会对该标准的不断推进，情况会变得越来越好。在包括一些混合式场景，例如APP内嵌（比如聊天工具或通讯工具当中打开一个链接）等情况，是否支持也取决于WebView本身提供的能力以及WebAssembly的支持情况，总体上来说趋于向好。

1.4 HEVC播放器需求目标

HEVC播放器的需求目标，就是基于 JavaScript 相关API，配合FFmpeg+WASM达成 HEVC 在浏览器端的解码解密、渲染播放的需求，接下来我们就开始研究如何落地这一目标。

2. 架构设计

总体架构设计思路如上图所示，首先我们需要一个专门负责下载的下载器，该下载器也是基于浏览器的JS Fetch或XHR API，以实现文件获取或直播拉流等操作。成功拉取的视频流会被存储在一个数据队列当中，随后基于WebAssembly（WASM）+FFmpeg的解码器会来消费处理队列里这些流数据，解码出音视频数据，并放置在音视频帧数据队列当中，等待随后的渲染器对其进行渲染处理。渲染器基于WebGL+Canvas与WebAudio调用硬件渲染出图像与音频。

最后则是控制层用于贯穿整体流程中下载、解码、渲染等独立模块，同时实现底层一些基本功能：如之前我们提到JS为单线程，而浏览器提供的WebWork API可拉起一个子线程。该流程中每一个模块都是独立的，队列中的生产与消费过程也是异步进行的。（我们可基于JS本身一些比较好的特性实现诸多便捷的功能。例如基于Promise可以将异步过程进行较为合理的封装，并呈现一些异步处理逻辑流程的关键环节的控制到UI层。）

除此之外，还有控制层的一些基础配置选项，包括播放器本身的一些事件或消息的管理，都可以基于控制层来实现。

3. 分解实现

3.1 下载器

下载器作为一个基本模块独立存在，具有初始配置、启动、暂停、停止、队列管理与Seek响应（用于进度条拖拽）等基本功能。上图左侧图标是在开发完成后，基于下载器的事件消息呈现的数据可视化结果。（柱状图表示单位时间下载量，这里我们可以看到的是，下载量并不均匀，其中的变化可能取决于推流端、服务端、用户端，也可能取决于整个网络环境。）

下载器方面需要留意五个关键问题点：

线性的数据流的合并与拆分

我们应当进行线性数据流的合并与拆分。理论上浏览器从服务端下载一个视频流的过程是线性的，但浏览器的表现实际上并非如此，二者的差异可能会很大。

例如当一个浏览器启动并基于JSFetch API抓取流，其过程也是通过API监听数据回调来实现，每次回调可能间隔会很短、数据量也只是一个很小的一千字节左右的数据包。但有些浏览器的表现并非如此，它们会等抓取到一个1M或2M的数据包之后才反馈给API回调。

而那些过于零碎的数据直接丢给队列或之后的流程来处理，这样势必导致更频繁的数据处理；数据包体积大的直接队列和后续流程势必增加单次处理成本。

因此对线性数据流的合理合并与拆分十分必要，整个过程也是结合初始配置来实现阈值控制。

通过阈值调节控制，我们希望能够做好用户端浏览器硬件资源消耗，与该业务场景下媒体播放产品服务体验之间的取舍与平衡。

内部维护管理 range 状态

除此之外，下载器实际上也需要内部维护管理range 状态。例如当用户选择点播时，我们需要明确是从哪一个字节位置到另一个字节位置下载传输中间这一片数据。而在直播过程中，则可能出现由网络环境造成卡顿或用户端主动暂停的现象，此时下载器需要明确知道播放或当前下载的位置。

不同媒体类型数据获取的差异

第三点是不同媒体类型数据获取的差异，也就是下载器针对不同的媒体类型开发不同的下载功能。例如一个FLV直播流可以理解为是一个连续的线性的数据获取，而点播则以包为单位获取。对于HLS流需要获取m3u8列表，完成分析之后再从中选取数据包的地址并单独下载，随后进行流的合并或拆分。总地来说，我们需要保证数据的最终产出尽量均匀存储到队列中，以便于后续的一系列处理。

MOOV 前置或后置

在媒体处理中像MOOV等的索引数据有前置与后置两种情况，这里需要注意的是，我们的播放器基于Web端。

若索引文件为后置，如果播放器直接下载了一部分数据就直接丢给FFmpeg解码器进行解码，由于FFmpeg解码器无法获取索引，当然也就无法解码成功。除非解码器等待整体媒体源下载完毕，实际上这样是不现实的。

另外由于我们无法控制MOOV索引数据的体量，前置索引的大小无法确定，尤其对于一些特殊情况，这种逻辑会带来很多问题。（但是这里有一个取巧的办法，就是我们可以尝试首先抓取前面几个数据包，探测MOOV边界，并基于此得到MOOV的长度，从而判断取舍在什么时机启动后续的解码。）

慎重并折中的控制内存消耗

最后，慎重并折中控制内存消耗也至关重要。例如尽管较大的缓存能带来流畅的播放，但在Seek时就会带来很大的浪费，我们则需要根据服务所在的应用场景、帧率码率等来实现合理的折中与取舍。

3.2 解码器

下载器之后，整个流程的核心能力就是解码器。解码器的基本功能与下载器相比大同小异，需要特别关注的是解码器并不是像下载器完全是去调用一个原生的JS Fetch API或XHR，而是在启动WebWorker之后再启动WebAssembly（这里的WebAssembly依赖中是引入了定制化的FFmpeg API，以解决解容器、解码等需求），并实现一些API的交互。上图左侧展现了音频与视频帧解码数据队列的可视化结果。

解码器方面，需要关注的关键问题主要有以下几点：

启动解码前依赖数据量控制

刚才讲到MOOV前置与后置时我们也提及这一点，也就是在启动解码前做好数据量控制，明确其数据量是否已经达到FFmpeg的基本需求。如果索引文件的数据还没有完全给到就直接使用命令行启动FFmpeg，那么就会出现报错的情况。我们应当结合数据量的精准控制来对解码器的启动时机做合理的判断。

主动向下载器获取数据

解码器需要主动获取下载器生成的数据队列，这样系统便可根据数据消费效率获知当前解码器是否处于繁忙的状态。同时，主动向下载器获取数据也能在一定程度上减轻CPU的负担，并可根据CPU的负载来决定当前从下载端应该获取多少数据。例如如果CPU负载较大则数据队列自然会出现累积，我们可以在下载器初始化时设置一个阈值，如果数据队列积累达到该阈值则下载器暂停下载，这样就可合理控制处理的整体流程并确保播放的正常。

动态解码模式控制CPU消耗

整个解码过程实际上还依赖CPU的性能，如果单帧解码的时间较长，例如一个帧率是25的视频，仅单帧解码就需耗费半秒钟甚至更长时间，此时如果我们依然按照这样半秒钟或更久的频度解码，则解码数据生产效率完全跟不上渲染的自然时间进度，效果肯定不符合预期，播放也会断断续续。因此我们需要针对不同的应用场景，使用动态解码模式（主动丢帧）控制好CPU的消耗。例如在直播或安防场景下，我们可以舍弃一些指标以保证解码与传输的时效性。

独立的音频、画面帧数据队列

如上图左侧所示，独立的音频与画面帧数据队列分别管理；比如我们启动丢帧策略的话，会看到画面帧数据量变少，但声音没有变化。

音频重新采样

采集端编码数据的音频采样率需要结合播放端的支持情况来留意兼容问题。

浏览器是一个比较特殊的应用场景，各浏览器对音频渲染中采样率的支持程度也是不同的。

例如安防场景对声音的要求并不是很高，通常16,000的采样率即可，但是如果想在浏览器端播放视频，则部分浏览器要求至少22,050的采样率，否则浏览器端播放无法成功识别并渲染音频数据。FFmpeg本身可以进行音频重新采样，因此我们可以在解码器端加入相应的配置项，如果用户有该需求那么就可以启动音频重新采样，重新把16,000的音频采样率重采样成符合浏览器所要求的22050采样率。有了符合要求的独立的音频与视频数据帧队列，接下来也自然就能基于浏览器实现对音视频的渲染与呈现。

3.3 渲染器

渲染器的基本功能与下载器、解码器相似，不同之处在于以下几个关键点：

依赖解码、UI提供画布

渲染器需要浏览器提供一个独立的画布用于绘制相应的视觉画面内容。在UI模块初始化时呈现出一个画布的容器，渲染器渲染生成的画面才能表现在网页上。

除此之外，渲染器依赖解码器解码生产出的音视频帧数据才能进行音画渲染。

主动向解码器获取帧数据

这一点与解码器向下载器主动拿数据相似。

分缓存队列、渲染队列

渲染器会消费处理等待渲染的帧数据队列，只不过帧数据会被分为缓存队列与渲染队列。

而之前我们介绍的下载器与解码器，本身只有一组数据队列。为什么要这样呢？渲染器调用WebAudio API将音频数据传输给浏览器进行PCM渲染时，无法将已经通过该API传输给浏览器的数据做取回控制，因此就需要记录当前已经给了多少数据到浏览器，这就是“渲染队列”。而“缓存队列”则是从进程中获取一部分数据先存储在一个临时队列当中，从而避免频繁地向处于另一个独立WebWorker中的解码器索取其音画帧队列数据，而带来不必要的时间消耗。

音画同步、倍速播放、Waiting

音画同步、倍速播放以及判定是否处于等待状态至关重要。比如要追求直播的低延时，网络抖动导致数据堆积发生的时候，倍速追帧是个有效的办法。

动态码率变化

一个视频在播放的过程中，可能随网络状态的波动出现码率的动态变化，例如为适应较差的网络状况，播放器可以主动将媒体流获取从一个较为清晰的高分辨率变化到一个比较模糊的低分辨率源。

而再渲染中，基于WebGLCanavas的渲染器，我们首先需要对YUV着色器进行初始化操作，而YUV着色器的初始化，依赖于其所绘制的数据对应的分辨率、比例与尺寸。如果最开始的分辨率、比例和尺寸与之后要渲染的数据不一样，而我们又未对此做相应的响应适配，那么就会出现画面绘制花屏的情况。而动态码率变化就是要随时响应每一画面帧所对应的分辨率变化，对YUV着色器作动态调整，从而保证画面的实时性与稳定性。

从下载、解码到渲染，视频播放器的基本流程就此建立，播放器便有了获取媒体数据、完成解码、呈现音画效果的基本能力。

3.4 UI

基本的UI如上图左侧所示，上半部分是整个播放器在实例化之前我们可以去做的一系列初始化配置。图中所示的仅是一小部分参数，例如媒体源的地址、是否启用了加密Key、对应的解密算法，包括渲染时为满足某些特定场景下的需求，音视频是同时进行渲染还是在主动控制下仅渲染音频或视频——例如在安防监控业务场景，会有一些设备需要音频采集、另一些不需要，或者干脆播放时就不想播放源流音频等等。若在这里播放器不做判定支持，则存在由于音画同步控制依赖音频帧视频帧时间戳比对，但没有音频帧数据的原因导致无法正常播放，而播放器使用者能进行主动控制则可以避免该问题。

UI的基本功能包括实例化、用户操作触发后续流程涉及的各模块接下来要做什么，还有状态信息响应展现，也就是根据用户交互行为和播放器工作状态作出反馈与信息传递。

另外，UI也需要对相应的状态变化作出响应，例如用户控制当前播放器从正在播放切换到暂停，那么UI层面则需要针对用户操作进行相应的变化。还有快进、拖拽进度条等等。

3.5 控制层

最后的控制层至关重要，首先控制层隔离校验对外暴露的参数及方法。播放器可实现或具备的特性有很多，不可能全部暴露给用户。在播放视频时，下载与解码的数据实际上存在一个前后呼应的关系，如果我们不考虑用户行为与需求，在网页上呈现播放器的所有特性。而用户也不对其进行科学性选择与判断，而是随意调用API，势必会带来矛盾、冲突与混乱。因此我们需要隔离配置信息、校验对外暴露的控制参数及方法，以避免可能存在的冲突。

另外根据之前的介绍我们可以看到，不同模块的基本功能大致相同。因此在控制层我们需要统一各模块的生命周期，并完成用于调度各模块工作的基础类的实现。

每个独立的模块什么时刻可以实例装载？什么时刻销毁？该模块是否支持热插拔？各模块生命周期状态的管控与事件消息的监听与调度…… 这些都由控制层进行管理。

有时我们需要做一些取舍，例如编码器并不是基于FFmpeg，而是基于我们自己的解码解决方案，那么就可以尝试在播放器实例化时候，更换对应模块当中相对应的部分依赖为自己的解码方案；如果我们需要调整播放器UI层界面样式，那么就可能需要定制自己的UI模块……

在这个播放器实现中，为了规避单线程一些弊端，我们基于WebWorker API对重点模块开启子线程。

而WebWorker本身的设计存在各种不便：

首先，要求我们必须单独打包一个JS文件，基于 new Worker(“*.js”)引入到项目中。

但我们整个播放器作为SDK项目的构建来说，通常只产生一个JS文件发布出去，才是合理的。如果同时产生多个JS文件，这对我们的调试、开发或后续应用等来说都不方便。

针对这个问题我们结合Promise 实现了PromiseWebWorker。

PromiseWebWorker 相对于原生Worker，参数不再必须是传入一个JS引用路径，而是可以传入一个函数。

这样以来我们就可以在项目编译时生成一个独立的JS文件，在播放器的执行过程中将其中worker依赖的那部分函数内容生成一个虚拟的文件依赖地址，作为WebWorker执行的资源。

其次，WebWorker原生能力实现父子线程之间数据传递通讯，只能通过postMessage传送数据、通过onMessage获取传送过来的数据，这对于频繁的数据交互中想保证上下文关联对应关系是比较麻烦的。PromiseWebWorker则借助了Promise的优势，对以上整个数据交换过程做严格的应答封装处理，从而实现播放器功能的健壮可靠。

上图链接 http://lab.pyzy.net/qhww 中是播放器DEMO展示地址。

若对播放器的效果和实现感兴趣可以前往试用研究。

4. 要点回顾

调度控制层控制下载器、解码器、渲染器与UI交互四大模块，如果要做某功能模块的业务定制化开发、功能增强补充，对对应独立的模块内部进行优化并做出相应的功能扩展或者调整即可。

5. 难点突破

开发过程所遇到的难点总体可以用以上三点来概括：首先基于WebAssembly 工具链（emscripten.org），借助EMSC编译器我们可以直接将一个C和C++编译成JS可用。这一过程本身存在诸多不便之处，主要是因为其本身对系统一些底层库的依赖或对于开发环境的要求，导致可移植性并没有那么好，当需要跨机器协作时容易出现诸多问题。现在我们内部的解决方案是自己找一台专用机器来配置做为编译发布使用。

第二点是队列管理与状态控制，只有精确实现队列管理与状态控制，我们才能保证整个程序能合理稳定的执行。

第三点就是项目构建打包，我们要解决前端一些构建打包的习惯以及其在逻辑需求上存在的一些冲突。

6. 未来展望

展望未来，我希望未来浏览器能对HEVC有更加出色的支持。本次分享虽然是一个播放器，但我们知道FFmpeg的能力不只是解码播放，还可以做更多实用工具的发掘实现。同时我也希望未来媒体类型百花齐放，甚至私有编解码也能够形成Web端场景更规范灵活的解决方案。WASM成熟、标准化完善、各业务领域对应解决能力的细分，也是很值得期待的一件事情；而回到播放器本身，字幕、AI、互动交互等都是能进一步提升音视频播放服务的可玩性与用户体验方向值得研究的方向。

有时候，我们的产品交互上需要一些特别的效果，比如一个可编辑区域往往会添加一些动态描边效果，那么下面这个可能不失为一个不错的备选方案。

废话不说，直接上效果：

代码：

<!DOCTYPE html>
<html>
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width">
  <title>JS Bin</title>
  <style>
    .box{
      position: relative;
      width:128px;
      height: 128px;
      1overflow: hidden;
    }
    .content {
      position: absolute;
      left:1px;
      top:1px;
      right:1px;
      bottom:1px;
      background:#fff;
    }
    .box:after{
      content:'';
      position: absolute;
      z-index: -1;
      left:0;
      bottom:0;
      top:1px;
      right:1px;
      background: repeating-linear-gradient(135deg, transparent, transparent 3px, #000 3px, #fff 8px);
      animation: shine 1s infinite linear;
    }
    .box:before{
      content:'';
      position: absolute;
      z-index: -1;
      left:1px;
      bottom:1px;
      top:0;
      right:0;
      background: repeating-linear-gradient(135deg, transparent, transparent 3px, #fff 3px, #000 8px);
      animation: shine2 1s infinite linear;
    }
    @keyframes shine {
      0% { background-position: -1px -1px;}
      100% { background-position: -12px -12px;}
    }

    @keyframes shine2 {
      0% { background-position: -12px -12px;}
      100% { background-position: -1px -1px;}
    }
  </style>
</head>
<body>

<div class="box">
    <div class="content">内容占位</div>
</div>

</body>
</html>