我的天

这几天准备把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，欢迎留言告知。请低调测试，谢谢合作。

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

迷上了正则，不断尝试着新花招，首先感谢TNA的非完全输出RSS，然后再次感谢SH的强迫性学习。没有TNA，我不会去看正则，更不知道世界上有种这么牛的表达式；不是SH的死活说他不懂不知道，我也不会硬着头皮去琢磨，去改进。达到同一个目的，正则的表达方式可以不唯一，没有做不到，只有你没想到。可以这样说吧，正则就是玩设定规律，我大爱这种东西。没有比设定规律筛选东西更让我兴奋、感到awesome的了。

分享一下在php环境下使用正则提取图片地址的一些小心得：

图片网址规范的html代码无非就是

<img style="囧1" title="囧2" src="囧3" alt="囧4" width="囧5" height="囧6" />

囧1和囧2是非必需的，若要通过XHTML认证囧4、囧5、囧6必不可少，囧3是核心内容，当然就不能少了。

就正则谈正则的话，我写出的最短匹配是

(?<=img.+?src=”).*?(?=”)

不过，这条在php里不行，会出现：

Warning: preg_match_all() [function.preg-match-all]: Compilation failed: lookbehind assertion is not fixed length at offset *** in ***

纠结了很久，都不行，原因何在呢？试了很多次，终于发现问题在(?<=img.+?src=”)这个零宽断言里，在php中，零宽断言里不支持类似“*”、“+”这些无限次的东西，于是报错了，把“.+?”改为定长就好。不过，要“img”和“src=”之间定长基本上是不可能的。通常，图片地址的img和src只会相隔一个很简单的空格，但不排除某些情况在src之前，img后有alt、titlte等东西。

所以

(?<=img.src=”).*?(?=”)

或

(?<=img\ssrc=”).*?(?=”)

可能可以，但不保证100%没问题。

你也许会问，单纯

(?<=src=”).*?(?=”)

不行吗？通常情况，可以，但，搜索过页面的盆友应该知道，除了图片地址用src开头以外，javascript地址也用src开头！而且，太多神通广大的不可预知因素隐含其中，于是这个貌似很简短完美的写法就行不通了。

你又或许会问，聪明简短的不行，我把图片的后缀列出来，总该可以了吧，如

(?<=src=”).*?\.(jpg|jpeg|gif|png|bmp|JPG|JPEG|GIF|PNG|BMP)

的确，这个写法实在是很老实，不过，你见过没有后缀的图片？wwe.com有很多这种例子呢

RAW http://us.wwe.com/content/media/images/Headers/15559182
SmackDown http://us.wwe.com/content/media/images/Headers/15854138
NXT http://us.wwe.com/content/media/images/Headers/15929136
Superstars http://us.wwe.com/content/media/images/Headers/15815850

上面的网址都是图片，但都没有传统后缀，你老实也没用，还是不能获取到它们。

怎么办呢？还可以这样

<img(.*?)src=”(.*?)(?=”)

和上面的表达式不同，这次的结果中array[0]的内容不是我们想要的，我们要的图片地址在array[2]里。为什么呢？因为我们用了2个(.*?)，每个“（）”的东西会自动存在一个组里，而array[0]代表结果的汇总，array[1]包含了img和src里的所有东西，array[2]才轮到我们想要的图片地址。这种匹配方法，既能匹配有传统后缀的图片，也能匹配一些无后缀的图片文件，同时又不会杀错其它src=文件。个人感觉还是不错的，呵呵。当然了，如果你还有更好的建议，请马上留言，全球人民都会感谢你！

你到底要什么样的图片，是固定格式还是其它？得具体情况具体分析呢。

我的建议是：

如果你要的图片地址的格式是img空格src=的，请使用：(?<=img.src=”).*?(?=”)，数组唯一，你懂的。

否则，请使用<img(.*?)src=”(.*?)(?=”)，记得留意有用内容所在的数组位置哦！

花费了好几个小时学习正则表达式（Regular Expression），简称regex。非常非常强大的一个程序员利器，在此，再次感谢SH童鞋的强迫性学习。在多种程序语言里正则都通用，用简单的符号却能组合出任何你需要的结果。看着那堆“\/#$&*^()_+|{}<>?=.”等实在会把人弄疯掉，再加上26个英文字母的大小写组合，宇宙就能编出来！这让我想起了大学时期老师教的文献检索，在说到英文数据库的时候就是这般*来?去的，但和相比，英文数据库的搜索方法只是个非常非常的简化版的正则，小儿科而已。

简单看了几个正则教程，最终觉得还是要自己打开个正则测试工具（如Windows下的Regex Tester）实操。

经过还不算太辛苦的挣扎，对TNA而言，我要提取的信息可以用以下正则实现：

(?<=href=”).*\.jpg.php

说明：“(?<=囧)”，定位在囧后；“href=””，一个字符串，也就相当于囧；“.*”，别以为“.”是连接符“*”是任意字符，恰恰相反，“.”代表除换行符以外的任意字符，“*”代表前面的东西，也就是除换行符以外的任意字符可以重复零次或更多次；“\.”，其实就代表了“.”，在正则里，“.”必须用“\”转义；“jpg.php”我的原意是一个字符串，但在正则里，看来“.”也不会被看作“.”，而代表一个除换行符以外的任意字符，也无伤大雅，毕竟我希望的“.”也在正则“.”包含的范围内。

除了用上面的“(?<=href=”).*\.jpg.php”以外，还能把正则改写为：

(?<=href=”).*\.jpg\.php /*把“.”全部正确转义，不打擦边球*/
(?<=href=”).*\b.jpg.php\b /*把“.jpg.php”看作一个单词，很自然地把其中的“.”一般字符化了，“\b”用于匹配单词的开始或结束*/

具体在YARK的正则是这般写的

preg_match_all('/(?< =href=").*\.jpg.php/', $data, $log);
囧囧囧囧
for($i=0;$i<count($log[0]);$i++) 
{  	
	<?php echo '囧'.$log[0][$i].'囧' ?>			
}

说明：由于我的正则表达式里只有一个未知数，也就是“.*”折腾出来的内容，所以，正则结果在新建的$log将是一个二维数组，具体内容将在[0][囧]里显示。如果，正则里有多个未知数，未知数就会分别出现在[0][囧0]、[1][囧1]、[2][囧2]等等里面了。得打一套“组合拳”才能把它们拼凑在一起。

正则搞定了，YARK的TNA瓶颈当然就没问题了啦！

******************* YARK专栏 *******************
2010-11-19
update
* 改进TNA功能，不再依赖页面提供的rss而是自编正则表达式，提取页面信息，再分析出图片地址
bug
* 暂无新发现
plan
* 留个门，对付任何规则资源（正则是强大的，就看你怎么用了）
******************* YARK专栏 *******************

自觉通过自学又提升一个矮矮的层次了。