易栈网-膘叔

本内容来自群聊天记录，开花石头吐出来的。。。

取字段注释

参考http://dev.mysql.com/doc/refman/5.1/zh/ 今天找到了取mysql表和字段注释的语句

下午上班，收到一条短信，一看，哇，189发来的，天翼用户啊。

激动不己的打开短信，发现内容为：上海XXXX大酒店现诚聘男女公关，需体健貌端思想开放，18至48岁，月薪三万，当天结算，咨询XXXXX李经理。

第一个XXXX是酒店名称，第二个XXXX是联系电话

一下子心情都没有了。唉。原来189的优惠已经被沦为干这种活的工具了。

突然间对189失去了热情。

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，有兴趣的话也可以动手测测，欢迎交流，如果有什么不当之处希望指出。