易栈网-膘叔

phpED算是老牌PHPIDE了，几年前用过，这几天重拾起来又是一翻风味。
几年前，PHPED最大的垢病就是不支持中文，每次删中文时，都是不见了一半字符，从那时候起我就基本放弃了。

这两天又有人推荐他，于是我重新下载进行安装。说一下简单的用后感吧。

界面啥的也就不提了，反正几乎所有的IDE都那样，有点不同的是PHPED多了一点HTML控件的快速插入，屏幕右侧的快捷工具栏中有一些比较常用的DB连接、SSH连接、MANUAL手册等，这些还是相对比较方便的。

编辑代码时，如果是PHP和HTML混编，两种代码的颜色还是很分明的。

DEBUG的时候还是需要使用它的dbg listener，并且需要在服务器上使用它自己的dbg的组件，并加入PHP.ini，才可以进行调试。
启动速度的话，不能算快，但是ZS比起来，速度还是有明显优势的。
自动提示功能的响应速度可以忍受，对中文的支持没有什么大的问题。
自动模版完成，是按ctrl+J，定义模版变量有点郁闷，因为他的编辑PHP4和PHP5分别用了不同的模版，如果你起初没有选定为PHP5，他就会默认调用PHP4的模版

缺点当然也有：
1、自动提示（自动完成）有时候会突然出不来，必须再重新刷新一下workspace就出来了。妖
2、注释代码没有快捷键，当然可以自定义，但ctrl+/却无法定义，很多IDE里都是使用它为注释的快捷键，上手一下子不习惯了。最后我定义成CTRL+M，但，不习惯
3、所有国外IDE的通病，部分快捷键与切换中文输入有冲突
4、对于project的管理不如其他IDE
5、我个人最不舒服的是，对于使用了rewrite功能做dispatch的框架，无法进行调试，例如ZF，或许是我不会调试吧？

其他情况下的应用基本没什么大问题。函数定义的跳转还是比较准确的，选中函数按F1可以跳到函数说明（手册好象有点老）

网页打开速度到底对用户行为有什么影响，恐怕没几个人能够说清楚吧。以下内容来自博客园独孤一草摘抄的文章，他是摘了其中一段，我也就把他摘抄的部分再次摘抄回来，他的原文地址是：http://www.cnblogs.com/shoudu/archive/2009/03/26/1421928.html

网页打开的最佳速度

2秒！

许多研究都表明，用户最满意的打开网页时间，是在2秒以下。用户能够忍受的最长等待时间的中位数，在6～8秒之间。这就是说，8秒是一个临界值，如果你的网站打开速度在8秒以上，那么很可能，大部分访问者最终都会离你而去。

研究显示，如果等待12秒以后，网页还是没有载入，那么99%以上的用户会关闭这个网页，不再等待。

但是，如果在等待载入期间，网站能够向用户显示反馈消息，比如一个进度条，那么用户可以忍受的时间会延长到38秒。

对访问者的心理影响

根据一些抽样调查，访问者倾向于认为，打开速度较快的网站质量更高，更可信，也更有趣。

相对应地，网页打开速度越慢，访问者的心理挫折感就越强，就会对网站的可信性和质量产生怀疑。在这种情况下，用户会觉得网站的后台可能出现了一些错 误，因为在很长一段时间内，他没有得到任何提示。而且，缓慢的打开速度会让用户忘了下一步要干什么，不得不重新回忆，这会进一步恶化用户的使用体验。

这个指标对电子商务网站尤其重要。载入速度越快，就越容易使访问者变成你的客户，降低客户选择商品后、最后却放弃结账的比例。

不过，网站反应速度也不宜太快，否则用户会增加与服务器互动的频率，这可能加大出现错误的概率。

一些实证结果

Google做过一个试验，显示10条搜索结果的页面载入需要0.4秒，显示30条搜索结果的页面载入需要0.9秒，结果后者使得Google总的流量和收入减少了20%。

Google地图上线的时候，首页大小有100KB，后来下降到70~80KB。结果，流量在第一个星期上升了10%，接下来的3个星期又再上升了25%。

Amazon的统计也显示了相近的结果，首页打开时间每增加100毫秒，网站销售量会减少1%。

宽带与窄带的区别

有研究显示，宽带用户比窄带用户更没有耐心。宽带用户愿意忍受的最长等待时间，往往只有4～6秒。

