遇到一个很奇怪的buffer现象。。。

[Setting Sun]

客户端为as3
服务器为nodejs

客户端代码如下

var bytes2:ByteArray=new ByteArray();
var bytes:ByteArray = new ByteArray();

bytes2.writeUTF(Json.encode(data));

trace('length', Json.encode(data).length);

bytes.writeUnsignedInt(bytes2.length-2);//四个字节的数据长度
bytes.writeBytes(bytes2,2,bytes2.length-2);//去掉UTF的两字节长度

socket.writeUnsignedInt(bytes.length+4);
socket.writeBytes(bytes);
socket.flush();

包格式：[包长][数据长][数据]

当数据量小的时候，貌似没什么问题
当数据量大的时候，包长总是多了个字节。不知道是什么东西。。。

服务器收包数据如下
{"op":3,"userId":1}
<Buffer 00 00 00 1b 00 00 00 13 7b 22 6f 70 22 3a 33 2c 22 75 73 65 72 49 64 22 3a 31 7d>
27 19 '{"op":3,"userId":1}'
�|{"op":5,"points":[1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,11,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1]}
<Buffer 00 00 00 ef bf bd 00 00 00 7c 7b 22 6f 70 22 3a 35 2c 22 70 6f 69 6e 74 73 22 3a 5b 31 2c 31 2c 31 2c 31 2c 31 2c 31 2c 31 2c 31 2c 31 2c 31 2c 31 2c 31 ...>

可以看到，第二个包
前4位是的数据已经不对了，真实包长应该为 124 + 8
数据前的数据包长 为 7C= 124
为什么？总包长的数据变成了 00 00 00 ef bf bd很不理解，忘解答

nodejs的代码，可以从这是下，https://github.com/sunblessyou/node-framework
是我闲暇之余搞的小东西。


服务器的收包代码

var buffer = new Buffer(msg, this.charset);
var offset = 0;

while(offset < buffer.length)
{
    var length = buffer.readUInt32BE(offset);
    var dataLength = buffer.readUInt32BE(offset + 4);
    var data = buffer.slice(offset + 8 , offset + 8 + dataLength).toString();

    console.log(length, dataLength, data);

    var dispatcher = new Dispatcher(this, JSON.parse(data));
    var view = dispatcher.dispatch();
    view.display();

    offset += length;
}

[AleiPhoenix (A.K.A Areverie)]

看起来像UTF8 BOM还是 U+FFFD 来着

AS不懂，看看是不是字节流编码的时候有特殊的地方

2012/12/1 Setting Sun <sun...@gmail.com>

--
ThinkingInLAMP邮件组使用说明：http://blog.thinkinlamp.com/?p=758

--
Silence is gold.

twitter: @areverie
wikipedia: AleiPhoenix
blog: weblog.areverie.org
wiki: wiki.areverie.org

[Setting Sun]

我找到了出现的原因，但是我不明白为什么会是如此

就是当我的数据长度是128的时候，总包长就会乱掉，当小于128时就可以正常解析。。。
关键问题是我写的是32int，怎么可能128就跪了呢？？

难不成是nodejs哪方面有限制？

--
ThinkingInLAMP邮件组使用说明：http://blog.thinkinlamp.com/?p=758

[Xiang Song]

UTF8 bom?

EF BB BF

--
ThinkingInLAMP邮件组使用说明：http://blog.thinkinlamp.com/?p=758

[Setting Sun]

不太像bom。。总之后来用土方法解决了。。
客户端在数据包后写\0 服务器如果读到\0则认为一个包，结束
服务器收的包会有如下几种情况，拆包、粘包、包+半包，这些都要额外判断。

--
ThinkingInLAMP邮件组使用说明：http://blog.thinkinlamp.com/?p=758

[Chaos Ray]

可以参考下网易的Pomelo的设计 https://github.com/NetEase/pomelo

于 2012/12/2 17:03, Setting Sun 写道:

不太像bom。。总之后来用土方法解决了。。
客户端在数据包后写\0 服务器如果读到\0则认为一个包，结束
服务器收的包会有如下几种情况，拆包、粘包、包+半包，这些都要额外判断。

在 2012年12月2日 下午12:36，Xiang Song <littlex...@gmail.com>写 道：

UTF8 bom?

EF BB BF

在 2012年12月1日 下午4:49，Setting Sun <sun...@gmail.com>写 道：

我找到了出现的原因，但是我不明白为什么会是如此

就是当我的数据长度是128的时候，总包长就会乱掉，当小于128时就可以正常解析。。。
关键问题是我写的是32int，怎么可能128就跪了呢？？

难不成是nodejs哪方面有限制？

在 2012年12月1日 下午4:29，AleiPhoenix (A.K.A Areverie) <aleip...@gmail.com>写 道：

看起来像UTF8 BOM还是 U+FFFD 来着

AS不懂，看看是不是字节流编码的时候有特殊的地方

2012/12/1 Setting Sun <sun...@gmail.com>

客户端为as3
服务器为nodejs

客户端代码如下

var bytes2:ByteArray=new ByteArray();
var bytes:ByteArray = new ByteArray();

bytes2.writeUTF(Json.encode(data));

trace('length', Json.encode(data).length);

bytes.writeUnsignedInt(bytes2.length- 2);//四个字节的数据长度

bytes.writeBytes(bytes2,2,bytes2.length- 2);//去掉UTF的两字节长度

--
ThinkingInLAMP邮件组使用说明：http://blog.thinkinlamp.com/?p=758

--
ThinkingInLAMP邮件组使用说明：http://blog.thinkinlamp.com/?p=758

--
ThinkingInLAMP邮件组使用说明：http://blog.thinkinlamp.com/?p=758

--
ThinkingInLAMP邮件组使用说明：http://blog.thinkinlamp.com/?p=758

--
ThinkingInLAMP邮件组使用说明：http://blog.thinkinlamp.com/?p=758