不好也不坏的人

原文作者:刘墉 |每日一文

有一天,我到某地办事,下飞机之后搭计程车。由于是初次到那个城市,就跟司机打听当地的情形。他除了为我介绍,还发表了不少对时局的看法,两人谈得很投机。

到达目的地,表上是180元。

“给100就好了!”他居然手一挥,豪爽地说。

“那怎么成?”我递过去200元,说:“不用找了!”就跳下车。听到他在背后连声喊着“谢谢、谢谢”,觉得好温馨。

办完事,我又叫车回机场。机场到了,计程表上的数字是120元,我真是哭笑不得,发现和前一位司机虽然谈得投机,但在谈的时候,他发现我是外来客,也就大绕远路。加上我给他的小费,足足多要了我80元。

但是,再想想,他后来主动说:“给100就好了”。如果我照办,他不是反而亏了吗?他为什么降价?一定是谈得投机,心里过意不去了。

我有个朋友,夫妻二人到欧洲旅行。临回国,特地跑到工艺品店,订了一个大号的名画复制品。

店老板是个很豪爽的人,仿佛一见面就成了老朋友,七折八扣,还附送女士一件小礼物。

但是当他们拿过账单时,却觉得数字好像不对,细看才发现,老板居然把上面的1995年,也当作货款加了上去。

“天哪!多糊涂!”老板把两只手摊向天空,赶快作了“修正”,直赔不是地送二人出门,并保证东西准时寄到。

夫妻俩站在门口等计程车,偏偏碰到下班高峰,一辆空车也没有。眼看飞机就要起飞,他们急得像热锅上的蚂蚁。

“叫不到车?”店老板探出头来,“飞机几点起飞?”接着跑到屋后,开出自己的车,送他们飞驰到机场,正好赶上飞机。

不久,接到邮包,画像寄到了,包装得非常讲究,毫无损伤,只是——大号变成了小号。

我常把这两个故事放在一起想,想那司机和工艺品店的老板,他们是好人还是坏人?抑或是好人,也是坏人?

想来想去,我发现,其实世上许多人,都是这样不好不坏的人。当你不小心的时候,他们会占你的便宜,当你跟他有了交情,他又可能为你付出。

我也发觉,在这瞬息万变的年代,每个人似乎都成了旅客,当你有一点陌生,有一点外行,或者不懂得工作伦理的时候,他们在指导你之前,可能先欺负你。

如果你同时养了猫和鱼,猫吃了鱼,你除了责备猫,更应该责备自己。同样的道理,当你明明知道人性有弱点,却不加防范,而且吃亏的时候,除了怨恨那个人,更应该检讨自己。

每个人都是“人”,都有着人性的贪婪、自私与温情,如同前面的司机和工艺品店的老板。我们永远不能因为对方表现得善良,而忘记了他也有人性的弱点。更不可由他一时的卑劣,而否认他可爱的一面。

Continue Reading

HTTP协议中GET/POST/COOKIE数据传递方式的对比

GET

GET方式传递数据,数据直接写在URL中,用一个英文问号分隔,然后以name=value的形式描述。为了避免和URL分隔符冲突,value部分的数据还需要进行urlencode转义处理。下面给出了一个典型的GET方式传递数据的例子:

http://guangxin.name/?p=772

问号后面的p=772就是GET方式传递的数据。对于PHP程序来说,GET方式传递的数据会被初始化成$_GET全局变量。对于大多数浏览器而言,GET方式传递的数据会在地址栏中显示出来。

由于GET方式直接利用URL传递,受限于URL的长度,GET无法传递太长的数据,一般数百字节的长度还可以容纳,数千字节可能就容纳不了了。GET方式的另一个限制是无法传送文件,因为文件数据需要使用多分段的方式传送,GET方式无法支持。

HTTP设计之初,GET方法就是为了获取某个网页的数据而存在的。GET方式传递的数据更多是作为cgi生成网页的参数使用,所以也无需处理太大量的数据。

POST