网站制作者必须记住，在ADSL条件下，3~5秒就能载入的网页，在窄带条件下需要20~30秒才能打开。因此，网页总的大小——包括图片、Javascript和CSS文件的大小——不宜过大，这样对宽带和窄带用户都有利。

前几天的问题仍然在思索，这些网上搜索下来的文章，都将成为我的资料库中的参考资料。

原文：http://www.v-sky.com/blog/?p=215

　　为什么页面出现乱码？为什么数据库里出现乱码？为什么这些乱码的出现几率飘忽不定了？诸如此类的乱码问题困扰了很多WEB开发人员。假如不将这 背后的细节扫扫清楚，那么我们的确不知道什么时候乱码又出现了，如果你确实没有时间关心这些细节，那么你可以直接看文章最后的总结。

　　我们所遇到的乱码多数情况是发生在有中文字符的时候，这是由于计算机各种编码的标准不同而造成的，首先我们有必要了解一下计算机编码的发展 史，ASCII码、GB2312、GBK、GB18030、UNICODE、UTF-8、UTF-16、ISO-8859-1…，简而言之它们都是为了满 足不同时期，不同对象的需求，以自己的一套标准尽可能多地表示所需要的符号信息，如果你需要了解得更深入，可以google一下相关资料。（PS:计算机 领域的很多技术发展都是很有意思的）正是因为有这么多不同标准的编码存在，稍不留神我们就走入了编码“陷阱”，如何避免这些“陷阱”了？

　　一、注意文件编码和字符编码

　　用记事本建立一个新的文件，默认是ASCII码，我们另存为其他编码类型，例如unicode，如果用UtraEdit或者Emeditor编 辑，你会发现编码类型的选择范围更大。试想一下如果在编码A类型的文件中存在了编码B的字符会有什么现象了？多数情况下会出现乱码。例如我们在一个文件编 码为GB2312的网页文件中写入了UTF-8的字符，那么这个网页浏览的时候就出现了乱码，而我们在浏览器中再自己设定一下编码为UTF-8，页面就恢 复正常了。当然也有例外情况，如果这两种编码是扩展关系，其中的部分字符编码是相同的，这个时候当然不会出现乱码了，例如GBK就兼容了BG2312的所 有字符。（PS：这里有个有趣的现象，新建一个记事本，然后输入“联通”两个字，保存再打开，你会发现它变成了乱码。具体原因你可以google一下，简 单说来是记事本错误地识别了字符编码。）

　　第一条原则：保持文件编码和字符编码的一致性。（PS：尤其是在客户端使用编辑器更改文件的编码类型时更要注意，有些编辑器只改变了文件编码，而没有将内部的字符编码同样做转换。）

　　二、 指定网页编码

　　目前，主流浏览器都遵循RFC标准，他们会优先考虑服务端对Header中的content-type属性的设置，无论你是在server层做的全局设置，还是你的服务端脚本临时设置，你都需要清楚地知道网页否指定了你预定的编码。

　　如果服务端对Header没有做处理，那么浏览器会识别Meta信息中的content-type，例如，这个网页的编码就指定了是UTF-8，如果其中存在GB的字符，那么乱码就出现了。

第二条原则：清楚地为网页指定我们预定的编码，最便捷的方式是在服务端指定。

　　三、 留意Form这个数据入口

　　Form的数据提交看起来是一个很简单的过程，事实上在这个背后浏览器给我们做了很多工作：（详细可参考W3C网站上的TR文档）
1． 检测这个Form是否标准，包括name属性是否存在，disabled是否可用等等一系列信息，同时获取到各种表单的当前值
2． 对于一个检测通过的Form，要把它内部的表单元素的值按照他们在文档中的出现顺序，以name/value的形式记录为一组数据集。
3． 根据Form的enctype属性指定的content-type对获取到的一组数据集做URL编码
4． 最后根据action　和method属性来向服务端发送这组数据集

　　这里我们需要特别留意的是第三步，这里做URL编码的数据集本身是什么字符编码了？通常情况下它会遵照网页 本身的编码，这就是为何我在第二原则里建议你要明确指定你选定的网页编码。假如你的网页是GBK编码，那么表单提交到服务端的数据就是GBK的编码，如果 网页是UTF-8，那么提交过去的就是UTF-8的。这里就有一个问题，如果客户端提交的是UTF-8，而我们服务端（包括数据库）都统一使用的是GBK 的编码，那会出现什么问题了？答案是：那会很棘手，服务端不得不对这个UTF-8的数据做编码转换，转换为了GBK才能入库，否则你的数据库里存入的就是 UTF-8的编码，乱码又出现了。

