易栈网-膘叔

PHP处理COOKIE是一件很方便的事情。print_r（$_COOKIE）就可以打印所有的cookie变量。而且cookie也能够存为数组。确实操作和应用都非常方便 。

以前，对于子域和根域下的cookie并没有研究太深。因为都直接设在根域的。以前注意cookie是路径（path），这个的影响也是有的。不过现在大多数程序的cookie都是设在根路径（“/”）下，所以也回避了不少问题。

以下是老王提出的问题和解决方法（子域和根域同名cookie的处理），引伸开的话，你也可以测试一下，根路径与子路径下同名cookie的情况。【果然，老王文章结尾就是这样的提问，呵呵】

我们都知道，在子域下请求时，浏览器会把子域和根域下的Cookie一起发送到服务器，那如果子域和根域下有一个同名Cookie，当我们在PHP里使 用$_COOKIE访问时，到底生效的是哪个呢？下面做试验测试一下，测试使用Firefox，用到了以下插件：SwitchHosts+WebDeveloper+Firebug。

注意：试验结果可能因为浏览器的不同而存在差异。

首先通过SwitchHosts设定虚拟域名：www.foo.com，并且配置好Web服务器，当然，你手动设置Hosts文件也可以，我本意是为了多介绍几个工具。

然后编写设置Cookie的PHP脚本，先设置子域，再设置根域：

再编写浏览Cookie的脚本： BTW：最初写脚本的时候我竟然在setcookie前使用了var_dump，也就是在发送请求头之前有了输出，犯了这样的初学者错误实在是罪过，可更令人惊讶的是脚本没有报错，查了半天原来是因为php.ini里缺省output_buffering = 4096。

先设置再浏览，就能看到结果了，结果显示有效的是子域下的Cookie。

重开一个浏览器窗口，并使用WebDeveloper删除Cookie，或手动删除，避免对结果造成影响。

然后调换两次调用setcookie的顺序，也就是先设置根域，再设置子域： 先设置再浏览，就能看到结果了，结果显示有效的是根域下的Cookie。

重复两次测试过程，并用Firebug记录下请求头的差异：

第一次先设置子域，再设置根域：请求头Cookie的值是bar=www;bar=foo，结果有效的是bar=www
第二次先设置根域，再设置子域：请求头Cookie的值是bar=foo;bar=www，结果有效的是bar=foo

也就说，同名Cookie对于服务端PHP来说，在请求头Cookie中，哪个在前哪个生效，后面的会被忽略。

如果使用的不是Firefox，那就用不了Firebug，此时可以用PHP代码来检测Cookie头：

PHP代码

1. if (isset($_SERVER['HTTP_COOKIE'])) var_dump($_SERVER['HTTP_COOKIE']);  

以上的实验结论是基于Firefox而言的，由于不同的浏览器发送Cookie的策略可能有差异，所以在其他浏览器上结果可能会有所不同，比如在 Safari下就始终是子域有效，其他浏览器如Opera，Chrome等未仔细测试。鉴于这个混乱的结论，所以还是不要在子域和根域下使用同名 Cookie为好！

题外话：类似的情况，如子目录和根目录下的同名Cookie是什么情况，读者可以自行测试。

--EOF--

原文来自：http://hi.baidu.com/thinkinginlamp/blog/item/899551dacd807ad6b6fd48cd.html


 

做电子商务的不可避免的都会遇到价格区间的问题。这，主要显示在搜索的时候，如果你区间设的过大，那几乎把所有产品都列出来了。那和没有分区间没啥分别。因此，还真有一种算法可以解决这个问题（当然也只是基本解决，看上去不是特别的乱而己）。

这是在老王的博客上看到的：

means算法

Web开发中，CRUD做多了难免厌烦，其实还有很多细节可以挖掘，比如很多电子商务网站上都有商品价格区间，都是诸如1000-2000，2000-3000之类定死的，而没有按商品自己的分布规律来划分，此时有一种名为Kmeans的算法可以使用，效果很好，网上有很多现成的代码可以参阅，比如PHP的版本：

kmeanspp
K-Means Clustering in PHP

--EOF--

到百科看了一下，这么解释K-means：k-means 算法接受输入量 k ；然后将n个数据对象划分为 k个聚类以便使得所获得的聚类满足：同一聚类中的对象相似度较高；而不同聚类中的对象相似度较小。聚类相似度是利用各聚类中对象的均值所获得一个“中心对象”（引力中心）来进行计算的。

虽然这样能够处理，老王也给了一个PHP的解决方案，但在实际中，应用的范围并能算是特别大，有时候还是直接手写的。以前的时候，我们是在分类里，直接把几个区间定义好，然后在搜索的时候指定某一分类时，自动调用这个区间。理由是，如果你的产品分的很散，从几块到几千块的都有，这种分类区间，就只能定义到分类上了。

不过上面的算法可以学习一下

以下内容均来自老王。说实话，simplexml的这些问题我以前遇到过，而且还是非常强烈的遇到了。
那时候是08年的事了，项目中与SOAP在交互，返回的都是XML，所以就直接采用了simplexml_load_string了。这时候就会遇到这种问题，比如我拉一个列表，但会有三种情况：1、没数据，2、1条数据，3、正常数据
1、没数据的时候，返回一个空的simplexml Object，
2、一条数据的时候，返回的也是一个simplexml Object，结果集成了这个object的元素
3、数据列表，这时候返回的却是一个Array，每一个元素是simplexml Object，等同于2。
后来我是没办法，就多写了一个函数判断，如果是object，并且不为空，直接把object强制转为array，因为，如果是空的simplexml Object，强制转的话，还是Object,转不了。。。

