Byte数据在未填充的位置上补充0

[CapAvenger]

有一个数组

 Byte[] Message;
Byte[] byte_Length=new byte[4];

int SendLength = Message.Length;  //获取Message的长度
byte_Length = System.Text.Encoding.UTF8.GetBytes(SendLength.ToString());  //转成Byte

我会把message的长度进去。
比如说长度是7
希望得到byte_Length数组的效果是：{0,0,0,55}
如果SendLength长度是15，byte_Length长度是两位则是{0,0,49,53}
。。依次类推
就是吧Byte数组没满的部分都填充0
这个怎么写，Byte数组固定是4位~

[CapAvenger]

引用 7 楼 Forty2 的回复:

我一点都没有觉得你幼稚。 我是想提醒初学者，那种方法非常不好。

好吧，那我请教个问题呗，就是我有个字符串长度，需要保存到数Byte[]里面去 长度是可能是5，可能是15，可能是155可能是1233，四位以及以内的 在保存到Byte[]里的时候我希望无论是多少位的数字，保存到数组里面都是4位，没有填充的地方填充0就行

[以专业开发人员为伍]

万一长度是 12345 可咋办呢？ 既然你预留了4个字节，那就保存一个 int 而不是字符串，才是专业程序员的习惯。 例如你可以写

int x = 12345;    或者  uint x = 12345;
var r = BitConverter.GetBytes(x);

[wangyu0517]

         
            //  byte_Length = System.Text.Encoding.UTF8.GetBytes(SendLength.ToString());  //转成Byte
            Byte[] byteTemp;
            byteTemp = System.Text.Encoding.UTF8.GetBytes(SendLength.ToString()); 
            for (int i = 0; i < byteTemp.Length; i++)
            {
                byte_Length[byteTemp.Length+i] = byteTemp[i];   
            }

[wangyu0517]

我只按要求解决你的问题，不考虑你的方案是否合理

[Forty2]

两种方法：

int length = 155;
byte[] bs1 = BitConverter.GetBytes(length);   // {155, 0, 0, 0}
byte[] bs2 = Encoding.ASCII.GetBytes(length.ToString("0000")); // {'0','1','5','5'}

int l1 = BitConverter.ToInt32(bs1, 0);  // 155
int l2 = Convert.ToInt32(Encoding.ASCII.GetString(bs2)); // 155

[以专业开发人员为伍]

其实你随便打开一个页面，其主页面的那点 html 内容部分也基本上都超过 10000 个字符。 所以你按照 Ascii 码形式以为“4位”字符就够表示消息长度了，这其实不符合一个通讯程序的基本。低于应用要求。

[wangyu0517]

投标时我也经常遇到奇葩协议，有一次就和这个一样，要求数据包长度通过明文发过来，也就是发明文字符串，多此一举的事，没办法，别人协议就要求那样。

[以专业开发人员为伍]

html 内容部分也基本上都超过 10000 个字符 --> html 内容部分也基本上都超过 10000 个字节

[娃都会打酱油了]

new byte[4]，默认每个值都是0啊…… 你自己赋了其它值，导致它不再是原来的byte数组……

[以专业开发人员为伍]

引用 15 楼 u012830772 的回复:

投标时我也经常遇到奇葩协议，有一次就和这个一样，要求数据包长度通过明文发过来，也就是发明文字符串，多此一举的事，没办法，别人协议就要求那样。

我们还直接使用 json 明文呢，用回车换行作为消息结束符。 用明文一点问题都没有，关键是如何用明文。不要用混乱的方式来结合字符串和二进制数字就很好了。

[CapAvenger]

引用 10 楼 sp1234 的回复:

万一长度是 12345 可咋办呢？ 既然你预留了4个字节，那就保存一个 int 而不是字符串，才是专业程序员的习惯。 例如你可以写

int x = 12345;    或者  uint x = 12345;
var r = BitConverter.GetBytes(x);

你说的很对，现在看一下我的这段代码是不太好，谢谢

[Forty2]

引用 15 楼 u012830772 的回复:

投标时我也经常遇到奇葩协议，有一次就和这个一样，要求数据包长度通过明文发过来，也就是发明文字符串，多此一举的事，没办法，别人协议就要求那样。

"长度通过明文发过来"本身并没有问题。HTTP协议的Content-Length就是发的明文。 关键是协议要一致。字符和字节混用，就不是好的协议。

[CapAvenger]

引用 15 楼 u012830772 的回复:

