IOS开发中HTML5到底需要多少种编码格式

IOS开发中HTML5到底需要多少种编码格式是本文要介绍的内容，主要是来了解HTML5到底需要多少编码格式才能支撑的起来，来看详细内容。

HTML5 的 <video>标签真的很威武，几乎所有的主流浏览器可以直接提供本地的视频播放功能，相对于以前通过 Flash 这种类似“中继”的播放方式，要先进很多。同时也为一些不支持 Flash 播放的移动设备带来的希望。

也许，你会因为 <video>标签可以支持到的视频种类而感到困惑。嗯，到底为了实现 HTML5 的特性，到底要转换多少种编码格式的视频？WebM，Ogg 还是 MP4？那…iPhone 和 Android 又需要哪种编码格式？如果我还要提供高、中、低三种码率的视频呢？

下面就来看看到底 HTML5 <video>标签的详细情况吧。

关于 Web 格式

目前来说，广泛被浏览器支持的的视频编码格式总共有三种，但是没有一种可以达到通吃所有浏览器的境界。所以对于同一个视频，至少需要两种格式，才能在所有浏览器里播放。

首先要选择一个被支持最多的视频格式，那么就是 MP4 H.264 这个组合了，音频方面则是 AAC 或者 MP3。MP4 封装的视频，可以在 Safari、Chrome 和 IE9 里播放（悲剧的是 IE9 只支持 Windows Vsita 和 Windows 7）。同时，这个组合也是你通过 Flash 来作为播放器播放的最好选择了，同时这个组合也可以在很多手持设备上播放，比如 iOS、Android、Blackberry、PSP、PS3 等等。在 H.264 编码的时候，可以选择 “High Profile” 以获得最好的编码质量，或者 “Baseline” 来应对一些移动设备。

除此之外，还有两个组合，WebM VP8 和 Ogg Theora Vorbis 来满足其他的浏览器。WebM 可以在 Firefox（4.0 ）、Chrome（6.0 ）和 Opera（10.60 ）中播放；Ogg 可以在 Firefox（3.5 ）、Chrome（3.0 ）和 Opera（10.54 ）中播放。

那么问题又来了，如果要从中选择一个，是 Ogg 呢，还是 WebM 呢？

从我们（Zencoder）来看，WebM 肯定是未来开放式视频格式的领跑者，VP8 比起 Theora 来说，要更加的优秀，而且还有强大的社区作为其后盾，特别是 Google 的支持。

反过来看 Ogg，其最大的特点是她支持了 44.64% 的浏览器（译者注：这里应该是指浏览器分部率中，可以播放的比例），而 WebM 仅支持 9.35% 的浏览器。如果仅着眼于 2010 年 10 月，那么 Ogg 也是一个不错的选择。如果你是为了未来的 1-2 年，那么WebM 似乎更有优势一些。

推荐：MP4 WebM 或者 Ogg 其中一种，当然全部都编码出来也可以 ^^。

关于移动设备

和浏览器的情况一样，在移动设备上也没有一个可以通吃全盘的编码方案。不同的移动设备有着不同的编码标准，甚至比起浏览器领域来说，更加的复杂。不过还是有一些方案可以让你省不少精力的。

在这里你可以查看一个完整的移动设备编码列表。

1、现在绝大多数的移动设备都支持 MP4/H.264。包括 iOS 系列的产品（iPhone、iPod、iPad、Apple TV 等），绝大多数的 Android 设备，新的黑莓手机。对于这类设备，编码的时候应该选择 “Baseline”。在分辨率上，对于 iOS 和 Android 设备，选择不高于 640×480 的分辨率即可，对于黑莓系列手机，选择不高于 480×360 的分辨率即可。

注意：可以在 iPhone 上播放的这类编码格式，同样也可以在 HTML5（当然仅仅是一部分浏览器） 或者 Flash 中播放。如果你怕麻烦或者想节省一些转换花费的时间，可以考虑选择在编码的时候，不高于 iOS 系列设备和 Android 系列设备的分辨率。如果你不怕麻烦，并且视频在不同的码率上表现差异很大，或者需要在电脑上有更清晰的表现，就多编码出来几个不同的码率吧。

2、对于一些老的移动设备，选择 3GP/MPEG4。绝大多数的黑莓手机和一些 Android 的手机，都支持这种格式。同时，3GP 在 iPhone 和 iPod 上都可以播放。

