养生：肉类的这几个部位千万不能吃
2012年1月11日 11:12 | by gaoolp ]
1、正则表达式的介绍和作用
什么是正则表达式？
在编写处理字符串的程序或网页时，经常会有查找符合某些复杂规则的字符串
的需要。正则表达式就是用于描述这些规则的语法。
例：在判断用户邮件地址格式、手机号码格式或者采集别人网页内容时
主要的作用是：分割、匹配、查找、替换
注：正则表达式对于一个程序员来讲是至关重要的一个知识点，所以学好正则
是每一个程序员必须具备的。不仅可以帮助我们完成一些通过函数无法实现
的工作，还可以帮助我们减轻很多工作量。
2、PHP中两个常用的正则函数
preg_match 正则函数，以perl语言为基础
preg_match ( mode, string subject , array matches )
ereg 正则函数，以POSIX基础 （Unix 、 Script）
ereg ( mode, string subject , array regs )
3、正则表达式中包括的元素
(1)、原子（普通字符：a-z A-Z 0-9 、原子表、 转义字符）
(2)、元字符 （有特殊功能的字符）
(3)、模式修正符 （系统内置部分字符 i 、m、S、U…）
4、正则表达式中的“原子”
①a-z A-Z _ 0-9 //最常见的字符
②(abc) (skd) //用圆括号包含起来的单元符合
③[abcs] [^abd] //用方括号包含的原子表，原子表中的^代表排除或相反内容
④转义字符
\d 包含所有数字[0-9]
\D 除所有数字外[^0-9]
\w 包含所有英文字符[a-zA-Z_0-9]
\W 除所有英文字符外[^a-zA-Z_0-9]
\s 包含空白区域如回车、换行、分页等 [\f\n\r]
……
5、正则表达式元字符
* 匹配前一个内容的0次1次或多次
. 匹配内容的0次1次或多次，但不包含回车换行
+ 匹配前一个内容的1次或多次
？匹配前一个内容的0次或1次
| 选择匹配类似PHP中的| （因为这个运算符合是弱类型导致前面最为整体匹配）
^ 匹配字符串首部内容
$ 匹配字符串尾部内容
\b 匹配单词边界，边界可以是空格或者特殊符合
\B 匹配除带单词边界意外内容
{m} 匹配前一个内容的重复次数为M次
{m,} 匹配前一个内容的重复次数大于等于M次
{m,n} 匹配前一个内容的重复次数M次到N次
( ) 合并整体匹配，并放入内存，可使用\1 \2…依次获取
6、模式修正符
模式修正符是为正则表达式增强和补充的一个功能，使用在正则之外
常用修正符
i 正则内容在匹配时候不区分大小写（默认是区分的）
m 在匹配首内容或者尾内容时候采用多行识别匹配
S 将转义回车取消是为单行匹配如. 匹配的时候
x 忽略正则中的空白
A 强制从头开始匹配
D 强制$匹配尾部无任何内容 \n
U 禁止贪婪匹配 只跟踪到最近的一个匹配符并结束，
常用在采集程序上的正则表达式
7、匹配功能
preg_match_all 全部匹配函数
preg_match_all ( string pattern, string subject, array matches [, int flags] )
对结果排序使 $matches[0] 为全部模式匹配的数组
用途：截取比较详细的内容，采集网页，分析文本
8、替换功能
preg_replace 正则替换函数
preg_replace ( mixed pattern, mixed replacement, mixed subject [, int limit] )
通过正则表达式来替换相关内容，类似之前学过的str_replace字符串替换，但
功能要强于它。
提示：1、替换内容可以是一个正则也可以是数组正则
2、替换内容可以通过修正符e来解决替换执行内容
用途：替换一些比较复杂的内容上，也可以用于内容的转换上
9、分割功能
preg_split ( string pattern, string subject [, int limit [, int flags]] )
preg_split 正则切割
通过正则表达式来切割相关内容，类似之前学过的explode切割函数，但explode
只能按照一种方式切割有局限性。
PHP &&及||的非正常用法
2011年3月2日 12:50 | by gaoolp ]
&&及||的非正常用法
$a && $b=10;
当$a为真是才执行$b=10;
$a || $b=10;
当$a为假是才执行$b=10;
26个英文字母的爱情定义
2011年1月31日 18:37 | by gaoolp ]
“世上没有十全十美的人”。记着，你爱他，就必须接受他的一切，甚至他的缺点
Ｂ--belief（信任）
不信任对方，经常以怀疑的口吻盘问对方，这种互相猜度的爱情就只有分手下场
Ｃ--care（关心）
关心的程度正好表现你对她的重视程度
Ｄ--digest（理解）
我们不是圣人，
总有情绪起伏的时候，
若对方是“凸”的时候，
你何不做“凹”去忍耐一下她，安慰一下她
Ｅ--enjoy（欣赏）
你应欣赏对方的一切，欣赏这段爱情带给你的开心、幸福。
Ｆ--freedom（自由）
纵然已婚，也应给予对方应有自由及保持秘密的权利。
Ｇ--give（付出）
爱情这样东西不一定是你付出“一”，便会收回“一”。
但不付出，便一定没有收获。
对你的爱人，应有如对自己一样，毫无保留地付出，这才算得上真爱
Ｈ--heart（心）
爱情最重要的道具是心，
你必须真心对待，用心去爱。
没有心，又怎称得上真心相爱？
Ｉ--independence（独立）
甜言蜜语的人会说：“我是为了你而生。”
其实，每个人都有自己的生存意义，
不应过分依赖对方，成为对方的沉重负担，甚至累赘
Ｊ--jealousy（妒忌）
适当的妒忌、呷醋能表示你对对方的重视，
但切记是合情合理的呷醋；
反之，毫不讲理，大发雷霆地呷醋，必惹反感
K--kiss（吻）
一吻胜过千言万语，
轻轻的一吻已能代表你惜她、爱护她.
L--love（爱）
都说是爱情，没有爱又怎会有情呢？
M--mature（成熟）
为什么一般人的初恋总会无声无色地惨败，
因为年轻人多恋爱得较幼稚。
人成熟一点，你的爱情便会早熟一点，直到开花结果
N--nutural（自然）
很多人初拍拖时都会把一切的缺点隐藏起来，变成另一个人。
日子久了，缺点才一箩箩地出现，令对方吃不消。
其实，不做作，流于自然的爱情才是细水长流的。
O--observe（观察）
经常细心观察爱侣的喜好，不但能更了解对方，更能给他惊喜。
那份心意必定比礼物来得珍贵。
P--protect（保护）
做男朋友的当然要保护女朋友，
但做女朋友的亦要保护对方的尊严，
不应容许别人中伤、侮辱你的另一半
Q--quarter（宽大）
宽大是基本的要诀，
对爱侣的错误，
以宽大的态度原谅他，
因为你是最爱他的人。
R--receive（接收）
对于爱侣为你所做的，请不要表现得无动于衷，令他气馁。
她付出，你便应以欣赏的态度去接受，这才能令感情更进一步
S--share（分享）
若你爱他，就必能与他分享他的喜与哀，这是作为一个伴侣最简单的责任。
T--tender（温柔）
歌都有得唱《love me tender》啦！爱人当然要温柔地爱，因为男人女人缺乏温柔都不可爱
U--understand（明白）
不明白对方的想法，对方跟你说话，你永远只独自发呆，那就是一段缺乏沟通的爱情。多站在对方立场，将心比心地想，必定能更了解你的另一半
V--veracity（诚实）
对爱情，必须一百倍的诚实，
你也不想你的另一半是个“大话精”吧！
时常互相欺骗的感情又怎能天长地久呢？
W--wait（等待）
等是维系一段感情的基本元素。
最重要的是你要与他同步成长，同步走完这段人生路，
千万不可一个走先，遗下另一半在后。
X--“X”（乘法符号）
把你对他的爱每天以倍数地乘上去，
爱情自然变成无限大，
爱情走也走不掉。
Y--yearn（想念）
工作或不在一起时，
不妨多想念对方，
间或致电或传呼他说句“我很挂念你”必能令对方甜在心头，更起劲地工作
Z--zest（热情）
像小龙女般虽然貌若天仙，却冷若冰霜的情人，除了杨过，相信都没有人愿意跟她一生一世。所以，伴侣的，适当的热情能加添不少乐趣，但切忌过分热情
Comet, 下一代反向AJAX（即服务器推送技术- Server-side push）
2010年12月18日 13:24 | by gaoolp ]
理解 Comet
您可能已经听说过 Comet，因为它最近受到了一定的关注。Comet 有时也称反向 Ajax 或服务器端推技术（server-side push）。其思想很简单：将数据直接从服务器推到浏览器，而不必等到浏览器请求数据。听起来简单，但是如果熟悉 Web 应用程序，尤其是 HTTP 协议，那么您就会知道，这绝不简单。实现 Comet 风格的 Web 应用程序，同时保证在浏览器和服务器上的可伸缩性，这只是在最近几年才成为可能。目前一些主流网站都有类似的原理，例如：webQQ、开心网、白社会等等，它们中消息动态都是采用类似的技术，也许具体实现方式不一样；
使用 Comet 的动机
HTTP 协议的成功毋庸置疑。它是 Internet 上大部分信息交换的基础。然而，它也有一些局限性。特别是，它是无状态、单向的协议。请求被发送到 Web 服务器，服务器处理请求并发回一个响应 — 仅此而已。请求必须由客户机发出，而服务器则只能在对请求的响应中发送数据。这至少会影响很多类型的 Web 应用程序的实用性。典型的例子就是聊天程序。另外还有一些例子，例如比赛的比分、股票行情或电子邮件程序。
HTTP 的这些局限性也是它取得一定成功的原因。请求/响应周期使它成为了经典的模型，即每个连接使用一个线程。只要能够快速为请求提供服务，这种方法就有巨大的可伸缩性。每秒钟可以处理大量的请求，只需使用少量的服务器就可以处理很大数量的用户。对于很多经典的 Web 应用程序，例如内容管理系统、搜索应用程序和电子商务站点等等而言，这非常适合。在以上任何一种 Web 应用程序中，服务器提供用户请求的数据，然后关闭连接，并释放那个线程，使之可以为其他请求服务。如果提供初始数据之后仍可能存在交互，那么将连接保持为打开状态，因此线程就不能释放出来，服务器也就不能为很多用户服务。
但是，如果想在对请求做出响应并发送初始数据之后，仍然保持与用户的交互呢？在 Web 早期，这一点常使用 meta 刷新实现。这将自动指示浏览器在指定秒数之后重新装载页面，从而支持简陋的轮询（polling）。这不仅是一种糟糕的用户体验，而且通常效率非常低下。如果没有新的数据要显示在页面上呢？这时不得不重新呈现同样的页面。如果对页面的更改很少，并且页面的大部分没有变化呢？同样，不管是否有必要，都得重新请求和获取页面上的一切内容。
Ajax 的发明和流行改变了上述状况。现在，服务器可以异步通信，因此不必重新请求整个页面。现在可以进行增量式的更新。只需使用 XMLHttpRequest 轮询服务器。这项技术通常被称作 Comet。这项技术存在一些变体，每种变体具有不同的性能和可伸缩性。我们来看看这些不同风格的 Comet。
Comet 风格
Ajax 的出现使 Comet 成为可能。HTTP 的单向性质可以有效地加以规避。实际上有一些不同的方法可以绕过这一点。您可能已经猜到，支持 Comet 的最容易的方式是轮询（poll）。使用 XMLHttpRequest 向服务器发出调用，返回后，等待一段固定的时间（通常使用 JavaScript 的 setTimeout 函数），然后再次调用。这是一项非常常见的技术。例如，大多数 webmail 应用程序就是通过这种技术在电子邮件到达时显示电子邮件的。
这项技术有优点也有缺点。在这种情况下，您期望快速返回响应，就像任何其他 Ajax 请求一样。在请求之间必须有一段暂停。否则，连续不断的请求会冲垮服务器，并且这种情况下显然不具有可伸缩性。这段暂停使应用程序产生一个延时。暂停的时间越长，服务器上的新数据就需要越多的时间才能到达客户机。如果缩短暂停时间，又将重新面临冲垮服务器的风险。但是另一方面，这显然是最简单的实现 Comet 的方式。
现在应该指出，很多人认为轮询并不属于 Comet。相反，他们认为 Comet 是对轮询的局限性的一个解决方案。最常见的 “真正的” Comet 技术是轮询的一种变体，即长轮询（long polling）。轮询与长轮询之间的主要区别在于服务器花多长的时间作出响应。长轮询通常将连接保持一段较长的时间 — 通常是数秒钟，但是也可能是一分钟甚至更长。当服务器上发生某个事件时，响应被发送并随即关闭，轮询立即重新开始。
长轮询相对于一般轮询的优点在于，数据一旦可用，便立即从服务器发送到客户机。请求可能等待较长的时间，期间没有任何数据返回，但是一旦有了新的数据，它将立即被发送到客户机。因此没有延时。如果您使用过基于 Web 的聊天程序，或者声称 “实时” 的任何程序，那么它很可能就是使用了这种技术。
长轮询有一种变体，这是第三种风格的 Comet。这通常被称为流（streaming）。按照这种风格，服务器将数据推回客户机，但是不关闭连接。连接将一直保持开启，直到过期，并导致重新发出请求。XMLHttpRequest 规范表明，可以检查 readyState 的值是否为 3 或 Receiving（而不是 4 或 Loaded），并获取正从服务器 “流出” 的数据。和长轮询一样，这种方式也没有延时。当服务器上的数据就绪时，该数据被发送到客户机。这种方式的另一个优点是可以大大减少发送到服务器的请求，从而避免了与设置服务器连接相关的开销和延时。不幸的是，XMLHttpRequest 在不同的浏览器中有很多不同的实现。这项技术只能在较新版本的 Mozilla Firefox 中可靠地使用。对于 Internet Explorer 或 Safari，仍需使用长轮询。
至此，您可能会想，长轮询和流都有一个很大的问题。请求需要在服务器上存在一段较长的时间。这打破了每个请求使用一个线程的模型，因为用于一个请求的线程一直没有被释放。更糟糕的是，除非要发回数据，否则该线程一直处于空闲状态。这显然不具有可伸缩性。幸运的是，现代 Java Web 服务器有很多方式可以解决这个问题。搞JAVA开发的程序员，相对而言比较幸运，PHP目前还不是很多的；我今天花了一天的时间，找了各方面的资料，共享一个国外的author写的demo附件；有兴趣的朋友可以研究一下，研究出更好的“服务器推”方案；
附件见原帖：http://bbs.phpchina.com/viewthread.php?tid=166038