投标时我也经常遇到奇葩协议，有一次就和这个一样，要求数据包长度通过明文发过来，也就是发明文字符串，多此一举的事，没办法，别人协议就要求那样。

这个东西就别人要的~

[CapAvenger]

引用 13 楼 Forty2 的回复:

两种方法：

int length = 155;
byte[] bs1 = BitConverter.GetBytes(length);   // {155, 0, 0, 0}
byte[] bs2 = Encoding.ASCII.GetBytes(length.ToString("0000")); // {'0','1','5','5'}

int l1 = BitConverter.ToInt32(bs1, 0);  // 155
int l2 = Convert.ToInt32(Encoding.ASCII.GetString(bs2)); // 155

我想要的就是这一句 byte[] bs1 = BitConverter.GetBytes(length) 就行了~

[以专业开发人员为伍]

比如说，要发送视频流，那么你的系统可能首先发一个指令，是 json 形式的，是明文的，里边就有数据的长度（json中的数值自然就是字符表示的、可读的）。 然后你或者使用另一个端口、或者使用同一个端口，随后发二进制视频流。（使用同一个端口，就阻塞了指令服务的并发多线程处理的能力，所以通常用另外一个专门用来收发二进制信息、而不是 json 形式指令的端口。 用明文，一点问题都没有。但是这个协议中很明晰，两个不同的消息类型所使用的技术的区别很干净，不混乱。

[以专业开发人员为伍]

引用 22 楼 z1992x 的回复:

我想要的就是这一句 byte[] bs1 = BitConverter.GetBytes(length) 就行了~

举例说明两种不同形式的消息常见的形式 如果你的消息体是纯粹二进制的 byte[ ]，那么前边4为是 BitConverter.GetBytes(bytes.Length)。这样就能引导上G字节长度的消息。 而如果你的消息体是 string，不管里边包含什么字符（包括换行、回车），你可以使用 json 形式的 string 来转义，例如

var str = @"dfafd ad f
4324234";
var serializer = new JavaScriptSerializer();
var msg = serializer.Serialize(str);    //发消息用msg
var str2 = serializer.Deserialize<string>(msg);   //解析消息结果为 str2
Debug.Assert(str == str2);

在发消息时，在 msg 的最后加上回车，然后接收消息端用回车符号作为消息结束符，来识别消息。 实际上传字符串方式也是一种很常见的通讯方式。最近10几年许多通讯框架都是基于字符串序列化机制的（支持两端程序版本不一致，两端解析同一个对象的属性顺序颠倒、增删，仍然可以顺利解析消息对象），而几十年前的老的电信业一类的软件才会抠字节报文。

[CapAvenger]

引用 24 楼 sp1234 的回复:

[quote=引用 22 楼 z1992x 的回复:] 我想要的就是这一句 byte[] bs1 = BitConverter.GetBytes(length) 就行了~

举例说明两种不同形式的消息常见的形式 如果你的消息体是纯粹二进制的 byte[ ]，那么前边4为是 BitConverter.GetBytes(bytes.Length)。这样就能引导上G字节长度的消息。 而如果你的消息体是 string，不管里边包含什么字符（包括换行、回车），你可以使用 json 形式的 string 来转义，例如

var str = @"dfafd ad f
4324234";
var serializer = new JavaScriptSerializer();
var msg = serializer.Serialize(str);    //发消息用msg
var str2 = serializer.Deserialize<string>(msg);   //解析消息结果为 str2
Debug.Assert(str == str2);

在发消息时，在 msg 的最后加上回车，然后接收消息端用回车符号作为消息结束符，来识别消息。 实际上传字符串方式也是一种很常见的通讯方式。最近10几年许多通讯框架都是基于字符串序列化机制的（支持两端程序版本不一致，两端解析同一个对象的属性顺序颠倒、增删，仍然可以顺利解析消息对象），而几十年前的老的电信业一类的软件才会抠字节报文。 [/quote] 我这边是socket去传输数据的，所以都要转换成Byte数组，然后解析的~

[_小黑_]

引用 15 楼 u012830772 的回复:

投标时我也经常遇到奇葩协议，有一次就和这个一样，要求数据包长度通过明文发过来，也就是发明文字符串，多此一举的事，没办法，别人协议就要求那样。

没有 传输大小 限制的话 当然用明文比较好 简单粗暴 还不用解析

[ceshizxcvbnm]

test002

[CapAvenger]

感谢大家，结帖啦