事实上这里还有个例外的情况，在W3C的标准中Form是有一个ACCEPT-CHARSET属性的，目的单独指定FORM中的编码，这个比文档的编 码设置优先级要高。我个人认为开发中用到的可能性不大，一个指定了编码A的文档，为何要发送编码B的字符呢？如果有真有这个需要，那么在服务端做转换就可 以了，没有必要在客户端弄出两种不同的编码，更何况IE这个强硬的家伙又是背离标准的。

A character encoding is a method of converting a sequence of bytes into a sequence of characters.
If ACCEPT-CHARSET is not specified, the form will be submitted in the character encoding specified for the document. If the form includes characters that fall outside the character set specified for the document, Microsoft Internet Explorer will attempt to determine an appropriate character set. If an appropriate character set cannot be determined, then the characters will be encoded as HTML numeric character references. For more information on character sets and numerical character references, see HTML Character Sets. （参考：MSNDhttp://msdn2.microsoft.com/en-us/library/ms533061.aspx）

　　因此，我们还是“忘记”这个属性吧，没有它，我们的FORM一样可以运转得很好。（也正是因为浏览器默认会给FORM做很多不错的工作，所以我们看到的很多富文本编辑器在提交编辑内容时，都会先把这个内容写入到一个表单的value中，让浏览器自动给它编码。）

　　第三个原则：清楚地认识Form中的数据的编码是依照网页本身编码的，在提交到服务端之前，这组数据是做了格式化处理，然后做了URL编码。目前服务端不会智能到自动识别FORM发送过来的编码类型，更不会智能到给你自动转换为服务端统一使用的编码。

　　四、 特别留意AJAX这个数据入口

　　AJAX的流行让XMLHTTPRequest这个“数据入口”使用更频繁了，但遗憾的是XMLHTTPRequest对象本身没有像浏览器对 Form的处理那么勤劳，同时它的无刷新特性让我们可以动态将服务端返回给我们的数据显示在当前已经被渲染过的页面内，相对于FORM这个数据入 口，XMLHTTPRequest还存在一个“数据出口”的问题，因此这里的乱码现象更加频繁。
1、“数据入口”
一般情况下，XMLHTTPRequest发送的数据来源有两种：页面源码和XMLHTTPRequest所在的Javascript的文件源码。为何会将它们分开了？这里我们来假设几种不同情况：

　•　JS获取用户在表单元素中的输入数据，然后设置XMLHTTPRequest

　　　　在上文中已经提到了Form表单中数据的编码问题，用户输入的字符编码是和网页编码一致的，因此这里JS获取的数据编码和网页编码是一致的。

　　•　JS源码中预设的数据

　　　　某些情况下，我们会将一些预定参数在程序中写死（这里就不要讨论程序扩展性了），那么这种情况的编码就得取决于文件编辑时编辑器输出字符 的编码了。这就是我们的一个准则中建议的，你需要保持文件编码和字符编码的统一。JS本身是基于UNICODE编码的，所以这是我推荐文件用UTF-8编 码的理由之一。

　　　　现在我们已经知道了XMLHTTPRequest发送的数据的编码，接着我们来看发送数据会出现什么问题。
XMLHTTPRequest不同于表单数据的发送，它不会给我们的数据做序列化，不会自动给我们做URL编码，也不能在客户端指定发送的编码类 型。（PS:虽然setRequestHeader方法可以设置发送请求Header中的charset，不过我经过测试和对Header信息的监视，发 现这个设置从Header中看是有效的，但服务端接收到的数据始终是UTF-8的，查了些资料没有找到原因在哪儿，暂且认为XMLHTTPRequest 只能以UTF-8格式发送数据吧。但值得“庆幸”的是无论客户端的网页是什么编码，这里发送的UTF-8编码的数据都是正确转换过的，否则让我们自己在客 户端写转换功能那就相当棘手了）为了保证数据send到服务端不出问题，我们只有自己动手做XMLHTTPRequest没有给我们完成的工作了。
•　指定请求Header中的content-type

　　•　将序列化的数据进行URL编码
这里可以使用encodeURI和encodeURIComponent　
这样以来，那么服务端就可以正确接收到我们POST过去的数据集了，这里需要注意，服务端得到的数据集是UTF-8格式的，是否做编码转换，那就是视你具体情况而定了。

