我有平面文件，我可以在 .NET 中以 UTF-16 很好地加载，即使它们在技术上是 UCS2-LE（没有 BOM），我理解这是因为 UCS-2 是 UTF-16 的旧标准取代。
但是，我感兴趣的是能够确定一个文件是否真的是 UCS-2。我知道这意味着我会猜测。我已经尝试了 chardet 的 .NET 端口、IMultilang2 互操作以及 Novell 的一些开放源代码，试图找出 UCS-2 优于 UTF-16 的决定，但我没有取得任何成功。我还没有找到任何可以确定 UCS-2LE w/o BOM 和无效/超长 UTF-8 之间区别的技术。
我应该逐字节检查它们并尝试确定它是可变长度编码还是固定长度编码？也许寻找丢失的代码点？问题是这些文本文件没有特殊的代码点，它们只有沼泽标准的西方字符集。但是 TextPad 将它们保存为 UCS2-LE w/o BOM，它使我们的软件中的下游文件操作复杂化，希望它们完全符合 UTF-16（并且只是强制加载文件有效，但不能满足软件的要求）。
这个维基百科文章部分，http ://en.wikipedia.org/wiki/UTF-16 ，谈到了基本多语言平面，BMP。BMP 中的所有代码点对于 UTF-16 和 UCS-2 都是相同的。如果 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 之外做什么是正确处理它们的唯一方法。