data redirecturiuri协议 内容需要解密吗

即将图片资源转换为 base64 字符串格式嵌到页面或样式中。这样连图片的请求链接都省了。如:使用方式CSS Code复制内容到剪贴板/** 数据格式 **/data:image/base64,iVBORw0KGgoAAAANSUhEUgAAAA4AAAAOCAYAAAAfSC3RAAAABHNCSVQICAgIfAhkiAAAAAlwSFlzAAALEwAACxMBAJqcGAAAAE1JREFUKJHV0MEOwCAIA9DW7MP983pymUaweluv8IAABJFUJdWonqEeD0/IwwHK8QatsYlGfIhezM9WOc8jSQAoTvMqTzY1u+ZD4iZ6wwAAAAAElFTkSuQmCC/** 样式引用 **/.icon{width: 30 height: 30background-image:url(data:image/base64,iVBORw0KGgoAAAANSUhEUgAAAA4AAAAOCAYAAAAfSC3RAAAABHNCSVQICAgIfAhkiAAAAAlwSFlzAAALEwAACxMBAJqcGAAAAE1JREFUKJHV0MEOwCAIA9DW7MP983pymUaweluv8IAABJFUJdWonqEeD0/IwwHK8QatsYlGfIhezM9WOc8jSQAoTvMqTzY1u+ZD4iZ6wwAAAAAElFTkSuQmCC);}标签语法:data : 取得数据协议image/png : 取得数据的协议名称(注意这里也图片资源也可以使用字体等)base64 : 数据编码方式iVBOR... : 编码后数据优点减少 HTTP 请求避免某些文件跨域无图片缓存等问题(但是一般 css 也是有缓存的好不好)缺点兼容性 ( IE6,7 不兼容, 可以使用 MHTML 来解决 )浏览器不会缓存该图片(这里是否是这样我存有疑惑,因为好像看上去也是第一次加载的时候慢)增加 css 文件大小编码成本及维护(展示不直观,目前需手动转换,我暂时不知道自动替换之类的插件)之前有看到过篇测评说性能上比 sprite 微弱一些,一时间找不到链接综合起来,data URI可以使用在* 图片尺寸很小,使用一条 http 请求有点浪费,如渐变背景框* 图片在全站大规模使用,且很少被更新的,如 loading最近更新:免责声明:本文仅代表作者个人观点,与本网无关。看完本文,记得打分哦:很好下载Doc格式文档马上分享给朋友:?知道苹果代表什么吗实用文章,深受网友追捧比较有用,值得网友借鉴没有价值,写作仍需努力相关综合教程:
48小时热门诡异问题排查之「DataURI 引发的血案」 | JerryQu 的小站如果你看到这段文字,说明本地存储文件已损坏。!诡异问题排查之「DataURI 引发的血案」文章目录今天在整理资料时,无意中看到一年前做过的一个名为《移动 Web 诡异问题两则》的小分享。这两个问题源自于实际线上业务,都挺有意思,我准备以博客的形式分享给大家。由于文中的案例发生在一年前,当时的现象和测试数据不一定适用于当前环境,但排查问题的思路可以通用。这篇文章不会涉及任何具体的业务信息。
我们有一个移动 Web 项目,某天启用了内部编译工具中几个优化功能,发布上线后,马上收到了 404 请求报警邮件。这种情况之前从没遇见过,因为我们的静态资源要么托管在 CDN 上,要么 inline 在页面中,正常情况下并不会从我们的 Web 机器读取。
我的第一反应是代码有问题,立马线上验证。问题当然不是出在代码上,不然就不会称之为诡异问题。排除代码问题后,我又快速过了一遍错误日志,来源 IP 和 UserAgent 并没有明显的规律,所以基本可以排除机器扫描或人为构造 URL 的情况。
接着对收集到的 404 错误 URL 进行初步分析,找出错误次数最多的 URL,这通过 awk、sort、uniq -c 就可以搞定。将 URL 除重排序后,发现错误请求主要有这两类:
/data:image/base64,iVBORw.......
//t01acxxxxxx.png
一类是图片 DataURI 前面多了一个 /;一类是图片 CDN 地址前面多了一个 /。去掉它们前面的 /,图片都可以正常访问。
对照线上的代码,发现问题很可能出在下面这两个优化上:
1)将小图片编成 DataURI 形式,如:
background:url(data:image/base64,...
这种做法的目的是减少连接数(移动端尤为重要),是一种非常普遍的做法。本博客四年半前。
2)去掉 URL 的协议部分:
background:url(///t01ac...
对于 // 开头的 URL,浏览器会自动补上当前页面协议去请求。这样做有两个好处:1)减小页面大小;2)自动兼容 HTTP 和 HTTPS。鉴于低廉的成本,这也是一种非常普遍的做法,本站也一直这么用。
根据常识,移动端这两种写法都是合法的,所有浏览器都支持,无论如何也不应该出现 404。之前有篇文章,写到开发同学对测试同学的常用语中有这么一条:在我这里是好的。当时我面临的情况真的是线上源源不断在报 404,而我无论怎么测试都是好的,没有任何办法复现这个问题,如何修复更无从谈起,只能先回滚代码。
回滚代码后,404 错误立马降下去了。但是优化还是要做,我必须尽快找到原因并解决它。现在,我手头已经有了几万行错误日志,我需要从中找出真相。
首先,我怀疑是某个特定版本的系统、或者某个特定的浏览器,处理 URL 有缺陷导致的问题。因为 Android 设备所安装的系统,经常被厂商改得乱七八糟;移动浏览器也是百花齐放,各种奇怪的改动都有。于是我对日志中的 UA 字段,进行了操作系统、浏览器等几个纬度的分析。然而,并没有发现异样,也就是说这个推测不成立。
接下来,我怀疑的是用户网络环境。相比 PC 端,移动端网络更为复杂:各种免费 WIFI、省流代理,很有可能为了实现某些功能,修改 HTTP 数据包。由于手头的 404 日志是从 Nginx 访问日志筛出来的,能用于分析网络环境的只有终端 IP 了。
首先,我分析了地域分布。下图中,左侧是 404 错误地域分布,右侧是同时期正常访问地域分布:
可以看到,正常请求来自江苏的有 6.29%,而在 404 错误统计中,却找不到任何来自于江苏的访问;湖北也是类似情况。所以这次诡异的 404 事件有着明显不正常的地域分布。
接下来,利用 IP 信息,还可以分析出运营商分布。下图中,左侧是 404 错误运营商分布,右侧是同时期正常访问运营商分布:
这下就更一目了然了,诡异的 404 请求几乎全部来自于特定的运营商。考虑到 IP 地址库自身有偏差,可以认为全部 404 流量都来自于某一家运营商。
那么综上,我们可以得出结论:某些省份的某个运营商会修改我们的页面结果,导致 DataURI 和省略了协议的 URL 出错。
有了之前的分析,我打算主动出击,验证我的结论并收集更多信息。
首先我在页面 inline 一小段用来测试的 style 标签,里面使用了 DataURI 格式的图片。并在页面底部 inline 一小段 JS,大致内容如下:
var flag = 0;
var styles = document.querySelectorAll('style');
for(var i = 0; i & styles. i++) {
if(styles[i].innerHTML.indexOf('/data:image') & -1) {
最终,试验结果验证了之前的结论,还让我们搞明白了运营商修改页面的目的:在页面底部插入他们网上营业厅的 Banner 条。
至此,这个诡异问题的原因终于水落石出了。但没有 HTTPS 或客户端的帮助,无法避免 Web 页面被修改。如果坚持上线前面两个优化,一些用户就看不到某些图片,我们无法接受这个体验。但是受影响的用户比例很小,如果为了大部分人而放弃 DataURI 优化,显然也不合理。
最终,我们采用了以下方案:
1)针对 DataURI 这种形式,我们在 Nginx 加了一个 rewrite 规则。下面这种形式的请求会被 rewrite 给一个 php 页面,从而获取 URL 内容并转为图片输出。确保页面被修改时用户依然能看到图片:
/data:image/base64,iVBORw.......
2)关闭「移除 URL 协议部分」这个优化点。因为这个优化的收益实在太小了,为此做兼容方案并不划算。
本文链接:,--EOF--提醒:本文最后更新于&678&天前,文中所描述的信息可能已发生改变,请谨慎使用。

我要回帖

更多关于 intent.setdata uri 的文章

 

随机推荐