Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<blockquote> <p>I'm receiving an UDP packet (in which format I don't know, I think UTF-16 -little endian-), only thing that I know is the following doc.</p> </blockquote> <p>You really need to find out what the packet actually contains. The packet contents you have posted in your question don't make much sense to me, and don't seem to correspond to the supposed format.</p> <p>Start out by dumping the bytes of the byte array like this:</p> <pre><code>byte[] bytes = ... int len = // number of bytes read. for (int i = 0; i &lt; len; i++) { System.out.format("%02x ", bytes[i]); } </code></pre> <p>Then compare that with the expected format from the documentation. If they match (more or less) then you can start on the problem of deciding how to extract the data that you need. Otherwise, you first need to figure out what the format REALLY is. Maybe we can help ... but we need a <em>reliable</em> rendering of the packet (e.g. produced as above.)</p> <hr> <p>FWIW, the reason that you are getting <code>-0000000000000000000000000008cf52df7c08c</code> is (I think) that <code>BigInteger(byte[])</code> is interpreting the byte array as a <em>signed</em> number. Any way, that's a not a good way to do this. The UDP packet body is a sequence of bytes, not a number.</p> <hr> <p>I also think it is unlikely that the UDP packet is UTF-16. FFFF is described thus in the official Unicode code charts:</p> <blockquote> <p>Noncharacters:</p> <p>These codes are intended for process-internal uses, but are not permitted for interchange. [...]</p> <p>FFFF : • the value FFFF is guaranteed not to be a Unicode character at all</p> </blockquote> <p>So if someone is claiming that this is UTF-16, the usage is violating the Unicode standard.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload