字符串总是 Little Endian Unicode 吗？答案

【问题标题】：Are strings ALWAYS Little Endian Unicode?字符串总是 Little Endian Unicode 吗？
【发布时间】：2020-09-06 18:20:48
【问题描述】：

我知道字符串以 Unicode 格式存储。我还听说字符串总是 Little Endian Unicode，即使系统是 Big Endian。我的问题是这样的：

如果系统也是 Big Endian，字符串是否以 Big Endian Unicode 表示？

顺便说一句，在写入需要为 Little Endian Unicode 的文件时，我使用它来提高性能。

【问题讨论】：

你能澄清一下你想知道的吗？？
我的问题是字符串在内部存储为 Big Endian Unicode IF SYSTEM 也是 big endian？
这听起来像XY problem：您为什么对.Net 如何存储字符串感兴趣（我假设在内存中）？除非您打算使用原始内存和不安全的代码，否则这不是您应该担心的事情。还是只是单纯的（好的）好奇心？
我不知道 .NET 内部使用什么字节顺序来存储字符串。无论如何，对于你的情况，我认为你不应该知道它来加速你的代码，除非你测量并意识到你有一个真实而有意义的性能问题。你最终应该使用不安全的代码，在任何情况下我都怀疑你将能够击败 .Net UnicodeEncoding 类性能
如果您想通过匹配编码来实现性能加速，您必须对 .NET 字符串有深入的了解，并且您必须已经花费数小时来优化其他所有内容。如果没有，您可以通过优化其他内容获得更多收益。

标签： c# .net string unicode encoding

【解决方案1】：

The CLI specification 说：

I II.1.1.3 字符数据类型

CLI char 类型在内存中占用 2 个字节，表示使用 UTF-16 的 Unicode 代码单元编码。

不要求它采用特定的字节顺序。并且有充分的理由期望字节顺序与当前架构的其他数字类型的字节顺序相匹配。 IE。在大端机器上，人们会期望 char 类型被存储为大端 16 位值。

虽然它不是权威文档，但我会注意到有几个回答或评论过How do I get a consistent byte representation of strings in C# without manually specifying an encoding? 的人都认同这一观点，即char 类型的字节序取决于平台架构。 cmets 中有几个声明和该问题的答案声称 char 在大端系统上是大端。

在我看来，如果您的架构的字节序很重要，您将可以访问大字节序架构的 CLI 实现，并且可以轻松验证用于 char 类型的字节顺序.你有没有努力做这样的验证？

话虽如此，您很可能不需要知道char 类型的字节顺序。 .NET 为各种编码提供字符编码器，包括 UTF16-LE 和 UTF16-BE。当使用 char 类型本身时，字节顺序无关紧要，在字节顺序很重要的情况下，您可以使用适当的 Encoding 类型强制特定的顺序。如果您认为自己的情况属于这些一般准则的例外情况，最好发布一个问题，准确描述该情况是什么以及您为什么认为这是一般准则的例外情况。

【讨论】：