卫星地图上的Dgwxx

最近Google Earth超级流行,人们最热衷的事情就是在Google提供的高清晰卫星题图上寻找自己家、自己工作的地方。这回我也加入进来,贴一下自己呆的地方。
非常幸运的是,无论是天津市的家还是在哈尔滨的学校,都有Google提供的高清晰卫星地图,很容易分辨。同宿舍的来自陕西农村和大庆油田的同学就没有这么幸运了,Google还没有更新他们家乡所在地区的高清晰地图,不过相信不久之后所有人都能在Google上面找到他们的家。

我的家:
Image
黑龙江大学A、B区鸟瞰图:
Image
黑龙江大学C区鸟瞰图,图中有Dgwxx的宿舍哦:
Image

在来说说Waki-Blog的事情:
今天加强了Waki-Blog的内部图库的处理功能,增加了自动缩小与水印添加功能。
自动等比缩小采用设定一个阈值,图片长宽任意一条边的长度大于阈值即启动自动缩小。首先使用长、宽中最大的那一边的长度除以阈值算出缩小比例,再用比例反过来乘以长、宽两边,分别乘以图片长宽,在依据缩小后的长宽进行缩小。这样可以保证在基本没有比例失真的前提下对图片进行缩小。
水印添加没有采用z-AutoWatermark,而是采用相对比较简单、同时也相对节省很多系统资源、高速的方法:首先在图像坐标2,2的地方添加一行黑色的文字,再在3,3位置添加一行相同的白色文字,制造了一个“白色字左上方有黑色阴影”的效果,不管图片背景颜色深浅,总能保证前方文字清晰可辨。
很不幸的,Waki-Blog的TrackBack发送部分出来了一个很让人囧的BUG……昨天我在引用月光博客的一条Blog的时候,发现引用地址后面竟然没有ID号,查了半天也没有头绪,还以为是不用Blog系统之间的兼容性问题。今天突然恍然大悟,Waki-Blog的最后一条记录的ID号是使用mysql_insert_id()函数取得的,难道虚拟主机的MySQL或者PHP版本太低,不支持这个函数?
于是只得在下面加了一句:
if (!$new_id){
list($new_id) = mysql_fetch_array($db->query("SELECT bid FROM {$tablepre}blogs ORDER BY bid DESC LIMIT 0,1"));
}
这才解决这个问题……怪不得Bo-Blog要MySQL 4以上的版本= =||

Blog的“人身安全”

今天晚上闲着没事,又修改了一下Waki-Blog。本次修改主旨在于提高前台程序的执行效率。首先分离了前台和后台的语言包文件,因为Waki-Blog的前台远比后台来的简单,所以需要的语言包的数量比较少,为前台专门做一个语言包可以加快前台的程序加载速度。由于Waki-Blog程序结构的原因,PHP代码与语言、模板完全分离(PHP代码中看不到一个字、一点HTML代码,当然,BBCDOE解析除外),所以程序更加依赖于语言包和模板,要提高效率,只要从语言包和模板入手即可。
此外还调整了用户身份验证部分。只在后台的时候才验证用户身份,这样就在前台减少了一次数据库查询。

今天启动了Waki-Blog的图片防盗链功能。
Waki-Blog的图片管理依赖于站内图库功能。在编辑器中可以上传图片,并指定一个该图片的索引。比如我给某副图片取名叫“feiron”(《天高く、雲は流れ》男主角的名字-0-),就可以在编辑器内用BBCODE贴上[image|feiron],BBCDOE解析的时候,就会插入索引为feiron的图片,与wiki原理相似。不仅如此,索引在BBCODE解析的时候,会通过加密的方式传递给程序,这样,图片地址就变成了类似response.php?image:show::a44c2FpdG91的形式,隐藏了图片的真实路径和文件名,达到了保护图片的目的。
当response.php接到请求的时候,会首先检查1.加密了的索引是否合法、2.检查请求来源是否在指定的白名单之内。如果没有问题,就会解码图片索引、查询数据库找到图片的真实路径、由GD库打开图片、PHP输出HTTP头、之后同样通过GD库来将图片呈现。任何一项不符合要求,都会拒绝请求。

