试试这个，代码更少：

System.Text.Encoding.UTF8.GetBytes("TEST String");

当被问及您打算如何处理字节时，您回答：

我将对它进行加密。我可以在不进行转换的情况下对其进行加密，但我仍然想知道为什么编码会在这里发挥作用。给我字节就是我说的。

无论您是否打算通过网络发送加密数据，稍后将其加载回内存，或将其流式传输到另一个进程，您显然都打算在某个时刻对其进行解密。在这种情况下，答案是您正在定义通信协议。通信协议不应根据编程语言及其相关运行时的实现细节来定义。这有几个原因：

您可能需要与以不同语言或运行时实现的流程进行通信。（例如，这可能包括在另一台机器上运行的服务器或将字符串发送到JavaScript浏览器客户端。）该程序将来可以用不同的语言或运行时重新实现。.NET实现可能会更改字符串的内部表示形式。您可能会觉得这听起来有些牵强，但这实际上发生在Java9中，以减少内存使用。.NET没有理由不能效仿。Skeet表明，UTF-16在今天可能不是最佳的，因为表情符号和其他Unicode块也需要2个以上的字节来表示，这增加了内部表示在未来可能发生变化的可能性。

为了进行通信（无论是与完全不同的进程还是将来与相同的程序），您需要严格定义协议，以最大限度地减少使用协议或意外创建错误的难度。依赖于.NET的内部表示并不是一个严格的、明确的，甚至不能保证是一致的定义。标准编码是一个严格的定义，将来不会让您失望。

换句话说，如果不指定编码，就无法满足一致性要求。

如果您发现由于.NET在内部使用了UTF-16或出于其他原因，您的进程的性能明显更好，那么您当然可以选择直接使用UTF-16，但您需要显式选择编码，并在代码中显式执行这些转换，而不是依赖于.NET的内部实现。

因此，选择一种编码并使用它：

using System.Text;

// ...

Encoding.Unicode.GetBytes("abc"); # UTF-16 little endian
Encoding.UTF8.GetBytes("abc")

正如您所看到的，与实现您自己的读写器方法相比，仅使用内置的编码对象实际上也是更少的代码。

如果您真的想要一个字符串的基本字节的副本，可以使用下面这样的函数。然而，你不应该继续阅读以找出原因。

[DllImport(
        "msvcrt.dll",
        EntryPoint = "memcpy",
        CallingConvention = CallingConvention.Cdecl,
        SetLastError = false)]
private static extern unsafe void* UnsafeMemoryCopy(
    void* destination,
    void* source,
    uint count);

public static byte[] GetUnderlyingBytes(string source)
{
    var length = source.Length * sizeof(char);
    var result = new byte[length];
    unsafe
    {
        fixed (char* firstSourceChar = source)
        fixed (byte* firstDestination = result)
        {
            var firstSource = (byte*)firstSourceChar;
            UnsafeMemoryCopy(
                firstDestination,
                firstSource,
                (uint)length);
        }
    }

    return result;
}

这个函数会很快地得到字符串下面的字节的副本。您将以任何方式在系统上编码这些字节。这种编码几乎可以肯定是UTF-16LE，但这是一个您不必关心的实现细节。

打电话会更安全、更简单、更可靠，

System.Text.Encoding.Unicode.GetBytes()

这很可能会产生相同的结果，更容易键入，字节将往返，Unicode中的字节表示也可以，调用

System.Text.Encoding.Unicode.GetString()

关键问题是字符串中的字形需要32位（字符代码为16位），但字节只有8位可用。一对一映射不存在，除非您将自己限制为仅包含ASCII字符的字符串。System.Text.Encoding有很多方法可以将字符串映射到byte[]，您需要选择一种方法来避免信息丢失，并且当您的客户端需要将byte[]映射回字符串时，它很容易使用。

Utf8是一种流行的编码方式，它紧凑而无损耗。

最接近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的答案。所以，如果你无论如何都要转换。。。为什么不“编码”？

随着C#7.2发布的Span<T>的出现，将字符串的底层内存表示捕获到托管字节数组中的规范技术是：

byte[] bytes = "rubbish_\u9999_string".AsSpan().AsBytes().ToArray();

将其转换回去应该是一件不容易的事，因为这意味着您实际上正在以某种方式解释数据，但为了完整性：

string s;
unsafe
{
    fixed (char* f = &bytes.AsSpan().NonPortableCast<byte, char>().DangerousGetPinnableReference())
    {
        s = new string(f);
    }
}

NonPortableCast和DangerousGetPinnableReference这两个名称应该进一步证明您可能不应该这样做。

注意，使用Span<T>需要安装System.Memory NuGet包。

无论如何，实际的原始问题和后续评论暗示底层内存没有被“解释”（我假设这意味着没有修改或读取，超出了按原样编写的需要），这表明应该使用Stream类的某些实现，而不是将数据作为字符串进行推理。