视频video标签在移动端的播放总结 昨天新上线了一个关于腾讯 18 周年嘉年华的 html5，这个 html5 是有 5 段不同的视频组成，中间使用各种手势进行串联，欢迎大家访问。众所周知，在移动端的视频和音频都是需要用户手动点击开启的，而使用autoplay或在 js 里写play()是没有任何作用的。还有几个常见的问题这里也提示一下： iOS 不支持preload属性，android 可能会支持，没太细测试。用户只有在点击的时候才会去加载视频； iOS 不支持autoplay属性，需手动点击开启，使用 setTimeout 延迟开启也不行； canplaythrough表示可是流畅播放了，但是在 android 下是没有卵用的； 有的 android 下是播放完成后才会触发。 playing表示开始播放了，android 下无效； canplay认为是视频元素没有问题，可以运行，没有更多含义了，基本用不上，android 下一样； iOS 和 android 都支持 ended 事件，但不能在 ended 事件里启动一段音频或视频，因此不能使用ended进行视频的循环播放； 有的 iOS 版本下，会弹出一个全屏播放器来播放视频，iPad 则支持内联播放。有人说添加webkit-playsinline属性即可支持内联播放，不过我这儿并没有什么卵用。全屏播放后，会造成操作很不流畅，必须关闭视频的全屏效果，才能进行下一步的操作； 在网络不太好，或视频比较大的情况下，在点击和正式播放的空隙内会有一段等待视频加载的时间；有时候也会出现只有音频而没有画面的情况。 针对这些问题，有的是系统级的问题（比如调起全屏的播放器，循环播放视频等），我们无法修改；其他的，我们都尽量地通过程序来实现。 1. 如何获取视频的加载进度，让视频加载完成后才让用户进入？ # 不能，没有任何的办法来判断视频的加载进度，而且在 iOS 中，只有视频在播放的时候，才临时去加载视频。因此，即使在 video 标签中写了preload属性也是不管用的。使用canplaythrough事件也是没法检测的，虽然 video 标签在加载的时候会触发 canplaythrough 方法，但播放时依然会有卡顿的现象，而且某些 android 还不支持次属性。 2. 播放视频时只有声音没有图像 # 有部分原因是视频的编码不正确，在 mp4 格式的视频中，只支持 h.264 的视频。我的项目中也遇到了这种情况，但不是视频编码的问题。我在自己的网络下测试时，没有这样的问题，但是在外部环境测试时就会出现黑屏、有声音没图像的情况。那么应该就是视频有点大了，然后我就把视频压缩了一下，结果还是会有这样的情况出现。经过同事的指点，我在用户点击和视频正式播放之前添加一个 loading 效果，当视频正式播放的时候就取消 loading。如下：function video_loading($video) { $(".video_loading").show(); var timer = setInterval(function () { var currentTime = $video[0].currentTime; // 检测当前的播放时间 if (currentTime > 0) { $(".video_loading").hide(); clearInterval(timer); } }, 100); } 完美解决黑屏和有声音没图像的问题。 3. 在每段视频的结尾都有向上滑、点击的操作 # 我们是无法在视频上直接进行滑动和点击等操作的，只能是在视频播放结束时，添加一个透明遮罩，让用户在遮罩上进行操作。/** 视频的播放时间改变时进行的操作 videoid video标签的id cur 当前播放时间，可以传入ended参数 func 回调函数 */ videoUpdate : function(videoid, cur, func){ var myVideo = document.getElementById(videoid); if( myVideo ){ if( typeof cur =='number' ){ myVideo.addEventListener('timeupdate', function(){ if( this.currentTime>=cur ){ func(); myVideo.removeEventListener('timeupdate', function(){ }, false); } }, false); }else{ myVideo.addEventListener(cur, function(){ func(); }, false); } } } 使用方法：// 第一屏的视频进行到4秒时，显示透明图层以提供用户操作 tool.videoUpdate("video1", 4, function () { $(".s1 .overlay").show(); }); // 第一屏的视频结束时，显示向下滑动提示按钮 tool.videoUpdate("video1", "ended", function () { $(".s1 .tip").show(); }); 总结 # 这是第一次做移动端的视频播放 html5，在很多地方还有不足的地方，欢迎大家提出意见和建议。