这只是防盗链的第一步,也是最基本的一步,即试图从本站做起防止他人盗链。但是,来源检查并不一定经常有效,遇上某些丧心病狂的人通过伪造HTTP头的方式来认为改变请求来源的时候,只有在图片上加入含有本站标志的水印来标明图片来源。这只能说是属于下下策的方式了,因为在图片上添加水印,不能直接起到防止盗链的作用,只能是一种类似“舆论施压”的作用。
过两天我会在Blog上贴一篇关于PHP图片水印添加的心得的文章,届时会公开Z-AutoWartermark 2.0的代码。

网络基本恢复

从入学开始学校的网络就一直跟我闹别扭。开始是无法从DHCP服务器处获得IP地址,打电话叫联通的人帮我在楼下的“交换机”(尽管他们一再强调是交换机,但是我仍然怀疑他们用的不是交换机而是集线器)帮我换了一个端口才基本没再闹大毛病。

好不容易将就对付过了一个学期,但从这学期开学开始,网就一直没正常过。最开始跟上学期一样无法获得IP地址,手动指定IP地址之后,虚拟拨号连接变得极其不稳定。通常是拨号成功后约10分钟左右断流,即无法发送数据也无法接收数据。这时候挂断连接,就再也无法重新进行虚拟拨号,表现是每次到“通过WAN微型端口”处就卡住,超时之后提示“远程计算机没有响应”。从昨天开始这种状况发展到了“登峰造极”的地步,一般拨号三分钟后就完蛋,只有重新启动电脑才能在拨号。

忍无可忍的我又打电话叫来了联通的人,解决办法仍然是在下面不停的换端口,这次竟然一点用都没有了,该上不去还是上不去。对方建议我关掉全部防火墙(我用windows自带的防火墙和金山网镖2006),照办了,还是不行。说我系统有毛病,重装系统,以干净的系统上网,还是不行。到最后人家建议我借同学的笔记本电脑看看,如果还是不行就只能认为线路有问题了。借来的同学的Think pad,上网,下载,聊天,完全没有问题……

系统、线路、联通的设备都没有问题,难道是我的硬件有问题?注意力最终聚焦到了“网卡”上……今天早晨,出去花¥35买来了TP-Link TF-3239DL(其实就是普通的螃蟹卡),安装,进BIOS,屏蔽板载的1000M网卡(Marvell Yukon Ethernet Controller),启动XP,发现新硬件,安装驱动(XP自带螃蟹8139驱动),拨号,一个多小时,完全没有问题。

问题的解决似乎相当顺利。总计成本¥35,似乎也不是很贵。总之,有以下两个要点:
1.宿舍楼网络环境复杂,网中网也不少,部分学生使用电脑的习惯不是很好,没有及时安装补丁、防火墙,蠕虫病毒泛滥(隔壁的电脑总是因为冲击波重起)。
2.建设网络的时候,联通为了降低成本使用了成本很低的10M集线器而不是100M交换机。集线器的通讯能力以及防止广播风暴的能力不如交换机,结构设计不好的话,非常容易造成网络瘫痪(这点上,联通似乎做得还不错,好像没出现过因为广播风暴造成网络瘫痪的事件)。而且,集线器对于其他的网络设备的兼容性比较差,尤其是现在主板一般会集成千兆网卡,如果速度自适应能力不佳很可能造成兼容问题,这次的问题很可能就是这个原因。

网络出现问题的时候,除了软件设置上的问题,还应该考虑硬件兼容性、网线质量的、网络设备的电源供应等等问题。我这半年多的“悲惨”经历似乎就说明了这一点。