与这里的答案相反，如果不需要解释字节，则不需要担心编码！

正如您提到的，您的目标很简单，就是“获取字符串存储的字节数”。（当然，还要能够根据字节重新构造字符串。）

对于这些目标，我真的不明白为什么人们总是告诉你你需要编码。你当然不需要担心编码。

只需执行以下操作：

static byte[] GetBytes(string str)
{
    byte[] bytes = new byte[str.Length * sizeof(char)];
    System.Buffer.BlockCopy(str.ToCharArray(), 0, bytes, 0, bytes.Length);
    return bytes;
}

// Do NOT use on arbitrary bytes; only use on GetBytes's output on the SAME system
static string GetString(byte[] bytes)
{
    char[] chars = new char[bytes.Length / sizeof(char)];
    System.Buffer.BlockCopy(bytes, 0, chars, 0, bytes.Length);
    return new string(chars);
}

只要你的程序（或其他程序）不试图以某种方式解释字节，而你显然没有提到你打算这样做，那么这种方法就没有错！担心编码只会让你的生活变得更加复杂，没有真正的原因。

这种方法的额外好处：字符串是否包含无效字符无关紧要，因为您仍然可以获取数据并重建原始字符串！

它将以相同的方式进行编码和解码，因为您只是在查看字节。

但是，如果您使用特定的编码，则会给您带来编码/解码无效字符的麻烦。

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

Joel对此发表了一篇帖子：

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

LINQ的简单代码

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

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

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

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

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

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

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

您可能需要与以不同语言或运行时实现的流程进行通信。（例如，这可能包括在另一台机器上运行的服务器或将字符串发送到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")

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

// C# to convert a string to a byte array.
public static byte[] StrToByteArray(string str)
{
    System.Text.ASCIIEncoding  encoding=new System.Text.ASCIIEncoding();
    return encoding.GetBytes(str);
}


// C# to convert a byte array to a string.
byte [] dBytes = ...
string str;
System.Text.ASCIIEncoding enc = new System.Text.ASCIIEncoding();
str = enc.GetString(dBytes);

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