3、关于 WebM，现在也许还不是一个好的选择，虽然在一些 Android 的手机上已经可以播放，但是支持还不是很广泛。预计未来 1-2 年会有更多的支持 WebM 格式的手机。

推荐：怕麻烦则 MP4 格式，640×480 或者 480×360。不在乎编码时间和存储空间，就应该选择三种 MP4 编码方案（480×360，640×480，720p “Main profile” ）

外加一到两种 3GP 格式（320×240 或者 176×144），可以参考这份日志来获取更加详细的编码参数。

关于多种比特率

有可能你在考虑，是不是要为带宽很足的用户准备高比特率的视频，并且为了照顾小带宽的用户，另外再准备一份低比特率的视频呢？如果你的用户已经 开始在互联网上观看高清的视频，那么为了迎合这类用户的习惯和用户体验，那么答案则为是。可以考虑提供 2-3 种不同比特率或者分辨率的视频来满足使用不同互联网连接方式的用户。比如提供一份 640×360 和 一份 1280×720 的选择。未来我们会更多的讨论这个问题。

关于流媒体播放

本篇文章不讨论关于流媒体的问题，并且 RTMP（Flash）、Smooth Streaming（Silverlight）、HTTP Live Streaming（iOS）都要求特殊的视频格式。这已经超出了我们要讨论的范围了。未来将会有相关的文章进行讨论

结论

1、最低限度的支持 HTML5，应该选择 MP4 WebM 或者 Ogg 其中的至少一种，并且使用 Flash 来播放 MP4 以便提供向下兼容支持。

2、移动设备方面，H.264/MP4 会让你省心很多，如果可以提供 2-3 种不同分辨率和码率的视频，会大大增加兼容性。

建议

以下是关于所有类型的视频编码方案建议，Zencoder 支持以下列出的所有编码格式（广告了…）

1、只为能播放

HTML5，Flash和移动设备：MP4/H.264，使用 “Baseline” 编码，480×360 或者 640×480

HTML5：WebM 或者 Ogg

2、更上一层楼

HTML5，Flash：MP4/H.264，“High profile” 编码

HTML5：WebM

HTML5：Ogg

移动设备：MP4/H.264，“Baseline profile” 编码，分辨率 480×360 或者 640×480

3、我要支持所有设备和浏览器

HTML5，Flash：MP4/H.264，“High profile” 编码

HTML5： WebM

HTML5：Ogg

移动设备：MP4/H.264，“Baseline profile” 编码，分辨率选择 480×360 以便提供高兼容性

移动设备：MP4/H.264，“Main profile” 编码，分辨率 1280×720 以便支持新的设备（如 iPhone4、iPad 和 Apple TV）

移动设备：3GP/MPEG4，分辨率320×240 和（或） 177×144 以便支持非智能手机。

富文本转html字符串

字符串转富文本

最近项目遇到的问题，因为后台返回的数据是HTML字符串，所以就按照常规处理方式把HTML字符串转换成富文本的字符串来处理，事实证明，tableview会非常卡，并且造成线程阻塞,无法响应事件

解决方案1.首先我想到的是把耗时 *** 作放在子线程来 *** 作

解决方案2. 因为是cell展示，所以只需要展示文本信息就行，那就过滤掉HTML标签，瞬间解决所有问题。所以在列表展示数据的时候HTML转换NSAttributedString一定要慎用

下面简单介绍一下NSScanner

NSScanner是一个类，用于在字符串中扫描指定的字符，翻译成我们需要的字符串或者数字，核心就是位置的移动 即scanLocation的移动变化

在上面的方法中首先指明了要扫描的对象 html（NSString） NSString * text 很重要 把我们要扫描出来的字符串存到text里面

而这个扫描到的字符串就是>之前的字符串 scanUpToString这个方法的意思是将scanLocation停留在>之前 并把之前的字符串传给text。

回头来看看我们去除html标签的方法 整个过程都是在扫描过程中进行的NSScanner在执行scanUpToString这个方法时一旦扫描到需要的字符串比如例子中的“<”，其scanLocation就会变为html的初始位置。所以，要在执行完一次完整的扫描后 把html标签用空字符串替换掉，在进行下一次扫描，也就是说再while中 html字符串的标签字符会越来越少，而每次扫描的初始位置相对没有变化都停留在上一次扫描结束的位置，即"<"标签的前面。

参考链接----传送门

---