iOS解析新浪微博的@##以及URL链接并展示

最近在做一个跟微博相关的应用。其中涉及到了对微博中@、##以及URL链接的解析与展示。分享一下个人处理的方式，希望对需要的人有所帮助。

最终的展现效果：

首先，第一步是你得从纯文本中找到它们。毫无疑问，采用正则表达式匹配是最佳的方式。我采用的是RegexKitLite库。

解析这三种格式的正则表达式如下：

分别为：匹配<a></a>标签，匹配a标签的href属性，匹配URL地址，匹配微博中的@，匹配微博中的##(topic);

对于文本的处理：

这里需要注意的是，微博的种类有很多种。大部分的地址都直接是纯粹的Url，但其中的一种微博(记不清是视频还是音乐的)返回的url是附带在a标签的内部作为href属性的。这样就不便于统一处理，所以我采取的做法是：首先，让解析流程统一化。也就是先把文本中包含的a标签去掉，把href包含的链接作为纯文本。然后，解析出微博中的这三种特殊字符串，并为其包裹一层a标签。

接着，谈谈关于展示的问题。上面你可能想知道为什么需要包上一层a标签呢？那是为了展示用的。

如何让@、##、URL高亮呢，我目前只找到三种展示它的方式：

(1)   Three 20中的TTStyledTextLabel

(2)   原先用于展示Twitter，后来被改写支持中文展示的FancyLabel

(3)   最擅长呈现html标记的UIWebView

三种我全部试过，最后还是选择了UIWebView。下面说明一下未曾使用前两种的原因。

其实，原本我是不倾向于使用UIWebView，我想能使用普通的控件，就无需把UIWebView这种大部头搬出来“救场”了(据说UIWebView的内存泄露问题由来已久，后续我会谈到这个问题，本篇不作深究)。

我首先尝试的是第二种：FancyLabel。开始使用的时候，觉得好像真能展示。它文件内部已经存在了解析的正则表达式了，并且RegexKitLite也是作为它的组件使用的(可见原理都是一样的)。但展示了几个发现：@、##、URL各种不同方式的复杂搭配，它显得有些无能为力(这其实是它附带的正则表达式匹配得不够健全的问题)，但当时我却不是这个原因放弃它的。放弃的原因是，它无法“折断换行”，也就是，当一个匹配项它呈现的位置已经在一行的末尾了，它无法呈现匹配项的一部分，同时将另一部分折断到下一行的起始去显示，它的处理方式时另起一行。这看起来非常难看，后面还有空间空出来了，就直接跑到下面一行去展示了，并且该行它也是独占的，后面的文本也不得不另起一行，显得非常不流畅。最致命的是：你无法算准它的高度，因为它归根到底是一个UILabel的子类。对于Label的高度，在它的宽度固定的情况下，通常都是带着它文本的字体大小算出来的。但这个时候，你已经无法准确地计算高度了(因为普通的计算方式，它默认Label文本的呈现方式是那种“流式”的，你换行起始占用了增大了它的高度，但在算的时候你无法将这些情况估算到)，所以它影响了接下来用于呈现评论/转发等控件的布局。

放弃了第二种，又在网上寻找其他的解决方案，发现大名鼎鼎的Three 20里面，有一种呈现富客户端文本的控件：TTStyledTextLabel，支持对连接、简单html标签以及样式。那我将这些解析出来的内容，包裹上<a></a>不就可以了吗？我当时就是这么想。结果同样不是太理想，也是无法折断换行的原因。当然，如果你下面没有依赖它来布局的控件(如同你在web中使用的是绝对定位，而不是相对定位一样)。那么你还是可以使用它的。

这可不像FancyLabel，你直接把接受到的纯文本丢给它一了百了。它自身只负责普通html标签以及链接的解析，所以你给它的文本必须是处理好之后的。其实，你处理好之后展现也是没有问题的。如果你使用的是UITableView的方式来展示它，并且你自定义了UITableViewCell来呈现它，会显得很麻烦。因为这个部分可能要计算两次高度：在heightForRowAtIndexPath代理方法中算一次，在自定义的Cell内部，为了下面控件的布局，必须算一次。其实，TTStyledTextLabel自身是可以返回高度的，并且它返回的高度是正确的(即使它有些匹配项是另起一行的，但占用的“额外”高度也被它包含在内，这也是我认为它很强大的地方)。但，在heightForRowAtIndexPath计算起来就不那么简单了，我简单得把一样的文本给一个“帮助方法”，它内部构建一个TTStyledTextLabel对象，获取到文本，并算高度，还是有所偏差。所以说能不能使用，主要是看你用怎样的方式来展示你的微博内容。如果你想用，这样是不够的，因为它只是完成了呈现的工作。使用过新浪微博或者腾讯微博客户端的人都知道，@、##、URL这些高亮文本是可以点击的。很遗憾的是，TTStyledTextLabel自身对于a标签的点击事件仅仅只是，用它内部的另一个浏览器组件来加载href属性的URL，这显然不是我们想要的。为了改变它这种默认行为，我继承了TTStyledTextLabel，重写了它的点击事件，以拦截它的默认行为：

在上段代码中：NSLog(@”others”);部分，你可以去实现你的逻辑：比如点击@XXX，弹出XXX的个人详情。你可以在地址中包含你需要的数据，在上面可以通过获得url来得到你的数据。

你可能会好奇，为何这两种方式都出现这种无法折断换行的行为呢。这也是由它们的实现方式决定的。你看到上面这段代码中，比如：TTStyledLinkNode、TTStyledButtonNode，它把相应的匹配项都转化为特定的Node，对这段Node单独绘制(这里牵扯到CoreText以及NSAttributeString等，具体未有空详细研究)，比如某个子节点是可点击的，那可能就是TTStyledButtonNode类型，也就形如一个Button。很明显，一个Button内的文本，如果在一个区域显示不下，只能另起一行了。

要应对这种方式，看来不得不请出：UIWebView。它本身也擅长于图文混排以及富文本的呈现。你只要按照上面的方式处理好文本，然后在UIWebView里设置相关样式，就可以完美呈现，甚至图片都省去了获取并处理的过程。形如：

一不用二不休，下面的转发与评论的列表，也顺便用它来展示吧。

展示的问题完美地解决了，下面还要能够响应点击事件。这里同样要改变UIWebView中a标签的默认行为，使其响应本地调用(obj-c代码)。怎么办呢？用js给a标签注册一个click event，然后它调用一个方法，发起一个请求：

它其实并不是一个真实意义上的url地址，只是一个携带了操作命令以及参数的“virtual url”。发起的任何请求都会被：

UIWebView 的shouldStartLoadWithRequest代理方法截获。

然后在这里，你可以判断相关的请求行为，获取参数，进行你的本地处理，比如弹出XXX的详情的模式窗口：

这篇就分享到这里，下面准备就UIWebView的使用分享一些经验。比如使用一些模板引擎来增强代码的可读性以及提升开发效率。对于“微博详情界面”我使用了两个模板：一个是用于呈现微博本身的HTML模板引擎；另一个是JS模板引擎(为了提升响应速度，并且为了配合转发/评论列表的异步加载)。