为什么在HTTP Accept-Language头中使用质量值？

Question

在HTTP中，Accept-Language请求头看起来像这样：

Accept-Language: da, en-gb;q=0.8, en;q=0.7

为什么HTTP规范中包含了质量值（q=...）？难道不能按照质量排序，对于质量相同的语言选择任意顺序，并且不包括任何q=0的语言吗？

- phihag

---

可能——“质量”评级可能被过度设计了。虽然您提出的方案失去了一些灵活性（例如，q = 0表示绝对不，而省略可以推断为“不首选，但不被拒绝”）。 - EricLaw

@EricLaw -MSFT- 嗯，如果服务器只支持 en，而请求指定了 en;q=0，那么服务器应该怎么做呢？不带文本地提供页面吗？我无法理解为什么客户端会说“不要英语，但是 任何 语言都可以”。 - phihag

@phihag，规范说明“q = 0表示不可接受”：“如果存在Accept-Language头，则所有分配了大于0的质量因子的语言都是可接受的。”（来源） - tanius

@tanius 是的，那正是我所假设的（而且你引用了我链接的规范中的确切段落）。请参见我上面的评论，了解q=0的两个问题。 - phihag

Answer 1

有趣的问题。

关于这个特性是如何产生的讨论可能被埋在邮件列表档案中，但我找不到有效的链接。你的例子并不是唯一的问题。如果一个服务器支持两种语言，“fr; q=1.0, en; q=1.0”应该怎么处理呢？优先提供法语内容吗？那么“fr，en; q = 1.0”呢？

在我的看来，一个有序的语言偏好列表比当前加权（也许排序）列表更适合解决这个问题。规范未明确期望实现的行为，存在太多边缘情况。

至少规范的某些贡献者认为这个特性还远未完善 (HTTP/1.0与HTTP/1.1之间的主要区别-第八届国际万维网会议发表的论文)：

"由于内容协商机制允许q值和通配符，并表达跨多个维度（语言、字符集、内容类型和内容编码）的变化，因此选择“最佳可用”变体的自动方式可能很复杂，并且可能会生成意外结果。这些选择可能会以微妙的方式与缓存交互；请参见第3.4节中的讨论。

内容协商承诺成为进一步协议发展的肥沃领域。例如，HTTP工作组认识到自动协商在客户端实现功能方面的效用，例如屏幕大小、分辨率和色彩深度。IETF创建了内容协商工作组，以继续在该领域开展工作。"

简而言之，我没有真正的答案，但希望规范过程中的某个参与者能够提供更多信息。

- Eli Algranti

---

这绝对是标准机构过度设计解决方案的味道。理论上，作为高级内容协商的一部分，创建与自己语言能力匹配的抽象层听起来很理想。然而，在现实中，只有极少数人会说超过3种语言，执行者几乎肯定更喜欢一个排序过的列表，并且大多数网站都会公开语言选择UI：该标准显然过于复杂。 - Indolering

Answer 2

请记住，质量值用于许多其他（Accept-*）标头，因此，虽然在选择语言的上下文中可能没有太多意义并且感觉过于复杂，但相同的通用概念也用于 MIME 类型（包括整个组的通配符）等等。因此，请不要仅仅根据它如何适合用户语言选择来评判它。

- janbrasna

---

目前你的回答不够清晰，请编辑并添加更多细节，以帮助其他人理解它如何回答问题。你可以在帮助中心找到有关如何编写好答案的更多信息。 - Community