您的位置：寻梦网首页＞编程乐园＞HTML园地＞HTML 4.0 参考文献
前页 后页 目录 元素 特性

HTML 文档字符集

>目录
  1. 文档字符集
  2. 字符条目
人类语言具有大量的文本字符并且被制作成大量的广泛的计算机系统。除非作出适当 的留心, 不同的字符并不能被全世界所有的用户代理器理解。

文档字符集

为了提高中间运算, SGML需要作为其定义中一部分每一个应用(包括HTML), 定义它自 身的文档字符集。一个文档字符集是一个抽象的字符集合(就象斯拉 夫字母"I", 在汉语中表示"水"等<译 者: 他妈的洋鬼子, 翻到这里差点没把我气死, 看来中国的文学绝不是洋人可染指的东西, 我仔细地研究原文, 丝毫没有中国的"水" 在斯拉夫语系中用"I" 表示的意思, 原文如下: such as the Cyrillic letter "I", the Chinese character meaning "water">) 和一套整体的字符参考集合。SGML在文档字符集中考虑一个优先参考次序。

HTML使用的文档字符集是根据[ISO10646]的世界字符集(Universal Character Set, UCS)。这个字符集逐字等同于Unicode 2.0 ([UNICODE])。两个标准都时常更新新字符并且改进方案都将在Web节点磋商。

就当前的说明书而言, 参考字符集为?ISO/IEC-10646 或 Unicode意味着是同一种字符集。无论如何, 当前的文本参考Unicode的描述文本的运算法则。

一致性的HTML用户代理器可能使用任何的字符解码方式(character encoding)接受或发送一个文本, 或者在内部描述一个文本。一个解码方法说明了一些文本字符集的子集。如ISO-8859-1 (常规的"Latin-1" 字符集参考并作为西方和欧洲语系的解码) 解码方式, ISO-8859-5 (提供斯拉夫语系)解码方式, SHIFT_JIS (日文解码) 解码方式和euc-jp (另一种日语解码) 解码方式保存了各自的字符集。

因此, 字符解码允许作者在方便的合适的文档字符子集下工作。作者无需知道任何的下层的 文档解码工作以及工具是怎样使用解码的?--- 在?UTF-8 下编辑日语编辑者就象在JIS 或SHIFT_JIS下编辑日语一样容易。

字符解码也意味着作者无需进入一个特定字符集的页面来输入文本。如果需要作 者自行对大型字符集解码是使人厌烦和浪费的 (即使如UTF-8包括了所有的Unicode)。

为了允许这个便利, 一致性的用户代理必须正确地对应于[UNICODE] 的所有字符的并且识别(就象目前做到的一样)任何解码方式("charsets")。一个建议 的对大量的脚本和语言而言的字符解码方式将在分列的文档中列示。

一个用户代理器是如何知道某个给定文本该怎样解码的?

在许多情况下, 一个Web服务器在Web上发送一份HTML文档, 它尝试指出文档的解码 方式(通过各种技术, 如在文件发送最起先的几个字节时, 对比数据库中已知文件和解 码方式, 等等)。服务器通过HTTP的"Content-Type"字段参数向用户代理器传送文档和 字符解码方式的名称。例如, 下面的HTTP头声明了字符解码方式为"euc-jp"。 

Content-Type: text/html; charset=euc-jp
在 "charset" 参数中的值必须是在[RFC2045] 中定义的"charset"的名称。

不幸的是, 并非所有的服务器发送关于字符解码的信息(甚至当字符解码方式不是广泛运用的 ISO-8859-1 解码方式)。 HTML因此允许作者使用一种在文档头使用META 元素来清晰地告诉用户代理器运用何种解码方式的途径。例如, 为了使当前文档使用 "euc-jp" 解码方式, 可以包含下面的META 声明: 

<META http-equiv="Content-Type" Content="text/html; charset=euc-jp">
此结构有个要注意的限制: 一个用户代理器无法对未知格式的文档字符集通过解译META 元素来判断字符解码方式。META 声明必须当解码方式在判断META 时自身可以被当作ASCII字符标准被识别时才能使用。在这些情况下, 一致性用户代 理器必须正确地解译META 元素。

