易栈网-膘叔

风雪之隅的网站上大多是对PHP的底层进行关注的文章，如果对PHP的核心内容有兴趣不妨多翻阅一下他的网站。

本文的标题，其实是一个老问题了。
大家都知道，PHP对于没有引号的字符串，会当成常量来处理，如果该常量不存在，则直接输出该字符串。也就是多做了几步处理。
事实上，上面的这个知识点，很早就知道，但，不是我自己研究出来的。虽然自己写过代码进行测试过。

雪候鸟则直接从OPCODE上进行查看，给你一个直观印象。好，我们来看看原文吧
地址：http://www.laruence.com/2009/04/24/695.html
内容：
我看到过很多人操作数组的时候, 对于数组中的非数字键名不使用引号,

我可以理解有些人可能会觉得这样的代码很”整洁”, 并且也能正常执行.
更甚至,如果他很”幸运的”php配置的好:

他也许永远都沉浸在自己的”整洁”风格中, 看不到任何的NOTICE提示, 也不会意识到, 他这么做, 能损失多少的性能~

来, 我们一起来看看:

分别看运行时间(多次平均时间):
加引号的:

不加引号的：

看看,差别有多大?
哦, 或许我们应该模拟一下那些”幸运的”人们的情况, 去掉花费在记录NOTICE的开销, 看看~

我们可以看出, 基本上, 使用引号,和不使用引号的效率损失在3倍以上

那么, 这些效率损失到哪里去了呢?

我们分别看下, 俩个文件生成的OPCODE序列:

good.php :

bad.php :

我们可以看出(其实,根据NOTICE的提示也知道), PHP会把没有引号引起来的键名当作是常量去获取, 当找不到的时候, 抛出一个NOTICE, 然后再根据”常量明”生成一个字符串, 然后再讲这个字符串做为键名继续~

聪明的你一定会想到, 可能会出现如下不可预期的错误:

明白了么? 数组中的非数字键的键名一定要有引号啊~
哦, 还记得有人会说, 那在字符串变量替换的时候, 写引号会导致错误,
恩, 标准写法:

我很赞同:”be lazy”, 但是, lazy也是应该有原则的.

最后, 好的代码,不应该通过关闭error_reporting来伪装.

附注, FETCH_CONSTANT OPCODE中找不到常量的相关逻辑:

 

 

——EOF——

膘叔最受不了的，就是discuz，特别是模版中的变量，全部是不含单引号的。写起来是方便啊。但是性能不敢恭维。所以common.inc.php的前面几句就是error_reporting了。。隐藏掉，看你怎么办，有本事你咬我呀。。

我还能怎么办？

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

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