我的天

一直很小心对待的WordPress升级原来只需点击后台，升级过程不超过10秒就好了。不得不说，我一直以来都太小心了……但其实我一直没有对WP的核心程序做修改，我修改的只是插件和主题，恰好那两样东西都是核心WP程序所没有的，所以，即便升级，新程序覆盖上去，也是没有丝毫问题的。为什么从前我脑袋瓜里想到的是删除并重新建立而不是覆盖替换呢？！显然，我想过头了。

有xinca在一切问题都不是问题，即便有再大的问题，他老人家也一定可以解决。

自从我们搬到新服务器后就没有安装后台，所以当我向他要后台登录方式的时候他无法拿出。那怎么更新呢？没有后台，也没有FTP。今天我们用了一种全新的更新方式——Dropbox，利用Dropbox的同步实现读写！！！！太牛了！因为我要修改更新的只是些几KB的小php，转眼间Dropbox就同步完成，同步完成后，网页也就能显示了。我们利用Dropbox实现从前FTP的功能，但FTP，你懂的，那东西有多慢，而且Dropbox还能自动保存你不同版本的东西1个月，这种优势FTP无法与之相比。有什么比我们系统文件夹内操作更可视化的呢？

不得不说，利用Dropbox的同步技术，实现单机和服务器之间的数据交换真的爽！但唯一可能有缺陷的就是无法设置文件的各种读写权限，暂时，我还用不着那个。Dropbox同步是高超的，但同时也可以是致命的，如果某天某坏人删掉你电脑的那些东西，虽然Dropbox有后悔药，但还是很恐怖的。

今天偶尔发现WWE改版后的图片展示页出现了图片说明，但不是每张图片都有，通过href里的title或img里的alt体现，没搞懂，为什么img的引用地址居然用ref开头而不是src开头呢？不是说每个img必须有alt才能符合W3C的要求吗？显然，WWE改版后一些图片有alt一些没有，汗。首先我使用2个正则获取到图片地址及不是每个图片都有的描述，然后，再用2个for语句实现图片数组和描述数组的统一，这样做有点笨，希望有高手指点改进，源程序如下：

1
2
3
4
5
6
7
8
9
10
11
12

preg_match_all('/(?< =href="\/f)(.*?)" title="(.*?)">/', $data, $alt);
preg_match_all('/(?< =href="\/f).*\.jpg/', $data, $log);
for($m=0;$m<count($log[0]);$m++)
{
	for($n=0;$n<count($log[0]);$n++)
	{
		if($alt[1][$n]==$log[0][$m])
		{
			$alt2[$m]=$alt[2][$n];
		}
	}
}

感觉周赛图片WWE都没放描述，只在一些WrestleMania Axxess活动里放了，希望呢，那些做网页的勤快点，描述是很重要的啊！

今天是GA的musical drama集，兴奋呢！

两天前Firefox自动升级至号称速度能达到3.0版6倍的4.0版。好几个插件都无法兼容其中就包括我最喜欢的美味书签插件，但我毅然升级了。因为如果大部分插件都能用，速度又能大幅度提升，更重要的是FF原生支持书签、历史记录以及其它一些资料同步的话，我真的很希望见识这个新版本。不得不说，这个FF4.0给我的感觉更像Google Chrome和Opera的混合版。特别当它的标签页到达了顶端，去掉了菜单栏和状态栏后。花了接近2天时间我都没有适应新版本右键菜单的“在新标签页中打开”和“在新窗口中打开”两个按钮位置的互换，所以当重新开窗口时，我知道我错了。用了javascript语句取代了美味书签插件，依旧能及时方便分享网页。因为始终觉得网页是众乐乐的，虽然FF的原生书签同步功能已经很不错。

对FF的改变，感觉还行。

不过，今天最大最突然的改变是WWE的网站，WWE网站改版了！被大大地雷到。从前用xml+flash实现的东西全部变回了一般的网页代码，不懂这是为什么，但现在WWE的图片全部强制16:9了，而那些达不到那个尺寸的一律“加黑框”，还有还有，图片全部加水印了。不过，这还不是让我最心痛的。对比下面两张图片，你大概就能体会到我痛的是什么了。

1、从前我存下的图片（624*390，87.47KB）

http://www.xlanda.net/wp-content/uploads/2010/08/SD_574_Photo_082.jpg

2、现在WWE网站看到的图片（686*384，36.82KB）

