我认为这取决于您的动机。例如，在移动Web领域中，您试图为用户提供在其平台上看起来很明智的内容。当纯粹出于自己的利益考虑时，为什么要担心用户报告的是哪个用户代理？如果他们试图用另一个用户代理欺骗您，那么他们就是唯一遭受痛苦的人。当然，主要的麻烦是误报。

I think it depends what your motivation is. For example, in the mobile web sector what you are attempting to do is provide the user with something that looks sensible on their platform. Why be concerned about what user-agent the user is reporting, when it is purely for their own benefit? If they go to the effort of tricking you with a different user-agent, then they are the only person that suffers. The main trouble of course is false positives; it's not entirely reliable.

我遵循这样一个论点，即您不应该依赖它，但是移动开发人员正受到此类通用声明的攻击。是的，有很多不错的选择，但是在您可以想象的每种浏览器中，随着确定性开始降低，这些信息实际上在某些时候会有用。

I follow the argument that you should not rely on it as such, but mobile developers are under attack from generic broad statements like this. Yes there are good alternatives, but across every browser you can imagine, this information can actually be useful at some point as the certainty begins to degrade.

您当然不知道的任何纯文本标头都永远不会使用它来简化访问控制。

What you certainly don't ever do with any plain-text header is use it to facilitate access control.

如果有更好的选择，则认为用户代理检测很糟糕，但是将其包含在检测过程中无疑会带来一定的危害。

User agent detection is considered bad when there are better alternatives, but there is certainly no harm in including it in a detection process which degrades gracefully in certainty.

我在整个过程中遇到的问题是，我们在为用户提供明智的东西上陷入了困境，但是似乎从来没有想过在不确定的情况下问是可以接受的。如果您不确定用户代理，为什么不问一次并存储？您可以使用用户代理作为指导。

The issue I have with the whole process is that we are caught up in providing the user something sensible, but never seem to think it's acceptable to ask when you are uncertain. If you are uncertain about the user-agent, why not ask once and store? You can use the user-agent as a guideline.

因此，总结一下我的想法，用户代理标头本质上是不可靠的，因此依赖。这并不意味着您无法从中提取有价值的信息，而更可靠的选择会使您处于不确定状态。总的来说，得出不好的结论是错误的。只是使用这些信息即可使它变得不好或不坏。

So to conclude my thoughts, essentially the user-agent header is unreliable, so it is bad to rely on it. This doesn't mean you can't extract a degree of valuable information from it where more reliable options leave you in an uncertain state. In general it's wrong to conclude that it is bad. It's simply what you do with this information that makes it bad or not.

看到更新后对于这个问题，我有以下几点看法。
我是否要监听图像请求并向客户端提供基于用户代理的图像？

After seeing your updates to the question, I have the following comments to contribute. Do I want to be sniffing image requests and providing the client with an image based on user agent?

如果这是唯一的变量，则也许可以使用，但很少有唯一变化的是图像。我不想检测每个请求，因为我想为客户提供一致的解决方案。这意味着我为他们提供了一个页面，使他们可以请求正确的资源。该页面为所有集成资源提供了一个统一的解决方案。本文档中的所有变体都针对特定的视图协同工作。

If this is the only variable then maybe it could work, but it's rarely the case that the only thing you are varying is the images. I don't want to detect per request because I want to serve the client a coherent solution. This means I served them a page that causes them to request the correct resources. This page yields a single coherent solution for all of the integrated resources. All variations in this document work together for a particular view.

我认为用户代理字符串在视图中部更改的可能性很小，似乎没有值得担心。但是，采用此原理也会减少执行浏览器/平台检测所需的次数，这只会是有益的。这使您可以更轻松地在客户端上切换视图。如果客户说您实际上错了，我是平板电脑而不是手机，您该如何纠正呢？您可以为用户提供一个更好的页面，否则您将需要为您的图像请求欺骗标题...这是一个糟糕的主意。 不要使用用户代理字符串来提供图像之类的通用资源。

I respect that the chance of the user-agent string changing mid-view is so slim it doesn't seem worth worrying about. However adopting this principle also reduces the number of times you need to perform browser/platform detection, which can only be beneficial. This allows you to switch views on the client much more easily. If the client says actually you got the view wrong, I am a tablet not a phone, how do you go about correcting that? You serve the user a better page, otherwise you will need to be spoofing headers for your image requests... terrible idea. Don't use the user-agent string to serve generic resources like images.

平台识别是网络上现代发展的一个非常活跃的领域。随着计算的普及和平台的广泛变化，我们对所服务平台的了解日益增加。我认为在当前条件下，此问题的一般解决方案将取决于指纹识别和统计分析。

Platform identification is a very active area of modern developments in the web. As computing becomes more ubiquitous and platforms vary much more widely, our need to understand the platforms we are serving increases. I think the general solution to this problem under the current conditions is going to fall on fingerprinting and statistical analysis.

请考虑此应用程序- akinator.com -请注意，从庞大的稀疏数据集中进行的统计分析非常令人讨厌。在有限的环境（一组浏览器配置）中，您可以想象我们可以向客户的浏览器询问一些问题。然后，我们对某些n维特征空间中的响应进行统计分析。使用用户代理作为该空间的维度将非常有用并且可以自我限制，具体取决于找到的结果。如果它基本上不准确，那么它将看到大的价差，并且您从中获得的价值将是自我限制的。

Consider this application - akinator.com - Notice how the statistical analysis from a huge set of sparse data is annoyingly accurate. In a limited environment (the set of browser configurations), you can imagine that we could ask the client's browser some questions. We then perform a statistical analysis on the response in some n-dimensional feature space. Using the user-agent as a dimension of this space is going to be useful and self limiting, depending on the results that you find. If it's largely inaccurate then it will see a large spread, and the amount of worth you derive from it will be self limiting.

当然，您有能力从中获得任何价值这种统计模型要求您能够获得一些经过验证的真相。例如，这可能是运行JavaScript测试套件来检测客户端js功能，或者实际上，在不确定的情况下，您实际上可以要求用户告诉您他们的平台是什么。

Of course your ability to derive any value from this statistical model requires you to be able to obtain some verified truths. This could be, for example, running a JavaScript test-suite to detect client side js capabilities, or indeed, in uncertainty, you can actually ask the user to tell you what their platform is.

要进一步阅读，请参考Mozilla的这篇文章

For further reading I'd refer you to this article by Mozilla

https://developer.mozilla.org/en/Browser_detection_using_the_user_agent

今天，寻找这些字符串是在提供
HTML之前知道
设备在移动设备（如平板电脑）上运行的唯一方法。

Today, looking for these strings are the only way to know that the device runs on a mobile device (resp. a tablet) before serving the HTML.