我有平面文件，我可以在UTF-16中加载.NET，即使它们在技术上是UCS2-LE（没有BOM），我明白这是因为UCS-2是一个较旧的标准， UTF-16取代。
然而，我感兴趣的是能够确定文件是否实际上是UCS-2。我知道这意味着我会猜测。我已经尝试过chardet的.NET端口，IMultilang2互操作，以及Novell的一些开源，试图通过UTF-16来判断UCS-2的确定并且我没有取得任何成功。我还没有找到任何技术可以确定UCS-2LE没有BOM和无效/超长UTF-8之间的区别。
我应该逐字节检查它们并尝试确定它是可变的还是固定长度编码？也许寻找丢失的代码点？问题是这些文本文件没有特殊的代码点，它们只有沼泽标准的西方字符集。但是TextPad将它们保存为UCS2-LE没有BOM，并且它使我们的软件中的下游文件操作变得复杂，希望它们完全兼容UTF-16（并且只是强制加载文件工作，但不能满足软件的要求） ）。
答案 0 :(得分：3)
此维基百科文章部分http://en.wikipedia.org/wiki/UTF-16， 谈到基本的多语言平面，BMP。对于UTF-16和UCS-2，BMP中的所有代码点都是相同的。如果TextPad只是对BMP进行编码，那么您可以将文档视为UTF-16或UCS-2。
当BMP之外的代码点被编码时，出现问题。 UCS-2无法代表BMP之外的代码点。 http://en.wikipedia.org/wiki/Universal_Character_Set 这将导致人们假设如果代码点在BMP之外，则可以在UTF-16处理它。如果创建文件的程序不正确地执行UCS-2并且出于辅助原因在BMP之外使用代码点，则可能会出现问题。
大多数读取UTF的库和程序允许您指定在每个字符的基础上发生编码错误时要执行的操作（引发异常，替换为占位符，只需忽略）。如果不正确的UCS-2文件通过UTF-16中的一个运行，则会引发错误。了解文件的作者在BMP之外尝试做的事情将是适当处理它们的唯一方法。