http://us.wwe.com/f/imagecache/gallery_photo/photo/image/2010/12/15453834.jpg

原图是一样的，但现在大家在WWE网站所看到的图片都被狠狠压缩并处理过，长宽变化很微小，但图片质量的变化非常巨大！噪点更多了，有模糊感，颜色明显没有从前的鲜艳。连续几周下来我已经明显感觉到摄影师们的角度和时间捕捉得不完美了，如果连一些最最基本的“优点”都缺失掉，哎～～～ 叫我这个图片控情何以堪呢！

看着WWE的图片多方面都在倒退，我掩面，将要泪奔。

花了一点时间，调整了正则，让YARK再次适应WWE：http://a99a.z9.tcp.cc/

至于WWE网站除图片外整体的变化嘛，感觉还行，是朝着Blog的方向发展的，每篇文章都加入“FB顶”之类的东西，有了更多的延伸阅读的指引，还有就是网页载入是分段的，在图片强力压缩后网站还不是一下子完全载入，你懂的，那里省了多少的时间。已经没办法考究从前的WWE网站Page Speed分数是多少了，但现在的，此刻的，是70分，YSlow(V2)的分数是65[D等]，从一个纯网站角度考虑的话，这不优秀，远远谈不上优秀，不过，你懂的，吐槽有什么用呢。

或许我不喜欢，一点不习惯，但WWE网站改版了，除了调整我自己去适应，没有其它办法。

改变，有时根本不容得你愿意不愿意。

这几天准备把2010年8月至今收集到的WWE Magazine都处理压缩分享，因为外国友人去年的那些版本都实在太“庞大”了，经常超过200MB一期（每期约80页PDF），不利于长期分享，所以，我选择把它们都处理一下，减肥成大约30MB，只要能看清字就好，其实用太大太夸张的像素和分辨率都是浪费的。

具体步骤如下：

1、从原PDF里利用Adobe Acrobat的：文件-导出-图像-JPEG，把每页PDF导出成JPEG。大小超过200MB（80页PDF）的杂志通常导出的JPEG图片的宽都大约在1530-2500px之间，以19寸宽屏显示器为例，其宽度为1440，大于这个数的图片都会被自动缩放显示，缩放了的，清晰度如何，你懂的。

2、利用PhotoZoom Pro 4.04对导出的.jpg文件压缩，我选择的参数如下：如果导出的图片大小是一致的，那么把像素大小的单位设置为“像素”，固定长宽比的前提下，设置宽为1230；如果导出的图片大小不一致，那么按照实际情况缩小成宽大概为1230，若原图大小为2406*3113，那么把像素大小单位设置为“百分比”，然后用50%。更改大小的方式选择PZ独门的“S-Spline Max”预设选择“Reduce JPEG Artifacts – Medium”，个人感觉中等就好，如果你选择压缩成宽为1530的，那么推荐使用“Graphics – Extra Detailed”。经过处理后，图片会变小20%至80%，压缩的前提提保证足够的清晰度。

3、利用Adobe Acrobat重新组合.jpg文件，合成新的PDF：创建 – 合并文件到单个PDF – 选择文件 – 合并文件 – 保存

经历3步后就完成了。

今天一口气处理了3个期杂志，但到2010年11月The Undertaker做封面那期的时候，我被卡住了，The Undertaker主动欺负我！NND～～～

是怎么回事呢？先看图

WWE.Magazine.2010.11.By.Hurricane.Guga.pdf的这个文件第一次见的时候我就觉得不妥当，为什么第一页有“格子”后面却很清晰呢？看过上图就会明白，第一页的大小跟后面相差很远，当页面放大到相同倍数的时候，偏小的第一页当然有“格子”了。出于这个原因，我没有对第一页进行缩小操作。

不过问题来了

左图是我用不经压缩的第一张.jpg和后面90张.jpg合并出来的PDF，不知为何，第一张图就是超大，足足是其它的两倍，所以就囧了，PDF阅读器是根据最大的那张图自动调整缩放宽度的，所以如果适合第一张，那么后面的都杯具了。从上上图可以看出，明明合并之前，第二张以后的图都是比第一张大，但PDF合并出来就会出现这个囧状况，怎么办呢？如果把第一张图也压缩的话，那么我做出来的压缩版PDF比原版的第一页“格子”更多，会到达不可接受的状态，该怎么处理这个页面大小不一致的问题呢？

