Network Working Group H. Alvestrand
Request for Comments: 3282 Cisco Systems
Obsoletes: 1766 May 2002
Category: Standards Track
Network Working Group H. Alvestrand
Request for Comments: 3282 Cisco Systems
Obsoletes: 1766 May 2002
Category: Standards Track
Content Language Headers
内容语言标题
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
Abstract
摘要
This document defines a "Content-language:" header, for use in cases where one desires to indicate the language of something that has RFC 822-like headers, like MIME body parts or Web documents, and an "Accept-Language:" header for use in cases where one wishes to indicate one's preferences with regard to language.
本文档定义了一个“内容语言：”标题，用于表示具有RFC 822类标题（如MIME身体部位或Web文档）的事物的语言，以及一个“接受语言：”标题，用于表示自己对语言的偏好。
There are a number of languages presently or previously used by human beings in this world.
在这个世界上，人类现在或以前使用过许多语言。
A great number of these people would prefer to have information presented in a language which they understand.
这些人中的许多人更喜欢用他们能理解的语言来表达信息。
In some contexts, it is possible to have information available in more than one language, or it might be possible to provide tools (such as dictionaries) to assist in the understanding of a language.
在某些情况下，可以使用多种语言提供信息，或者可以提供工具（如词典）来帮助理解一种语言。
In other cases, it may be desirable to use a computer program to convert information from one format (such as plaintext) into another (such as computer-synthesized speech, or Braille, or high-quality print renderings).
在其他情况下，可能希望使用计算机程序将信息从一种格式（例如明文）转换为另一种格式（例如计算机合成语音、盲文或高质量打印渲染）。
A prerequisite for any such function is a means of labelling the information content with an identifier for the language that is used in this information content, such as is defined by [TAGS]. This document specifies a protocol element for use with protocols that use RFC 822-like headers for carrying language tags as defined in [TAGS].
任何此类功能的先决条件是使用该信息内容中使用的语言的标识符（如[TAGS]定义）标记信息内容的方法。本文档指定了一个协议元素，用于使用RFC 822类头来承载[tags]中定义的语言标记的协议。
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不得”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC 2119]中所述进行解释。
The "Content-Language" header is intended for use in the case where one desires to indicate the language(s) of something that has RFC 822-like headers, such as MIME body parts or Web documents.
“Content Language”（内容语言）标题旨在用于希望指示具有类似RFC 822的标题（例如MIME正文部分或Web文档）的某物的语言的情况。
The RFC 822 EBNF of the Content-Language header is:
内容语言头的RFC 822 EBNF是：
Content-Language = "Content-Language" ":" 1#Language-tag
Content-Language = "Content-Language" ":" 1#Language-tag
In the more strict RFC 2234 ABNF:
在更严格的RFC 2234 ABNF中：
Content-Language = "Content-Language" ":" [CFWS] Language-List Language-List = Language-Tag [CFWS] *("," [CFWS] Language-Tag [CFWS])
Content Language=“Content Language”“：”[CFWS]语言列表语言列表=语言标记[CFWS]*（“，”[CFWS]语言标记[CFWS]）
The Content-Language header may list several languages in a comma-separated list.
内容语言标题可以在逗号分隔的列表中列出几种语言。
The CFWS construct is intended to function like the whitespace convention in RFC 822, which means also that one can place parenthesized comments anywhere in the language sequence, or use continuation lines. A formal definition is given in RFC 2822 [RFC2822].
CFWS构造的功能类似于RFC 822中的空白约定，这也意味着可以在语言序列中的任何位置放置括号注释，或使用连续行。RFC 2822[RFC2822]中给出了正式定义。
In keeping with the tradition of RFC 2822, a more liberal "obsolete" grammar is also given:
为了与RFC 2822的传统保持一致，还提供了更自由的“过时”语法：
obs-content-language = "Content-Language" *WSP ":" [CFWS] Language-List
obs content language=“content language”*WSP:“[CFWS]语言列表
Like RFC 2822, this specification says that conforming implementations MUST accept the obs-content-language syntax, but MUST NOT generate it; all generated headers MUST conform to the Content-Language syntax.
与RFC 2822一样，该规范规定一致性实现必须接受obs内容语言语法，但不能生成它；所有生成的标题必须符合内容语言语法。
Voice recording from Liverpool downtown
利物浦市区的录音
Content-type: audio/basic Content-Language: en-scouse
内容类型：音频/基本内容语言：搜索
Document in Mingo, an American Indian language which does not have an ISO 639 code:
明戈语文件，一种美国印第安语，没有ISO 639代码：
Content-type: text/plain Content-Language: i-mingo
内容类型：文本/普通内容语言：i-mingo
A English-French dictionary
英法词典
Content-type: application/dictionary Content-Language: en, fr (This is a dictionary)
内容类型：应用程序/词典内容语言：en，fr（这是一本词典）
An official European Commission document (in a few of its official languages):
欧盟委员会的官方文件（以几种官方语言）：
Content-type: multipart/alternative Content-Language: da, de, el, en, fr, it
内容类型：多部分/可选内容语言：da、de、el、en、fr、it
An excerpt from Star Trek
摘自《星际迷航记》
Content-type: video/mpeg Content-Language: i-klingon
内容类型：视频/mpeg内容语言：i-klingon
The "Accept-Language" header is intended for use in cases where a user or a process desires to identify the preferred language(s) when RFC 822-like headers, such as MIME body parts or Web documents, are used.
“Accept Language（接受语言）”报头用于当使用类似RFC 822的报头（例如MIME正文部分或Web文档）时，用户或进程希望识别首选语言的情况。
The RFC 822 EBNF of the Accept-Language header is:
Accept Language标头的RFC 822 EBNF为：
Accept-Language = "Accept-Language" ":"
1#( language-range [ ";" "q" "=" qvalue ] )
Accept-Language = "Accept-Language" ":"
1#( language-range [ ";" "q" "=" qvalue ] )
A slightly more restrictive RFC 2234 ABNF definition is:
稍具限制性的RFC 2234 ABNF定义为：
Accept-Language = "Accept-Language:" [CFWS] language-q
*( "," [CFWS] language-q )
language-q = language-range [";" [CFWS] "q=" qvalue ] [CFWS]
qvalue = ( "0" [ "." 0*3DIGIT ] )
/ ( "1" [ "." 0*3("0") ] )
Accept-Language = "Accept-Language:" [CFWS] language-q
*( "," [CFWS] language-q )
language-q = language-range [";" [CFWS] "q=" qvalue ] [CFWS]
qvalue = ( "0" [ "." 0*3DIGIT ] )
/ ( "1" [ "." 0*3("0") ] )
A more liberal RFC 2234 ABNF definition is:
更自由的RFC 2234 ABNF定义是：
Obs-accept-language = "Accept-Language" *WSP ":" [CFWS]
obs-language-q *( "," [CFWS] obs-language-q ) [CFWS]
obs-language-q = language-range
[ [CFWS] ";" [CFWS] "q" [CFWS] "=" qvalue ]
Obs-accept-language = "Accept-Language" *WSP ":" [CFWS]
obs-language-q *( "," [CFWS] obs-language-q ) [CFWS]
obs-language-q = language-range
[ [CFWS] ";" [CFWS] "q" [CFWS] "=" qvalue ]
Like RFC 2822, this specification says that conforming implementations MUST accept the obs-accept-language syntax, but MUST NOT generate it; all generated messages MUST conform to the Accept-Language syntax.
与RFC 2822一样，该规范规定一致性实现必须接受obs接受语言语法，但不能生成它；所有生成的消息必须符合Accept语言语法。
The syntax and semantics of language-range is defined in [TAGS]. The Accept-Language header may list several language-ranges in a comma-separated list, and each may include a quality value Q. If no Q values are given, the language-ranges are given in priority order, with the leftmost language-range being the most preferred language; this is an extension to the HTTP/1.1 rules, but matches current practice.
语言范围的语法和语义在[TAGS]中定义。Accept Language标头可在逗号分隔的列表中列出多个语言范围，每个语言范围可包括质量值Q。如果未给出Q值，则按优先级顺序给出语言范围，最左边的语言范围为最首选语言；这是HTTP/1.1规则的扩展，但符合当前的实践。
If Q values are given, refer to HTTP/1.1 [RFC 2616] for the details on how to evaluate it.
如果给出了Q值，请参考HTTP/1.1[RFC 2616]了解如何评估它的详细信息。
The only security issue that has been raised with language tags since the publication of RFC 1766, which stated that "Security issues are believed to be irrelevant to this memo", is a concern with language ranges used in content negotiation - that they may be used to infer the nationality of the sender, and thus identify potential targets for surveillance.
自RFC 1766发布以来，语言标签引发的唯一安全问题是内容协商中使用的语言范围，即它们可能被用来推断发送者的国籍，RFC 1766声明“安全问题被认为与本备忘录无关”，从而确定潜在的监视目标。
This is a special case of the general problem that anything you send is visible to the receiving party; it is useful to be aware that such concerns can exist in some cases.
这是一般问题的一个特例，即您发送的任何内容都对接收方可见；意识到这种担忧在某些情况下可能存在是有益的。
The exact magnitude of the threat, and any possible countermeasures, is left to each application protocol.
威胁的确切程度以及任何可能的对策由每个应用程序协议决定。
This document adds no new considerations beyond what is mentioned in [TAGS].
除了[TAGS]中提到的内容外，本文档没有添加任何新的注意事项。
This document has benefited from many rounds of review and comments in various fora of the IETF and the Internet working groups.
本文件得益于IETF和互联网工作组在各种论坛上的多轮审查和评论。
Any list of contributors is bound to be incomplete; please regard the following as only a selection from the group of people who have contributed to make this document what it is today.
任何贡献者的名单都是不完整的；请将以下内容视为仅从为本文件的编制做出贡献的人员中选出的一部分。
In alphabetical order:
按字母顺序：
Tim Berners-Lee, Nathaniel Borenstein, Sean M. Burke, John Clews, Jim Conklin, John Cowan, Dave Crocker, Martin Duerst, Michael Everson, Ned Freed, Tim Goodwin, Dirk-Willem van Gulik, Marion Gunn, Paul Hoffman, Olle Jarnefors, John Klensin, Bruce Lilly, Keith Moore, Chris Newman, Masataka Ohta, Keld Jorn Simonsen, Rhys Weatherley, Misha Wolf, Francois Yergeau and many, many others.
蒂姆·伯纳斯·李、纳撒尼尔·博伦斯坦、肖恩·伯克、约翰·克莱斯、吉姆·康克林、约翰·考恩、戴夫·克罗克、马丁·杜尔斯、迈克尔·埃弗森、内德·弗里德、蒂姆·古德温、德克·威廉·范·古利克、马里恩·冈恩、保罗·霍夫曼、奥利·贾内福斯、约翰·克莱森、布鲁斯·莉莉、基思·摩尔、克里斯·纽曼、玛斯塔卡·奥塔、凯尔德·乔恩·西蒙森、里斯·韦瑟利、米莎·沃尔夫、，Francois Yergeau和许多其他人。
Special thanks must go to Michael Everson, who has served as language tag reviewer for almost the entire period, since the publication of RFC 1766, and has provided a great deal of input to this revision. Bruce Lilly did a special job of reading and commenting on my ABNF definitions.
特别要感谢Michael Everson，自RFC1766出版以来，他几乎在整个时期内都担任语言标签审查员，并为本次修订提供了大量投入。布鲁斯·莉莉专门阅读和评论了我的ABNF定义。
[TAGS] Alvestrand, H., "Tags for the Identification of Languages", BCP 47, RFC 3066
[TAGS]Alvestrand，H.，“识别语言的标签”，BCP 47，RFC 3066
[ISO 639] ISO 639:1988 (E/F) - Code for the representation of names of languages - The International Organization for Standardization, 1st edition, 1988-04-01 Prepared by ISO/TC 37 - Terminology (principles and coordination). Note that a new version (ISO 639-1:2000) is in preparation at the time of this writing.
[ISO 639]ISO 639:1988（E/F）-语言名称表示代码-国际标准化组织，第一版，1988-04-01，由ISO/TC 37编制-术语（原则和协调）。请注意，撰写本文时，新版本（ISO 639-1:2000）正在准备中。
[ISO 639-2] ISO 639-2:1998 - Codes for the representation of names of
languages -- Part 2: Alpha-3 code - edition 1, 1998-11-
01, 66 pages, prepared by ISO/TC 37/SC 2
[ISO 639-2] ISO 639-2:1998 - Codes for the representation of names of
languages -- Part 2: Alpha-3 code - edition 1, 1998-11-
01, 66 pages, prepared by ISO/TC 37/SC 2
[ISO 3166] ISO 3166:1988 (E/F) - Codes for the representation of names of countries - The International Organization for Standardization, 3rd edition, 1988-08-15.
[ISO 3166]ISO 3166:1988（E/F）-国家名称表示代码-国际标准化组织，第3版，1988-08-15。
[ISO 15924] ISO/DIS 15924 - Codes for the representation of names of scripts (under development by ISO TC46/SC2)
[ISO 15924]ISO/DIS 15924-脚本名称表示代码（由ISO TC46/SC2开发）
[RFC 2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[RFC 2045]Freed，N.和N.Borenstein，“多用途Internet邮件扩展（MIME）第一部分：Internet邮件正文格式”，RFC 20451996年11月。
[RFC 2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[RFC 2046]Freed，N.和N.Borenstein，“多用途互联网邮件扩展（MIME）第二部分：媒体类型”，RFC 2046，1996年11月。
[RFC 2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996.
[RFC 2047]Moore，K.，“MIME（多用途互联网邮件扩展）第三部分：非ASCII文本的消息头扩展”，RFC 2047，1996年11月。
[RFC 2048] Freed, N., Klensin, J. and J. Postel, "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", RFC 2048, November 1996.
[RFC 2048]Freed，N.，Klensin，J.和J.Postel，“多用途互联网邮件扩展（MIME）第四部分：注册程序”，RFC 2048，1996年11月。
[RFC 2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples", RFC 2049, November 1996.
[RFC 2049]Freed，N.和N.Borenstein，“多用途Internet邮件扩展（MIME）第五部分：一致性标准和示例”，RFC 2049，1996年11月。
[RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC 2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC 2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[RFC 2234]Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，RFC 2234，1997年11月。
[RFC 2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC 2616]菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.，马斯特，L.，利奇，P.和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC 2616，1999年6月。
[RFC 2822] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[RFC 2822]Resnick，P.，“互联网信息格式”，RFC 2822，2001年4月。
Appendix A: Changes from RFC 1766
附录A：RFC 1766的变更
The definition of the language tags has been split, and is now RFC 3066. The differences parameter to multipart/alternative is no longer part of this standard, because no implementations of the function were ever found. Consult RFC 1766 if you need the information.
语言标记的定义已被拆分，现在是RFC 3066。multipart/alternative的differences参数不再是本标准的一部分，因为找不到该函数的任何实现。如果需要信息，请咨询RFC1766。
The ABNF for content-language has been updated to use the RFC 2234 ABNF.
内容语言ABNF已更新为使用RFC 2234 ABNF。
Author's Address
作者地址
Harald Tveit Alvestrand Cisco Systems Weidemanns vei 27 7043 Trondheim NORWAY
Harald Tveit Alvestrand Cisco Systems Weidemans vei 27 7043挪威特隆赫姆
EMail: Harald@Alvestrand.no
Phone: +47 73 50 33 52
EMail: Harald@Alvestrand.no
Phone: +47 73 50 33 52
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。