如何在.NET(C#)中将字符串转换为字节[]而不手动指定特定编码?
我要加密字符串。我可以在不进行转换的情况下对其进行加密,但我仍然想知道为什么编码会在这里发挥作用。
此外,为什么还要考虑编码?我不能简单地获取字符串存储的字节数吗?为什么依赖字符编码?
如何在.NET(C#)中将字符串转换为字节[]而不手动指定特定编码?
我要加密字符串。我可以在不进行转换的情况下对其进行加密,但我仍然想知道为什么编码会在这里发挥作用。
此外,为什么还要考虑编码?我不能简单地获取字符串存储的字节数吗?为什么依赖字符编码?
byte[] strToByteArray(string str)
{
System.Text.ASCIIEncoding enc = new System.Text.ASCIIEncoding();
return enc.GetBytes(str);
}
这取决于字符串的编码(ASCII、UTF-8…)。
例如:
byte[] b1 = System.Text.Encoding.UTF8.GetBytes (myString);
byte[] b2 = System.Text.Encoding.ASCII.GetBytes (myString);
编码重要的一个小例子:
string pi = "\u03a0";
byte[] ascii = System.Text.Encoding.ASCII.GetBytes (pi);
byte[] utf8 = System.Text.Encoding.UTF8.GetBytes (pi);
Console.WriteLine (ascii.Length); //Will print 1
Console.WriteLine (utf8.Length); //Will print 2
Console.WriteLine (System.Text.Encoding.ASCII.GetString (ascii)); //Will print '?'
ASCII根本无法处理特殊字符。
在内部,.NET框架使用UTF-16表示字符串,因此,如果您只想获得.NET使用的确切字节,请使用System.Text.Encoding.Unicode.GetBytes(…)。
有关详细信息,请参阅.NET Framework(MSDN)中的字符编码。
// 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);
您需要考虑编码,因为1个字符可以由1个或多个字节(最多约6个)表示,不同的编码将对这些字节进行不同的处理。
Joel对此发表了一篇帖子:
绝对最低限度每个软件开发人员绝对、肯定地必须了解Unicode和字符集(没有借口!)
关键问题是字符串中的字形需要32位(字符代码为16位),但字节只有8位可用。一对一映射不存在,除非您将自己限制为仅包含ASCII字符的字符串。System.Text.Encoding有很多方法可以将字符串映射到byte[],您需要选择一种方法来避免信息丢失,并且当您的客户端需要将byte[]映射回字符串时,它很容易使用。
Utf8是一种流行的编码方式,它紧凑而无损耗。
我不确定,但我认为字符串将其信息存储为一个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,但存储空间会很低。
其他人已经回答了您问题的第一部分(如何获取字节):查看System.Text.Encoding命名空间。
我将回答您的后续问题:为什么需要选择编码?为什么不能从字符串类本身获得这些信息?
答案分为两部分。
首先,字符串类内部使用的字节并不重要,只要假设它们存在,就可能引入错误。
如果您的程序完全在.Net世界中,那么您根本不需要担心获取字符串的字节数组,即使您正在通过网络发送数据。相反,请使用.Net Serialization来担心数据传输问题。您不再担心实际的字节数:Serialization格式化程序会为您提供。
另一方面,如果您将这些字节发送到某个无法保证将从.Net序列化流中提取数据的地方,该怎么办?在这种情况下,您确实需要担心编码问题,因为显然,这个外部系统关心编码问题。同样,字符串使用的内部字节无关紧要:您需要选择一种编码,以便在接收端明确该编码,即使它与.Net内部使用的编码相同。
我理解,在这种情况下,您可能更希望在可能的情况下使用字符串变量存储在内存中的实际字节,这样可以节省创建字节流的工作量。然而,我告诉你,与确保输出在另一端被理解,并保证编码必须明确相比,这并不重要。此外,如果您真的想匹配内部字节,您可以只选择Unicode编码,从而节省性能。
这让我进入第二部分。。。选择Unicode编码就是告诉.Net使用底层字节。您确实需要选择这种编码,因为当一些新的Unicode Plus问世时,.Net运行时需要自由使用这种更新、更好的编码模型,而不会破坏您的程序。但是,目前(以及可预见的未来),只要选择Unicode编码就可以满足您的需要。
理解字符串必须重写为线也是很重要的,即使使用匹配的编码,也至少需要对位模式进行一些转换。计算机需要考虑诸如Big vs Little Endian、网络字节顺序、分组化、会话信息等。
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());
两种方式:
public static byte[] StrToByteArray(this string s)
{
List<byte> value = new List<byte>();
foreach (char c in s.ToCharArray())
value.Add(c.ToByte());
return value.ToArray();
}
And,
public static byte[] StrToByteArray(this string s)
{
s = s.Replace(" ", string.Empty);
byte[] buffer = new byte[s.Length / 2];
for (int i = 0; i < s.Length; i += 2)
buffer[i / 2] = (byte)Convert.ToByte(s.Substring(i, 2), 16);
return buffer;
}
我倾向于使用最下面的一个比最上面的一个更频繁,还没有对它们的速度进行基准测试。
此外,请解释为什么要考虑编码。我不能简单地获取字符串存储的字节数吗?为什么依赖编码?!!!
因为没有“字符串的字节”这样的东西。
字符串(或更一般的文本)由字符组成:字母、数字和其他符号。这就是全部。然而,计算机对字符一无所知;它们只能处理字节。因此,如果要使用计算机存储或传输文本,需要将字符转换为字节。你是怎么做到的?这里是编码出现的地方。
编码只是将逻辑字符转换为物理字节的惯例。最简单和最著名的编码是ASCII,如果你用英语写作,这就是你所需要的。对于其他语言,您将需要更完整的编码,因为Unicode是当今最安全的选择。
因此,简而言之,尝试“不使用编码获取字符串的字节”与“不使用任何语言编写文本”一样不可能。
顺便说一句,我强烈建议你(以及任何人)阅读这篇小智慧:绝对最低限度每个软件开发人员绝对、积极地必须了解Unicode和字符集(没有借口!)
最快的方式
public static byte[] GetBytes(string text)
{
return System.Text.ASCIIEncoding.UTF8.GetBytes(text);
}
编辑正如Makotosan所说,这是现在最好的方式:
Encoding.UTF8.GetBytes(text)
嗯,我读过所有的答案,它们都是关于使用编码或关于删除未配对代理的序列化。
例如,如果字符串来自SQL Server,它是从存储例如密码哈希的字节数组构建的,这就很糟糕了。如果我们从中删除任何内容,它将存储一个无效的哈希,如果我们想将其存储在XML中,我们希望保持它的完整性(因为XML编写器会在它找到的任何未配对代理上删除一个异常)。
所以我在这种情况下使用了字节数组的Base64编码,但是在互联网上,只有一种解决方案是C#,而且它有bug,而且只有一种方法,所以我已经修复了bug并编写了返回过程。给你,未来的谷歌人:
public static byte[] StringToBytes(string str)
{
byte[] data = new byte[str.Length * 2];
for (int i = 0; i < str.Length; ++i)
{
char ch = str[i];
data[i * 2] = (byte)(ch & 0xFF);
data[i * 2 + 1] = (byte)((ch & 0xFF00) >> 8);
}
return data;
}
public static string StringFromBytes(byte[] arr)
{
char[] ch = new char[arr.Length / 2];
for (int i = 0; i < ch.Length; ++i)
{
ch[i] = (char)((int)arr[i * 2] + (((int)arr[i * 2 + 1]) << 8));
}
return new String(ch);
}
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类:
const string data = "A string with international characters: Norwegian: ÆØÅæøå, Chinese: 喂 谢谢";
var bytes = System.Text.Encoding.UTF8.GetBytes(data);
var decoded = System.Text.Encoding.UTF8.GetString(bytes);
如果你不需要。。。
与这里的答案相反,如果不需要解释字节,则不需要担心编码!
正如您提到的,您的目标很简单,就是“获取字符串存储的字节数”。(当然,还要能够根据字节重新构造字符串。)
对于这些目标,我真的不明白为什么人们总是告诉你你需要编码。你当然不需要担心编码。
只需执行以下操作:
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);
}
只要你的程序(或其他程序)不试图以某种方式解释字节,而你显然没有提到你打算这样做,那么这种方法就没有错!担心编码只会让你的生活变得更加复杂,没有真正的原因。
这种方法的额外好处:字符串是否包含无效字符无关紧要,因为您仍然可以获取数据并重建原始字符串!
它将以相同的方式进行编码和解码,因为您只是在查看字节。
但是,如果您使用特定的编码,则会给您带来编码/解码无效字符的麻烦。
为了证明Mehrrad的声音回答有效,他的方法甚至可以持久化未配对的代理字符(其中许多人对我的答案持反对态度,但每个人都有同样的错误,例如System.Text.Encoding.UTF8.GetBytes、System.Text.Encding.Unicode.GetBytes;例如,这些编码方法不能持久化高代理字符d800,而这些方法只是用值fffd替换高代理字符):
using System;
class Program
{
static void Main(string[] args)
{
string t = "爱虫";
string s = "Test\ud800Test";
byte[] dumpToBytes = GetBytes(s);
string getItBack = GetString(dumpToBytes);
foreach (char item in getItBack)
{
Console.WriteLine("{0} {1}", item, ((ushort)item).ToString("x"));
}
}
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;
}
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);
}
}
输出:
T 54
e 65
s 73
t 74
? d800
T 54
e 65
s 73
t 74
尝试使用System.Text.Encoding.UTF8.GetBytes或System.Text.Encding.Unicode.GetBytes,它们只会用值fffd替换高代理项字符
每当这个问题发生变化时,我仍然在想一个序列化程序(无论是来自Microsoft还是来自第三方组件),它可以持久化字符串,即使它包含不成对的代理字符;我时不时地在谷歌上搜索这个:序列化不成对的代理角色.NET。这不会让我失眠,但偶尔有人评论我的答案,说它有缺陷,但他们的答案在不成对的替代角色方面同样有缺陷,这让我很烦。
Darn,Microsoft应该在BinaryFormatter中使用System.Buffer.BlockCopyツ
谢谢!
LINQ的简单代码
string s = "abc"
byte[] b = s.Select(e => (byte)e).ToArray();
编辑:如下所述,这不是一个好方法。
但您仍然可以使用它来理解LINQ,并使用更合适的编码:
string s = "abc"
byte[] b = s.Cast<byte>().ToArray();
以下是我的String-to-Byte[]转换的不安全实现:
public static unsafe Byte[] GetBytes(String s)
{
Int32 length = s.Length * sizeof(Char);
Byte[] bytes = new Byte[length];
fixed (Char* pInput = s)
fixed (Byte* pBytes = bytes)
{
Byte* source = (Byte*)pInput;
Byte* destination = pBytes;
if (length >= 16)
{
do
{
*((Int64*)destination) = *((Int64*)source);
*((Int64*)(destination + 8)) = *((Int64*)(source + 8));
source += 16;
destination += 16;
}
while ((length -= 16) >= 16);
}
if (length > 0)
{
if ((length & 8) != 0)
{
*((Int64*)destination) = *((Int64*)source);
source += 8;
destination += 8;
}
if ((length & 4) != 0)
{
*((Int32*)destination) = *((Int32*)source);
source += 4;
destination += 4;
}
if ((length & 2) != 0)
{
*((Int16*)destination) = *((Int16*)source);
source += 2;
destination += 2;
}
if ((length & 1) != 0)
{
++source;
++destination;
destination[0] = source[0];
}
}
}
return bytes;
}
它比公认的anwser要快得多,即使没有它那么优雅。以下是我在10000000次迭代中的秒表基准:
[Second String: Length 20]
Buffer.BlockCopy: 746ms
Unsafe: 557ms
[Second String: Length 50]
Buffer.BlockCopy: 861ms
Unsafe: 753ms
[Third String: Length 100]
Buffer.BlockCopy: 1250ms
Unsafe: 1063ms
为了使用它,您必须在项目构建财产中勾选“允许不安全代码”。根据.NET Framework 3.5,此方法也可以用作字符串扩展:
public static unsafe class StringExtensions
{
public static Byte[] ToByteArray(this String s)
{
// Method Code
}
}
代码如下:
// Input string.
const string input = "Dot Net Perls";
// Invoke GetBytes method.
// ... You can store this array as a field!
byte[] array = Encoding.ASCII.GetBytes(input);
// Loop through contents of the array.
foreach (byte element in array)
{
Console.WriteLine("{0} = {1}", element, (char)element);
}
C#将字符串转换为字节数组:
public static byte[] StrToByteArray(string str)
{
System.Text.UTF8Encoding encoding=new System.Text.UTF8Encoding();
return encoding.GetBytes(str);
}
可以使用以下代码将字符串转换为.NET中的字节数组
string s_unicode = "abcéabc";
byte[] utf8Bytes = System.Text.Encoding.UTF8.GetBytes(s_unicode);
OP的问题:“如何在.NET(C#)中将字符串转换为字节数组?”
您可以使用以下代码:
static byte[] ConvertString (string s) {
return new byte[0];
}
作为一个好处,编码无关紧要!哦,等等,这是一个ecoding。。。它只是微不足道的,而且损耗很大。
Use:
string text = "string";
byte[] array = System.Text.Encoding.UTF8.GetBytes(text);
结果是:
[0] = 115
[1] = 116
[2] = 114
[3] = 105
[4] = 110
[5] = 103
这是一个流行的问题。重要的是要了解作者所问的问题,以及它与最常见的需求不同。为了防止在不需要的地方滥用代码,我首先回答了后者。
共同需求
每个字符串都有一个字符集和编码。将System.String对象转换为System.Byte数组时,仍有字符集和编码。对于大多数用途,您可以知道需要哪个字符集和编码,.NET使“复制并转换”变得简单。只需选择适当的encoding类即可。
// using System.Text;
Encoding.UTF8.GetBytes(".NET String to byte array")
转换可能需要处理目标字符集或编码不支持源中的字符的情况。您有一些选择:异常、替换或跳过。默认策略是替换“?”。
// using System.Text;
var text = Encoding.ASCII.GetString(Encoding.ASCII.GetBytes("You win €100"));
// -> "You win ?100"
显然,转换不一定是无损的!
注意:对于System.String,源字符集是Unicode。
唯一令人困惑的是,.NET使用字符集的名称作为该字符集的一个特定编码的名称。编码。Unicode应称为Encoding.UTF16。
这就是大多数用法。如果这正是你所需要的,请停止阅读这里。如果您不了解编码是什么,请参阅有趣的Joel Spolsky文章。
特定需求
现在,作者提出的问题是,“每个字符串都存储为一个字节数组,对吗?为什么我不能简单地拥有这些字节?”
他不想改变信仰。
根据C#规范:
C#中的字符和字符串处理使用Unicode编码。字符类型表示UTF-16代码单元,字符串类型表示UTF-16代码单元序列。
因此,我们知道,如果我们请求空转换(即,从UTF-16到UTF-16),我们将得到所需的结果:
Encoding.Unicode.GetBytes(".NET String to byte array")
但为了避免提及编码,我们必须采用另一种方式。如果可以接受中间数据类型,则有一个概念上的快捷方式:
".NET String to byte array".ToCharArray()
这并不能为我们提供所需的数据类型,但Mehrad的答案显示了如何使用BlockCopy将此Char数组转换为Byte数组。然而,这将复制字符串两次!而且,它也显式地使用特定于编码的代码:数据类型System.Char。
获取存储字符串的实际字节的唯一方法是使用指针。fixed语句允许获取值的地址。根据C#规范:
[对于]字符串类型的表达式。。。初始值设定项计算字符串中第一个字符的地址。
为此,编译器使用RuntimeHelpers.OffsetToStringData跳过字符串对象的其他部分编写代码。因此,要获取原始字节,只需创建一个指向字符串的指针并复制所需的字节数。
// using System.Runtime.InteropServices
unsafe byte[] GetRawBytes(String s)
{
if (s == null) return null;
var codeunitCount = s.Length;
/* We know that String is a sequence of UTF-16 code units
and such code units are 2 bytes */
var byteCount = codeunitCount * 2;
var bytes = new byte[byteCount];
fixed(void* pRaw = s)
{
Marshal.Copy((IntPtr)pRaw, bytes, 0, byteCount);
}
return bytes;
}
正如@CodesInChaus所指出的,结果取决于机器的端序。但问题的作者并不关心这一点。
要将字符串转换为字节[],请使用以下解决方案:
string s = "abcdefghijklmnopqrstuvwxyz";
byte[] b = System.Text.UTF32Encoding.GetBytes(s);
我希望这有帮助。
由于以下事实,字符串可以通过几种不同的方式转换为字节数组:.NET支持Unicode,Unicode标准化了几种称为UTF的不同编码。它们具有不同长度的字节表示,但在这个意义上是等价的,即当字符串被编码时,它可以被编码回字符串,但如果字符串用一个UTF编码,并且在不同UTF的假设下解码,如果可能会出错。
此外,.NET支持非Unicode编码,但它们在一般情况下无效(只有在实际字符串(如ASCII)中使用有限的Unicode代码点子集时才有效)。在内部,.NET支持UTF-16,但对于流表示,通常使用UTF-8。它也是互联网的事实标准。
毫不奇怪,System.Text.Encoding类是一个抽象类,它支持将字符串序列化为字节数组和反序列化;它的派生类支持具体编码:ASCIIEncoding和四个UTF(System.Text.UnicodeEncoding支持UTF-16)
参考此链接。
对于使用System.Text.Encoding.GetBytes对字节数组进行序列化。对于反向操作,使用System.Text.Encoding.GGetChars。此函数返回字符数组,因此要获取字符串,请使用字符串构造函数System.string(char[])。请参阅本页。
例子:
string myString = //... some string
System.Text.Encoding encoding = System.Text.Encoding.UTF8; //or some other, but prefer some UTF is Unicode is used
byte[] bytes = encoding.GetBytes(myString);
//next lines are written in response to a follow-up questions:
myString = new string(encoding.GetChars(bytes));
byte[] bytes = encoding.GetBytes(myString);
myString = new string(encoding.GetChars(bytes));
byte[] bytes = encoding.GetBytes(myString);
//how many times shall I repeat it to show there is a round-trip? :-)
字符既是字体表的查找键,也是词汇传统,如排序、大小写版本等。
因此,字符不是字节(8位),字节不是字符。特别是,一个字节的256个排列不能容纳某些书面语言中的数千个符号,更不用说所有语言了。因此,已经设计了各种编码字符的方法。某些编码用于特定类别的语言(ASCII编码);使用代码页的多种语言(扩展ASCII);或者,雄心勃勃地,通过根据需要选择性地包括额外的字节,Unicode来实现所有语言。
在系统(如.NET框架)中,字符串表示特定的字符编码。在.NET中,此编码为Unicode。由于框架默认读取和写入Unicode,因此在.NET中通常不需要处理字符编码。
然而,一般来说,要从字节流将字符串加载到系统中,您需要知道源编码,从而正确解释并随后翻译它(否则代码将被视为已在系统的默认编码中,从而呈现乱码)。类似地,当字符串被写入外部源时,它将以特定的编码被写入。
可以使用以下代码在字符串和字节数组之间进行转换。
string s = "Hello World";
// String to Byte[]
byte[] byte1 = System.Text.Encoding.Default.GetBytes(s);
// OR
byte[] byte2 = System.Text.ASCIIEncoding.Default.GetBytes(s);
// Byte[] to string
string str = System.Text.Encoding.UTF8.GetString(byte1);
如果您真的想要一个字符串的基本字节的副本,可以使用下面这样的函数。然而,你不应该继续阅读以找出原因。
[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()
最接近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的答案。所以,如果你无论如何都要转换。。。为什么不“编码”?
对于串行通信项目,我必须将字符串转换为字节数组-我必须处理8位字符,而且我无法找到使用框架转换器的方法,这样既不会添加两个字节条目,也不会错误地转换具有第八位集的字节。所以我做了以下工作:
string message = "This is a message.";
byte[] bytes = new byte[message.Length];
for (int i = 0; i < message.Length; i++)
bytes[i] = (byte)message[i];
这取决于你想要的字节
这是因为,正如泰勒所恰当地说的,“字符串不是纯数据。它们也有信息。”在这种情况下,信息是创建字符串时假定的编码。
假设您有二进制数据(而不是文本)存储在字符串中
这是基于OP对自己问题的评论,如果我理解OP在用例中的提示,这是正确的问题。
由于上面提到的假设编码,将二进制数据存储在字符串中可能是错误的方法!无论哪个程序或库将二进制数据存储在字符串中(而不是更合适的byte[]数组),在战斗开始之前就已经失败了。如果他们以REST请求/响应或任何必须传输字符串的方式向您发送字节,Base64将是正确的方法。
如果您有一个编码未知的文本字符串
其他人都错误地回答了这个错误的问题。
如果字符串看起来不错,只需选择一个编码(最好是以UTF开头的编码),使用相应的System.Text.encoding。???。GetBytes()函数,并告诉给谁您选择了哪种编码。
随着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类的某些实现,而不是将数据作为字符串进行推理。
如何在.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将为您提供一个小端字节顺序编码,并将在现在和将来的每个系统上执行相同的编码。
当被问及您打算如何处理字节时,您回答:
我将对它进行加密。我可以在不进行转换的情况下对其进行加密,但我仍然想知道为什么编码会在这里发挥作用。给我字节就是我说的。
无论您是否打算通过网络发送加密数据,稍后将其加载回内存,或将其流式传输到另一个进程,您显然都打算在某个时刻对其进行解密。在这种情况下,答案是您正在定义通信协议。通信协议不应根据编程语言及其相关运行时的实现细节来定义。这有几个原因:
您可能需要与以不同语言或运行时实现的流程进行通信。(例如,这可能包括在另一台机器上运行的服务器或将字符串发送到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")
正如您所看到的,与实现您自己的读写器方法相比,仅使用内置的编码对象实际上也是更少的代码。
如果您使用的是.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>意味着如果需要执行变异,必须创建一个副本,因为字符串是不可变的。
计算机只理解原始二进制数据,原始比特。一位是二进制数字: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字节表示é字符。
当您有一个表示字符串的原始字节流时,了解匹配的编码比猜测要好得多。
下面是曾经被广泛使用的各种编码中的一个原始字节的屏幕截图。