浏览器网页剪贴板及其存储不同类型数据的方式

如果你使用电脑有一段时间了，你可能知道剪贴板可以存储多种类型的数据(图像、富文本内容、文件等)。作为一名软件开发者，我开始感到沮丧，因为我对剪贴板如何存储和组织不同类型的数据缺乏深入的理解。

我最近决定揭开剪贴板的神秘面纱，并基于我的学习成果撰写了这篇文章。我们将重点探讨网页剪贴板及其API，同时也会涉及它与操作系统剪贴板的交互方式。

我们将首先探索网页剪贴板API及其发展历史。剪贴板API在数据类型方面存在一些有趣的限制，我们将看到一些公司是如何绕过这些限制的。我们还将探讨一些旨在解决这些限制的提案(最值得注意的是Web Custom Formats)。

如果你曾经好奇过网页剪贴板是如何工作的，这篇文章就是为你准备的。

使用异步剪贴板 API

如果我从一个网站复制一些内容并粘贴到 Google 文档中，其中的一些格式会被保留，例如链接、字体大小和颜色。

但如果我打开 VS Code 并将其粘贴到那里，只有原始文本内容会被粘贴。

剪贴板通过允许信息以与 MIME 类型关联的多种 表示形式 进行存储，来支持这两种使用场景。W3C 剪贴板规范规定在写入和读取剪贴板时，必须支持以下三种数据类型：

• text/plain 用于纯文本。
• text/html 用于 HTML。
• image/png 用于 PNG 图片。

因此，当我之前粘贴时，Google Docs 读取了 text/html 表示形式并使用它来保留富文本格式。VS Code 只关心原始文本并读取 text/plain 表示形式。这很有道理。

通过异步剪贴板 API 的 read 方法读取特定表示形式非常简单：

const items = await navigator.clipboard.read();


for (const item of items) {
  if (item.types.includes("text/html")) {
    const blob = await item.getType("text/html");
    const html = await blob.text();
    // Do stuff with HTML...
  }
}

通过 write 方法将多个表示形式写入剪贴板稍显复杂，但仍相对简单。首先，我们为要写入剪贴板的每个表示形式构建 Blob：

const textBlob = new Blob(["Hello, world"], { type: "text/plain" });
const htmlBlob = new Blob(["Hello, <em>world<em>"], { type: "text/html" });

获得 Blob 后，我们将它们传递给一个新的 ClipboardItem，该项以数据类型为键、Blob 为值存储在键值对存储中：

const clipboardItem = new ClipboardItem({
  [textBlob.type]: textBlob,
  [htmlBlob.type]: htmlBlob,
});

注意：我喜欢 ClipboardItem 接受键值存储。这与使用一种使非法状态无法表示的数据结构的理念相契合，如在 解析，不要验证 中讨论的 .

最后，我们使用新构建的 ClipboardItem 调用 write：

await navigator.clipboard.write([clipboardItem]);

其它数据类型呢？

HTML 和图像很酷，但对于像 JSON 这样的通用数据交换格式呢？如果我正在编写一个支持复制粘贴的应用程序，我可能会想将 JSON 或一些二进制数据写入剪贴板。

让我们尝试将 JSON 数据写入剪贴板：

// Create JSON blob
const json = JSON.stringify({ message: "Hello" });
const blob = new Blob([json], { type: "application/json" });


// Write JSON blob to clipboard
const clipboardItem = new ClipboardItem({ [blob.type]: blob });
await navigator.clipboard.write([clipboardItem]);

运行此代码时，会抛出异常：

Failed to execute 'write' on 'Clipboard':
  Type application/json not supported on write.

嗯，这是怎么回事？根据 write 的规范，除了 text/plain、text/html 和 image/png 之外的数据类型必须被拒绝：

如果 type 不在 强制数据类型 列表中，则拒绝 […] 并终止这些步骤。

值得注意的是，application/json MIME 类型在 2012 to 2021 期间一直是强制性数据类型列表的一部分，但在 w3c/clipboard-apis#155 中被移除。在此变更之前，强制性数据类型的列表要长得多，从剪贴板读取时有 16 个强制性数据类型，写入时有 8 个。变更后，仅保留了 text/plain、text/html 和 image/png 三种数据类型。

这一变更是在浏览器因安全问题而选择不支持许多强制类型后做出的。这一变化在规范的强制性数据类型部分中以警告形式体现：

