java Integer.parseInt() 表现得很奇怪
因此,我一直在开发一个服务器-客户端程序,其中客户端向服务器发送一个字符串,服务器拆分该字符串以执行某些计算。
//消息样本
18011d5651,0,348,1649520496736,5,0:1010,1
该消息存储在名为 msg 的字符串中
,然后当我尝试在服务器端运行以下行时,
int d = Integer.parseInt(msg.split(",")[4]);
:它返回一个错误,如下所示
Exception in thread "main" java.lang.NumberFormatException: For input string: "5"
at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
at java.lang.Integer.parseInt(Integer.java:580)
at java.lang.Integer.parseInt(Integer.java:615)
at test.test1.main(test1.java:54)
C:\Users\xxxx\AppData\Local\NetBeans\Cache\8.2\executor-snippets\run.xml:53: Java returned: 1
BUILD FAILED (total time: 9 seconds) ```
So I've been working on a server-client program where the client sends the server a string, the server splits that string to perform certain calculations.
//message sample
18011d5651,0,348,1649520496736,5,0:1010,1
then the message is stored in a string called msg
when I try to run the following line on the server side:
int d = Integer.parseInt(msg.split(",")[4]);
it returns an error as follows
Exception in thread "main" java.lang.NumberFormatException: For input string: "5"
at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
at java.lang.Integer.parseInt(Integer.java:580)
at java.lang.Integer.parseInt(Integer.java:615)
at test.test1.main(test1.java:54)
C:\Users\xxxx\AppData\Local\NetBeans\Cache\8.2\executor-snippets\run.xml:53: Java returned: 1
BUILD FAILED (total time: 9 seconds) ```
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
问题解决了,
我将数据从客户端发送到代理再发送到服务器,因此在代理中,它读取了 1000 个字节,其中被附加到最后一个元素“5”,然后是代理的部分添加了附加内容 (,0:1010,1),因此有 834 个空值。使用上面的行,我在将其转发到服务器之前替换了代理中消息中的所有空值,然后添加了代理部分,然后将其发送到服务器并且处理成功。
解决这个问题的另一种方法是在服务器端删除空值,但如果服务器缓冲区是 1000 字节,我们也会遇到问题,因为代理附加部分不会被传递。直到我将服务器中的缓冲区设置为 1100 字节后,我才意识到为什么会发生这种情况。
假设服务器中的缓冲区为1100字节,解决方案如下
the problem was solved with
I was sending the data from a client to a proxy to a server, so in the proxy, it was reading 1000 bytes, and of which are being appended to the last element "5" then the part that the proxy adds was appended (,0:1010,1) so there were 834 nulls. using the line above I replaced all the nulls in the message in the proxy before forwarding it to the server, then added the proxy part then sent it to the server and the processing was successful.
another way to tackle it is by removing the nulls from it on the server-side, but if the server buffer was 1000 bytes we'll have an issue too, cuz the proxy appended part wouldn't be delivered. I didn't realize why that was happening until I made the buffer in the server 1100 bytes.
the solution given that the buffer in the server is 1100 bytes is as follows
因此,根据您的自我答复,问题在于您正在处理的消息字符串中有很多意外的NUL字符(
'\ 000'
)。您的解决方案是仅使用
替换
删除所有NUK。这是(IMO)次优,可能是不正确的。有两个问题:您仍在从服务器中发送毫无意义的NUL字符的消息。 成本网络带宽。它也直接在客户端的时间 CPU时间,直接是由于您将生成更多的垃圾。
根据如何实现服务器,它可能在不完全归零的情况下在连续消息之间回收其输出缓冲区。如果是这种情况,并且消息并不总是具有相同的长度,那么有时是字符串中不是nul字符的垃圾字符。
我认为您需要修复服务器,而不是尝试在客户端进行修复,以便它不会在其中发送带有垃圾字符的消息。
根据您的后续评论,问题在接收端。您是在数据报中收到数据,而垃圾是由于接收到比数据报大的字节数组。
在这种情况下,您的接收代码中有一个错误。
datagrampacket
类具有getLength
方法,该方法返回实际收到的数据的字节数。您应该使用该值(不是字节数组大小),在其中将字节转换为String
;例如So as per your self-answer, the problem was that you had lots of unexpected NUL characters (
'\000'
) in the message string you were processing.Your solution was to just remove all of the NUK's with
replaceAll
. This is (IMO) suboptimal, and possibly incorrect. There are two problems:You are still sending messages from your server that are bloated with meaningless NUL characters. That costs network bandwidth. It also costs CPU time on the client side, directly because of the extra data copying, the
replaceAll
, etc, and indirectly because you will be generating more garbage.Depending on how your server is implemented, it is possible that it is recycling its output buffer between successive messages without fully zeroing it. If that is the case, and the messages don't always have the same length, then it is possible that there will occasionally be garbage characters in the string that are not NUL characters.
Rather than trying to fix this on the client side, I think you need to fix the server so that it doesn't send messages with garbage characters in them.
Per your followup comments, the problem is on the receiving end. You are receiving the data in datagrams, and the junk is due to receiving into a byte array that is larger than the datagram.
In that case, you have a bug in your receiving code. The
DatagramPacket
class has agetLength
method that returns the number of bytes of data actually received. You should use that value (not the byte array size) where you are converting the bytes to aString
; e.g.也许问题是服务器使用不同的字符集包含。您可以尝试将Charset转换为UTF-8:
您应该导入Stringutils:
Perhaps the problem is that server uses different charset enconding. You can try converting the charset to UTF-8:
You should import StringUtils: