javascript国际化实现原理

资料地址：http://lamp.linux.gov.cn/Apache/ApacheMenu/content-negotiation.html

Apache 2.0手册中文版翻译项目 [本文译者: kajaa * ]
项目说明 | 项目进度 | 项目讨论区 | Apache手册中文版



--------------------------------------------

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本



Apache主站 > HTTP服务器 > 文档 > 2.0版本
内容协商
Apache支持HTTP/1.1规范中定义的内容协商， 以根据浏览器提供的设置选择不同媒介类型、语言、字符集和编码的最佳表现， 还有对来自浏览器的不完整内容协商信息作智能处理的能力。

内容协商由mod_negotiation模块支持， 并被缺省地编译进服务器核心。

关于内容协商
Apache的内容协商
协商的方法
打乱品质值
透明内容协商的扩展
超链和名称转换说明
缓冲说明
更多资料

关于内容协商
一个资源可能会有多种不同的表现形式，比如，可能会有不同语言或者媒体类型的版本甚至其组合。 最常用的选择方法是提供一个索引页以供选择。但是由于浏览器可以在请求头信息中提供其首选项的表现形式， 因此就有可能让服务器自动选择。比如，浏览器可以表明希望看见法语的信息，如果没有，英语的也行。 如需仅请求法语表现形式，浏览器可以发出：

Accept-Language: fr

注意：此首选项信息仅当存在可选的多种语言表现形式时有效。

这是一个更复杂的请求，浏览器表明，可以接受法语和英语，但最好是法语； 接受各种媒体类型，最好是HTML，纯文件或其他文本类型也可以； 最好是GIF或JPEG，其他媒体类型也可以，并允许其他媒体类型作为最终表现形式：

Accept-Language: fr; q=1.0, en; q=0.5
Accept: text/html; q=1.0, text/*; q=0.8, image/gif; q=0.6, image/jpeg; q=0.6, image/*; q=0.5, */*; q=0.1

Apache支持HTTP/1.1规范中定义的“服务器驱动”的内容协商， 可以完全地支持Accept, Accept-Language, Accept-Charset和Accept-Encoding请求头， 这些是RFC 2295和RFC2296中定义的实验协商协议，但是不支持这些RFC中定义的“功能协商”。

资源是一个在URI (RFC 2396)中定义的概念上的实体。 一个HTTP服务器，比如Apache，以表现形式提供对其名称空间中资源的访问， 各表现形式由已定义的媒体类型、字符集和编码的字节流构成。 任何一个特定的时刻，一个资源可以没有，或者有一个，或者有多个表现形式。 如果有多个表现形式存在，则称该资源是可协商的， 其各种表现形式术语称为变种， 而一个可协商的资源的各种变种的区别方式称为变元。


Apache的内容协商
有两种途径向服务器提供有关各变种的信息，以实现对资源的协商：

使用类型表(例如, 一个*.var文件)明确指定各变种的文件名；
使用'MultiViews'搜索，即，服务器执行一个隐含的文件名模式匹配，并在其结果中选择。
使用类型表文件
类型表是一个与命名为type-map的处理器关联的文档 (或者是MIME类型application/x-type-map，以向下兼容早期Apache的配置)。 要使用这个功能，必须在配置中建立处理器，以定义一个文件后缀为type-map， 最好的方法是在配置文件中这样设置：

AddHandler type-map .var

类型表文件应该与所描述资源同名，且对每个有效变种有一个块， 各块由若干连续的HTTP格式头组成，各变种的块用空行分开，块中不允许有空行。 习惯上，类型表首部会有一个概要性质的组合描述块(这不是必须的，如果有也会被忽略)。 下例是一个描述资源foo的命名为foo.var的类型表文件：

URI: foo

URI: foo.en.html
Content-type: text/html
Content-language: en

URI: foo.fr.de.html
Content-type: text/html;charset=iso-8859-2
Content-language: fr, de


注意：即使Multiviews设置为on，类型表都优先于文件后缀。 可以对媒体类型用"qs"参数指示变种不同的资源品质。 下例，演示了这个图片的jpeg, gif和字符构图三个有效变种：

URI: foo

URI: foo.jpeg
Content-type: image/jpeg; qs=0.8

URI: foo.gif
Content-type: image/gif; qs=0.5

URI: foo.txt
Content-type: text/plain; qs=0.01


qs的取值范围是0.000到1.000，取值为0.000的变种将不会被选择，没有指定qs值的变种会赋予其qs值为1.0。 qs表示一个变种相对于其他变种的“品质”，比如在表现一张照片时，jpeg文件通常比字符构图有较高的还原品质；而如果要表现的本来就是一个字符构图，那么当然字符构图会比jpeg文件有较高的还原品质。因此，qs的值取决于变种所表现的资源本身。

mod_negotation typemap文档中有完整的HTTP头的列表。

Multiviews
MultiViews是一个针对目录的选项，可以在access.conf或者.htaccess 文件(如果正确设置了AllowOverride)中的<Directory>, <Location>和<Files>段中，用Options指令来指定。注意，Options All并不会设置MultiViews，必须明确地指定。

MultiViews的效果是：如果服务器收到/some/dir/foo请求，而/some/dir/foo并不存在，但是如果/some/dir允许MultiViews，则服务器会查找这个目录下的foo.*，有效地利用说明了这些文件的类型表，假定其媒体类型及内容编码符合客户的要求，并选择其中最合适的匹配返回给客户。

MultiViews还可以在服务器索引一个目录时，用于DirectoryIndex指令的文件搜索。如果设置了：

DirectoryIndex index

而index.html和index.html3并存，则服务器会作一个权衡；如果都没有，但是有index.cgi，则服务器会执行它。

如果一个目录中没有任何文件具有mod_mime可以识别的表示其字符集、内容类型、语言和编码的后缀，那么其结果将取决于MultiViewsMatch指令的设置，这个指令决定了在MultiViews协商中将使用的处理器、过滤器和其他后缀类型。


协商的方法
Apache从一个类型表或者某个目录的文件名中得到对一个资源的变种列表以后，会使用两种方法之一选择可能的“最佳”变种返回给客户。使用Apache的内容协商功能并不必须了解协商的过程细节，以下对这些方法加以说明，有兴趣的人可以看看。

协商的两种方法：

一般情况下，使用下述的服务器驱动的Apache算法。使用这个算法，为了得到更好的效果，Apache有时会“打乱”一个特定变元的品质因子，其方法稍后会阐述。
当浏览器明确地用RFC 2295中定义的机制发出请求，则会使用透明内容协商。这种方法给予浏览器对“最佳”变种选择的完全控制，因此其效果也取决于浏览器使用的特定算法。作为透明协商过程的一部分，浏览器可以要求Apache执行RFC 2296中定义的“远程变种选择算法”。
协商的变元
变元 说明
媒体类型 浏览器在Acce