前些日子一篇N久之前的老文忽然成了被阅读的热点，检查之后才发现自己使用那段代码来做pr查询的页面已经不能正常得到URL的Page Rank值了，取而代之的是一大段“In your email, please send us the entire code displayed below”之类的Google terms_of_service错误提示信息。看来是原先的接口已经失效了。

但我装在Firefox工具栏的扩展插件SearchStatus仍然能够正常解析出每个受访页的PR值，找到 SearchStatus 的插件包解开来看源码，果然是使用了不一样的验证码生成算法，在原先的 checksum 生成之后，还需要再进行一次计算，两次演算之后得到的才是正确的ch参数。

于是拿现成的js代码改造一番之后，新的PHP版本的 Google PageRank 查询接口方法就出来了。经过本地测试之后，谁想传到服务器之后又出现了该死的 terms_of_service 错误提示。把checksum的计算过程一步步打出来，发现经过了几次右位移之后本地和服务器上的数字就不一样了。这才想到服务器是64位机，32位系统下位移之后应该被cut掉的bit在那里就活得好好的。加了个 trunkbitForce32bit 方法，对所有算术运算之后的数值进行高位屏蔽，算是搞定了64位系统下的多余位问题。结果拿到32位Linux环境下跑又不兼容了，原因是PHP在进行算术处理出现溢出时，会自动尝试将int转为float。当发生的是负数溢出时，这一操作在Windows下能正确保留精度，但在Linux下就有问题了。

下面这段代码：

$a = -4294967295;
echo dechex($a)."<br />\n";
if ( $a < 0 ) $a += 4294967296;
echo dechex($a)."<br />\n";

第一个echo在Windows下能够正确输出该负数低32位的补码，而在32位Linux机上输出的则是int类型所能表示的最大负数0x80000000了。只有通过取巧的方式给这个溢出的大负数加上一个超出整数范围的大整数来抵消掉溢出的部分，才能复原低32位应该有的样子。

使用这些非常规手段，终于炮制出这个更新版的兼容Linux32/Linux64/Windows的Google PR值查询接口的PHP脚本实现（含完整代码）。

参考:
php异或运算的不可靠性
PHP vs. BIGINT vs. float conversion caveat
http://www.teamworksusa.com/RDS275/HydroWorks275/keygen.php

刚写完这个标题，就看到埃辛一脚劲射被吹无效，我还以为利物浦的鸟运又要来了；没想转眼就吃进点球一粒，加上德罗巴的锁定胜局，切尔西总算是出了一口欧冠赛场被利物浦连K的恶气。

昨天凌晨巴萨已经以一种让人郁闷的方式被淘汰，我在八强名单出炉时候预测的两支决赛球队都没能杀到最后，5.22卢日尼基的决赛真正成了英超内战。现在看来，切尔西很有拿双料冠军的面相。。

Reverse Geocoding ，也就是反向地理编码（逆地理编码），可以根据地图上某一点的经纬度值来查询该点附近的地理信息。比如要实现捕获用户鼠标事件判断用户点的是哪国哪省哪市哪条街道，就需要有相应的 reverse geocoding 服务支撑。

在当前版本的 Google Maps API 中对这项功能提供了有限支持。对于开放了 Geocoding (GClientGeocoder) 和 Driving Directions (GDirections) 接口的国家和地区，Nico Goeminne 写了个 GReverseGeocoder 类来完成反向地理编码解析（Google Pages 貌似这几天被 GFW 掉了，访问不到 Nico Goeminne 站点的朋友可以看我本地的镜像链接）。可惜的是目前谷歌中国的ditu.google.com还没有提供GDirections接口，不知道后续的版本会不会放出。下面是 Nico Goeminne 列出的 GReverseGeocoder 当前的国家支持情况(x=支持, n=不支持, p=理论上支持但未经过测试)：

实际上，在 Google Maps API 官方文档里面 GClientGeocoder 接口的 getLocations(address, callback) 方法里面虽然没有明确说明，却可以传递用逗号或空格分隔的经纬度值进去作为address参数，也能达到反向地理编码解析的目地。只是目前这样调用返回的Placemark对象精度只能到国家级别，并没有更进一步的所在地信息，还没有太多的实际价值。

一些非 Google Maps 提供的 geocoding / reverse geocoding 服务链接： http://groups.google.com/group/Google-Maps-API/web/resources-non-google-geocoders ，基本上可查询范围都是欧美国家，有偿服务居多。

中国区域的 reverse geocoding 服务方面， MapABC的搜索API中倒是有 reverseGeoCoding(msearchpointpara) 接口方法，美中不足的是其flash版本的地图跨浏览器兼容性又不是太好还有滚动广告条，文档的组织也够凌乱，所使用的经纬度坐标又不是标准的数字形式，极大的影响了使用体验；51ditu 的位置描述接口则直接作为收费接口有偿提供。看来想使用免费又称心的 reverse geocoding 还得耐心等谷歌地图开放相应的功能了。

附： 中国地区大中城市经纬度参照表

主客场两个疑似点球的判罚一出一进，阿森纳实在是背到极点。尽管沃尔科特用惊世骇俗的速度过掉了整支利物浦队助攻阿德巴约打进力挽狂澜的一球，依然无法与命运的作弄相抗衡。看不到阿森纳和巴萨的再度对决了，洗洗睡去，sigh。

经过了一段和谐的外国大片真空期之后，三月份的影院开始重新成为好莱坞巨制的天下。《史前一万年》的预告片让我有买票的冲动，但看到豆瓣上的评价之后还是改变主意选择了《黄金罗盘》。虽然新线后来出品的魔幻系列每一个能跟魔戒相提并论，但这次的Golden Compass能够击败变形金刚拿走奥斯卡最佳视效，对我这个迷恋CG的人来说诱惑实在不小。

上次看投名状碰到八佰伴搞活动；这次又碰到平安信用卡搞活动，10块钱一张票的噱头又是引来超级排队购票长龙，所有的大厅一律上映史前一万年，黄金罗盘和国家宝藏2都只好挤在百来人的小厅放。等到检票进去之后，这小厅之小还是超乎了我的想象：要是家庭影院那算是超豪华的，可摆上一百多把椅子在这块豆腐干前面，实在是狭促到家了。

不过也许正是因为有这样一个不够震撼的观影环境做为先决条件，看完之后的第一感觉是：不像网上评论的那么差 -- 至少比纳尼亚要好。CG的确很强，双熊争霸那场戏多少有点三龙战金刚的味道（但为什么大黄蜂没有斗过披甲熊捏？不服啊不服），基本让我没白冲最佳视效而来。故事性方面虽然还是太过于儿童化思维，好在不像纳尼亚那样有一堆小孩子在演绎，不至于杂乱无章到不可收拾。伊拉贡也罢，纳尼亚也好，还有这个黄金罗盘，都在用小孩子讲故事的方式讲述发生在小孩子身上的故事，原著本不应该被如此改编。。

因为影片提到了 Star dust 的缘故，刚巧收了星尘的9区碟，看完黄金罗盘之后又在家看了星尘。相比之下，星尘的导演兼编剧 Matthew Vaughn 就有才得多，可以把一个俗得不能再俗的童话故事编排得妙趣横生，所以说想导演编剧一肩挑不是不可以，但要勉强为之就还不如专心一意的好。