php里简单的对称加密算法 前几天突发奇想要往数据库里保存一些机密的东西，然后就想着怎么让别人即使进入到了数据库也看不懂存储的是什么，那么只有加密了；可是我们自己还要看呢，那只能找一些对称加密的算法了，我们想看的时候再解密回来。在网上找到了一个不错的PHP方面的对称加密算法；在PHP的语法环境里，有urlencode与urldecode,base64_encode和base64_decode自带的对称算法，不过这些自带的算法不能称之为加密算法，只能说是编码方式而已。可是我们可以利用这些来进行一些加工，来实现简单的加密和解密算法。这次的加密和解密算法是使用base64的方式改编的。通常我们使用base64_encode($str)产生的字符串，不经过任何的加工的话，base64_decode()就能转回我们之前的字符串；可是如果我们在base64_encode()之后的字符串里插入几个字符呢，那他就转不回来了，即使转过来也不是我们自己的字符串。

移动端在页面输出调试信息 在移动端，没有了PC浏览器上调试代码的利器，导致我们很难排查和调试问题，于是我就简单的写了一个可把log输出到页面上的js代码。那么log输出的日志里通常需要包含这些信息： 当前时间，精确到秒或毫秒； 输出想要输出的信息 调试的文件； log输出所在的行数，同一个文件可能有多个log输出，最好每个都能定位到行 通常第1个和第2个比较容易实现，直接获取当前date的时间，然后追加到页面上即可。但是当前所处的文件和行号好像不太好获取。经常看console的时候应该知道，通常js出错的时候，console会给出错误信息和所在行号。这里我们也是这样的思路。 主动抛出错误，然后用try...catch进行接收，在catch里获取当前执行代码所在的行号 function log(){ try{ throw new Error(); }catch(e){ console.log(e.stack); } } log(); 运行上面的代码，console里会这样的输出：Error // 抛出异常的类型 at log (tools.html:175) // 抛出异常时的行号： throw new Error() ，这里也能看到其所处的函数和所在文件 at tools.html:180 // 运行log函数的行号： log() 我们从e.stack里能获取不少的信息，同时，我们还能获取到log()执行所处的环境：function a(){ log() } a(); var obj = { func : function(){ log(); } } obj.func(); 输出的信息是：Error at log (tools.html:175) at a (tools.html:183) // 在a函数中运行，执行log的位置是183 at tools.html:185 --- Error at log (tools.html:175) at Object.b (tools.html:189) // 在Object.b函数中运行，执行log的位置是189 at tools.html:192 我们再对e.stack进行优化处理一下，就可以获取到我们想要的信息了，完整的代码如下：function log(msg){ var $body = document.querySelector('body'); if( !$body.querySelector('.info_wz_852') ){ $body.innerHTML += ''; } var $info = $body.querySelector('.info_wz_852'); var date = new Date(), minute = ('00'+date.getMinutes()).slice(-2), second = ('00'+date.getSeconds()).slice(-2); try{ throw new Error(); }catch(e){ var loc = (e.stack.replace(/Error\n/).split(/\n/)[1]).replace(/^(\s|\u00A0)+/,'').replace(/(\s|\u00A0)+$/,''); // var arr = loc.split(':'), // col = parseInt(arr.pop()), // line = parseInt(arr.pop()); $info.innerHTML += '['+minute+':'+second+'] '+loc+''+msg+''; } } 输出的结果是： [47:47] at foo (http://xxx.com/test/index.html:165:5)123[47:47] at http://xxx.com/test/index.html:171:1456 当然，如果需要更复杂的功能，也可以继续添加，比如ajax传给后端等。

