如果您使用的是.NET Core或System.Memory for.NET Framework，则通过Span＜T＞和Memory＜T＞有一种非常有效的封送机制，可以有效地将字符串内存重新解释为字节跨度。一旦有了一个字节跨度，就可以自由地封送回另一个类型，或者将该跨度复制到数组中进行序列化。

总结一下其他人的看法：

存储这种序列化的表示形式对系统端序、编译器优化以及正在执行的.NET运行时中字符串的内部表示形式的更改非常敏感。避免长期储存避免在其他环境中反序列化或解释字符串这包括其他机器、处理器体系结构、.NET运行时、容器等。这包括比较、格式化、加密、字符串操作、本地化、字符转换等。避免对字符编码进行假设在实践中，默认编码倾向于UTF-16LE，但编译器/运行时可以选择任何内部表示

实施

public static class MarshalExtensions
{
   public static ReadOnlySpan<byte> AsBytes(this string value) => MemoryMarshal.AsBytes(value.AsSpan());
   public static string AsString(this ReadOnlySpan<byte> value) => new string(MemoryMarshal.Cast<byte, char>(value));
}

实例

static void Main(string[] args)
{
    string str1 = "你好，世界";
    ReadOnlySpan<byte> span = str1.AsBytes();
    string str2 = span.AsString();

    byte[] bytes = span.ToArray();

    Debug.Assert(bytes.Length > 0);
    Debug.Assert(str1 == str2);
}

Furthur洞察

在C++中，这大致相当于reinterpret_cast，而C大致相当于对系统的单词类型（char）的强制转换。

在最新版本的.NET核心运行时（CoreCLR）中，如果您的内存是由CLR分配的，并且跨段不是从非托管内存分配器的指针派生的，则跨段上的操作可以有效地调用编译器内部函数和各种优化，这些优化有时可以消除边界检查，从而在保持内存安全的同时提高性能。

注意事项

这使用CLR支持的机制，该机制从字符串返回ReadOnlyPan<char>；此外，此跨度不一定包含完整的内部字符串布局。ReadOnlySpan＜T＞意味着如果需要执行变异，必须创建一个副本，因为字符串是不可变的。

BinaryFormatter bf = new BinaryFormatter();
byte[] bytes;
MemoryStream ms = new MemoryStream();

string orig = "喂 Hello 谢谢 Thank You";
bf.Serialize(ms, orig);
ms.Seek(0, 0);
bytes = ms.ToArray();

MessageBox.Show("Original bytes Length: " + bytes.Length.ToString());

MessageBox.Show("Original string Length: " + orig.Length.ToString());

for (int i = 0; i < bytes.Length; ++i) bytes[i] ^= 168; // pseudo encrypt
for (int i = 0; i < bytes.Length; ++i) bytes[i] ^= 168; // pseudo decrypt

BinaryFormatter bfx = new BinaryFormatter();
MemoryStream msx = new MemoryStream();            
msx.Write(bytes, 0, bytes.Length);
msx.Seek(0, 0);
string sx = (string)bfx.Deserialize(msx);

MessageBox.Show("Still intact :" + sx);

MessageBox.Show("Deserialize string Length(still intact): " 
    + sx.Length.ToString());

BinaryFormatter bfy = new BinaryFormatter();
MemoryStream msy = new MemoryStream();
bfy.Serialize(msy, sx);
msy.Seek(0, 0);
byte[] bytesy = msy.ToArray();

MessageBox.Show("Deserialize bytes Length(still intact): " 
   + bytesy.Length.ToString());

如何在.NET（C#）中将字符串转换为字节[]而不手动指定特定编码？

NET中的字符串将文本表示为UTF-16代码单元的序列，因此字节已经在UTF-16中的内存中编码。

Mehrad的回答

您可以使用Mehrad的答案，但它实际上使用了编码，因为字符是UTF-16。它调用ToCharArray，通过查看源代码创建一个char[]并将内存直接复制到它。然后，它将数据复制到同样分配的字节数组中。因此，在后台，它复制了两次底层字节，并分配了一个在调用后不使用的字符数组。

Tom Blodget的回答

Tom Blodget的答案比Mehrad快20-30%，因为它跳过了分配一个字符数组并将字节复制到其中的中间步骤，但它需要使用/safe选项进行编译。如果你绝对不想使用编码，我认为这是正确的方法。如果将加密登录放在固定块中，甚至不需要分配单独的字节数组并将字节复制到其中。

此外，为什么要考虑编码？我不能简单地获取字符串存储的字节数吗？为什么依赖字符编码？

因为这是正确的方法。字符串是一个抽象。

如果“字符串”包含无效字符，使用编码可能会给您带来麻烦，但这不应该发生。如果将数据输入到字符串中包含无效字符，则说明操作错误。您可能应该首先使用字节数组或Base64编码。

如果使用System.Text.Encoding.Unicode，代码将更具弹性。您不必担心运行代码的系统的端序。您不必担忧下一版本的CLR是否会使用不同的内部字符编码。

我认为问题不在于你为什么要担心编码，而是你为什么要忽略它而使用其他东西。编码旨在表示字节序列中字符串的抽象。System.Text.Encoding.Unicode将为您提供一个小端字节顺序编码，并将在现在和将来的每个系统上执行相同的编码。

