易栈网-膘叔

count_chars表面上是計算char出現的次數，但事實上對中文支持明顯是不好的。
所以，它還有另外一個作用，即count_chars($str,4);
看好第二個參數哦。當這個參數是4時，會返回所有的会用作计算的字符串：

嗯，因此这也算是一个小技巧啦。

关于使用GUID和INT做主键，性能差异的文章历来很多，不过。大多都是从理论上来说明，这次难得看到某人用PC机做测试，所以贴上来看看。但我不贴全文，毕竟。。。大量的代码贴上来，也没有太大的意义 。所以仅贴上主体内容和测试结果，当然还会有一些用户的评论。。

原文网址为：http://www.cnblogs.com/jackhuclan/archive/2010/01/04/1639005.html
内容大致如下，【如想看全文，请使用上面的链接】
在数据库的设计中我们常常用Guid或int来做主键，根据所学的知识一直感觉int做主键效率要高，但没有做仔细的测试无法说明道理。碰巧今天在数据库的优化过程中，遇到此问题，于是做了一下测试。

测试环境：

　　台式电脑 Pentiun(R) 4 Cpu 3.06GHz
Win XP professional
1.5G DDR RAM
SQL Server 2005 个人版 

测试过程：
首先创建测试数据库Test
1.创建Test_Guid表，创建Test_Int表
2.创建Test_Guid子表：Test_Guid_Detail和创建Test_Int子表：Test_Int_Detail，用来做连接查询
3、然后进行一些CRUD的操作【这是我写的，因为原文中写插入N行数据，删除N行数据之类的太复杂，也太多，简化为一句话了】

测试结果如下：

综上所述，使用int做主键比用guid做主键各中情况下效率均有提高，特别是在有连接查询和删除记录效率提升明显。

而且本人今日在guid做主键的数据查询中因为嵌套几个子查询结果屡屡出现查询超时。因此本人赞同用int做主键，不赞同guid做主键。
以上观点代表个人观点，欢迎大家各抒己见，说明guid和int各自做主键的优劣所在。

----EOF---

本来到这里就可以结束了，但有一个用户的评论还算不错：

更多的人认为GUID在做数据迁移的时候很方便，而如果使用INT则会有意料不到的问题。而GUID遇到的问题会少很多。。。

相对于以上的观点我还是比较认同的，但我认为性能相差这么大是有可能有以下的原因：
1、作者用的是PC机
2、操作系统是XP
3、sql server 是个人版【我没有试用服务器版性能如何，但我想，一定比个人版性能更优，当然这是猜测】

说归说，对于MYSQL来说，基本上还是只能使用INT做主键。毕竟MYSQL没有自带的生成GUID的方法【我不是指手动生成，我是说自动生成。。。UUID()函数是可以生成GUID的，但不能象INT那样自动插入，也没有办法设置default为UUID()方法】

这是cssrain站长翻译的一篇文章，事实上，在PHP中，已经不太建议使用switch-case了。
特别是在面向OO的代码中，你几乎也看不到这样的代码出现

不是说这个方式不好。而是，它的可扩展性不强。所以在大多数情况下，都放弃采用这种方式。

以下是翻译内容，来源于：http://www.cssrain.cn/article.asp?id=1384：

我很年轻，还没有做过很长的编程。所以我对使用switch-case 语法没有什么很深刻的印象，至少在我的记忆中是这样。或许你认为这是一件坏事情。你甚至会怀疑我为什么不使用它们。我真的不知道为什么，似乎我天生就不喜欢使用它，如下所示：

显然，虚构此代码的作者不够了解使用其他JavaScript方法来构建此功能。其实有很多种方式更适合这种情况，而不是一个丑陋的switch. 有许多许多更轻松，更优雅的方式来实现这种功能。
switch-case组合肯定是非常有用的，当你有一个变量并且依靠它的值的不同来做不同的事情。使用多个if-else不太恰当，所以人们通常使用switch-case来代替多个if-else.我敢肯定你也是.
上面的例子依赖于 something 判断 ，然后根据条件运行doX ， doY或doN 。在JavaScript中，同样的逻辑可以表示一个简单的查找表的形式————对象，如下所示：

这不仅简洁，而且也可以重复使用和修改条件。所有条件都是对象的一部分，因此，如果您需要改变某些条件那就非常简单了。

