各大视频网站的视频截图抓取

-Flyぁ梦- — Thu, 28 Jun 2012 15:09:08 +0000

新的一个项目，要有视频的功能，当然只是简单的贴URL和标题罢了，不会涉及到要去上传视频文件，但是在展示视频的时候就需要用到视频截图了，自己去生成截图难度太大了也不现实，去视频的源网站抓取是可行也比较方便的方法。

试过优酷、土豆、酷6、56、腾讯、新浪、搜狐这些国内最大的视频门户，基本都成功获取到截图，其中属优酷最麻烦。

优酷

感觉优酷不愧为国内第一视频门户吧，技术算是最成熟的，安全也做得最好，直接体现在获取它的视频截图真心不容易。用查看html源码的方式根本无法实现，用firebug等工具找图片也不行因为图片是在flash里的。不过网上已经有文章告诉了方法，自己也可以通过httpfox或chrome自带的Network工具查看发起的http请求去找图片地址，优酷通过向URL：

1	'http://v.youku.com/player/getPlayList/VideoIDS/视频的ID/version/5/source/out'

而视频的ID就是普通视频URL中id_xxx中的xxx串，URL返回一段json字符串，其中的logo字段就是图片地址，可以发现此图片地址也是一个动态请求，非常复杂。

$url = 'http://v.youku.com/v_show/id_XMTA0NTM2MzI4.html';
preg_match_all("/id\_(\w+)[\=|.html]/", $url, $matches);
if(!empty($matches[1][0])) {
	$id = $matches[1][0];
	$u = 'http://v.youku.com/player/getPlayList/VideoIDS/'.$id.'/version/5/source/out';
	$json_str = file_get_contents($u);
	$json = json_decode($json_str);
	$image_url = $json-&gt;data[0]-&gt;logo;
	echo $image_url;
}

56

类似优酷，请求url为http://vxml.56.com/json/视频ID/?src=out，视频ID也好辨别。//测试可行，此来源网络

土豆、酷6、腾讯、新浪、搜狐

这些都比较简单，打开html源码细心点就能找到image的url，用正则就可以抓取出来了。其中酷6比较麻烦，把url中的:和.都用unicode编码了，先用字符串匹配给转了回来再去正则，因为不知道正则字符串中怎么搞反斜杠=.=（\\不起作用咩…）

土豆：开头的js代码中有个属性listData，里面放了5部视频的信息，选第一部，其中的pic属性，正则字符串：/,pic:\”([\w\/\.\:]+)\”/
酷6：Ctrl-F搜索bigpicpath属性，也在js代码中，正则字符串：/\”bigpicpath\”\:\”([\w\/\.\:]+)\”/
腾讯：pic属性，正则字符串：/pic \:\”([\w\/\.\:]+)\”/
新浪：pic属性，正则字符串：/pic\: \'([\w\/\.\:]+)\’/ 和楼上非常相似，难道又是抄袭？哈哈哈
搜狐：cover属性，正则字符串：/var cover=\”([\w\/\.\:]+)\”/

在网上找资料的时候发现一个看似很好用的PHP的VideoUrlParser类，试了下只有优酷和56是起作用的，然后自己再用正则的办法把剩下的视频网站搞定。

原先的VideoUrlParser类

改良后VideoUrlParser类

看看截图 , 正则 , 视频

2012-05-15 -- Play框架的Router机制和jregex包

看看 PHP

2012-07-03 -- 敏感词过滤，PHP实现的Trie树

Play框架的Router机制和jregex包

-Flyぁ梦- — Mon, 14 May 2012 16:23:37 +0000

最近对Play框架兴趣甚浓，对其有兴趣的功能都想一探究竟，先研究了下它的Router机制。概要地说，主要使用routes文件和正则表达式来完成URL到函数的映射，不过这里正则表达式功能比较强可以解析出{id}这样的参数，因此Play使用了第三方jregex包而不是JDK的java.util.regex包来执行正则表达式的工作。

Play的routes文件很清楚简单，每行一个Route，最重要的参数包含请求方式、请求URL和响应的函数，就像下面这一行：

	GET	/customer/detail/{id}	CustomerController.detail

Router机制机制具体包含解析和路由2个阶段。路由代码主要在play.mvc.Router和其静态内部类Route，解析Request代码主要在play.mvc.ActionInvoker中。

1.route文件的解析和路由表的建立

Play在启动初始化时，通过application.conf配置文件获取http.path参数，ctxPath = http.path;（这个就是相对路径啦）
调用Router.detectChanges(ctxPath);//若路由表没有建立或者routes文件被更新，解析文件
针对route文件的每一行（所以路由的顺序按照routes文件行的顺序为优先级），根据正则表达式获取method、path、action值，可能还有headers和params值
新建一条Route记录，并作一些解析计算（比如找出path中带有的参数信息）

以上面提到那条示例的route为例，method = GET，path = /customer/detail/{id}，action = CustomerController.detail，在新建Route记录作解析计算时，会先将path利用正则表示式转化为/customer/detail/{<[^/]+>id}的形式，然后拿出所有的{id}形式的变量信息，再然后继续通过正则表达式再转化为

	/customer/detail/({id}[^/]+)

这样的形式，这也是path最后的pattern，用来去匹配请求的URL。这个形式的正则表达式，java.util.regex包无法解析，而jregex包是可以处理的，并且group的时候可以根据变量名来取变量值，很方便。

2.URL的路由

当一个Http请求过来，就遍历路由表，当一条Route记录可以匹配当前的path，就可以获得在routes文件中配置的action值，就比如上面的CustomerController.detail，并通过正则表达式获得路径中的参数（id=?）。然后解析action值得到Controller类名和Action方法名（action值若不以“controllers.”开头的话会被自动加上），通过Play框架中的ApplicationClassloader获取到Controller类的Class类，然后通过此Class类反射获取到具体Action的Method，将这些解析的结果都赋给play.mvc.Http的静态内部类Request中，URL路由就完成了。

值得优化

这样看来，其实这自定义URL的路由机制还是蛮简单的，如果去除了动态参数绑定、静态文件路由特判等一些特殊功能的话，那真的是很简单很容易实现了。而且感觉Play的路由代码还有很多可以值得优化：

不带动态参数的路由路径（就是纯字符串匹配）可以通过HashMap来匹配，而不用每条都去执行一遍正则表达式
每条路由对应的Controller类和调用的Action Method应该在路由表建立的时候就应该被解析完毕并存储在路由表中，而不是每一个http请求都重新解析一遍

jregex包

看Play源代码发现了这个包，官方网址：http://jregex.sourceforge.net/。网站上很好地比较了它与java.util.regex的优劣，用变量名去Group即网站上介绍的named groups，而且据它自己介绍性能比较高。觉得当一个应用大量用到正则表达式的话，jregex是比较推荐的。

JRegex vs. java.util.regex

(+) JRegex is a Free Software
(+) JRegex is portable (runs under any version of java)
(+) JRegex supports more features (named groups, Perl5.6’s conditional statements and more)
(-) java.util.regex implements 2’d level of Unicode support (JRegex is level 1)
(-) JRegex is not a ‘standard’ library

看看 Play , 框架 , 正则 , 路由

看看 Java

2016-09-09 -- 64位Linux下Java进程堆外内存迷之64M问题
2016-08-18 -- 读java concurrency in practice
2016-08-05 -- 线程清理
2016-06-21 -- FutureTask简单分析和用法
2016-06-21 -- Semaphore简单分析

-Flyぁ梦- » 正则