Bri*_*eud 6 javascript base64 mime-types data-uri data-uri-scheme
我知道您可以包括css和图像以及其他文件类型,这些文件已经以base64形式存储在javascript文件中。但是,它们相当庞大……并且压缩后,它们缩小了很多,即使有base64编码带来的〜33%的开销。
未压缩的图像是data:image / gif; base64,data:image / jpeg,data:image / png和css是data:text / css; base64。那么,我可以/应该使用哪种MIME类型来包含压缩的css或图像数据URI?(或者,如果gzip + base64无法正常工作,我还有其他压缩方法可以减小字符串的大小,同时仍将数据存储在javascript中吗?)
..edit ..我认为这个问题被误解了。我不问,如果我应包括在JavaScript中的base64 gzip压缩的字符串。是的,我知道在大多数情况下,最好在服务器端gzip javascript和其他文件。但这不适用于用户脚本;一个用户脚本没有服务器,并且只包含一个文件。Firefox允许使用@require指令,但是Opera和Chrome不允许使用,加载任何本地文件时,本地文件安全性问题也随之而来。因此,脚本所需的任何内容都必须是:1)在Web上(慢)或2)嵌入在用户脚本中(大)。
现在,这个问题假设大的比慢的更可取,但是大的并不一定意味着我们完全忽略了多大。如果可以更小,那就是一种改进。
因此,假设在JavaScript中嵌入了base64字符串,问题是如何使它变成有意义的东西。
要么:
1)atob()可以在javascript中将原始base64编码的gzip转换为原始gzip。(atob不需要知道媒体类型)。然后的问题是如何解压缩原始的gszip css或图像文件,以便将结果输出输入文档中。
或2)给定正确的媒体类型,浏览器至少理论上(根据datauri RFC)应该能够直接从datauri加载任何文件。“”足以加载未压缩的CSS样式表。这里的问题是什么链接类型属性和datauri媒体类型组合应该起作用(以及它适用于哪些浏览器)?对于用户脚本,最好是可以在Opera,FF和Chrome中使用的组合。
在 HTTP 中,压缩通常仅应用于传输,以减少要传输的有效负载。这是通过Content-Encoding标头字段完成的。
\n但dataURL 方案非常有限,只能指定媒体类型:
\n\nRun Code Online (Sandbox Code Playgroud)\ndataurl := "data:" [ mediatype ] [ ";base64" ] "," data\n
尽管您可以使用多部分消息,但大多数用户代理在 URL 中不支持它们data。描述这种多部分消息的附加数据是否会多于通过压缩实际有效负载而安全的数据也值得怀疑。
因此,压缩 URL 中的数据data理论上是可能的,但不切实际。最好简单地压缩data嵌入 URL 的整个文档。