警告！出于安全考虑，未受信任的脚本写入剪贴板的数据类型受到限制。

未受信任的脚本可能会通过将已知会触发这些漏洞的数据放置到剪贴板中，来尝试利用本地软件中的安全漏洞。

好的，所以我们只能将有限类型的数据写入剪贴板。但“未受信任的脚本”是什么意思？我们是否可以通过在“受信任的脚本”中运行代码，来实现将其他类型的数据写入剪贴板？

isTrusted 属性

或许“可信”部分指的是事件上的 isTrusted 属性。isTrusted 是一个只读属性，仅当事件由用户代理触发时才设置为 true。

document.addEventListener("copy", (e) => {
  if (e.isTrusted) {
    // This event was triggered by the user agent
  }
})

“由用户代理触发”意味着该事件是由用户触发的，例如用户按下 Command C 触发的复制事件。这与通过 dispatchEvent() 方法程序化触发的合成事件不同：

document.addEventListener("copy", (e) => {
  console.log("e.isTrusted is " + e.isTrusted);
});


document.dispatchEvent(new ClipboardEvent("copy"));
//=> "e.isTrusted is false"

让我们看看剪贴板事件是否允许我们向剪贴板写入任意数据类型。

剪贴板事件 API

ClipboardEvent 用于触发复制、剪切和粘贴事件，它包含一个类型为 DataTransfer 的 clipboardData 属性。DataTransfer 对象用于存储数据的多种表示形式。

在 copy 事件中向剪贴板写入数据非常简单：

document.addEventListener("copy", (e) => {
  e.preventDefault(); // Prevent default copy behavior


  e.clipboardData.setData("text/plain", "Hello, world");
  e.clipboardData.setData("text/html", "Hello, <em>world</em>");
});

而在 paste 事件中从剪贴板读取数据同样简单：

document.addEventListener("paste", (e) => {
  e.preventDefault(); // Prevent default paste behavior


  const html = e.clipboardData.getData("text/html");
  if (html) {
    // Do stuff with HTML...
  }
});

现在来回答关键问题：我们能否将 JSON 写入剪贴板？

document.addEventListener("copy", (e) => {
  e.preventDefault();


  const json = JSON.stringify({ message: "Hello" });
  e.clipboardData.setData("application/json", json); // No error
});

没有抛出异常，但这是否真的将 JSON 写入了剪贴板？让我们通过编写一个粘贴处理程序来验证，该处理程序会遍历剪贴板中的所有条目并将其输出：

document.addEventListener("paste", (e) => {
  for (const item of e.clipboardData.items) {
    const { kind, type } = item;
    if (kind === "string") {
      item.getAsString((content) => {
        console.log({ type, content });
      });
    }
  }
});

添加这两个处理程序并执行复制粘贴操作后，会输出以下内容：

{ "type": "application/json", content: "{\"message\":\"Hello\"}" }

成功了！似乎 clipboardData.setData 方法并未像异步 write 方法那样对数据类型进行限制。

但……为什么？为什么我们可以使用 clipboardData 读写任意数据类型，而使用异步剪贴板 API 时却不行？

clipboardData 的历史

相对较新的异步剪贴板 API 于 2017 被添加到规范中，但 clipboardData 要比这早得多。W3C于2006年发布的剪贴板API草案中定义了clipboardData及其setData和getData方法(这表明当时尚未使用MIME类型)：

setData() 该方法接受一个或两个参数。第一个参数必须设置为‘text’或‘URL’(不区分大小写)。

getData() 该方法接受一个参数，允许目标请求特定类型的数据。

但事实证明，clipboardData 的历史比 2006 年的草案还要悠久。请看“本文件的状态”部分中的这段引文：

本文档在很大程度上描述了Internet Explorer中实现的功能…

本文档的目的是[…]指定当前浏览器中实际可用的功能，或[作为]一个简单的目标，以促进浏览器之间的互操作性，而非添加新功能。

这篇2003年的文章详细说明了，当时在Internet Explorer 4及以上版本中，可以使用clipboardData在未经用户同意的情况下读取用户的剪贴板。由于 Internet Explorer 4 于 1997 年发布，因此 clipboardData 接口在本文撰写时至少已有 26 年历史。

MIME类型于2011年被纳入规范：

dataType参数是一个字符串，例如但不限于MIME类型…