我问过G老师，问过B老师，用过AdvancedPDFTools，试过打印重新输出PDF，全体二次输出的PDF是我原来PDF的3倍大小啊！试过软件解决，但貌似软件根本无法正常运作。问题没解决。

难道我真的被UT Rest in Peace了？NO~~~~

绝望之际突然想到为什么要对一整个合并好的PDF进行处理呢？我应该单独用第一页的图生成PDF，然后对PDF做固定页面大小的打印输出，再把输出后的单页面合并到另外90页里去。嘿嘿，还真行！效果见上右图。

具体做法是利用虚拟打印机，我用的是pdfFactory Pro，这个虚拟打印机能手动设置页面大小，所以，我就把那个超大的UT页面输出为和其他页面大小一致的尺寸了。可以，这样做非常可以。

WrestleMania上的The Undertaker至今为止（截至2011-03-21），但今天，我的确把他的18:0给终结了！嘿嘿嘿，PDF问题上无剧情的UT怎么可能是我的对手呢。

哈哈哈～～～～ 华丽地做了个18:1！

吹水一旦开始就会一发不可收拾，所以如何才能把握好吹水与思考的度呢？不容易啊不容易。

今天网友给我发了个3744*5616（2100万像素）的图片，足足19.2MB！我孤陋寡闻，没见过这么大的人物图，分辨率是240 DPI的，让人有大开眼界的感觉，用ACDSee加载就需要2.3秒，于是图片变成了真人大小那么恐怖，一条毛一粒豆豆都看得清清楚楚。看看我多么落后啊！我out了呀！这显然不是出于一个普通相机也不是出于一个普通人之手，所以，到底网友们是怎么找到这些专业级的studio照片的呢？真牛啊～～～ 不过回头想想，普通人真不需要那么大啦，照片再高清再大，放在屏幕里如果要缩小看的话还是会不爽。任何事适度就好。上星期我还在研究如何把大图压缩，这个星期我就见识到如此“庞大”的巨图。简单来说，我被震惊了，不过，震惊归震惊，震惊一次后往后就淡定了。

昨晚2点多接近3点才睡觉，今天早上8点起来，一整天都是游云恍惚状态，聊天时经常打错字。

所以呢，早点睡，必须早点睡，这周我还有很多任务要完成，所以，为了明天的努力，今天我得先储备了。

从前，周末是用来睡觉的，现在，周末是用来打字的，囧。

前天写了小谈php正则提取图片地址，但其实，提取src=里面的图片地址还不足够，因为不能保证那个地址一定是绝对地址，完全的地址，如果那是相对的呢？如果地址诸如：

albums/Candids/thumb_P1050338.jpg
/content/media/touts/5271608/5271654/15320982

那该如何是好？

有时在这些地址前面需要加http://example1.com/，有些甚至要加http://example1.com/example2/…/于是，要写出出一种法则符合所有要求，简直是天方夜谭。只能见机行事对症下药。有时，需要从前面动刀，有时需要从后面砍断。

今天，我惊讶地知道了一个道理，原来http://example.com/和http://example.com//////是一样的！

http://img3.douban.com/pics/nav/lg_main_a6.png

和

http://img3.douban.com////pics////nav///lg_main_a6.png

最终你都能到达

于是，对于一开始提到的两个相对地址如果要强行加入某前缀恢复成绝对地址的话，也不管前面有没有“/”，只管加一个“/”就好，“有杀错，没放过”嘛，多一个显示仍会正常，但少一个“/”，嘿嘿，你就别想成功了。开始的时候我还没意识到这种东西，复制了一大段代码，把一样的东西硬生生弄两份，一份加“./.”，一份不加。我这个火星来的，浪费时间了。

放出2个地址，公测一下网页获取图片的情况：

针对任何网页，需要登入的除外：http://xyark.serw5.com/img.php
针对Coppermine Photo Gallery系统：http://xyark.serw5.com/g.php（如果你认为弹出原图的js页面也需要的话，我只好囧你了）

普页是个对抓取任何图片的尝试，系统专页是为了展示什么叫做具体情况具体分析。试过的童鞋会知道，普页对某些使用Coppermine Photo Gallery系统的网站是行不通的，原因何在？就是那个前缀搞的鬼！但系统专页就能很好地避开了这个问题。

如果大家在测试时发现任何bug，欢迎留言告知。请低调测试，谢谢合作。

注：以上话题纯粹出于就正则谈正则，光技术谈技术，不可作非正当用途。若非正当使用而引发任何杯具、餐具本人概不负责。