您的位置：寻梦网首页＞编程乐园＞HTML园地＞HTML4.0参考文献

语言信息和文字方向

指定内容的语言:lang特性

指定文字方向:dir特性

文档的这部分讨论两个重要的影响HTML国际化的因素:指定语言(lang特性)和文档的文字方向(dir特性).

指定文档内容的语言:`lang`特性

特性定义

lang=language-code: 指定元素文字内容的主要语言.这个特性的值是在[RFC1766] 中指定的语言代码.请参阅关于语言代码信息的权威性文档.语言代码中不允许空格.所有的语言代码是大小写敏感的.缺省的语言是"unknown".

语言信息能够在变化多端的场合中用来控制对标注文档的渲染.一些此信息提供帮助的情况为:

协助搜索引擎
语音综合
为高品质排印选择纵向排列
选择一个引号设置
解决hyphenation绑定和空格
拼写和语法检查

lang特性值是一种标志了自然语言说法,写法或由人们在信息通讯中使用方法的语言代码.计算机明显示地被排除在语言代码外.

[RFC1766] 定义和解释了在HTML文档中必须用到的语言代码.

简单地说,语言代码由主代码和可能的空系列子代码组成:

   ?language-code?=primary-code *("-"subcode )

这里是一些语言代码实例:

"en":英语.
"en-US":美国英语.
"en-cockney":伦敦英语.
"i-cherokee":本土美国人说的伦敦英语.
"x-pig-latin":"pig-latin"语还没有在IANA 注册,这个组合控制了语言命名标志.

双字母主代码作为[ISO639] 语言缩写保留字.双字母代码包括FR(法语),DE(德语),IT(意大利语),NL(荷兰语),EL(希腊语),ES(西班牙语),PT(葡萄牙语),AR(阿拉伯语),HE(希伯来语),RU(俄语),ZH(汉语),JA(日语),HI(北印度语),UR(乌尔都语)和SA(梵文,Sanskrit).

所有双字母子代码被作为[ISO3166] 定义的国家代码来理解.

语言代码的继承

一个元素根据下列的优先权(从高到低)继承语言代码信息:

元素自身的lang特性设置.
一个含有lang设置的非全局元素(就是说lang 特性是从嵌套元素而来的).?!--Taken out after email from Martin Duerst
AMETAdeclaration equivalent of the same HTTPheader.For example:
```
<METAhttp-equiv="Content-Language"content="en-cockney">
```
-->
HTTP"Content-Language"头,由服务级设定,例如:

Content-Language:en-cockney

外部HTML源(例如用户代理器值,用户优先设定,HTTP头).

在本例中,文档主语言代码是法语("fr"). 其中一段被?声明为西班牙语("es"),在此以后主语言改变回法语.下列的段落还包括了?一条日文("ja")短语,而后主语言代码依然回到法语.

<HTML lang="fr"> <BODY>
...Interpreted as French...
<P lang="es">...Interpreted as Spanish...
<P>...Interpreted as French again...
<P>...French text interrupted by<EM lang="ja">some      Japanese</EM>French begins here again...
</BODY> </HTML>

语言代码的演绎

在HTML上下文关系中,一种语言代码首先应当被用户代理器作为层次接受,其次为单个的接受.当用户代理器根据语言信息调整了代码时(通过对风格页语言代码和lang 值的比较后)应当经常证实是否完全的符合,但同时也应当充分判断是否完全符合主代码.因此,如果HTML 元素中的lang特性值是"en-US",一个用户代理器首先应当?趋?向于符合"en-US"的风格信息,然后再是更通常?的"US"值.

注意:语言代码的控制者并不保证所有的具有通常前缀的语言能够被流利地理解.他们通常接受一个对用户来说为真的请求.

对于某些人为的语言如Elfish (译者:小精灵?恶作剧?恶作剧的小精灵?)或Klingon,它将使用它的辨别力来使用lang 特性来指示由内容解码方式而来的语言.直到[RFC1766] 的继承者来定义一个标准的解决方法,一个可能性是使用 x-前缀,例如x-elfish.

指定文字方向:`dir`特性

特性定义