如果脚本调用getData(‘text/html’)…

当时，规范尚未确定应使用哪些数据类型：

虽然可以为setData()的类型参数使用任何字符串，但建议使用常见类型。

[Issue] 是否应列出一些“常见类型”？

使用任何字符串作为setData和getData的参数至今仍有效。这完全可行：

document.addEventListener("copy", (e) => {
  e.preventDefault();
  e.clipboardData.setData("foo bar baz", "Hello, world");
});


document.addEventListener("paste", (e) => {
  const content = e.clipboardData.getData("foo bar baz");
  if (content) {
    console.log(content); // Logs "Hello, world!"
  }
});

如果你将这段代码片段粘贴到开发者工具中，然后点击复制粘贴，你将在控制台看到“Hello, world”的日志输出。

Clipboard Events API 的 clipboardData 允许使用任何数据类型的原因似乎是历史遗留问题。“不要破坏网络”。

重新审视 isTrusted

让我们再次考虑来自强制数据类型部分的这句话：

作为安全预防措施，未受信任的脚本写入剪贴板的数据类型受到限制。

那么，如果我们在合成(不受信任)的剪贴板事件中尝试写入剪贴板，会发生什么？

document.addEventListener("copy", (e) => {
  e.preventDefault();
  e.clipboardData.setData("text/plain", "Hello");
});


document.dispatchEvent(new ClipboardEvent("copy", {
  clipboardData: new DataTransfer(),
}));

此操作执行成功，但并未修改剪贴板内容。这是预期行为如规范中所解释的：

合成剪切和复制事件 不得 修改系统剪贴板中的数据。

合成粘贴事件 不得 使脚本访问真实系统剪贴板中的数据。

因此，只有由用户代理触发的复制和粘贴事件才允许修改剪贴板。这完全合理——我可不希望网站随意读取我的剪贴板内容并窃取我的密码。

---

总结我们目前的发现：

• 2017年引入的异步剪贴板API限制了可写入和读取剪贴板的数据类型。然而，只要用户已授予权限(且文档处于焦点状态)，该API可在任何时间读取和写入剪贴板。
• 较旧的剪贴板事件 API 对可写入和读取的剪贴板数据类型没有实质性限制。然而，它只能在由用户代理触发的复制和粘贴事件处理程序中使用(即当 isTrusted 为 true 时)。

如果想要将非纯文本、HTML 或图像类型的数据写入剪贴板，似乎使用剪贴板事件 API 是唯一可行方案。在这一点上，它要宽松得多。

但如果你想构建一个将非标准数据类型写入剪贴板的复制按钮，该怎么办？如果用户未触发复制事件，似乎无法使用剪贴板事件 API。对吧？

构建一个可写入任意数据类型的复制按钮

我尝试在不同网页应用中测试了复制按钮，并检查了写入剪贴板的内容。结果颇具启发性。

Google Docs 的右键菜单中包含一个“复制”按钮。

该复制按钮向剪贴板写入三种表示形式：

• text/plain,
• text/html, 和
• application/x-vnd.google-docs-document-slice-clip+wrapped

注意：第三种表示形式包含 JSON 数据。

他们正在将自定义数据类型写入剪贴板，这意味着他们并未使用异步剪贴板 API。他们是如何通过点击处理程序实现这一点的？

我运行了分析器，点击了“复制”按钮，并检查了结果。结果发现，点击“复制”按钮会触发对 document.execCommand(“copy”) 的调用。

这让我感到意外。我的第一反应是“execCommand 不是过时且被废弃的复制文本到剪贴板的方式吗？”

是的，它是，但谷歌有其使用原因。execCommand 的特殊之处在于，它允许你程序化地触发一个可信的复制事件，就好像用户自己调用了复制命令一样。

document.addEventListener("copy", (e) => {
  console.log("e.isTrusted is " + e.isTrusted);
});


document.execCommand("copy");
//=> "e.isTrusted is true"

注意：Safari 要求在调用 execCommand(“copy”) 时必须有活跃的选中内容。可以通过在 DOM 中添加一个非空的输入元素并在此之前选中它来模拟选中内容，随后再移除该输入元素。

好，使用 execCommand 允许我们在点击事件响应中将任意数据类型写入剪贴板。太棒了！

那么粘贴呢？我们可以使用 execCommand(“paste”) 吗？

