-1

I am currently trying to perform some regex on the result of a DatagramPacket.getData() call.

Implemented as String myString = new String(thepkt.getData()):

But weirdly, java is dropping the end quotation that it uses to encapsulate all data(see linked image below).

When I click the field in the variable inspector during a debug session and don't change anything, when I click off the variable field it corrects itself again without me changing anything. It even highlights the variable inspection field in yellow to signal change. Its values are also displaying like it is still a byte array rather than a String object

https://i.stack.imgur.com/i5tad.png

It's throwing off my regex and I can't see anything that would cause it. It's a client server simulation and on the client side, the getData returns the data no problem.

andersoj
  • 22,406
  • 7
  • 62
  • 73
StevieJayCee
  • 114
  • 1
  • 7
  • 1
    Can you provide a hex dump of the byte array? E.g. Using http://stackoverflow.com/questions/9655181/convert-from-byte-array-to-hex-string-in-java – andersoj Mar 30 '13 at 00:23
  • Sorry was just trying to reply there, but the following worked: I got it working by using the solution provided in: http://stackoverflow.com/a/8557165/1700855 But I still don't understand how not specifying the length of the packet to the String constructor would cause it to drop the systematic end double quotes. Can anyone provide an explanation as I really like to understand solutions to my issues before moving on :) I will provide what you asked too though incase you can help explain it. – StevieJayCee Mar 30 '13 at 00:29
  • Looks like it's filling the 256 buffer I am giving the byte array. Why would padding cause the problem though 68656C6C6F0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000...... – StevieJayCee Mar 30 '13 at 00:33
  • In the case of the hex dump you provided, it's pretty easy: the last non-null character is 0x6F, which is the letter 'o', which isn't a quotation. You sure that's the right dump? Depending on what junk is in the "padding" (I'm not sure it's guaranteed to be zeroes) your call to new String() could have picked up garbage or been confused by the character set. – andersoj Mar 30 '13 at 00:46
  • 1
    When doing this, you should at least specify the character set when doing the conversion, e.g. `new String(pkt.getData(),"ASCII")` or `new String(pkt.getData(),"UTF-8")`. – andersoj Mar 30 '13 at 00:48
  • Note that there is no leading quote mark in that buffer dump. – Hot Licks Mar 30 '13 at 00:53
  • @andersoj - Yes, that is the dump of pkt.getData(). I had already tried setting character encoding to UTF-8, but I'll try ASCII to see if it works too. But as I already said, setting the length of the packet seems to have worked. – StevieJayCee Mar 30 '13 at 08:53
  • @HotLicks Note that from the original post and supplied image that I am not passing quotation marks within the String object. It's the trailing quotation mark that is missing within the variable display, something that I cannot directly manipulate... – StevieJayCee Mar 30 '13 at 08:54
  • 1
    @Scoch if you don't have quotes in your message payload I think we're confused aout what your question is. You say something about a missing trailing quote impacting a regex but don't provide a data block with a quote or a regex for us to look at. Can you try providing an sscce (http://sscce.org) and desired output? – andersoj Mar 30 '13 at 10:24
  • So you're saying the problem is with your development tools (which you don't identify). – Hot Licks Mar 30 '13 at 12:36
  • But the problem isn't with the development tools? (I don't remember implying that I was sending quotes either, one could get that impression if they just skim read the post title though.) I honestly don't know how to describe the quotation marks that the debugger implies to signal the start and end of a variable/fields contents within its variable inspection pane. That's why I provided the image to illustrate what I was talking about. That's why I also pointed out "Its values are also displaying like it is still a byte array rather than a String object". You can't edit the implied quotes. – StevieJayCee Mar 30 '13 at 13:58
  • Honestly, it isn't worth the effort any more with petty bickering over mis-reading the OP. I tried in vane to include the screenshot for that very reason and it is possibly my cause by not including a red arrow and red bordered box to make it as clear as day. I was just looking to understand better why it was causing this weird side effect when not specifying the length, when other solutions on StackOverflow and from my notes seem to use it happily. @andersoj Thank you for at least trying to understand what I was talking about but I think I'll come back to this on my own when I have more time – StevieJayCee Mar 30 '13 at 14:24
  • The thing is you completely failed to appreciate the problem -- a String being returned that was 256 bytes long (as indicated by your display) vs the 5 you were expecting. – Hot Licks Mar 30 '13 at 17:45
  • Thanks for finally reading the OP and thanks for your answer below. I can appreciate the 256 byte array producing the extra padding but I still don't understand the display issue within eclipse, but the initial quip and petty bickering afterwards definitely made it not worth the hassle. But thanks again, take it easy buddy. – StevieJayCee Mar 30 '13 at 18:37
  • possible duplicate of [DatagramPacket to string](http://stackoverflow.com/questions/8557132/datagrampacket-to-string) – fglez Apr 02 '13 at 10:27

2 Answers2

0

I got it working by using the solution provided in:

https://stackoverflow.com/a/8557165/1700855

But I still don't understand how not specifying the length of the packet to the String constructor would cause it to drop the systematic end double quotes. Can anyone provide an explanation as I really like to understand solutions to my issues before moving on :)

Community
  • 1
  • 1
StevieJayCee
  • 114
  • 1
  • 7
0

The problem is that you didn't read the spec for DatagramPacket.getData:

Returns the data buffer. The data received or the data to be sent starts from the offset in the buffer, and runs for length long.

So, to be correct, you should use

new String(thepkt.getData(), thepkt.getOffset(), thepht.getLength())

Or, to not use the default charset:

new String(thepkt.getData(), thepkt.getOffset(), thepht.getLength(), someCharset)

Hot Licks
  • 47,103
  • 17
  • 93
  • 151
  • Thanks, but that was already covered in the solution I provided below. My query was more geared towards why it wasn't working without the length being specified as all other examples on StackOverflow only seem to go as far as specifying the charset UTF-8. I just found this a weird side effect that it was dropping the end quotation mark in the variable inspector and seemed to still be treating it somewhat like a byte array where values were concerned (again in variable inspector). But thanks for trying buddy, greatly appreciated :) – StevieJayCee Mar 30 '13 at 14:18
  • It was working, exactly like it's supposed to -- a string containing the entire buffer contents was being created. A byte array in Java (unlike C) has a length that can be queried, so the String constructor did that, got the length, and constructed a string that long. If the byte array is the "right" length (and there's no "offset" to worry about) then it works out the same, but DatagramPacket.getData() returns the entire buffer, not an array of the "right" length. – Hot Licks Mar 30 '13 at 17:41