基于无线端的图片压缩上传

引言 无线端开发和PC端开发 ,很大的不同 ,在于要考虑用户的网速以及流量开销 。上传图片作为很普通的需求 ,在很多地方都用的到 ,但是在无线端,有很多不同之处 。 IOS不支持flash,使得无法使用成熟的桌面端的上传组件 ,比如基于flash的swfupload 图片上传需要压缩–基于流量原因 无线端可以不考虑低版本的IE浏览器 ,但是存在更多的兼容问题,更为细节。 需求设定 上传前可预览 上传时 ,如果图片体积太大,则进行压缩 准备工作 一个简单的html html里包含一个文本域  ,id 为 file 读取文件,完成预览 html5 提供了File API 和FileReader API ,允许js读取图片信息 这里有一个兼容性修正 ,某些低版本的android浏览器中 ,读出来的base64缺少字节 。 结果如下 对图片进行压缩 压缩的方法是 ,讲图片用drawImage的方法写入canvas,然后再通过toDataURL 读出来   对于移动端浏览器来说 ,toDataURL只能返回png图片数据 ,jpg是不被支持的 w和h  ,是压缩后的大小 ,在不同的需求里,可以重写这部分  ,达到压缩不变形的目的  。 ajax上传图片 使用base64上传图片 或者使用binary上传 ,但是由于移动端对formData的支持度不好 ,所以只能通过流上传 本次使用base64上传 上传后 ,处理上传图片。

移动端的开发与桌面端web开发 ,谁更苦逼  。

最近几年 ,移动端开发成了热门,我也随大流 ,搞了几次移动端的web前端 。 这段时间的经历,给我的感悟是 ,现在的移动端开发 ,对于web前端来说,是最好的时代,也是最坏的时代 。 刚开始做移动端开发的时候 ,觉得真的很开心 ,终于再也不用为IE678不支持这个不支持那个发愁了,CSS3动画什么的,都可以high起来了。结果没做几天 ,发现移动端的坑真心不少啊 。 第一个遇到的,就是android 2.3问题 。 android2.3自带的浏览器,不支持overflow:scroll  ,也就是说不支持div的滚动条  。这是坑爹呢。这种东西都不支持   。 然后,各种不好的东西出现了 。 首先是 ,手机上的web网页的应用场景远比桌面浏览器复杂  。大量的APP,读取网页webview,而且都有自己的特立独行的那一面 。 更糟的是  ,手机浏览器基于系统的内核 ,但是种类太多,桌面也就是360浏览器 ,搜狗浏览器什么的,除了360浏览器其他用的都少 ,但是手机上 ,浏览器种类更多,UC,QQ ,百度  。。太多了  。 然后,系统版本也特别多 ,从android2.3-android 4.4 ,从IOS4-IOS7 ,每种浏览器的特性也不同  。 这真是最好的时代 ,也是最坏的时代。  

一个有趣的问题{}+[]与[]+{}