创建粘贴按钮

让我们尝试 Google 文档中的粘贴按钮，看看它会做什么。

在我的MacBook上，弹出一个提示框，告诉我需要安装扩展程序才能使用粘贴按钮。

但奇怪的是，在我的Windows笔记本上，粘贴按钮直接就能用。

奇怪。这种不一致性是从哪里来的？其实，是否能使用粘贴按钮可以通过运行queryCommandSupported(“paste”)来检查：

document.queryCommandSupported("paste");

在我的MacBook上，Chrome和Firefox返回false，而Safari返回true。

Safari出于隐私考虑，要求我确认粘贴操作。我认为这是一个非常好的想法。它明确表明网站将读取你的剪贴板。

在我的 Windows 笔记本上，Chrome 和 Edge 返回 true，而 Firefox 返回 false。Chrome 与 Firefox 之间的差异令人惊讶。为什么 Chrome 在 Windows 上允许 execCommand(“paste”)，但在 macOS 上不允许？我未能找到相关信息。

我感到惊讶的是，Google 并未尝试在 execCommand(“paste”) 不可用时回退到异步剪贴板 API。尽管他们无法通过该 API 读取 application/x-vnd.google-[...] 格式，但 HTML 格式中包含可用的内部 ID。

<!-- HTML representation, cleaned up -->
<meta charset="utf-8">
<b id="docs-internal-guid-[guid]" style="...">
  <span style="...">Copied text</span>
</b>

---

另一个带有粘贴按钮的网页应用是 Figma，他们采用了完全不同的方法。让我们看看他们是如何实现的。

Figma 中的复制和粘贴

Figma 是一个基于网页的应用程序(其原生应用使用 Electron)。让我们看看他们的复制按钮向剪贴板写入了什么。

Figma 的复制按钮会将两种格式写入剪贴板：text/plain 和 text/html。这让我感到有些意外。Figma 究竟是如何将各种布局和样式功能以纯 HTML 格式呈现的呢？

但查看 HTML 代码后，我们可以看到两个空的 span 元素，它们带有 data-metadata 和 data-buffer 属性：

<meta charset="utf-8">
<div>
  <span data-metadata="<!--(figmeta)eyJma[...]9ifQo=(/figmeta)-->"></span>
  <span data-buffer="<!--(figma)ZmlnL[...]P/Ag==(/figma)-->"></span>
</div>
<span style="white-space:pre-wrap;">Text</span>

注意：对于一个空框架，data-buffer 字符串长度约为 26,000 个字符。之后，data-buffer 的长度似乎会随着复制内容的数量呈线性增长。

看起来像是 base64 编码。以 eyJ 开头的字符串明确表明 data-metadata 是一个 base64 编码的 JSON 字符串。对 data-metadata 运行 JSON.parse(atob()) 得到：

{
  "fileKey": "4XvKUK38NtRPZASgUJiZ87",
  "pasteID": 1261442360,
  "dataType": "scene"
}

注意：我已替换了真实的 fileKey 和 pasteID。

那么，关于那个庞大的 data-buffer 属性呢？对其进行 Base64 解码后得到以下内容：

fig-kiwiF\x00\x00\x00\x1CK\x00\x00µ½\v\x9CdI[...]\x197Ü\x83\x03

看起来像是二进制格式。经过一番调查——以 fig-kiwi 为线索——我发现这是 Kiwi 消息格式(由 Figma 的联合创始人兼前 CTO Evan Wallace 创建)，用于编码 .fig 文件。

由于Kiwi是一种基于模式的格式，似乎在不知道模式的情况下无法解析这些数据。不过幸运的是，Evan创建了一个公开的.fig文件解析器。让我们尝试将缓冲区插入其中！

为了将缓冲区转换为 .fig 文件，我编写了一个小脚本以生成 Blob URL：

const base64 = "ZmlnL[...]P/Ag==";
const blob = base64toBlob(base64, "application/octet-stream");


console.log(URL.createObjectURL(blob));
//=> blob:<origin>/1fdf7c0a-5b56-4cb5-b7c0-fb665122b2ab

随后，我将生成的 Blob 下载为 .fig 文件，将其上传至 .fig 文件解析器，结果如愿以偿：

因此，Figma 中的复制功能是通过创建一个小型 Figma 文件，将其编码为 base64，将生成的 base64 字符串放入空 HTML span 元素的 data-buffer 属性中，并将其存储在用户的剪贴板中。