我不确定，但我认为字符串将其信息存储为一个Chars数组，这对字节来说效率很低。具体来说，Char的定义是“表示Unicode字符”。

以以下示例为例：

String str = "asdf éß";
String str2 = "asdf gh";
EncodingInfo[] info =  Encoding.GetEncodings();
foreach (EncodingInfo enc in info)
{
    System.Console.WriteLine(enc.Name + " - " 
      + enc.GetEncoding().GetByteCount(str)
      + enc.GetEncoding().GetByteCount(str2));
}

请注意，在这两种情况下，Unicode答案都是14个字节，而UTF-8答案第一种只有9个字节，第二种只有7个字节。

因此，如果您只想要字符串所使用的字节，只需使用Encoding.Unicode，但存储空间会很低。

最接近OP问题的方法是Tom Blodget的，它实际上进入对象并提取字节。我说最接近，因为它取决于String对象的实现。

"Can't I simply get what bytes the string has been stored in?"

当然，但这就是问题的根本错误所在。String是一个可能具有有趣数据结构的对象。我们已经知道它确实存在，因为它允许存储未配对的代孕对象。它可能会存储长度。它可能会保持一个指针指向每一个“配对”的代孕者，以便快速计数。所有这些额外的字节都不是字符数据的一部分。

您需要的是数组中每个字符的字节。这就是“编码”的含义。默认情况下，您将获得UTF-16LE。如果您不关心字节本身，除了往返之外，那么您可以选择任何编码，包括“默认”，然后稍后将其转换回（假设相同的参数，例如默认编码、代码点、错误修复、允许的事情，例如未配对的代理等）。

但为什么要让“编码”变魔术呢？为什么不指定编码，以便知道将获得哪些字节？

"Why is there a dependency on character encodings?"

编码（在此上下文中）只是表示字符串的字节。不是字符串对象的字节。您需要字符串存储的字节——这是天真地问这个问题的地方。您希望字符串的字节位于表示字符串的连续数组中，而不是字符串对象可能包含的所有其他二进制数据。

这意味着字符串的存储方式无关紧要。您需要将字符串“编码”为字节数组中的字节。

我喜欢Tom Bloget的回答，因为他把你引向了“字符串对象的字节”的方向。但它依赖于实现，而且因为他在窥探内部，所以很难重建字符串的副本。

迈赫达德的回应是错误的，因为它在概念层面上具有误导性。您仍然有一个字节列表，已编码。他的特定解决方案允许保留未配对的代孕对象——这取决于实现。如果GetBytes默认以UTF-8格式返回字符串，他的特定解决方案将无法准确生成字符串的字节。

我已经改变了主意（Mehrad的解决方案）——这不是获取字符串的字节数；而是获取从字符串创建的字符数组的字节。无论编码如何，c#中的char数据类型都是固定大小。这允许生成一致长度的字节数组，并且允许基于字节数组的大小来再现字符数组。因此，如果编码是UTF-8，但每个字符都是6字节以容纳最大的utf8值，那么它仍然可以工作。所以事实上，字符的编码并不重要。

但是使用了转换——每个字符都放在一个固定大小的框中（c#的字符类型）。然而，这个表示是什么并不重要，从技术上来说，这是OP的答案。所以，如果你无论如何都要转换。。。为什么不“编码”？

计算机只理解原始二进制数据，原始比特。一位是二进制数字：0或1。8位数字是一个字节。一个字节是介于0和255之间的数字。

ASCII是一种将数字转换为字符的表格。0到31之间的数字是控件：制表符、换行符和其他。32到126之间的数字为可打印字符：字母a，数字1，%符号，下划线_

因此，对于ASCII，有33个控制字符和95个可打印字符。

ASCII是当今最常用的字符编码。Unicode表的第一个条目是ASCII，并与ASCII字符集匹配。

ASCII是一个7位字符集。介于0和127之间的数字。使用8位，我们可以达到255位。

ASCII最常见的替代品是EBCDIC，它与ASCII不兼容，今天仍然存在于IBM计算机和数据库中。

1字节，因此8位数字是当今计算机科学中最常用的单位。1字节是介于0和255之间的数字。

ASCII为0到127之间的每个数字定义了一个含义。

与128和255之间的数字相关联的字符取决于所使用的字符编码。目前广泛使用的两种字符编码是windows1252和UTF-8。

在windows1252中，欧元符号对应的数字是128。1字节：[A0]。在Unicode数据库中，欧元符号是数字8364。

现在我给你电话8364。两个字节：[20，AC]。在UTF-8中，欧元符号是数字14844588。三个字节：[E282AC]。

现在我给你一些原始数据。假设20AC。是两个windows1252字符：£还是一个Unicode€符号？

我给你一些原始数据。e282交流。82是windows1252中未分配的字符，因此它可能不是windows1252。它可能是macRoman“”C“”或OEM 437“”或UTF-8“€”符号。

根据字符编码的特性和统计数据，可以猜测原始字节流的编码，但没有可靠的方法。128到255之间的数字在UTF-8中是无效的。é在某些语言（法语）中很常见，因此如果您看到许多字节的值E9被字母包围，那么它可能是一个windows1252编码字符串，E9字节表示é字符。

当您有一个表示字符串的原始字节流时，了解匹配的编码比猜测要好得多。

下面是曾经被广泛使用的各种编码中的一个原始字节的屏幕截图。