标题: MIME Type 引出的两难困境 [打印本页] 作者: admin 时间: 2008-1-19 23:10 标题: MIME Type 引出的两难困境
一切从一个糟糕的浏览器开始，它完全不支持 XHTML。 什么是 MIME Type？ 为什么这么说呢？首先，我们要了解浏览器是如何处理内容的。在浏览器中显示的内容有 HTML、有 XML、有 GIF、还有 Flash……那么，浏览器是如何区分它们，绝对什么内容用什么形式来显示呢？答案是 MIME Type，也就是该资源的媒体类型。 $ R. }. t* B0 d8 C 媒体类型通常是通过 HTTP 协议，由 Web 服务器告知浏览器的，更准确地说，是通过 Content-Type 来表示的，例如:1 O& L; x8 [3 X0 [
Content-Type: text/html 表示内容是 text/html 类型，也就是超文本文件。为什么是“text/html”而不是“html/text”或者别的什么？MIME Type 不是个人指定的，是经过 ietf 组织协商，以 RFC 的形式作为建议的标准发布在网上的，大多数的 Web 服务器和用户代理都会支持这个规范 (顺便说一句，Email 附件的类型也是通过 MIME Type 指定的)。 7 Y2 I1 H: K s# p p/ W: t$ v$ A/ P 通常只有一些在互联网上获得广泛应用的格式才会获得一个 MIME Type，如果是某个客户端自己定义的格式，一般只能以 application/x- 开头。3 h; c1 o1 Z, k% M8 k
XHTML 正是一个获得广泛应用的格式，因此，在 RFC 3236 中，说明了 XHTML 格式文件的 MIME Type 应该是 application/xhtml+xml。5 q% t0 ]8 Q# j1 i0 R
当然，处理本地的文件，在没有人告诉浏览器某个文件的 MIME Type 的情况下，浏览器也会做一些默认的处理，这可能和你在操作系统中给文件配置的 MIME Type 有关。比如在 Windows 下，打开注册表的“HKEY_LOCAL_MACHINESOFTWAREClassesMIMEDatabaseContent Type”主键，你可以看到所有 MIME Type 的配置信息。1 a( `4 a( s! u- Q) v- t 浏览器处理 XHTML 和 HTML 有什么区别？ HTML 的语法过于随意了，有许多简写，标记不匹配的复杂情况，同时长期 Web 发展下来积累下来了许多错误的用法——比如一个文档里完全没有 标记——但浏览器还是得支持它，可想而知，为了支持这些“TagSoup”——也就是我们所说的那些，乱成一锅粥的标签——浏览器要很费力地去猜测一段标记的意思，努力以用户期望的形式表达出来。一句话说，虽然HTML 4.01 允许你用语义化、结构化的、内容与表现分离的方法来书写标记，但由于它沿袭了 HTML 这种格式，使得浏览器对于凡是 MIME Type 为“text/html”的文件，都得采用一种非常费劲的方法去处理，这对于 Web 的发展是很不利的。 4 |5 w6 {/ t9 K/ k; T* o 再说除了浏览器，还有许多其他的用户代理要阅读 HTML：纯文本的浏览工具、读屏器等等。 5 [$ X3 |9 b8 E+ B# x5 Z. }$ [创造 XHTML，很大一部分原因正是要通过 XML 重新严格地规范一遍标记，让这些用户代理可以以一种更简便的方式来解析这些标记。因此，XHTML 这种新的格式，天生就要求内容的发布者必须以严格的方式来标记自己的文档。 3 C! g$ U; j* G4 w# }/ E 当然，XHTML 对于内容提供者也有好处，此处先不展开，详见下文。! e) a+ E s& ^3 H6 U2 s/ _7 r MIME Type 与之又有什么关系？ 把前两节的内容合起来，你显然可以发现：一个正常支持 XHTML 的浏览器会根据服务器提供的 MIME Type 是 text/html 还是 application/xhtml+xml 来区分获取到的内容是 HTML 还是 XHTML，对这两种格式，分别以两种不同的方式来解析文档，后者解析起来要严格得多，但对于用户代理开发者和内容提供者都有很大的好处。 ! L$ K: M9 x! P" W: C- r8 g 那么，那些浏览器正常的支持了 XHTML 呢？答案是 Mozilla、基于 Mozilla 的浏览器如 Netscape 7 和Firefox、较新版本的 Opera 和 Safari 等等。但不包括 Microsoft InternetExplorer。问题是，这一“不包括”，就除掉了大约 90% 的浏览器市场啊，在我们抓狂以前，先来看看 IE 是什么处理 application/xhtml+xml 的：IE 不认得这种 MIME Type，它要么提示你是否下载那个文件，要么就把文件内容当作纯文本显示出来，反正是不可能正常显示标记。 2 C, g- p+ O& t$ {: @4 s 这正是造成我们不得不给 XHTML 文档标以 text/html 的原因 1，实际上，目前 Web 上 95% 的 XHTML，都是扮成 HTML 的 XHTML (包括 w3.org)，浏览器 (包括我们引以为傲的 Mozilla) 压根没有用 XML 解析器去解析那些 XHTML，而是沿用处理标签汤的老办法。 ; D4 n6 t% ^* F$ u- g2 ]) S# X, ~ 这个时候你会问了，在我看起来，老办法显示得很好啊，干吗为此感到头疼呢？问题正是出在“看起来”这个词上，实际上，一些细微但是不可忽略的差别仍然存在。8 {* M( k* m1 G; h1 ^& | 用 application/xhtml+xml 方式解析 XHTML 与用 text/html 方式解析的差别 下面所说的“HTML”，就是指 text/html 的解析方式；相应地“XHTML”就是指“application/xhtml+xml”的解析方式。 $ s# X! H/ P+ n) T; N
这是最重要的，严格的 XML 解析至少要求文档是 well-formed 的，也就是标签要正确开闭，& 等 XML 实体要正确使用。
在 HTML 中 是用户所能看到的全部视域，给 body 设置背景色就是给整个文档设置了背景色，但在 XHTML 中并非如此，给 设定背景色的效果和给 设定的不同。
在 HTML 中 CSS 规则中对元素的匹配是大小写不敏感的，BODY 和 body 匹配的是同一个元素，但在 XHTML 中却是大小写敏感的。
在注释中隐藏的 javascript 脚本会被 XHTML 忽略。
document.write() 不能在 XHTML 中使用。
HTML DOM 和 XHTML DOM 的元素和属性返回值是不同的，HTML 中是大写，XHTML 中是小写。
还有不少其他的 DOM 问题。
总结起来就是，我们正在广泛使用的其实是一种看起来已经 XHTML 化的 HTML，想象一下吧，如果要求所有这些网站立即把 MIME Type 换成 application/xhtml+xml，即便用可以正常解析 XHTML 的浏览器来浏览，它们多数会死在前面列举的某一条原因下，无法正常显示。然而这不好说是 XHTML 的错，正常的处理理应如此，只不过我们一直被纵容了。# ]' c5 B: ^/ V A, l
可是 W3C 还是不断要求我们以正确的 MIME Type 来提供 XHTML，为什么呢？因为我们要用到 XHTML 提供的好处啊，只有被认为是 XHTML 或者 XML 文档的东西，浏览器才会启用这些“好处”，比如你可以试着在 IE 中打开 XHTML 中嵌入的 MathML 看看，没有效果，它被当作 HTML 一样显示。 j2 l8 i/ A) l' @% d# d! w, ~2 N N 现在的问题是，既然把文档设定为真正的 XHTML 是如此的麻烦，会带来如此多的问题，干吗不舒舒服服地呆在 HTML 上呢？为什么要往 XHTML 过渡？XHTML 提供的“好处”值得我们为此付出如此多的代价吗？3 x* w& v a3 v% a XHTML 的优势 最重要的两点是：9 i/ v* S' F: G& L j9 _$ i
除了前面讨论的用户代理易于处理以外，实际上，大量的基于 XML 的工具，许多对 XML 有很好支持的编程语言，都能够方便地解析你的文档，从中提取出需要的信息。当然，也包括搜索引擎。