复制粘贴 HTML 的优势

起初我认为这有点荒谬，但这种方法确实有显著优势。要理解原因，需考虑基于网页的剪贴板 API 与各操作系统剪贴板 API 的交互方式。

Windows、macOS 和 Linux 系统在将数据写入剪贴板时采用不同的格式。若要将 HTML 写入剪贴板，Windows 提供 CF_HTML 和 macOS 提供 NSPasteboard.PasteboardType.html。

所有操作系统都提供了“标准”格式的类型(纯文本、HTML 和 PNG 图片)。但当用户尝试将任意数据类型(如 application/foo-bar)写入剪贴板时，浏览器应使用哪个操作系统格式？

没有合适的匹配项，因此浏览器不会将该表示形式写入操作系统剪贴板的常见格式。相反，该表示形式仅存在于操作系统剪贴板中的自定义浏览器专用剪贴板格式中。这使得可以在浏览器标签页之间复制和粘贴任意数据类型，但不能在应用程序之间进行。

这就是为什么使用常见数据类型 text/plain、text/html 和 image/png 如此方便。它们映射到操作系统剪贴板的通用格式，因此其他应用程序可以轻松读取，从而实现跨应用程序的复制粘贴功能。以 Figma 为例，使用 text/html 格式可实现从浏览器中的 figma.com 复制 Figma 元素，然后将其粘贴到原生 Figma 应用程序中，反之亦然。

浏览器会将自定义数据类型写入剪贴板的哪些内容？

我们已经了解到，可以在浏览器标签页之间写入和读取自定义数据类型，但无法在应用程序之间进行。那么，当我们将自定义数据类型写入网页剪贴板时，浏览器会向原生操作系统剪贴板写入什么内容？

我在MacBook上的主要浏览器中每个浏览器的copy监听器中运行了以下代码：

document.addEventListener("copy", (e) => {
  e.preventDefault();
  e.clipboardData.setData("text/plain", "Hello, world");
  e.clipboardData.setData("text/html", "<em>Hello, world</em>");
  e.clipboardData.setData("application/json", JSON.stringify({ type: "Hello, world" }));
  e.clipboardData.setData("foo bar baz", "Hello, world");
});

随后我使用剪贴板查看器检查了剪贴板。Chrome在剪贴板中添加了四个条目：

• public.html包含HTML表示形式。
• public.utf8-plain-text包含纯文本表示形式。
• org.chromium.web-custom-data 包含自定义表示形式。
• org.chromium.source-url 包含复制操作所在网页的 URL。

查看 org.chromium.web-custom-data，我们可以看到复制的数据：

我推测带重音的“î”和不一致的换行符是由于某些分隔符显示不正确所致。

Firefox 也会创建 public.html 和 public.utf8-plain-text 条目，但将自定义数据写入 org.mozilla.custom-clipdata。它不像 Chrome 那样存储源 URL。

Safari，如你所料，也会创建 public.html 和 public.utf8-plain-text 条目。它将自定义数据写入 com.apple.WebKit.custom-pasteboard-data，并且有趣的是，它还会将所有表示形式(包括纯文本和 HTML)以及源 URL 存储在此处。

注意：Safari 允许在浏览器标签页之间复制粘贴自定义数据类型，前提是源 URL(域名)相同，但不支持跨不同域名。这一限制似乎在 Chrome 或 Firefox 中不存在(尽管 Chrome 会存储源 URL)。

网页的原始剪贴板访问

关于 原始剪贴板访问 的提案于2019年提出，该提案旨在为网页应用程序提供访问原生操作系统剪贴板的原始读写权限。

以下是 chromestatus.com 上 动机部分 中关于原始剪贴板访问功能的摘录，简明扼要地概述了其优势：

没有原始剪贴板访问权限 […]，网络应用程序通常只能处理少量格式，无法与大量其他格式实现互操作。例如，Figma 和 Photopea 无法与大多数图像格式实现互操作。

然而，由于安全问题而未被采纳，这些担忧主要围绕远程代码执行等漏洞在原生应用中的利用。

目前最新的将自定义数据类型写入剪贴板的提案是 Web 自定义格式提案(常被称为 pickling)。

Web 自定义格式(Pickling)

