英文:
Socket programming: Is extra '\n' added in the golang client or the Java server?
问题
我已经写了一个Java TCP套接字服务，这个服务被一个Golang客户端使用。
当服务器套接字响应在Golang端解析时，情况变得奇怪。
具体来说，这是Java服务器端的代码：
BufferedWriter bw = new BufferedWriter(new OutputStreamWriter(output));
bw.append('Y');
bw.append('E');
bw.append('S');
bw.append('\n');
bw.flush();
以及这是Golang客户端的代码：
extendTimoutFor(client.conn)
rspMsg, fault := bufio.NewReader(client.conn).ReadString('\n')
if fault != nil {
return UNKNOWN, fmt.Errorf("Ers reading response: %v", fault)
}
retStr := strings.TrimRight(rspMsg, "\n")
if retStr == YES {
return YES, nil
}
if retStr == NO {
return NO, nil
}
if retStr == FAIL {
return FAIL, nil
}
return UNKNOWN, fmt.Errorf("Ers parsing msg [%s]: %v", rspMsg, fault)
在客户端产生以下结果：
[UNDO|test|]: Ers parsing msg [YES
]: <nil>
我对这个结果的问题是客户端无法将retStr识别为有效的响应。由于rspMsg是我们期望的（即'YES\n'），那么如果我们在UNKNOWN块中，这意味着在这一行出现了问题：retStr := strings.TrimRight(rspMsg, "\n")？
我的具体问题是：
- 由于存在nil错误，'\n'和（其后的任何字符）不应该被剥离，留下"YES"吗？
- 我是否在Java端遗漏了一些怪癖？我已经使用Java重新创建了客户端，输出结果是我期望的。
英文:
I've written a Java TCP socket service and this service is used by a golang client.
Things get weird when the server socket response gets parsed on the golang side.
Specifically, this Java server code:
BufferedWriter bw = new BufferedWriter(new OutputStreamWriter(output));
bw.append('Y');
bw.append('E');
bw.append('S');
bw.append('\n');
bw.flush();
And this golang client code:
extendTimoutFor(client.conn)
rspMsg, fault := bufio.NewReader(client.conn).ReadString('\n')
if fault != nil {
return UNKNOWN, fmt.Errorf("Ers reading response: %v", fault)
}
retStr := strings.TrimRight(rspMsg, "\n")
if retStr == YES {
return YES, nil
}
if retStr == NO {
return NO, nil
}
if retStr == FAIL {
return FAIL, nil
}
return UNKNOWN, fmt.Errorf("Ers parsing msg [%s]: %v", rspMsg, fault)
Produce this result in the client:
[UNDO|test|]: Ers parsing msg [YES
]: <nil>
My problem with the result is that the client doesn't recognize retStr as a valid response. Since rspMsg is what we expect (i.e. 'YES\n') then if we're in the UNKNOWN block it means that something went wrong during this line: retStr := strings.TrimRight(rspMsg, "\n")?
My specific questions are:
- Since there are nil errors shouldn't '\n' and (any characters following it) have been stripped leaving us with "YES"?
- Am I missing some quirk on the Java side? I've recreated the client using Java and the output is what I expect.
答案1
得分: 0
-
由于没有错误，所以不应该将'\n'和（其后的任何字符）删除，只留下"YES"，对吗？
是的 -
我是否在Java方面遗漏了一些怪癖？我使用Java重新创建了客户端，输出结果符合我的预期。
是的
这个问题通过以下几个步骤解决：
- 使用java.io.PrintWriter在输出中引入了一些意外字符。
- strings.TrimRight(rspMsg, "\n")掩盖了上述问题，但在安装Golang并调试脚本后确认了这一点（使用strings.TrimSpace对上述操作是一种更健壮的方法）。
- 切换到java.io.OutputStream.write()简化了发送给客户端的输出。
英文:
-
Since there are nil errors shouldn't '\n' and (any characters following it) have been stripped leaving us with "YES"?
YES -
Am I missing some quirk on the Java side? I've recreated the client using Java and the output is what I expect.
YES
This was resolved with a few steps:
- Using java.io.PrintWriter introduced some unexpected characters throughout the output.
- strings.TrimRight(rspMsg, "\n") masked the point above but it was confirmed after installing Golang and debugging the script (using strings.TrimSpace for the operation above is a more robust approach)
- Switching to java.io.OutputStream.write() simplified the output sent to the client
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论