一个“极限挑战”主题的网站上线了 公众号微信公众号：前端小茶馆

https的研究与总结 为了保证用户数据的安全性、避免中间运营商的劫持，部署 https 已成当务之急。https 早已不是锦上添加的可有可无项，它已经逐渐成为 WEB 服务的标配。那么什么是 https 呢，https 与 http 的区别在哪儿，我们作为前端在部署 https 时应该注意什么呢？ 1. http 与 https 的区别 # 我们传统使用的 http 是 http1.0，是基于 TCP/IP 的应用层协议，浏览器的每次请求都需要与服务器建立一个 TCP 连接，服务器完成请求处理后立即断开 TCP 连接，服务器不再跟踪之前的请求。这种方式优点是： 通信开销小，简单快速，传输成本低； 使用灵活，允许传输任意类型或数据格式的对象，传输的类型由 Content-Type 标记 但 http 还有着更明显的缺点，导致使用 http 协议的不安全： 使用明文（不加密）的方式进行传输，内容容易被窃听和获取； 不验证通信方的身份，有可能遭遇伪装； 无法验证明文的完整性，有可能被篡改 正是因为 http 存在着不足的地方，才需要一个更安全的协议来保证数据在传输过程中安全。https=http+加密+认证+完整性保护，https 就是 http 的安全升级版。HTTPS 是运行在 SSL/TLS 之上的 HTTP 协议，SSL/TLS 运行在 TCP 之上。所有传输的内容都经过加密，加密采用对称加密。https 报文中的任何东西都被加密，包括所有报头和荷载。一个攻击者所能知道的只是两者之前有一个连接而已。 2. 运营商劫持 # 在我们通常使用的 http 协议里，信息都是使用明文的方式传输的，那么中间的运营商就有可能在信息上做手脚。运营商劫持主要有三种方式： DNS 劫持：又叫 DNS 重定向攻击，将用户到想到非预期网站的行为，主要是通过修改用户的 DNS 解析结果实现 url 劫持： 302 跳转劫持，将用户 url 重定向到非目标网站 修改 url 参数，比如在 url 里添加流量渠道标识或者页面参数 网页内容篡改 直接在网页中插入 js 在网页中嵌入 iframe 万一在遇到运营商劫持的情况时，有哪些应对方案呢 投诉增值业务部门进而投诉工信部 绕过运营商的 localDNS，使用公共的 DNS 抛弃域名访问方式，直接通过 IP 访问 https：https 只能解决连接劫持，无法解决 DNS 劫持 3. SPDY # SPDY 是 google 开发的基于传输控制协议（TCP）的应用层协议，SPDY 协议旨在通过压缩、多路复用和优先级来缩短网页的加载时间和提高安全性。（SPDY 是 speedy 的昵音，意为更快）SPDY 与 http 的关系：SPDY 协议只在性能上对 http 做了很大的优化，其核心思想是尽量减少连接个数，而对于 http 的语义并没有做太大的修改。具体来说是，SPDY 使用了 HTTP 的方法和页眉，但是删除了一些头并重写了 HTTP 中管理连接和数据转移格式的部分，所以基本上是兼容 HTTP 的。 HTTP 的 GET 和 POST 消息格式保持不变，即现有的所有服务端应用均不用做任何修改。SPDY 协议的优点： 多路复用 请求优化： 在一个连接内可以有多个请求，通过复用在单个 TCP 连接上的多次请求，而非为每个请求单独开放连接 支持服务器推送技术： 服务器可以主动向客户端发起通信向客户端推送数据，这种预加载可以使用户一直保持一个快速的网络。 压缩了 http 头： 舍弃掉了不必要的头信息，经过压缩之后可以节省多余数据传输所带来的等待时间和带宽 强制使用 SSL 传输协议： Web 未来的发展方向必定是安全的网络连接，全部请求 SSL 加密后，信息传输更加安全。 4. 在迁移到 https 的过程中，我们应该做些什么 # 在 https 的页面里，是不能有 http 链接存在的，在 chrome 下依然会请求服务器，但会在控制台给出警告；在 firefox 下直接拒绝请求，可能会知道页面混乱或报错。因此，在 https 的页面里，我们要确保所有的内部链接全部指向 https，确保已经在页面到页面级别制定了新的 https 网址。具体的操作是： 所有的链接指向 https，或者不明确协议，用//开头，则请求资源的协议与页面相同 如果页面中依然还有 http 的链接，可以在头部添加此 meta 头，自动将 http 资源替换成 https 请求： 所有的静态资源（js, css ,img 等）均需上传至 CDN 域名下：img1.gting.com 和 mat1.gtimg.com 我们尽量保证 https 页面里不含有 http 的链接，但是人工检查难免有疏漏的，因此写了一个 js 脚本用来检测页面中 http 连接的数量：(function () { var tags = ["link", "script", "img", "audo", "video", "frame"], // 遍历的资源 host_protocol = window.location.protocol.replace(":", ""), // 当前页面的协议 flag = true; // 是否打开上传 if (host_protocol == "https" && flag) { var a = document.createElement("a"), result = ""; for (var i = 0, len = tags.length; i < len; i++) { var item = document.getElementsByTagName(tags[i]), num = 0; for (var j = 0, t = item.length; j < t; j++) { var c = item[j]; var url = c.getAttribute("href") || c.getAttribute("src") || c.href || c.src; if (url) { a.href = url; var protocol = a.protocol.replace(":", ""); // var protocol = url.substr(0, 5); if (protocol == "http") { num++; } } } num && (result += tags[i] + "=" + num + "|"); } result = result.substring(0, result.length - 1); // console.log( result ); // console.log( encodeURIComponent(result) ); var img = new Image(); img.src = "http://www.qq.com/s.gif?q=" + encodeURIComponent(result); img.onload = img.onerror = function () { img = null; }; } })(); 这个脚本能在页面加载完成后，扫描页面中的资源，检测其链接是否为 http 类型，且只在 https 的页面中，开关打开的情况下才运行，统计各个资源里 http 的个数。不过更详细的信息还不太好获取到，比如：链接为 http 类型的资源在页面中的第几行，ajax 请求的链接等信息。 5. http2 展望 # HTTP/2 主要基于 SPDY 协议，不过还是有区别的， http/2 支持明文 http 传输，而 SPDY 强制使用 https。 HTTP/2 采用二进制格式传输数据，而非 HTTP/1.x 的文本格式。二进制格式在协议的解析和优化扩展上带来更多的优势和可能。http2 特点是： 多路复用：与 SPDY 类似，这样，就省掉了多次建立连接的时间，这个时间对 TLS 尤其明显，因为 TLS 连接费时间 加速 TLS 交付：HTTP/2 只需一次耗时的 TLS 握手，并且通过一个连接上的多路利用实现最佳性能。HTTP/2 还会压缩首部数据 简化 web 应用，适合内容混杂的页面： 用 HTTP/2 可以让 Web 开发者省很多事，因为不用再做那些针对 HTTP/1.x 的优化工作了 更安全： 通过减少 TLS 的性能损失，可以让更多应用使用 TLS，从而让用户信息更安全 那么在未来的 http2 下，我们前端需要做些什么呢？ 减少 http 请求不一定提升性能： 减少 http 请求的前提是资源的合并，导致单个文件的体积变大，根据测试表明，在 http2 的环境下，合并为一个大文件的加载时间反而会比不合并更长 压缩仍然需要：毕竟获取一个小文件的时间比大文件更短，http2 并不会帮你自动压缩文件。HTTP/2 目的之一，就在于想把开发环境与生产环境的部署尽量保持一致，减少因为打包合并而产生一些不必要的麻烦 未来将更专注与页面本身而非性能：http2 从页面加载速度，资源请求，安全性等做很多的工作，让我们更加专注于页面功能上的实现。 如果还有什么不足，欢迎指出批评，谢谢。