问题标签 [ucs2]

在阅读SortableIntField的源代码时，我注意到这个类在将整数转换为字符串时避免了“UCS-16 代理”（参见NumberUtils.javaint int2sortableStr(int, char[], int)的方法）。

这些角色会引发什么问题？

http://www.python.org/dev/peps/pep-0100/

PEP 100 声明内部格式 Python Unicode 保存 UTF-16 编码，但将值寻址为 UCS-2（或使用 flag 编译时的 UCS-4 --enable-unicode=ucs4）。

为什么不选择 UTF-16（可变长度格式）而不是 UCS-2（固定长度）？

尽管这两种编码基本相同，但当 PEP-100 发布时（2000 年 3 月），UTF-16 已经有 4 年的历史了。Python Unicode 是否旨在解决向后兼容性问题？

我真的很好奇为什么 Python 的内部格式是使用这种（看似）混合方法在内部存储编码数据来实现的？

提出我的问题的更好方法可能是：是否有人引用官方文件中的引用或链接，具体说明为什么 PEP 100 选择将 UTF-16 视为 UCS-2 而不是使用 UTF-16？

我正在寻找 php 中的代码/库，我将调用它并将文本传递给它，它会告诉我：

1. 我需要使用什么编码才能将此文本作为 SMS（7、8、16 位）发送
2. 我将使用多少条短信来发送此文本（计算“分段信息”必须很聪明，例如http://ozekisms.com/index.php?owpn=612）

您是否知道存在任何可以为我执行此操作的代码/库？

同样，我不是在寻找发送 SMS 或转换 SMS，只是为了给我有关文本的信息

更新：

好的，我做了下面的代码，它似乎工作正常，如果你有更好/优化的代码/解决方案/lib，请告诉我

我有一个 Flash 应用程序和一个文本字段。我可以更改系统托盘上的区域设置并键入 unicode 字符，例如使用 windows -1251 编码。如果我使用 jquery 将 unicoded 文本发送到数据库，它是如何到达那里的，如 windows-1251 编码或其他编码，如 UTF-8？

或者让我们先说一下它是用哪种编码进入 jquery 的？

如果我有数据列表：

$a = "hello";

$b= "4f60";

$c = "hi";

$d = "00480065006C006C006F";

$b 和 $d 是 UCS-2 字符串。我希望在表格中显示所有这些数据，那么我如何知道哪些数据是 UCS-2 以便在显示之前进行转换？是否可以 ？我为 php.net 上的 unicode 尝试了 mb_detect_encoding 和 preg_match，但即使它是一个未知符号，它仍然被认为是 unicode。

谢谢你。

在研究在可能非常大的 SQL Server 数据库中存储主要是英语但有时不是数据的选项时，我倾向于将大多数字符串数据存储为 UTF-8 编码。

但是，Microsoft 选择 UCS-2 的原因是我不完全理解，这导致我对这种倾向产生了怀疑。SQL Server 2012 的文档确实显示了如何创建UTF-8 UDT，但 UCS-2 的决定可能遍及 SQL Server。

Wikipedia（有趣地指出 UCS-2 已过时，取而代之的是 UTF-16）指出 UTF-8 是一个可变宽度字符集，能够对任何 Unicode 数据点进行编码，并且provides the de facto standard encoding for interchange of Unicode text. 所以，感觉任何 Unicode 字符都可以用 UTF-8 表示，而且由于大多数文本都是英文的，所以表示形式几乎是 UCS-2 的两倍（我知道磁盘“便宜”，但磁盘缓存不是't，并且内存与我正在处理的数据大小相比没有。当工作集大于可用 RAM 时，许多操作会呈指数级下降）。

顺着 UCS-2 流向上游泳可能会遇到什么问题？

我知道 USSD 消息由 160 个字节组成。对于 7 位数据编码方案，最大字符数为 160*8/7，即 182 个字符。我不清楚 UCS2 编码的最大字符数是多少。通常情况下，它会是 160/2 之类的东西，但我对此有一些混杂的信息。

更新的问题¹

关于字符类、比较、排序、规范化和排序规则，哪些 .NET 平台支持哪些 Unicode 版本？

原始问题

我记得有些模糊地读过 .NET 支持 Unicode 3.0 版，并且内部 UTF-16 编码并不是真正的 UTF-16，但实际上使用的是 UCS-2，这是不一样的。例如，似乎 U+FFFF 以上的字符是不可能的，即考虑：

它存储字符串"ᵽ9"。

我基本上是在寻找以下答案的明确参考：

• 如果在 .NET 中不是真正的 UTF-16，它是什么？
• .NET 支持哪个版本的 Unicode？
• 如果在不久的将来不支持或计划不支持最新版本，是否有人知道（非）商业库或我如何解决此问题？

¹）我随着时间的推移更新了这个问题，对于答案和更大的社区来说似乎更合适。我留下了原始问题，以代替评论中已回答的部分。旧的 UCS-2（无代理）也用于现在古老的 32 位 Windows 版本，.NET 在内部一直使用 UTF-16（有代理）。

我有平面文件，我可以在 .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（并且只是强制加载文件有效，但不能满足软件的要求）。

我在 SIM900 GPRS 的 SMS 中收到此消息。

07916698019021F00410D05479BDDC7CBBCB790008217002123430826A0049006E0063006F00720072006500630074002000700061007300730077006F00720064002E00200050006C050610306500065060740507202079060750702007001070730700F0700402001060010600E02

另一个示例消息：

07916698019021F00410D05479BDDC7CBBCB790008217002025501826A0049006E0063006F00720072006500630074002000700061007300730077006F00720064002E00200050006C06001073050200506E04065070200906F07072020700607307007060020600006007060090600E

我认为这条消息是 Unicode UCS-2 格式并且是泰语。但是我无法将其转换为可读的东西。我发现这个非常有用的代码：

提前致谢。