用户代理字符串可以有多大？
如果您要将用户代理存储在数据库中，您会容纳多大的数据库？
我发现这篇 technet 文章 建议将 UA 保持在 200 以下。事实并非如此看起来这是在 HTTP 规范中定义的，至少我没有发现。 我的 UA 已经是 149 个字符，而且似乎每个版本的 .NET 都会添加它。
我知道我可以解析该字符串并将其分解，但我宁愿不这样做。
编辑
基于此博客< /a> IE9 将改为发送短 UA 字符串。 这是一个很好的改变。
If you were going to store a user agent in a database, how large would you accomdate for?
I found this technet article which recommends keeping UA under 200. It doesn't look like this is defined in the HTTP specification at least not that I found. My UA is already 149 characters, and it seems like each version of .NET will be adding to it.
I know I can parse the string out and break it down but I'd rather not.
EDIT
Based on this Blog IE9 will be changing to send the short UA string. This is a good change.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（12）
这是 257 的一个
Here is one that is 257
任何官方标准或规范定义的用户代理字符串的大小没有严格限制。 定义HTTP协议的HTTP/1.1 RFC 2616没有指定User-Agent头字段的最大长度。
然而，实际限制可能适用，具体取决于处理用户代理字符串的特定 Web 服务器、浏览器或应用程序。 某些服务器或代理可能会对标头字段大小施加自己的限制，以防止滥用或拒绝服务攻击。 此外，过长的用户代理字符串可能会导致服务器端解析或处理出现问题。
实际上，用户代理字符串的长度可能会有所不同，但它们通常不会太长。 浏览器和用户代理字符串旨在提供有关客户端应用程序的有用信息，但又不会过于冗长。 大多数用户代理字符串都在几百个字符之内。
设计 Web 应用程序和服务来处理相当长的用户代理字符串非常重要，同时还要考虑潜在的安全和性能影响。
There is no strict limit on the size of a User-Agent string defined by any official standards or specifications. The HTTP/1.1 RFC 2616, which defines the HTTP protocol, does not specify a maximum length for the User-Agent header field.
However, practical limitations may apply depending on the specific web server, browser, or application handling the User-Agent string. Some servers or proxies may impose their own limits on header field sizes to prevent abuse or denial-of-service attacks. Additionally, excessively long User-Agent strings could potentially cause issues with parsing or handling on the server side.
In practice, User-Agent strings can vary in length, but they are typically not excessively long. Browsers and user-agent strings aim to provide useful information about the client application without being overly verbose. Most User-Agent strings are well within a few hundred characters.
It's essential to design web applications and services to handle reasonably long User-Agent strings while also considering potential security and performance implications.
HTTP 规范根本不限制标头的长度。
然而，网络服务器确实限制了它们接受的标头大小，如果超过则抛出
413 Entity Too Large。根据 Web 服务器及其设置，这些限制从 4KB 到 64KB 不等（所有标头的总计）。
HTTP specification does not limit length of headers at all.
However web-servers do limit header size they accept, throwing
413 Entity Too Largeif it exceeds.Depending on web-server and their settings these limits vary from 4KB to 64KB (total for all headers).
我对此的看法：
UNIQUE BINARY(32)（或 64 或 128，具体取决于您的哈希长度） 和 对 UserAgent 进行哈希某些 UA 字符串可能会变得非常长.这应该可以免除您的后顾之忧。 还要强制执行 INSERTer 中的最大长度，以将 UA 字符串保持在 4KB 以下。 除非有人在用户代理中向您发送电子邮件，否则它不应该超过这个长度。
My take on this:
UNIQUE BINARY(32)(or 64, or 128 depending on your hash length) and hash the UserAgentSome UA strings can get obscenely long. This should spare you the worries. Also enforce a maximum length in your INSERTer to keep UA strings it under 4KB. Unless someone is emailing you in the user-agent, it should not go over that length.
在我们的 apache 日志中注意到类似的内容。
对我来说这看起来很不正常，但我经常在 Windows 系统的日志中看到此类内容。
Noticed something like this in our apache logs.
It looks abnormal to me but I regularly see such things in logs mostly from Windows systems.
由于它用于数据库目的并且没有实际限制，因此我会选择 UserAgents 表，其中 UserAgentId 为 Int，UserAgentString 为 NVarChar(MAX)，并在原始表上使用外键。
Since it's for database purposes and there is no practical limit i'd go for a UserAgents Table with UserAgentId as Int and UserAgentString as NVarChar(MAX) and use a foreign key on the original table.
这个大的怎么样？：
How's this for big?:
没有规定的限制，只有大多数 HTTP 服务器的限制。 然而，请记住这一点，我会实现一个具有合理固定长度的列（使用 Google 查找已知用户代理的列表，找到最大的并添加 50%），然后裁剪任何太长的用户代理 - 任何异常的用户代理即使被裁剪，长用户代理也可能足够独特，或者是某种错误或“黑客”尝试的结果。
There is no stated limit, only the limit of most HTTP servers. Keeping that in mind however, I would implement a column with a reasonable fixed length (use Google to find a list of known user agents, find the largest and add 50%), and just crop any user agent that is too long - any exceptionally long user agent is probably unique enough even when cropped, or is the result of some kind of bug or "hack" attempt.
我今天得到了这个用户代理，溢出了我们供应商的存储字段：
荒谬！ 229个字符？
因此，采用这个大小，加倍，再加倍，你应该做好准备，直到微软犯下一个错误（也许是明年的这个时候）。
大于 1000！
I got this user agent today, overflowing our vendor's storage field:
Ridiculous! 229 chars?
So take that size, double it, double it again, and you should be set until Microsoft's next blunder (maybe this time next year).
Go bigger than 1000!
假设用户代理字符串的长度没有限制并准备存储这样的值。 正如您所见，长度是不可预测的。
在 Postgres 中，有一个 text 类型，它接受无限长度的字符串。 用那个。
但最有可能的是，您必须在某个时刻开始截断。 以合理有用的增量（200、1k、4k）称其为良好，并丢弃其余的。
Assume the user agent string has no limit on its length and prepare to store such a value. As you've seen, length is unpredictable.
In Postgres, there's a text type that accepts strings of unlimited length. Use that.
Most likely though, you'll have to start truncating at some point. Call it good at a reasonably useful increment (200, 1k, 4k) and throw away the rest.
并不表明用户代理可以达到多大，因为有很多答案显示了他们遇到的边缘情况，但可以在 http://www.useragentstring.com/pages/useragentstring.php?name=All 为 250 字节。
Not an indication of how big a user agent can get, as there's plenty of answers showing the edge cases they've came across, but the longest that could find on http://www.useragentstring.com/pages/useragentstring.php?name=All was 250 bytes.
我会给你标准答案：
取你能想象到的最大可能值，将其加倍，这就是你的答案。
I'll give you the standard answer:
Take the largest possible value you can possibly imagine it being, double it, and that's your answer.