在firefox中，直接将base64编码内容通过`data:` uri赋给`iframe`的`src`属性常导致下载而非显示。本文提供了一种跨浏览器兼容的解决方案，通过javascript的`fetch` api获取base64编码数据后，利用`atob()`函数解码，并直
接将其注入`iframe`的`contentdocument.body.innertext`，从而避免了浏览器差异导致的下载行为，确保文本内容在所有主流浏览器中正确显示。
在Web开发中，我们经常需要动态地将内容加载到iframe中，以实现隔离或嵌入外部资源。当需要加载远程文本文件（例如来自GitHub API的Base64编码文件内容）时，一种常见的方法是构建一个data: URI并将其赋给iframe的src属性。然而，这种方法在不同浏览器中的行为可能存在差异，尤其是在Firefox中。
问题分析：data: URI在Firefox中的特殊行为
考虑以下场景：从GitHub API获取一个文件的Base64编码内容，并尝试将其加载到iframe中。
上述代码在Chrome或Edge等浏览器中通常能正常工作，将Base64解码后的内容显示在iframe中。但当在Firefox中执行时，浏览器会将iframe.src的赋值操作视为一次文件下载请求，弹出下载对话框或直接将内容下载到一个临时文件，而不是在iframe中渲染。这主要是由于Firefox对data: URI在iframe.src属性中的处理方式与Chrome等浏览器存在差异。
此外，原始代码中对data['content']使用encodeURIComponent是不必要的，因为data['content']本身已经是Base64编码的字符串。在data: URI中，Base64编码后的内容通常不需要额外进行URI编码，除非其中包含URI保留字符且未被Base64正确处理，但在大多数情况下，直接使用Base64字符串即可。
解决方案：直接操作iframe内容
为了实现跨浏览器兼容性，避免Firefox的下载行为，并确保内容正确显示，最佳实践是绕过src属性，直接通过JavaScript操作iframe的文档对象模型（DOM）。
核心思路是：
- 使用fetch API获取Base64编码的文件内容。
- 使用atob()函数将Base64编码内容解码为原始字符串。
- 将解码后的内容直接写入iframe的contentDocument.body.innerText（如果需要显示纯文本）或contentDocument.body.innerHTML（如果需要渲染HTML）。
下面是修正后的代码示例：
在iframe中加载GitHub文本文件
动态加载GitHub文本文件到iframe
以下iframe将显示GitHub仓库中的一个CoffeeScript文件内容。
代码解析与注意事项
- fetch(githubApiUrl): 这是标准的Web API，用于从GitHub获取文件内容。GitHub API返回的JSON对象中，content字段包含了文件的Base64编码字符串。
- atob(data['content']): atob()（ASCII to Binary）是一个全局函数，用于解码Base64编码的字符串。这是关键一步，它将Base64字符串转换回原始文本。与encodeURIComponent不同，atob是专门用于Base64解码的。
- iframe.contentDocument: 这是iframe内部的Document对象。通过它，我们可以访问并操作iframe内部的DOM结构。
- iframe.contentDocument.body.innerText = decodedContent: 这是将解码后的文本内容注入iframe的最直接和安全的方式。innerText属性会确保内容被视为纯文本，不会解析其中的HTML标签，从而避免了跨站脚本（XSS）攻击的风险。
- src="about:blank": 建议在iframe初始化时将其src属性设置为about:blank。这会加载一个空的、同源的文档，确保contentDocument立即可用，并避免加载任何外部资源。
- 错误处理: 在fetch操作中加入.catch()可以捕获网络请求或JSON解析中的错误，提高代码的健壮性。
- innerHTML与安全性: 如果你确实需要将HTML内容加载到iframe中并希望它被渲染，可以使用iframe.contentDocument.body.innerHTML = decodedContent;。但请务必确保decodedContent是受信任的HTML，因为它可能包含恶意脚本，导致XSS漏洞。对于纯文本文件，innerText是更安全的选择。
- iframe加载时机: 在某些复杂场景下，如果iframe的src属性指向一个外部URL，并且你需要等待其完全加载后才能操作contentDocument，你可能需要监听iframe的onload事件。然而，对于src="about:blank"或在iframe创建后立即操作的情况，contentDocument通常是立即可用的。
总结
通过直接操作iframe的contentDocument.body.innerText（或innerHTML），我们可以有效地解决在Firefox中data: URI加载Base64内容时遇到的下载问题。这种方法提供了更强的跨浏览器兼容性，并允许开发者更精细地控制iframe内部的内容呈现。在处理动态内容加载时，始终优先考虑直接的DOM操作而非依赖src属性的data: URI，尤其是在需要确保广泛兼容性时。同时，对于任何用户或外部来源提供的内容，务必注意安全性，选择合适的属性（innerText vs innerHTML）以防范XSS攻击。