2022 年，Chromium 在异步剪贴板 API 中实现了对 Web Custom Formats 的支持。

它允许网页应用通过在数据类型前缀 “web ” 来使用异步剪贴板 API 写入自定义数据类型：

// Create JSON blob
const json = JSON.stringify({ message: "Hello, world" });
const jsonBlob = new Blob([json], { type: "application/json" });


// Write JSON blob to clipboard as a Web Custom Format
const clipboardItem = new ClipboardItem({
  [`web ${jsonBlob.type}`]: jsonBlob,
});
navigator.clipboard.write([clipboardItem]);

这些数据类型可像其他数据类型一样通过异步剪贴板 API 读取：

const items = await navigator.clipboard.read();
for (const item of items) {
  if (item.types.includes("web application/json")) {
    const blob = await item.getType("web application/json");
    const json = await blob.text();
    // Do stuff with JSON...
  }
}

更值得注意的是写入原生剪贴板的内容。在写入网页自定义格式时，以下内容会被写入原生操作系统剪贴板：

• 数据类型与剪贴板条目名称的映射关系
• 每个数据类型的剪贴板条目

在 macOS 上，该映射关系会被写入 org.w3.web-custom-format.map，其内容如下：

{
  "application/json": "org.w3.web-custom-format.type-0",
  "application/octet-stream": "org.w3.web-custom-format.type-1"
}

org.w3.web-custom-format.type-[index] 键对应于操作系统剪贴板中包含原始数据的条目。这使得原生应用程序可以查看映射以确定给定表示是否可用，然后从对应的剪贴板条目中读取原始内容。

注意： Windows 和 Linux 使用不同的命名约定 进行映射和剪贴板条目的命名。

这避免了与原始剪贴板访问相关的安全问题，因为网络应用程序无法将未经处理的数据写入任意操作系统剪贴板格式。这带来了一个明确列在异步剪贴板 API 规范中的序列化方案中明确列出：

非目标

允许与旧版原生应用程序实现互操作性，无需更新。这一方案曾在原始剪贴板提案中探讨过，未来可能进一步研究，但会带来显著的安全挑战(系统原生应用程序中的远程代码执行)。

这意味着，当使用自定义数据类型时，原生应用程序需要更新才能与网页应用程序实现剪贴板互操作性。

自2022年起，基于Chromium的浏览器已支持Web自定义格式，但其他浏览器尚未实现该提案。

结语

目前尚无一种通用的方法可在所有浏览器中实现自定义数据类型的剪贴板写入。Figma通过将Base64字符串转换为HTML表示形式的方案虽粗糙但有效，因其绕过了剪贴板API的诸多限制。若需通过剪贴板传输自定义数据类型，这似乎是一个值得采纳的方案。

我认为 Web Custom Formats 提案颇具潜力，希望它能被所有主流浏览器采纳。它似乎能以安全且实用的方式实现将自定义数据类型写入剪贴板的功能。

感谢阅读！希望这篇文章对您有所启发。

— Alex Harri

附录：unsanitized 选项

通过异步剪贴板 API 从剪贴板读取数据时，浏览器可能会对数据进行清理。例如，浏览器可能会移除 HTML 中潜在危险的脚本标签，并重新编码 PNG 图片以防止 zip 炸弹 攻击。

因此，异步剪贴板 API 的 read 方法包含一个 unsanitized 选项，允许您请求未经清理的数据。您可以在 Thomas Steiner 的这篇博文中了解更多关于此选项及其工作原理的信息。

目前，unsanitized 选项仅在基于 Chromium 的浏览器中支持(于 2023 年末添加)。其他浏览器未来可能支持此选项(尽管 Safari 似乎不太可能支持，详见 利益相关者反馈/反对意见)。

感谢 Tom 就提及 unsanitized 选项与我们联系！该选项与本文的讨论范围非常契合。

你也许感兴趣的：

• 我正在转向 Python 并且真的喜欢它
• 请准备好将 Android 应用的内存页大小过渡到 16 KB
• 🚦 JavaScript Signals 标准提案🚦
• Javascript 中的 using、Disposable 和显式资源管理
• Google 的设计文档
• CSS 层叠层级(@layer)指南
• 浏览器 HTTP 压缩传输新方法： 压缩字典传输
• Rust 的依赖关系吓到了我
• Rust 中的奇怪表达式
• 为什么 Rust 编译器这么慢？