和GET方式不同,POST方式传递的数据会放在HTTP Request的body部分,而不是放在header里,所以POST方式传递的数据不会显示在地址栏里,允许容纳的数据量也更大一些。在HTTP/1.0中,POST是主动提交大量数据的唯一办法;即使在HTTP/1.1中,POST也是主要的提交大量数据的方式。

POST方式传送的数据虽然不会显示在浏览器的地址栏中,但这并不意味着它比GET方式更安全。HTTP协议本身是明文传递数据的,所有的敏感信息都有可能被网络传输过程中的任一环节截获。HTTPS等加密技术才是解决安全问题的最佳选择。不过考虑到HTTPS加密解密环节的巨大开销,一般的网站也常常只在登录的地方使用HTTPS。

POST和GET方法传递的数据是可以并存的,甚至可以重名。向一个带有URL QueryString的地址发送POST请求是可以的,此时POST的表单数据通过Request Body传递,而URL中的QueryString会被解析成GET方式传递的数据。

COOKIE

HTTP协议本来是无状态的,各次请求之间没有任何关联性,但是有的时候网站开发人员的确需要维持一个用户的会话,完成一些上下文关联的操作,所以COOKIE这种东西就被发明出来了。

COOKIE是HTTP Header中的一部分,用类似GET那样的key=value的格式描述了一系列数据。COOKIE可以设置过期时间,作用的域和路径。如果当前访问的URL的域和路径与浏览器保存的COOKIE相符,COOKIE就会自动被放在Header中发送给WebServer。从某种意义上来说,使用COOKIE传递的数据往往是一些需要浏览器“带着跑”的数据,比如当前会话的ID、用户的唯一表示符等等。

COOKIE的安全性也不比GET或者POST更高,毕竟COOKIE也是明文传送的数据,而且COOKIE往往更容易让网站陷入危机。许多WebServer端开发人员会很小心的处理GET和POST传递来的数据,但是对COOKIE却直接使用,这绝对是安全隐患。

在PHP中,会话函数(session)就是使用一个名为PHPSESSID的COOKIE实现的客户端关系维持。Session和COOKIE不同,它的所有都保存在Server端,只留下一个Session ID交给浏览器保存,SessionID的生成规则毫无规律,这样可以最大限度的保证会话数据不被外界篡改。

常见使用场景

GET常常会用在链接中,POST常常会用在表单上,COOKIE则用来维持会话。

有一个比较特别的例子是多条件组合查询表单,这个表单的查询结果往往会很多,需要分页。如果使用GET方式传递数据,创建分页链接的时候会比较简单。

Continue Reading

T9 URL Shortener 的源代码


Warning: count(): Parameter must be an array or an object that implements Countable in /web/rek.me/rek/webroot/wp-content/plugins/wp-codebox/main.php on line 31

Fatal error: Uncaught Error: Call to undefined function eregi() in /web/rek.me/rek/webroot/wp-content/plugins/wp-codebox/main.php:136 Stack trace: #0 /web/rek.me/rek/webroot/wp-content/plugins/wp-codebox/main.php(75): wp_codebox_is_windowsie() #1 /web/rek.me/rek/webroot/wp-content/plugins/wp-codebox/main.php(50): wp_codebox_highlight_geshi(Array) #2 [internal function]: wp_codebox_highlight(Array) #3 /web/rek.me/rek/webroot/wp-content/plugins/wp-codebox/main.php(130): preg_replace_callback('/<p>\\s*3f99e694...', 'wp_codebox_high...', '<p style="text-...') #4 /web/rek.me/rek/webroot/wp-includes/class-wp-hook.php(310): wp_codebox_after_filter('<p style="text-...') #5 /web/rek.me/rek/webroot/wp-includes/plugin.php(205): WP_Hook->apply_filters('<p style="text-...', Array) #6 /web/rek.me/rek/webroot/wp-includes/post-template.php(256): apply_filters('the_content', '<p style="text-...') #7 /web/rek.me/rek/webroot/wp-content/themes/olsen-light/content-entry.php(59): the_content('') #8 /web/rek.me/rek/webroot/wp-includes/template. in /web/rek.me/rek/webroot/wp-content/plugins/wp-codebox/main.php on line 136