问题标签 [utf-16]

检查 UTF-16 和 UTF-8 的属性，我找不到任何理由更喜欢 UTF-16。

但是，检查 Java 和 C#，它看起来像那里的字符串和字符默认为 UTF-16。我在想这可能是出于历史原因，或者可能是出于性能原因，但找不到任何信息。

任何人都知道为什么这些语言选择 UTF-16？我也有任何正当理由这样做吗？

编辑：同时我也找到了这个答案，它看起来很相关并且有一些有趣的链接。

我的文本编辑器允许我以几种不同的字符格式进行编码 Ansi、UTF-8、UTF-8（无 BOM）、UTF-16LE 和 UTF-16BE。

它们之间有什么区别？

什么通常被认为是最好的格式（如果有区别，我正在使用 Python）？

我正在使用 pyODBC 与 MS SQL 2005 Express 服务器进行通信。我试图将数据保存到的表由 nvarchar 列组成。

变量名称、生日和性别是从 Excel 文件中读取的，它们是 Unicode 字符串。当我执行查询并使用 SQL Server Management Studio 查看表或执行获取刚刚插入的数据的查询时，所有用非英语语言编写的数据都会变成问号。用英文编写的数据将被保留并以正确的方式出现在表格中。我尝试添加CHARSET=UTF16到我的连接字符串，但没有运气。我可以使用UTF-8which 工作正常，但作为一个工作约定，我需要保存在我的数据库中的所有数据都是UTF16.

谢谢！

我在搜索 MySQL 表时遇到了麻烦，试图在特定列中查找带有字符（UTF-16 代码 200E）的条目。

这个特定的代码没有字形，所以当我尝试将它粘贴到我的搜索词中时它似乎不起作用。有没有办法将字符指定为它们各自的代码点而不是查询？

谢谢，-本

下面的 NewLISP 代码显示了 Win32 下文件的文件属性。但是，某些检索到的文件名中包含中文字符。当 GetFileAttributesA 函数遇到它们时，它会给我一个属性 -1。我查看了 GetFileAttributesW，但不知道如何以它识别的形式使 fname 的内容对函数可用。

如何处理这种情况？（我愿意考虑尝试另一种语言）

Ruby 在 Mac OS X 和 Linux 上与文件路径和文件名中的 Unicode 字符配合得很好，但为什么要让它在 Windows 上工作，花了 2 年多的时间？

我只是在看 Google Code Jam。人们在几个小时内解决了重要的问题。在工作中，我可以想象解决具有 unicode 字符的文件名或路径问题，即使我们需要将其写入标准库以在一两天、几天或 1 或 2 周内解决？但是2年？

可能是什么原因？我认为 Mac OS X 和 Linux 可能会按原样工作，因为它们使用的是 UTF-8，并且许多 ASCII 程序代码无需任何修改就可以很好地使用 UTF-8。

Windows 可能会返回 UTF-16 格式的文件名或路径，所以它更复杂，但是有一些函数可以将 UTF-16 转换为 UTF-8，反之亦然，所以这不是一个可以解决的问题吗？

我正在使用 Python 3 进行编程，但遇到了一个小问题，我在网上找不到任何对它的引用。

据我了解，默认字符串是 utf-16，但我必须使用 utf-8，我找不到将从默认字符串转换为 utf-8 的命令。非常感谢您的帮助。

欢迎unsafe登陆。

我正在对一个遗留库进行 P/Invoke，它以未知长度的非托管字节缓冲区的形式为我提供了一个以 0 结尾的 C 样式字符串，该缓冲区可以是 ASCII或UTF-16，但没有给出任何指示- 除了字节流本身...

现在我有一个糟糕的方案，基于检查单字节和双 0 字节，来决定是否应该创建一个托管String的 fromChar*或SByte*. 对于每个高于U+00FF.

这就是我所拥有的：

• 非托管字节缓冲区的地址。
• 非托管字节缓冲区的长度未知。
• 非托管字节缓冲区是一个以 0 结尾的 ASCII C 样式字符串或一个以 0 结尾的 UTF-16 C 样式字符串。

这就是我要的：

• 从非托管字节缓冲区创建正确String的托管字节缓冲区，无论是 ASCII 还是 UTF-16。

这个问题一般可以解决吗？

我使用此函数将文件读取为字符串

这是文件的文本：

这是 LoadFile 的返回值：

我想制作一个包含“verabc”的新文件。问题是我仍然无法将“sion”替换为“abc”。我正在使用 D2007。如果我删除所有 #0 则结果变为汉字。

我正在编写一个与 mingw 一起使用的包装层，它为应用程序提供虚拟 UTF-8 环境。处理文件名的函数是从 UTF-8 转换并调用相应的“_w”函数的包装器，依此类推。我遇到的最大问题是 Windowswchar_t是 16 位的。

对于文件系统操作，这没什么大不了的。我可以在 UTF-8 和 UTF-16 之间来回转换，一切正常。但是标准的 C 多字节/宽字符转换 API 不允许多 wchar_t 字符。

可能的解决方案：

1. 提供 CESU-8 环境而不是 UTF-8。我真的不喜欢这个。
2. 采取简单的方法，只支持 BMP。将长度为 4 的 UTF-8 序列视为无效。
3. 扩展包装以替换 mingw'swchar_t和typedef int32_t wchar_t;处理WCHAR和wchar_t不同。这很痛苦，但它可能是移植需要干净 POSIX 类型环境且不wchar_t用于任何 Windows-API 目的的应用程序的理想选择。
4. 以下黑客：

mbrtowcwchar_t读取一个 4 字节 UTF-8 字符的前 3 个字节后，输出对应于高代理的 a，并将剩余状态保留在mbstate_t对象中。在接收到下一个字节后，它将其与保存的状态结合以输出低代理。如果最后一个字节最终无效，则返回 -1（使用 EILSEQ），并且在输出流中会出现一个单独的代理项（坏...）。

wcrtomb在处理高位代理时输出 UTF-8 的前 2 个字节，并将剩余状态保存在其mbstate_t对象中。当它随后处理低代理时，它将其与保存的状态相结合以输出 UTF-8 的最后 2 个字节。如果未接收到有效的低代理，则返回 -1（使用 EILSEQ），并且输出流中会出现不完整的 UTF-8 序列（坏...）。

这个 hack 的好处是只要输入有效，它就可以工作，并允许访问任何 UTF-8 字符，从而访问任何可能的文件名/参数/等。应用程序可能需要使用的文本。

缺点是它不严格符合 ISO C（wchar_t字符串不允许有状态），并且它延迟了对畸形字符的检测，直到已经写入了不正确的部分输出。

我正在寻找有关不同选项的反馈，尤其是我提出的 hack：它是否合理，缺点是否可能导致严重错误，以及是否还有其他我尚未考虑的缺点可能会阻止该计划完全工作。我也很高兴听到我没有想到的任何其他可能的解决方案。