　　2、“数据出口”
无论XMLHTTPRequest　GET的是一个静态页面，还是一个动态页面，XMLHTTPRequest都不关心，它只关心 responseText得到数据的编码，默认的编码是UTF-8，而这个编码是可以通过服务端直接设置的，这个在上文的指定网页编码中已经提到了。
因此当你需要在页面显示responseText的内容时，你需要很清楚地知道页面的编码和responseText的编码，如果他们不统一，那乱码的麻烦就有出来了，不过现在你知道问题在哪儿了。

　　第四个原则：在使用AJAX时，尤其要注意数据流动中造成的编码类型改变。AJAX发送的是UTF-8编码，接收的编码默认是UTF-8，但允许服务端重新指定。

　　总结：避免乱码的最简洁方法就是系统中所有文本文件都统一使用最通用的编码，（目前在WEB应用上当然是 UTF-8了）并在页面中指定charset，同时在服务端设置header中的charset，防止客户端浏览器的设置造成编码不一致。但如果你目前的 系统已经存在了编码不统一情况，那么你就需要根据具体情况找到做编码转换代价最小的地方，或许上面的分析能帮你解决问题。

　　以上分析我的测试环境是IE6 、IE7、Firefox，有兴趣的话也可以动手测测，欢迎交流，如果有什么不当之处希望指出。

前两天刚说为之漫笔进行了翻译《flex3实战》，今天就把试读章节放出来了。而且说“ 对反映问题最多的前3位读者，译者将于本书出版后第一时间，赠送新书一册，以为答谢。”

兄弟们加油啊。。

样章下载

• 第1章 认识Flex（PDF,1391KB）
• 第4章 布局和容器（PDF,919KB）
• 第8章 DateGrid、列表和树（PDF,793KB）
• 第11章 应用程序导航（PDF,1033KB）
• 第20章 使用效果（PDF,746KB）
• 目录（简明）
• 目录（详细）

样章下载完后，别忘了去http://www.cn-cuckoo.com/提交BUG呀

本来不想转这个的，因为原文好象不全，但我试着将原文最后一句去掉，好象也能读的通，就先转上来看看了。。。

原文：http://netsecurity.51cto.com/art/200902/112190.htm

IE有一个特性，那就是在将一个文件展示给用户之前会首先检查文件的类型，这乍看起来并没什么问题，但实际上这是相当危险的，因为这会允许IE执行 图片中的代码，即嵌入在一个图像中的JavaScript代码。引入MIME sniffing功能的初衷是用来弥补Web服务器响应一个图像请求时有可能返回错误的内容类型信息这一缺陷。

但是事不遂人愿，心怀不轨的人可以轻易滥用这一特性，如通过精心制作一个图像文件，并在其中嵌入可以被浏览器所展示和执行的HTML和JavaScript代码。本文将深入考察该问题，并为用户和网站开发人员介绍如何降低此问题带来的风险。

一、危险的MIME sniffing功能

对于Web 2.0应用程序来说，允许用户上载图像是一项基本的要求。但是，IE用户面对这些图片时却要小心了，因为IE的某些功能会为利用图片进行跨站点脚本攻击大开方便之门。

虽然许多大型站点都设法保护其访问者免受可能的JavaScript攻击，例如实现专门用于防御活动内容的过滤器等，但是他们却无法跟活动内容一刀 两断，因为对于个人简介、博客和论坛来说，JavaScript、HTML 代码和Flash小应用程序是不可或缺的活动内容。

此外，大部分交互型站点都允许用户上载和链接他们的图片，但是攻击者却可以利用此功能来颠覆IE为保证兼容性和提供额外的安全性而引入的某些功能。 攻击者只需在图像的开头部分嵌入一些HTML代码和JavaScript，那么当IE打开这个做过手脚的图像时，浏览器所做的不是显示图像，而是检测并运 行图像中嵌入的代码。

之所以出现这种情况，是因为浏览器可以用来确定文件类型的方式多种多样，例如文件扩展名jpg可以指出一个图像为JPEG格式，此外Web服务器还 可以在HTTP报头中定义Content-Type（在本例中为image/jpg），但是一般说来使用上载的文件的文件名扩展部分来指出文件的类型。

最后，大多数 Web 浏览器还会检查一个文件的开始几个字节（即通常所说的文件的“签名”），这几个字节通常为一些众所周知的字节序列，例如PNG、PK、JPEG、JFIF等等。