当时还有一个可恨的事情，我以前可能介绍过，xml在返回的时候，他的形式可能是这样的<test-name>gouki</test-name>，在返回这样的形式时，生成object时，却是test_name，在没有print_r出来时，我死活搞不定。。。后来才发现这个问题，郁闷啊

好了，说了半天，该说说老王的内容了：
这个问题遇到好几次了，今天翻看以前代码的时候看到，便记下来，先用一段代码重现一下问题：

乍一看，结果很让人费解：

XML/HTML代码
SimpleXMLElement Object  
(  
    [foo] => Array  
        (  
            [0] => SimpleXMLElement Object  
                (  
                    [bar] => hello  
                )  
            [1] => SimpleXMLElement Object  
                (  
                    [bar] => world  
                )  
        )  
)  
SimpleXMLElement Object  
(  
    [bar] => hello  
)  

明明print_r显示foo是一个有两个bar元素的数组，但是最后却仅仅显示了一个bar元素！

原因其实很简单，在如上所示simplexml_load_string的结果里，foo并不是数组，而是一个迭代对象！

可以这样确认：

PHP代码
foreach ($data->foo as $v) print_r($v);  
foreach ($data->children() as $v) print_r($v);  
看来，print_r或者var_dump之类的表象并不完全可信，自己多留心吧。
原文来自：http://hi.baidu.com/thinkinginlamp/blog/item/9dbb15ce7a621632b700c86a.html

本来对于mysql proxy 0.70的release是仅仅当成一个新闻来报道的。结果，老王却写了一篇教你如何配置的文章，你说我是转好呢还是不转好呢？
上午我刚写，人家老王下午就来配置，你说我不转，对得起人家伐？
所以，我只好辛苦一点，，转载一下喽。。

感谢老王

原文：http://hi.baidu.com/thinkinginlamp/blog/item/f96559821fbda8aa0cf4d200.html

MySQL-Proxy的二进制版本的安装相对简单，无需多言，下面介绍的是源代码安装：

安装pkg-config：

tar zxvf pkg-config-0.23.tar.gz
cd pkg-config-0.23
./configure
make
make install

确保PKG_CONFIG_PATH环境变量包含了相关的pkg-config配置文件路径：

export PKG_CONFIG_PATH=$PKG_CONFIG_PATH:/usr/local/lib/pkgconfig

安装libevent：

tar zxvf libevent-1.4.10-stable.tar.gz
cd libevent-1.4.10-stable
./configure
make
make install

安装glib：

tar zxvf glib-2.20.0.tar.gz
cd glib-2.20.0
./configure
make
make install

安装lua：

tar zxvf lua-5.1.4.tar.gz
cd lua-5.1.4

如果你的服务器是64位的，这时要调整一下Makefile：vi src/Makefile，在CFLAGS里加上-fPIC，否则会出错：

/usr/bin/ld: /usr/local/lib/liblua.a(lapi.o):
relocation R_X86_64_32 against `luaO_nilobject_' can not be used when making a shared object;
recompile with -fPIC
/usr/local/lib/liblua.a: could not read symbols: Bad value

接下来不用执行常见的configure，直接make：

make linux
make install

安装pkg-config配置文件，以便编译mysql-proxy时能找到lua：

cp etc/lua.pc /usr/local/lib/pkgconfig/lua5.1.pc

如果没有执行此步骤的话，在后面编译安装mysql-proxy的时候，会得到类似下面的错误信息：

Package lua5.1 was not found in the pkg-config search path.
Perhaps you should add the directory containing `lua5.1.pc'
to the PKG_CONFIG_PATH environment variable
No package 'lua5.1' found

安装mysql：

这里介绍的是完整安装mysql，其实你只要安装mysql开发包即可。

tar zxvf mysql-5.1.33.tar.gz
cd tar zxvf mysql-5.1.33
./configure
make
make install
cp support-files/mysql.server /etc/init.d/mysql
chown +x /etc/init.d/mysql
cp support-files/my-[small|medium|large|huge|innodb-heavy-4G].cnf /etc/my.cnf

如果my.cnf里有skip-federated选项，就注释它，否则安装数据库的时候会出现类似下面的错误：
[ERROR] /usr/local/libexec/mysqld: unknown option '--skip-federated'

/usr/local/bin/mysql_install_db --user=mysql
/usr/local/bin/mysqld_safe --user=mysql &

保证系统能找到mysql_config，后面编译mysql-proxy会用到它：

export PATH=$PATH:/usr/local/bin

还要保证系统能找到mysql库文件：

vi /etc/ld.so.conf 加入/usr/local/lib目录

执行：/sbin/ldconfig /etc/ld.so.conf

安装mysql-proxy：

tar zxvf mysql-proxy-0.7.0.tar.gz
cd mysql-proxy-0.7.0
./configure
make
make install

按照官方介绍做好启动脚本/etc/init.d/mysql-proxy和参数脚本/etc/sysconfig/mysql-proxy，并设置：

chmod +x /etc/init.d/mysql-proxy
chkconfig --add mysql-proxy

搞定了，测试一下：/usr/local/sbin/mysql-proxy -V。官方论坛里有很多讨论，可以参阅。