10

我正在维护的应用程序使用“latin1”字符集将从 Web 日志中提取的用户代理加载到 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 标头中的合法用户代理吗？

4

3 回答 3

14

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

于 2012-04-30T13:52:50.750 回答
4

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

建议：去除所有大于 127 的八位字节。

于 2012-04-30T14:30:11.967 回答
2

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

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

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

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

于 2012-04-30T13:59:52.880 回答