所以，我想说的是：请不要使用switch-case，除非绝对必要的。 为什么？ 因为有更好的替代品，比它更简单！

关于“ switch-case”的语法，请浏览：http://en.wikipedia.org/wiki/Switch_statement

如果想阅读原文，请点击这里：http://james.padolsey.com/javascript/how-to-avoid-switch-case-syndrome/
提示:译文跟原文有出入，请看原文。

其实，开心网，我也就上去一段时间就不怎么玩了，主要还是我老婆在玩。
不习惯那种氛围吧？不过自己也会偶尔上去做做投票啥的，里面的停车位、买奴隶、咬人、种田啥的确实没有什么好玩的。

买房？纯粹是YY嘛。现实中买不起房只能去网上自己安慰一下自己？打工？王老吉分店总经理又怎么样？还是在YY。种田吧，还要担心被偷，停车吧还要被贴牌。车也买不起。所以。。。对这类YY型游戏，我是兴趣不大的。

当然做做投票，还是有点乐趣的，SNS嘛。传说中的六格理论（名字可能记错）？每6个人你就会认识一个人。找找朋友也还是有机会的。

下面贴上某位朋友的文章，里面介绍的两篇原文写的不错，挺长。我也全部看完了。作者截出来的这段很有意思。。。

原文：http://shiningray.cn/tou-cai.html

今天读到两篇文章，《这么开心》与和菜头的《韩流来袭》。这两篇应该合起来看。

前一篇文章作者分析了kaixin001的花园组件的设定，这种设定是完全鼓励偷窃而非劳作的——相比之下，开心农场的设定就要更有“道德”一些，开心农场中任何植物不能被完全偷光。

和菜头则通过韩国奇怪的搜索引擎（各家独立的庞大门户，和局限于自己的引擎），说出了这种模式的问题：

中国人有着悠久的传统，每天在书包里带一块砖，用饭盒打一盒单位的水泥回家，经过数月之功，修建一个自己家的小厨房。对于 分享和探索，中国人没有多少兴趣。但是，对于像个搬仓鼠一样把外面的资源弄回自己的小家，却人人都有浓厚的兴趣。开心网上最火热的两款游戏是争车位和偷 菜，可以从一个侧面印证这一点。

对于这种分享上的文化差异，我希望只是设计师的设定问题。

原文地址：http://www.phpv.net/html/1639.html，作者：手气不错

未删节版本

开门见山，考虑下面的代码（原文连接有详细的解释）

看似准确无误的代码，但是暗藏着危险。让我们将其保存为 foo.php ，然后放到 PHP 环境中使用

foo.php/%22%3E%3Cscript%3Ealert('xss')%3C/script%3E%3Cfoo

访问，会发现弹出个 Javascript 的 alert -- 这很明显又是个 XSS 的注入漏洞。究其原因，发现是在

echo $_SERVER['PHP_SELF'];

这条语句上直接输出了未过滤的值。追根数源，我们看下 PHP 手册的描述

'PHP_SELF'

The filename of the currently executing script, relative to the document root. 
For instance, $_SERVER['PHP_SELF'] in a script at the address 
http://example.com/test.php/foo.bar would be /test.php/foo.bar. The __FILE__ 
constant contains the full path and filename of the current (i.e. included) file.
If PHP is running as a command-line processor this variable contains the script 
name since PHP 4.3.0. Previously it was not available.

原因很明确了，原来是 $_SERVER['PHP_SELF'] 虽然“看起来”是服务器提供的环境变量，但这的确和 $_POST 与 $_GET 一样，是可以被用户更改的。

其它类似的变量有很多，比如 $_COOKIE 等（如果用户想“把玩”他们的 cookie，那我们也是没有办法）。解决方案很简单，使用 strip_tags、htmlentities 等此类函数过滤或者转义。

echo htmlentities($_SERVER['PHP_SELF']);

-- Split --

上述的例子让我们需要时刻保持谨慎 coding 的心态。Chris Shiflett 在他的 Blog 总结的相当直白，防止 XSS 的两个基本的安全思想就是

Filter input
Escape output

我将上面翻译成 “过滤输入，转义输出”。详细的内容，可以参考他 Blog 的这篇文章，此处略。