LINQ的简单代码

string s = "abc"
byte[] b = s.Select(e => (byte)e).ToArray();

编辑：如下所述，这不是一个好方法。

但您仍然可以使用它来理解LINQ，并使用更合适的编码：

string s = "abc"
byte[] b = s.Cast<byte>().ToArray();

bytes[] buffer = UnicodeEncoding.UTF8.GetBytes(string something); //for converting to UTF then get its bytes

bytes[] buffer = ASCIIEncoding.ASCII.GetBytes(string something); //for converting to ascii then get its bytes

如果您使用的是.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＞意味着如果需要执行变异，必须创建一个副本，因为字符串是不可变的。

您需要考虑编码，因为1个字符可以由1个或多个字节（最多约6个）表示，不同的编码将对这些字节进行不同的处理。

Joel对此发表了一篇帖子：

绝对最低限度每个软件开发人员绝对、肯定地必须了解Unicode和字符集（没有借口！）

其他人已经回答了您问题的第一部分（如何获取字节）：查看System.Text.Encoding命名空间。

我将回答您的后续问题：为什么需要选择编码？为什么不能从字符串类本身获得这些信息？

答案分为两部分。

首先，字符串类内部使用的字节并不重要，只要假设它们存在，就可能引入错误。

如果您的程序完全在.Net世界中，那么您根本不需要担心获取字符串的字节数组，即使您正在通过网络发送数据。相反，请使用.Net Serialization来担心数据传输问题。您不再担心实际的字节数：Serialization格式化程序会为您提供。

另一方面，如果您将这些字节发送到某个无法保证将从.Net序列化流中提取数据的地方，该怎么办？在这种情况下，您确实需要担心编码问题，因为显然，这个外部系统关心编码问题。同样，字符串使用的内部字节无关紧要：您需要选择一种编码，以便在接收端明确该编码，即使它与.Net内部使用的编码相同。

我理解，在这种情况下，您可能更希望在可能的情况下使用字符串变量存储在内存中的实际字节，这样可以节省创建字节流的工作量。然而，我告诉你，与确保输出在另一端被理解，并保证编码必须明确相比，这并不重要。此外，如果您真的想匹配内部字节，您可以只选择Unicode编码，从而节省性能。

这让我进入第二部分。。。选择Unicode编码就是告诉.Net使用底层字节。您确实需要选择这种编码，因为当一些新的Unicode Plus问世时，.Net运行时需要自由使用这种更新、更好的编码模型，而不会破坏您的程序。但是，目前（以及可预见的未来），只要选择Unicode编码就可以满足您的需要。

理解字符串必须重写为线也是很重要的，即使使用匹配的编码，也至少需要对位模式进行一些转换。计算机需要考虑诸如Big vs Little Endian、网络字节顺序、分组化、会话信息等。

只需使用此选项：

byte[] myByte= System.Text.ASCIIEncoding.Default.GetBytes(myString);