TCP/IP 客户端错误地读取输入流字节数组
TCP/IP client incorrectly reading inputstream byte array
我正在创建一个 Java 客户端程序,它向服务器发送命令,然后服务器发回确认和响应字符串。
The response is sent back in this manner
client -> server : cmd_string
server -> client : ack_msg(06)
server -> client : response_msg
客户代码
public static void readStream(InputStream in) {
byte[] messageByte = new byte[20];// assuming mug size -need to
// know eact msg size ?
boolean end = false;
String dataString = "";
int bytesRead = 0;
try {
DataInputStream in1 = new DataInputStream(in);
// while ctr==2 todo 2 streams
int ctr = 0;
while (ctr < 2) {//counter 2 if ACK if NAK ctr=1 todo
bytesRead = in1.read(messageByte);
if (bytesRead > -1) {
ctr++;
}
dataString += new String(messageByte, 0, bytesRead);
System.out.println("\ninput byte arr "+ctr);
for (byte b : messageByte) {
char c=(char)b;
System.out.print(" "+b);
}
}
System.out.println("MESSAGE: " + dataString + "\n bytesread " + bytesRead + " msg length "
+ dataString.length() + "\n");
char[] chars = dataString.toCharArray();
ArrayList<String> hex=new ArrayList<>();
// int[] msg ;
for (int i = 0; i < chars.length; i++) {
int val = (int) chars[i];
System.out.print(" " + val);
hex.add(String.format("%04x", val));
}
System.out.println("\n"+hex);
} catch (Exception e) {
e.printStackTrace();
}
// ===
}
输出
client Socket created ..
response:
input byte arr 1
6 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
input byte arr 2
2 -77 67 79 -77 48 -77 3 -116 0 0 0 0 0 0 0 0 0 0 0
MESSAGE: ##³CO³0³##
(where # is some not supported special character )
bytesread 9 msg length 10
dec: 6 2 179 67 79 179 48 179 3 338
hex: [0006, 0002, 00b3, 0043, 004f, 00b3, 0030, 00b3, 0003, 0152]
bytes: 2 -77 67 79 -77 48 -77 3 -116 0 0 0 0 0 0 0 0 0 0 0 (bytes recieved in 2nd packet)
connection closed
Problem: I'm reading the last value incorrect, I have verified using wireshark the server has sent back the response as 06 02 b3 43
4f b3 30 b3 03 8c
Some how I'm reading the last value in correctly. Is there some issue with the reading stream?
编辑
响应的其余部分已正确读取,但最后一个字符应为 8c 但读为 0152Hex
服务器响应:06 02 b3 43 4f b3 30 b3 03 8c
程序读取:[0006, 0002, 00b3, 0043, 004f, 00b3, 0030, 00b3, 0003, 0152]
读取最后一个字符时出现问题
编辑 2
收到的响应为 2 packets/streams
packet 1 byte arr : 6 (ACK)
packet 2 byte arr: 2 -77 67 79 -77 48 -77 3 -116 (response)
客户端读取完整响应
dec: 6 2 179 67 79 179 48 179 3 338
hex: [0006, 0002, 00b3, 0043, 004f, 00b3, 0030, 00b3, 0003, 0152]
谢谢
这个问题中的问题是 signed 变量与 unsigned 变量的问题。当您在计算机内存中有一个数字时,它由一堆位表示,每个位为 0 或 1。字节通常为 8 位,短字节为 16 等。在 unsigned 数字中, 8 位将使您从正数 0 到 255,但不会变成负数。
这就是 有符号 数字的用武之地。在有符号数字中,第一位告诉您后续位代表负值还是正值。所以现在你可以用8位来表示-128到+127。 (请注意,正数范围减半,从 255 到 127,因为您 "sacrifice" 范围的一半为负数)。
那么现在如果将 signed 转换为 unsigned 会发生什么?根据您的操作方式,事情可能会出错。在上面的问题中,代码 char c=(char)b;
将 signed 字节转换为 unsigned 字符。执行此操作的正确方法是在将其转换为 char 之前 "make your byte unsigned"。你可以这样做:char c=(char)(b&0xFF);
more info on casting a byte here.
基本上,你可以只记住,除了char,所有java数字都是有符号的,你需要做的就是粘贴&0xFF
让它工作一个字节,0xFFFF
使其短时间工作等
有关其工作原理的详细信息如下。调用 & 表示 bitwise and,而 0xFF
是 255 的十六进制。255 超出了有符号字节 (127) 的限制,因此数字 b&0xFF
通过 [= 升级为短整数49=]。但是,短符号位在第 16 位,而字节符号位在第 8 位。所以现在字节符号位变成了普通的 'data' 位,所以你的字节的符号基本上被丢弃了.
如果你进行普通转换,java 会意识到像上面那样进行直接位转换意味着你会丢失符号,并且 java 预计你不喜欢那样(至少,那是我的假设),因此它会为您保留标志。因此,如果这不是您想要的,您可以明确告诉 java 该怎么做。
我正在创建一个 Java 客户端程序,它向服务器发送命令,然后服务器发回确认和响应字符串。
The response is sent back in this manner
client -> server : cmd_string server -> client : ack_msg(06) server -> client : response_msg
客户代码
public static void readStream(InputStream in) {
byte[] messageByte = new byte[20];// assuming mug size -need to
// know eact msg size ?
boolean end = false;
String dataString = "";
int bytesRead = 0;
try {
DataInputStream in1 = new DataInputStream(in);
// while ctr==2 todo 2 streams
int ctr = 0;
while (ctr < 2) {//counter 2 if ACK if NAK ctr=1 todo
bytesRead = in1.read(messageByte);
if (bytesRead > -1) {
ctr++;
}
dataString += new String(messageByte, 0, bytesRead);
System.out.println("\ninput byte arr "+ctr);
for (byte b : messageByte) {
char c=(char)b;
System.out.print(" "+b);
}
}
System.out.println("MESSAGE: " + dataString + "\n bytesread " + bytesRead + " msg length "
+ dataString.length() + "\n");
char[] chars = dataString.toCharArray();
ArrayList<String> hex=new ArrayList<>();
// int[] msg ;
for (int i = 0; i < chars.length; i++) {
int val = (int) chars[i];
System.out.print(" " + val);
hex.add(String.format("%04x", val));
}
System.out.println("\n"+hex);
} catch (Exception e) {
e.printStackTrace();
}
// ===
}
输出
client Socket created ..
response:
input byte arr 1
6 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
input byte arr 2
2 -77 67 79 -77 48 -77 3 -116 0 0 0 0 0 0 0 0 0 0 0
MESSAGE: ##³CO³0³##
(where # is some not supported special character )
bytesread 9 msg length 10
dec: 6 2 179 67 79 179 48 179 3 338
hex: [0006, 0002, 00b3, 0043, 004f, 00b3, 0030, 00b3, 0003, 0152]
bytes: 2 -77 67 79 -77 48 -77 3 -116 0 0 0 0 0 0 0 0 0 0 0 (bytes recieved in 2nd packet)
connection closed
Problem: I'm reading the last value incorrect, I have verified using wireshark the server has sent back the response as 06 02 b3 43 4f b3 30 b3 03 8c
Some how I'm reading the last value in correctly. Is there some issue with the reading stream?
编辑
响应的其余部分已正确读取,但最后一个字符应为 8c 但读为 0152Hex
服务器响应:06 02 b3 43 4f b3 30 b3 03 8c
程序读取:[0006, 0002, 00b3, 0043, 004f, 00b3, 0030, 00b3, 0003, 0152]
读取最后一个字符时出现问题
编辑 2
收到的响应为 2 packets/streams
packet 1 byte arr : 6 (ACK)
packet 2 byte arr: 2 -77 67 79 -77 48 -77 3 -116 (response)
客户端读取完整响应
dec: 6 2 179 67 79 179 48 179 3 338
hex: [0006, 0002, 00b3, 0043, 004f, 00b3, 0030, 00b3, 0003, 0152]
谢谢
这个问题中的问题是 signed 变量与 unsigned 变量的问题。当您在计算机内存中有一个数字时,它由一堆位表示,每个位为 0 或 1。字节通常为 8 位,短字节为 16 等。在 unsigned 数字中, 8 位将使您从正数 0 到 255,但不会变成负数。
这就是 有符号 数字的用武之地。在有符号数字中,第一位告诉您后续位代表负值还是正值。所以现在你可以用8位来表示-128到+127。 (请注意,正数范围减半,从 255 到 127,因为您 "sacrifice" 范围的一半为负数)。
那么现在如果将 signed 转换为 unsigned 会发生什么?根据您的操作方式,事情可能会出错。在上面的问题中,代码 char c=(char)b;
将 signed 字节转换为 unsigned 字符。执行此操作的正确方法是在将其转换为 char 之前 "make your byte unsigned"。你可以这样做:char c=(char)(b&0xFF);
more info on casting a byte here.
基本上,你可以只记住,除了char,所有java数字都是有符号的,你需要做的就是粘贴&0xFF
让它工作一个字节,0xFFFF
使其短时间工作等
有关其工作原理的详细信息如下。调用 & 表示 bitwise and,而 0xFF
是 255 的十六进制。255 超出了有符号字节 (127) 的限制,因此数字 b&0xFF
通过 [= 升级为短整数49=]。但是,短符号位在第 16 位,而字节符号位在第 8 位。所以现在字节符号位变成了普通的 'data' 位,所以你的字节的符号基本上被丢弃了.
如果你进行普通转换,java 会意识到像上面那样进行直接位转换意味着你会丢失符号,并且 java 预计你不喜欢那样(至少,那是我的假设),因此它会为您保留标志。因此,如果这不是您想要的,您可以明确告诉 java 该怎么做。