8

有人可以提供一些我在 C# 中处理 Unicode 字符串时应该注意的重要方面吗?

4

7 回答 7

12

请记住,C# 字符串是 Char、UTF-16 代码单元的序列。它们不是Unicode 代码点。一些 unicode 代码点需要两个字符,您不应该在这些字符之间拆分字符串。

此外,unicode 代码点可以组合形成单一语言“字符”——例如,“u”字符后跟 umlat 字符。因此,您也不能在任意代码点之间拆分字符串。

基本上,这是一堆乱七八糟的问题,任何给定的问题在实践中可能只会影响你不知道的语言。

于 2008-09-27T21:53:37.817 回答
7

C#(和一般的 .Net)透明地处理 unicode 字符串,除非您的应用程序需要读取/写入具有特定编码的文件,否则您无需执行任何特殊操作。在这些情况下,您可以使用 System.Text.Encodings 命名空间中的类将托管字符串转换为您选择的编码的字节数组。

于 2008-09-27T20:33:02.770 回答
2

System.String 已经在内部处理了 unicode,因此您可以在其中进行处理。最佳做法是在读写文件时使用 System.Text.Encoding.UTF8Encoding。然而,它不仅仅是读取/写入文件,包括网络连接在内的任何流式传输数据都将取决于编码。如果您使用 WCF,大多数绑定将默认为 UTF8(实际上大多数绑定根本不允许使用 ASCII)。

UTF8 是一个不错的选择,因为虽然它仍然支持整个 Unicode 字符集,但对于大多数 ASCII 字符集来说,它具有字节相似性。因此,不支持 Unicode 的幼稚应用程序有一些机会读取/写入您的应用程序数据。只有当您开始使用扩展字符时,这些应用程序才会开始失败。

System.Text.Encoding.Unicode 将写入 UTF-16,即每个字符至少两个字节,使其更大且与 ASCII 完全不兼容。你可以猜到的 System.Text.Encoding.UTF32 仍然更大。我不确定 UTF-16 和 32 的实际用例,但是当您有大量扩展字符时,它们的性能可能会更好。这只是一个理论,但如果这是真的,那么日本/中国开发人员制作的产品主要用于这些语言可能会发现 UTF-16/32 是更好的选择。

于 2008-09-29T06:49:08.973 回答
1

读写流时只考虑编码。使用 TextReader 和 TextWriters 以不同的编码读取和写入文本。如果可以选择,请始终使用 utf-8。

不要对语言和文化感到困惑——这是与 unicode 完全不同的问题。

于 2008-09-27T20:33:36.823 回答
0

.Net 有比较好的 i18n 支持。您实际上不需要考虑 unicode,因为所有 .Net 字符串和内置字符串函数都使用 unicode 做正确的事情。唯一要记住的是,大多数字符串函数,例如 DateTime.ToString(),默认使用线程的文化,默认情况下是 Windows 文化。您可以在当前线程或每个方法调用上为格式化指定不同的文化。

唯一一次 unicode 是一个问题是在编码/解码字符串到字节和从字节中解码时。

于 2008-09-27T20:34:09.303 回答
0

如前所述,.NET 字符串透明地处理 Unicode。除了文件 I/O,另一个考虑因素是数据库层。例如,SQL Server 区分 VARCHAR(非 unicode)和 NVARCHAR(处理 unicode)。还需要注意存储过程的参数。

于 2008-09-28T16:26:25.647 回答
-1

可以在此线程上找到更多详细信息:

http://discuss.joelonsoftware.com/default.asp?dotnet.12.189999.12

于 2009-02-09T04:58:49.310 回答