HTTP 标头中的 unicode 用户代理是否合法？答案

【问题标题】：Is a unicode user agent legal inside an HTTP header?HTTP 标头中的 unicode 用户代理是否合法？
【发布时间】：2012-04-30 13:45:20
【问题描述】：

我维护的一个应用程序使用“latin1”字符集将从网络日志中提取的用户代理加载到 MySQL 表列中。有时，它无法加载如下所示的用户代理：

Mozilla/5.0 (Iâ?; CPU iPhone OS 5_0_1 like Mac OS X) AppleWebKit/534.46 (KHTML^C like Gecko) Version

我怀疑它在 Iâ? 上窒息。我正在努力弄清楚是否应该支持它，或者它是否是上游日志系统引入的损坏。这是 HTTP 标头中的合法用户代理吗？

【问题讨论】：

HTTP 规范早于 Unicode。我确定我看到一些建议说要输出 ASCII，但要接受 UTF-8。但我不记得我在哪里看到的，这就是为什么这是评论，而不是答案。
@TRiG：听起来像是Robustness principle 的特定实例。
一般来说，尝试将任意数据存储为 Latin-1 可能是个坏主意，除非您可以保证您只会获得适合 Latin-1 字符集的输入。为什么不使用 UTF-8？
@eggyal。是的。我不知道我在哪里看到了这个特别的建议，但它肯定符合 Postel 定律。我敢打赌它运作良好。
@Wooble 如果标准只指定ASCII，我认为按照标准设计一个存储这些值的系统是合理的。不过，看来我还有消毒工作要做。

标签： mysql http user-agent

【解决方案1】：

RFC 2616 (HTTP 1.1) says 消息头内容必须是“由*TEXT 或标记、分隔符和引号字符串的组合组成”。如果您查看 definitions 的 TEXT 等，您会发现合法字符是那些字节值不在 [0, 31] 范围内且不等于 127 的字符；因此，据我所知，â 等字符根据规范是合法的。

【讨论】：

TEXT 实际上确实允许八位字节 > 127：TEXT =
@JulianReschke：哎哟。应该教我不要读得太快……我已经更正了答案；谢谢你的收获。
2012 年是很久以前的事了。请注意 RFC 2616 已过时，请参阅 RFC 7230。特别是section 3.2.4中的最后一段。

【解决方案2】：

从技术上讲，在 cmets 中允许使用大于 127 的八位字节。 RFC 2616 使它们默认为 ISO-8859-1，但 HTTPbis（即将发布的 RFC 2616 修订版）已删除该规则，因此有时在遥远的将来，我们可能会转向合理的编码。

建议：去除所有八位字节 > 127。

【讨论】：

【解决方案3】：

HTTP 1.1 RFC2616 指的是 ISO-8859-1，它是基于拉丁文的单字节字符集。

考虑到 HTTP 流量应该是单字节，我也将 latin1 字符集用于我的类似日志。决定只是让我的索引更小。

如果你使用 UTF8 和 VARCHAR，只有多字节的字符需要额外的字节，所以在表空间中，它并不多。但是，索引是以固定宽度存储的，因此，它们会用空格填充以备不时之需（UTF8 索引是 latin1 索引的三倍）。

如果偶尔出现的奇怪标题不可读，这不会影响我。但是，如果您不为该列编制索引，则不妨使用 UTF8。

【讨论】：