群里的KB提出了一个很有趣的问题。 说出{}+[]和[]+{}的结果是什么 ,并为什么。 其实关于+运算符是怎么工作的 ,已经引发了挺多次的讨论。 无怪乎  : a+b的话 如果a和b都是数值 ,那么就把他们的数值相加  ,比如1+2=3 如果a和b都是字符串 ,那么 ,就把他们连接起来 ,比如”1″+”2″=”12″ 如果一个是数值一个是字符串 ,则把其中一个转化为字符串,然后连接 比如1+”2″=”12″ 如果以上情况都不属于 ,比如问题总的[]+{},那么就对双方都执行ToPrimitive操作,并把结果按照数值方式或字符串方式+操作 那么,[]+{}的结果就很容易理解了 ,[]的ToPrimitive获取默认值 ,实际是toString,变为空字符串””,{}的toString ,是”[object Object]” 他们的结果合并 ,就是”[object Object]” 按照这个理解,那么{}+[]的结果其实应该和[]+{}的结果是一样的 ,但是为什么{}+[]的结果是0呢? 其实在javasript解释代码文本的时候 ,字符{}有两种解释方式 ,一种是我们常认为的对象   ,例如{a:1},另一种是代码块例如  function a(){} 但是如果{字符出现在一段的开头,那么,肯定被当作代码块执行的  。 所以{}+[]的{}被当作代码块处理 ,没有了结果 ,最后就是+[]了  ,空数组被转化为数值,就是0了 真是一个有趣的问题!  

innerHTML=”" ,removeChild哪个快?

接上次的测试,在清空一个DOM元素时会发生什么 我的浏览器环境是Chrome 23,Firefox 17,IE9 我的作法 ,在body中创建1000个p标签 for(var i=0;i

innerHTML和appendChild ,哪个快?

以前在群里曾经和天牛讨论过一次innerHTML和appendChild谁更快的事情,当时也做过一次测试 ,结果就是  ,在IE 下,innerHTML比appendChild快 ,firefox和chrome ,safari下,appendChild比innerHTML要快。 当时的代码,是这样的  。 向body中插入1000个li, var str=”"; for(var i=0;i<1000;i++){ str+=”<li></li>”} document.body.innerHTML=str; appendChild for(var i=0;i<1000;i++){ var li=document.createElement(“li”); document.body.appendChild(li); } 不过已经过了2年了 ,现在的浏览器 ,也不是当年的浏览器了,字符串相加也比数组join来的快了,所以我一直有个想法 ,测试一下现代浏览器 。 我的浏览器环境是Chrome 23,Firefox 17,IE9 我的作法,在body中创建1000个p标签 for(var i=0;i

阻止designmode为on的iframe中图片被resize

我有个编辑器,用iframe做的 ,这个iframe的designmode为on  ,但是我不希望图片被改变大小 。 对于webkit浏览器 ,图片本身就无法被改变大小,所以 ,不用解决 firefox ,有个特殊的command—-enableObjectResizing ,于是 if(H.browser.getBrowser()==”ff”){ _.iDoc.execCommand(‘enableObjectResizing’, false, ‘false’); } 对于IE,就比较复杂,IE有一个onresizestart事件 ,可以通过 img.onresizestart=function(){ return false; } 来解决,但是这个有个问题 ,就是图片依然可以被选中。看着那几个方块 ,那叫一个难受  。想了很久 ,想到个办法 ,就是禁止图片被选中不就好了  , OK   img.onmousedown=function(){ window.event.returnValue=false; return false; }   于是 ,完美解决!

绝对定位子元素  ,是否决定父元素的scrollWidth?

今天遇到一个问题,发现浏览器 ,解释不一致 。于是讲测试结果记录下来 <div style=”width:30px; height:30px; position:relative” id=”outer”> <div style=”position:absolute; width:30px; height:30px; left:20px; top:20px;”></div> </div> <script> console.log(document.getElementById(“outer”).scrollWidth); </script>   chrome 16.0    结果是50 firefox 10.0     结果30 IE 9.0                结果50 IE 8.0                结果50 IE 7.0               ...Read More

常用的easing算法

var obj = { Linear: function(t,b,c,d){ return c*t/d + b; },    //线性 Quad: {                                                                                //二次方缓动 easeIn: function(t,b,c,d){ return c*(t/=d)*t + b; }, easeOut: function(t,b,c,d){ return -c *(t/=d)*(t-2) + b; }, easeInOut: function(t,b,c,d){ if ((t/=d/2) < 1) return c/2*t*t + b; return -c/2 * ((–t)*(t-2) - 1) + b; ...Read More

和蝈蝈龙的跨域讨论

蝈蝈笼和我讨论ajax跨域问题  ,首先是关于用document.domain做子域名的跨域 通过www.a.com向abc.a.com发送请求 ,然后神奇的事发生了 ,在firebug中,提示该次请求状态是200 ,但是实际上 ,status是0 ,这好像是firebug的一个bug吧 。 发现设置document.domain=”a.com”,需要一个iframe作为代理来发送ajax ,大不爽!选其他的 。 蝈总作为一名PHP人士,喜欢JSONP ,最后解决了问题,但是我更喜欢用flash做代理。 JSONP的优点:原生JS , 缺点 ,需要服务器端写特别的接口 FLASH的优点:一次设置,所以的连接都有用  缺点:需要一个控件,虽然基本每个浏览器都有 好吧 ,热烈的讨论持续了很久 ,最后我败了 。。。。

在AJAX中容易忽略的问题

1.替换掉textarea中的换行 2.每次提交  ,都要encodeURIComponent