用户代理字符串中的未识别字符(“in”)？该怎么办？

Question

下面是在“国家/语言代码”部分前面指定了这些神秘的3个字符的示例用户代理列表。

Vi http://www.webuseragents.com/ua/840966/opera-9-80-j2me-midp-opera-mini-4-2-14912-27-1251-u-vi-presto-2-8-119-version-11-10

http://www.webuseragents.com/ua/643853/opera-9-80-j2me-midp-opera-mini-4-2-14912-25-729-u-es-presto-2-5-25-version-10-54 http://www.webuseragents.com/ua/884994/opera-9-80-j2me-midp-opera-mini-4-2-14912-29-3134-u-es-presto-2-8-119-version-11-10 .

PT http://www.webuseragents.com/ua/874562/opera-9-80-j2me-midp-opera-mini-4-2-14912-28-4150-u-pt-presto-2-8-119-version-11-10 http://www.webuseragents.com/ua/961801/opera-9-80-j2me-midp-opera-mini-4-2-14912-30-3389-u-pt-presto-2-8-119-version-11-10 http://www.webuseragents.com/ua/1029731/opera-9-80-j2me-midp-opera-mini-4-2-14912-32-952-u-pt-presto-2-8-119-version-11-10

http://www.webuseragents.com/ua/911065/opera-9-80-j2me-midp-opera-mini-4-2-14912-29-3417-u-en-presto-2-8-119-version-11-10 http://www.webuseragents.com/ua/954938/opera-9-80-j2me-midp-opera-mini-4-2-14912-30-3341-u-en-presto-2-8-119-version-11-10 (英语)

还有更多，但我留下了它，在每个用户代理中，未被识别的字符总是相同的(存在)：“it”，并且它将显示为Vi、Vi或PT、PT或is、en。

现在，它可能看起来像一个外来的词或代码，但它不应该是。由于所有可能的用户代理国家(区域)和语言(地区)引用都是由Microsoft列出的，并且是用普通字符( all )完成的，很少使用数字(0-9)和破折号(连字符)和下划线。没有什么比这更能用来描述数以百计的地方和数百种方言(语言)。因此，使用ISO 639标准来描述这些区域中使用的区域和语言的整个组合，该标准使用的字符范围仅为a。

微软的官方名单虽然是全面的，但并没有涵盖所有内容，而是接近它：http://msdn.microsoft.com/en-us/library/cc233968.aspx

因此，通过使用Visual 2012和方便的Asc()函数将符号转换为相关字符代码，我研究了这3个字符，结果如下：

ï  = character 239
»  = character 187
¿  = character 191

现在，我真正需要知道的是，这样的用户代理是否是合法的UAs。我需要把它们扔进垃圾箱，还是按原样传递(不是为了任何特定的目的，而是一般意义上的)。有没有人知道这种奇怪的东西，或者它存在的原因，它代表什么，或者什么？用户-代理规范特殊字符部分(在ISO中)没有引用这一点.

假设地说，如果我要编写一个分析用户代理并将其合法性返回给一个用户的程序，那么一个具有这些字符的用户代理会要求我返回什么呢？用户代理是Legit (真)还是非Legit (假).

UPDATE/ADDITION:

我发现了另一个具有类似问题的用户代理，它显示如下(在JUC之后注意部分)：

JUC (DÌFH©3;U; 2.3.5; zh-cn; HTC_Explorer_A310e; 320*480)

然而，在我的文本流中，我认为它是"D?FH?3"，所以我有所有这些问号来替换原来的奇怪字符。

我正在使用System.Net.WebClient的.DownloadData子程序来获取这些数据，并且我猜测这就是转换发生的地方(除非链接到实体，因为我要存储它的数据库字段类型是nvarchar(MAX))。

我该怎么办？我应该以它的原始形式获得这些数据并将其传递到“原样”上，还是应该排除所有带有奇怪字符的项？

我的意思是，例如，D‘s FH_c_3是否代表中国制作和使用的真实产品名称？知道我该往哪个方向走吗？

非常感谢大家的阅读和任何预期的回应。

Answer 1

该网站假设这个用户代理字符串被编码为ISO-8859-1，但实际上它是UTF-8。

您看到的是Unicode代码点U+FEFF (a.k.a )。"字节顺序标记")。在UTF-8中编码时，它由三个字节组成: 0xEF、0xBB、0xBF。假设这三个字节实际上是ISO8859-1，则将它们编码为。

字节顺序标记总是可以安全地从UTF-8字符串中剥离出来.其他编码方案(UCS-2、UTF-16等)这可能是一个有用的提示，对解码器，但同样，它没有其他目的或意义。

当您直接处理UA字符串时，您最好的选择可能是尝试将其解码为UTF-8，并将所有不在字母、数字、标记或符号类别中的内容解释为空格。