.Net 客户端与使用原始数据的 Java 服务器
我正在 Solaris 上的 Java 服务器上编写 .Net/C# 客户端。
Java 服务器正在以 Gziped 格式写入原始字节数据，我需要提取该数据，但我无法以正确的缓冲区大小读取数据。 我读到的消息不确定是不完整还是完整，并且在任何情况下都无法读取第二条消息。 我正在使用带有 DataAvailable 属性的 NetworkStream 类读取字节。
我的猜测是，这可能与小/大端问题有关。 我是否需要使用特殊转换将数据从大端更改为小端？ 我需要使用 gzip 标头读取必要的字节吗？
我以前曾经使用具有未压缩协议的同一服务器，并且之前使用带有 ReadLine 函数的 StreamReader 没有问题，但该协议是纯粹基于文本的。
编辑：不幸的是，由于给出了远程服务器和协议，我别无选择。 endiness 是 GZip 格式的一部分还是我只需要相应地转换标头？ 未压缩的数据是纯UTF8编码的字符串，以换行符作为分隔符。
I am writting a .Net/C# client to a Java Server on Solaris.
The Java server is writting Raw byte data in a Gziped format which I need to extract, but I am having trouble to read the data in the right buffer sizes. I read the message not-deterministicly incomplete or complete and can not read the second message in any case.
I am reading the bytes using the NetworkStream class with the DataAvailable property.
My guess is that it could be related to a little/big endian problem.
Do I need to use a special conversion to change the data from big into little Endian? Do I need to read the necessary bytes using the gzip header?
I used to use the same server with an uncompressed protocol before and had no problem using a StreamReader with the ReadLine function before, but that protocol was purely text based.
Edit: Unfortunately I have no choice as the remote server and protocol is given. Is the endiness part of the GZip format or do I only need to convert the header accordingly? The uncompressed data are pure UTF8-encoded strings with line breaks as delimiters.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
GZIP 格式并不复杂。 它的所有优点都可以在简单易懂的规范文档 IETF RFC 1952 中找到。 。
GZIP 格式指定字节的位顺序。 它不能通过字节顺序标志进行调整。 GZIP 流的生产者负责遵守这方面的规范，GZIP 流的消费者也同样如此。
如果我正在调试它，我会查看线路两端的字节并验证输入的字节与输出的字节相同。 这足以抛开字节序问题。
如果您没有成功传输 GZIP 字节流，请尝试传输测试数据 - 16 字节的 0xFF，然后是 16 字节的 0xAA，等等。然后，验证这是来自另一端的数据。
抱歉，我不知道您所说的我读到的消息不确定不完整或完整，并且在任何情况下都无法读取第二条消息。第二条消息？ 第二条消息是什么？ 字节序不应影响您接收的数据量。
我觉得你对成功传输数据没有信心。 我建议您在处理字节序问题和 GZIP 格式问题之前验证这一点。
The GZIP format is not complex. It is available in all its glory in a simple, accessible specification document, IETF RFC 1952.
The GZIP format specifies the bit-order for bytes. It is not tunable with a flag for endianness. The producer of a GZIP stream is responsible for conforming to the spec in that regard, and a consumer of a GZIP stream, likewise.
If I were debugging this, I would look at the bytes on either end of the wire and verify that the bytes going in are the same as the bytes coming out. That's enough to put aside the endian issues.
If you don't have success transmitting a GZIP bytestream, try transmitting test data - 16 bytes of 0xFF, followed by 16 bytes of 0xAA, etc etc. And then, verify that this is the data coming out the other end.
I'm sorry, I don't know what you mean by I read the message not-deterministicly incomplete or complete and can not read the second message in any case. Second message? What second message? The endianness shouldn't affect the amount of data you receive.
It feels to me that you don't have confidence that you are successfully transmitting data. I would suggest that you verify that before working on endian issues and GZIP format issues.