类库大魔王
类库大魔王 多年C++、Go项目经验,长期从事跨平台(Windows/macOS/iOS/Android)应用架构设计与开发。

Ninayan W.I.P.(8)


  今天在处理超链接的问题,这是最重要的一环。
  Ninayan提供给用户的信息分两大类:图片/视频和文章,微博消息只算是附属品。所以从微博消息中得到一个URL后,最终要能正确识别出它是一个图片/视频,还是一篇文章(当然,文章中也可以有图片和视频,但重点是它有文字),对于其他不可识别的类型,比如zip,则忽略。
  我设计了如下的处理流程:
  1、将URL与embed.ly可处理的类型用正则表达式匹配一下,如果可以匹配上,则用embed.ly处理,不能匹配上,则假设它是个短网址,将其还原成长网址。
  2、embed.ly处理后,会返回缩略图和原图(如果是视频,则是一段HTML,可能还会有一段HTML5代码)的URL,假设这URL也是个短网址,也将其还原成长网址。
  3、还原成长网址后,与原来的短网址比较,如果两者不相等,则假设该长网址仍然是个短网址,继续还原,如此循环迭代,直到还原失败或两者相等,最后还原的最终长网址与embed.ly可处理的类型用正则表达式匹配一下,如果可以匹配上,则用embed.ly处理。
  4、如果第3步最终的长网址不能与embed.ly匹配上,则认为该网址是真正的最终应该由Ninayan处理的网址,可分为前面说的两类,图片/视频和文章。
  至于怎么辨别出属于哪一类,我决定采用一个很粗糙的办法,如果前面经过embed.ly处理过的,那么肯定是图片/视频,或者URL最后是以诸如.jpg/.png/.gif等known的图片/视频文件扩展名结尾,那么也是图片/视频,其他的则都划入文章类型。而文章类型其实是个很粗糙的结果,网页是要经过像Readability那样的处理才是最终显示给用户的,而在Readability处理的过程中,可以过滤掉诸如.zip等不支持的文件类型的。
  这个方案也只是考虑到了URL在网络交互上的处理过程。还有这处理结果怎么通知本地数据存储模块和UI显示模块,也是个问题。而这个问题涉及到何时通知,通知时采用什么数据结构,以及本地存储时采用什么数据结构。

感觉本文不错,不妨小额鼓励我一下!
如果你有Visa、MasterCard之类的国际银行卡,也可以考虑以下选项:
如果你看不到评论框,说明Disqus被墙了。