迄今为止，我们介绍了浏览器可以确定文件内容类型的三种方法，即通过文件本身的扩展名或文件开头部分的签名，或通过服务器响应报头Content-Type来确定文件类型。

不过，后来IE4引入了第四种方法，即通常所说的MIME sniffing或者MIME类型检测方法。所以，现在的IE版本都不自动地假定来自web的文件的内容类型就是服务器在HTTP报头中的所声明的内容类 型。IE浏览器既不信任文件名扩展部分，也不信任签名，相反，它是通过检查文件开头的256字节内容来确定文件的类型。

然而，只有当用户直接调用URL下载文件时IE才这样做。当使用IE打开HTML中的图像标签(IMG)所连接的本地存储的文件或者图像的时候，则不会进行嗅探。

IE引入MIME sniffing功能的初衷是用来提防服务器给出的错误内容类型指示的，但是攻击者却利用它来规避IE中的安全防御功能，即防止浏览器自动地执行所下载的文件（如hta文件）的那些功能。

此外，MIME sniffing还使得浏览器能够容忍在Content-Type声明中的偶然性错误，例如，如果服务器声明某文件类型为text/plain文件，然而实际提供的却是一个HTML文件，那么IE将它作为HTML处理。

对于常见的GIF、JPEG和PNG格式，只要文件扩展名、Content-Type和签名所指的类型相一致，那么浏览器就会对MIME sniffing所得到的结果置之不理。只有当文件扩展名、Content-Type和签名所指的类型有出入时，IE才会以MIME sniffing所确定的结果为准。

二、倒打一耙的MIME sniffing功能

现在，如何保护用户免受恶意服务器的侵害与如何为不正确地配置服务器的管理员提供有效帮助已经成为Web 2.0所面临的一大问题。 如果文件的扩展名、Content-Type和签名相抵触，那么浏览器会以内容为准。

所以，如果一幅图片的开头部分为一些HTML代码的话，虽然乍一看好像是无害的，但是实际上却可能相当危险，因为IE会执行图片中的代码。这为攻击 者把JavaScript嵌入图像提高了一个机会，所以他们可以利用这种方式执行跨站点脚本攻击，使用精心制作的图像来窃取受害者在当前访问的服务器上的 身份验证cookie，然后以受害者的身份登录到那个服务器。

三、援兵未至

微软公司已经认识到这个问题，并计划IE的新版本中加以修复。IE8不再探测图像，因此，它会忽略嵌入的HTML。此外，对于特定的下载，还可以通 过为私有的Content-Type以及authoritative指定值来关掉MIME sniffing功能，例如content-type=text/html; authoritative=true;。然后，IE会把文件当作服务器指出的类型来处理。

关键情况下，可以使用新的“X-Download-Options: noopen”头部来确保在站点上下文的外部显示相应的文件，这意味着即使HTML文件也能够安全的投递，因为浏览器只是将文件保存起来而已。遗憾的 是，IE8要想全面替代其他版本的IE尚需时日，在此之前，Web站点对此还是指望不上的。

四、急救措施

实际上，如今想要抵挡这些精心制作的文件也并非难事。自Windows XP SP2以来，用户已能禁用IE中的MIME sniffing功能，方法是打开浏览器的“工具”菜单中选择“Internet 选项”，点击“安全”选项卡，在“请为不同的区域的Web内容指定安全设置（z）”下面选择“Internet”图标，在“该区域的安全级别（L）”下面 点击“自定义级别”按钮，最后启用“基于内容打开文件，而不是文件扩展名”选项即可。然而，这样做会重新开放一些以前的古老漏洞！

这是否能够提供安全性只能够靠实践来证明。我们的重点不应该放在在用户间推广这个技巧，而是应该设法让web服务应用提供安全保障措施来保护访问者，并确保Web服务提供方的系统不向用户传送精心制作的图像。

管理员可以使用脚本检查上传到其服务器中的文件的类型的一致性。举例来说，如果某图像的文件名扩展部分为.jpg，并且文件起始字节部分的签名也指 出是相同的类型（在Linux下可以使用file image.jpg命令，而在PHP中可以使用getimagesize加以印证），经过上述验证后，服务器才能发出该文件。

这样，即使文件包含HTML 代码，IE也不会执行这些代码。然而要注意的是，通过这种方式只能保护图像的安全，同时服务器声明的Content-Type必须完全正确才行。 这个方法对其它格式均不起作用。

然而，要想达到绝对的可靠性，需要检查文件的前256字节是否HTML 代码