概括来说, 一致性用户代理器必须在判断一个文本的解码方式时注意到下面的属性 (从上至下):

  1. 显式的用户动作来覆盖错误行为。
  2. 一个在"Content-Type"字段中的HTTP "charset" 参数。
  3. 一个通过"http-equiv"设置成"Content-Type" 的 META 声明或一个"charset" 值。
  4. A 和 LINK 元素中的"charset" 属性设置。
  5. 用户代理器启发试地试探而让用户设置。例如, 典型地用户代理器假定没有别的指示 存在时, 解码方式为ISO-8859-1。这个假定对于某些特定文档非导致无法阅读 (译注: 我们通常说的乱码)。
在所有情况下, "charset"属性或参数的值必须是在[RFC2045] 中定义的"charset"名称。

对于某些指定的运用, 如果有必要指定超越[ISO10646] 的字符集, 字符应当被指定到一个私有区域来避免当前和将来标准之间的冲突。这的确非常有阻 碍, 但无论无何, 理由是为了简便。

注意: 流行的web服务器能够设置关于文档使用何种解码方式 的信息。Webmasters 应当使用这些灵巧性但应当花费心费来适当的配置服务器。

字符条目

你的硬件和软件设置可能不允许你通过简单的输入设机制来指定所有的Unicode字符, 所以SGML指定了字符 - 独立(encoding-independent) 结构来指定文档字符集中的任何字符。
  • 数字字符参照(10进制和16进制)。
  • 已命名字符参照。
数字字符参照指定了Unicode的整数参考。一个使用语法符号&#D的数字字符参照; 相当于Unicode 10进制字符数D。一个使用语法符号&#xH 的数字字符参照; 相当于 Unicode的16进制字符H。16进制表示法是一种新的SGML协定并且是字符标准 使用16进制后的一个显著使用。

这里是一些例程:

  • Entity &#229; 指字母"a" 上面有个小圈(便如在挪威语中)。
  • Entity &#xE5; 相当于16进制表示法中的相同字符。
  • Entity &#1048; 指斯拉夫语系中的大写字母 "I"。
  • Entity &#x6C34; 用16进制表示法表示的汉语的水。
为了指作者在文档字符集问题上提供一条更直觉的途径,HTML提供一组已命名字 符条目。已命名字符参照用象征性的名称代替了整数参照。命名条目&aring 指 Unicode码的&#229;。然而并没有命名条目用来指斯拉夫语系的大写字母"I"。已命名字符条目的全部列表 也被包含于这份说明书中。

有四种命名字符条目因为经常被用来"避免"特殊字符而值得提及: 当文字作为元 素内容出现时, 你应当用避免使用< 而用&lt;来避免可能与标注起始符之间 的冲突。而& 符号应避免为&amp;来避免与字符条目参照起始符的冲突。

你应当在cdata属性允许的条目参照值中 避免&。另外, 你也应当用&gt 来代替> 号, 因此可避免老式的用户代理器错当后面的语句这个字符作为引用值时错误地凭感 觉认为这是一个标注结束符。

与其担心引号的使用法则, 不如把任何的实例" 用&quot 代替来得容易; 并且任何真正引用参数值的场合使用"。许多人发现在元素内容和属 性值中经常避免4个字符要来得简单。

  • 用"&amp;" 来表示&符号。
  • 用"&lt;" 来表示< 符号。
  • 用"&gt;" 来表示>符号。
  • 用 "&quot; 来表示" 符号。

已命名字符条目的名称是大小写有关的。因此&Aring; (大写A 加 环(Å)) 不同于&aring; (小 写 a 加 环å)) 指示的字符..

注意: 在SGML中, 在某些情况下可以省去数字参照或命名字 符参照后面的";"。(例如在换行或在标注符前时)。 在另外的场合, 则不被除去(如 在某个词的中间时)。 我们强烈建议在所有情况下使用";" 来避免用户代理器需要对此字符的说明。
前页 后页 目录 元素 特性