dir=LTR|RTL: Specifies the default direction for directionally weak or neutral text in the element's content (left-to-right or right-to-left) in this document. (译注:可能是我才疏学浅,半路出家,对于上句我怎么也没法理解,我个人认为weak or neutral?指的是那种非标题的文字).可能的值为:

对于一个文档的主语言指定的扩展信息.作者需要指定缺省的文档条目和文句的文字方向.

[UNICODE] 说明书分配了Unicode 字符的方向并定义了一个(复合的)用来决定文字适当方向的运算法则.如果文档不包含可显示的从右到左内容,一个一致性用户代理器并不需要申请[UNICODE] 双向运算方法.如果一个文档包含从右到左的字符,并且如果用户代理器选择来显示那个字符,用户代理器必须使用双向运算法则.

虽然Unicode 指定了处理文字方向的特殊字符,HTML提供了高级的标注结构来完成此事:dir 特性(不要与DIR元素混淆)以及BDO元素.因此, 为了表达一个希伯来的引用语,可以直觉的写成

<Q lang="he" dir="rtl">...a Hebrew quotation...</Q>

然后是等同于Unicode 的字符参照:

&#x202B;&#x05F4;...a Hebrew quotation...&#x05F4;&#x202C;

用户代理器必须不使用lang 特性来决定文字方向.

在忽略本地文本的情况下,缺省的方向继承于包含它的元素.

双向运算法则介绍

下面的例程举例说明了双向运算法则期望的行为

请仔细研究下面的例程文档:

?english1HEBREW2english3HEBREW4english5HEBREW6

这此例中的字符(以及所有的相关举例?说明)在计算机中的存储方式如下显示:在文件中首先的字符是"e",其次为 "n"而最后为"6".

设想包含这个段?落的文档的主要语言是英语(从左到右). 那么这句的正确陈述了:

english12WERBEHenglish34WERBEHenglish56WERBEH
    -------    ?-------    ?-------
     ?H       ?H       ?H
--------------------------------------------------
           E

有点线的语句说明句子的结构:英语主导并且插入一些犹太文.当犹太文片断被提供双向运算法则用户代理正确地颠倒过来时并无需额外的标志来完成正确的说明.

在另一方面,如果文档的主导语言是犹太文(从右到左), 则正确的陈述为:

6WERBEHenglish54WERBEHenglish32WERBEHenglish1
   ?--------    --------    --------
     ?E       ?E       ?E
--------------------------------------------------
           H

于此情况,整句被陈述为从右到?左而插入的英语次序被双向运算法则颠倒了过来.

文字方向的继承

Unicode 双向运算法则需要一个初始的文字方向.为了指定基本的块一级元素的文字方向,可以设置?dir 特性.缺省的?dir特性是"ltr"(从左到右).

当?dir特性为块一级的元素作设定时,它仍旧对持续的元素和任何的嵌套块一级元素有影响.对嵌套元素设定dir 特性则可超越继承值.

为了对整个文档设定主导文本方向,可在HTML 元素中设定dir特性. 例:

<HTML dir="RTL">
...right-to-left text...
<P dir="ltr">...left-to-right text...</P> <P>...right-to-left text again...</P> </HTML>

另一方面,在行中的元素并不继承dir 特性.这意味着一个行中元素没有dir 特性并不为插入的双向法法则提供更高级别的处理.

为插入文字设定方向

[UNICODE] 双向运算法则自动地根据它们的继承方向颠倒插入字符的次序(如前例).无论如何,只有一级插入可以被识别.为了完成更多级别的插入方向的改变,你必须在行中元素中使用dir特性.

考虑与前相同的例?程:

english1HEBREW2english3HEBREW4english5HEBREW6

设想包含此段落的文档的主导语言是英语.上面的英语句子从HEBREW2至HEBREW4包含了一个犹太语部分.犹太语部分包含了英语引用(english3).因此希望得到的陈述为:

english14WERBEHenglish32WERBEHenglish56WERBEH
        -------
         ?E
    ------------------------
         ?H
--------------------------------------------------
         ?E

为了完成两次插入方向改变,我们必须提供额外的信息, 这里我们清楚地为第二个插入作了限制.在此例中,我们使用SPAN元素和dir 特性来标注文本:

english1 <SPAN dir="RTL">HEBREW2 english3 HEBREW4</SPAN>english5HEBREW6

作者也可以使用特殊的Unicode 字符来完成插入方向的改变.为了完成插入文字的从左到右,可用字符LEFT-TO-RIGHT EMBEDDING ("LRE",16进制202A)和POP DIRECTIONAL FORMATTING("PDF",16进制202C) 来围绕要插入的文字.为了完成从右到左的插入,可用RIGHT-TO-LEFT EMBEDDING("RTE",16进制202B)和PDF字符来包绕文字.

使用Unicode 字符来标注HTML方向.作者和权威软件的设计者应当意识到如果dir 属性与相对的[ISO10646] 格式字符一起使用时会引起的冲突.字愿非此即彼地来使用.标注方法提供了一种好些的完整的文档结构保证和减少了?在简单编辑器中编辑双向文本的问题.但某此软件可能更倾向于[ISO10646] 字符.如果两种方法同时使用,?要非常注意并应当多多尝? 试?来保证正确的嵌套和插入方向或是否产生未定义的覆盖和渲染结果.

超越双向运算法则:?A NAME="edef-BDO">`BDO`元素

<!ELEMENTBDO - - (%inline)*  ?-- I18N BiDi over-ride -->
<!ATTLIST BDO
?lang   ?NAME   #IMPLIED?--[RFC1766]language value --
?dir     (ltr|rtl)?#REQUIRED -- directionality -- ?>

开始标记:需要,结束标记:需要

特性在它处定义

lang(语言信息), dir(文字方向)

双向运算法则和dir属性通常足以满足插入的方向改变.无论如何,某些情况下双向运算法则会产生错误?的陈述结果.BDO 元素允许作者对选定的文字片断关闭双向运算法则.

再来研究与前包含相同文字的英语句子:

english1HEBREW2english3HEBREW4english5HEBREW6

设想字符次序正被一个用户代理器从左至右读入(位元流以"e"并以"6"结束)."e"在"english1"中的"n"左边,这是作者趋向的英文输入.无论如何,"HEBREW2"中的"H"在"E"的左边, 但这并不是犹太作者用来建立他们的文档的方法.例如, MIME([RFC2045]) 标准就需要电子邮件在位元流中按从?右至左的字符次序排序.这与[UNICODE] 的双向运算法则冲突,?它希望?犹?太字符从左至右排序.

因此,如果上例中的"HEBREW4"来自于犹太邮件,它的结构实际上为"4WERBEH".一个提供双向运算法则的用户代理器代将以错误的次序显示字符.
?

在此例中最容易的解决方式为通过在BDO 元素中放入犹太文电子邮件引用来超越双向运算法则,这里的dir特性为"LTR":

english1 HEBREW2 english3 <BDO dir="LTR">4WERBEH</BDO>english5HEBREW6

这告诉双向运算法则"让我从左到右!"并且生成希望的陈述:

english12WERBEHenglish34WERBEHenglish56WERBEH

BDO应当被用于希望绝对次序的场合(如:多语种的文档编号).dir 特性由这个元素决定.

作者也可以使用特殊的Unicode 字符来超越双向运算法则---LEFT-TO-RIGHT OVERRIDE(202D)或RIGHT-TO-LEFT OVERRIDE(16进制 202E).而POP DIRECTIONAL FORMATTING(16进制202C)字符在两种超越中均作为结束字符.

注意:在dir 特性被用在行内元素(包括BDO) 中并同时使用相对的[ISO10646] 格式字符时,再恢复它可能引起冲突.

双向和字符解码:根据[RFC1555] 和[RFC1556], 在MIME电子邮件中有特殊的使用＂chatset"参数值的协定来指定双向流.参数值"iso-8859-8"(犹太文)指视觉解码,"iso-8859-8-i" 指暗式的双向解码,和"iso-8859-8-e"指显示的方向性.

因为HTML使用完全的双向运算方式,确认文档必须加上"iso-8859-8-e"标签.暗式的双向性是全部Unicode 运算方式的一部分,?所以值"iso-8859-8-i"也可以被接受,但应当不使用.

值"iso-8859-8"定义了文档是视觉格式的,没有使用某些标注(象右对齐的TABLE 和没有自动换行)来保证在老的用户代理器上合理地不进行双向处理.这样的文档并不遵守目前的规格.如果需要, 它们可以通过在必须的地方加上?BDO 标记被制作成目前的规格(同时也在老的用户代理器上正确显示).相反的,在[RFC1555] 和[RFC1556] 说到的,以及iso-8859-6(阿拉伯语)则不是可视规则的.

字符方向和加入的提供

由于某些情况下特定字符的方向含糊(如阿拉伯语的某些情况),[UNICODE] 规格包含了一些用来正确解决的字符.HTML4.0包括一套命名字符条目来允许提供特定的Unicode 双向运算法则,并对某些在渲染时要考虑上下文语法关系的语言提供了一些帮助.

下面的DTD选录一些方向条目的陈述:

  <!ENTITY zwnj CDATA "&#8204;"--=zero width non-joiner-->   
<!ENTITY zwj?CDATA "&#8205;"--=zero width joiner-->   
<!ENTITY lrm?CDATA "&#8206;"--=left-to-right mark-->   
<!ENTITY rlm?CDATA "&#8207;"--=right-to-left mark-->

zwnj条目用来在对根据上下文加入可能出现但并不应当出现的情况下封锁加入.zwj条目则相反.例如,阿拉件字母"HEH"被用作"Hijri"的缩写,是伊斯兰教历系统的名称.而孤立"HEH"形式看上去象阿拉伯脚本中的数字 5(根据印度数字),为了避免"HEH"作为在年份的最后被作为数字5,以字母开头的"HEH"被使用.无论如何,这里没有下文可以被跟?随(就是说加入的字母).zwj字符提供了这个关系.

相同的,在波斯语中,有些情况一个字母后在草书中加入的字母在标准情况下是不该有的.zwnj被用来封锁在这种情况下加入字母.

对于其它的字符,lrm和rlm 被用来考虑语义不明字符的方向.例?如,一个双引号标记了一个阿拉伯字母和一个拉丁字母,那么引号的方向则不明确(按阿拉伯文字还是拉丁文字?).lrm和rlm字符有一个方向属性但没有宽度和词/句断义属性.请参阅[UNICODE] 以获得更多细节.

纵向翻转字符:双向运算法则颠倒了很好定义的字符组如引用语的陈述(参见[UNICODE], 表4-7).除去这此字符,双向性处理Except for these characters, bidirectionality processing leaves the shape of each glyph unaffected. 因此,如果你想显示单词"MURDER"并且看上去的效果象在镜子中(从右到?左的次序并纵向翻转),你可以使用一个BDO 元素并设置?dir的属性为从右到?左的文字方向,如:

<BDO class="mirror" dir="rtl">MURDER</BDO>

class 值"mirror"在风格页中的符合法择是选定一个特殊的字体使显示字符纵向翻转.

风格页对双向性的影响

通常,把一个元素从封闭区域的显示转换成行内或vice-versa 通过风格页可以直接进行.无论如何,?大封闭元素和行内元素之间的差异是对于双向运算法则是重要的,必要十分注意.

当某个行内元素没有设定dir 特性而通过风格页转换成封闭元素时,它继承了这个封闭区域的全局元素中的基础的方向dir 特性.

当一个没有dir特性的封闭元素通过风格页转换成行内元素时,表现结果是等价的,在双向格式部分,通过显式地设定dir 特性来获得(分配继承值)转换元素.

不可显示字符

用户代理器可能无法对意义深长的字符值进行渲染,例如, 因为缺少适当的字体或因为某个字符是内部字符解码方式无法识别的.

因为在这种情况下会有许多不同的事发生,?这份文档没有为特定行为提供解决.根据安装启用,这些可以被低层的显示系统处理而非就应用的本身.这份说明书建议用户代理的采取以下的行为:

采用清晰可见的,但毫不含糊的告诉用户某些资源的缺失.
如果用户代理器对丢失的字符提供数字化陈述,16进制(非 10进制)格式是较好的字符集标准(参见[ERCS]).

前页|后页|目录| 元素|特性?