Decoding array of hexadecimal bytes to a specific codepage brings a wrong result when encoding afterwards

Viewed 178

I created a simple app which looks like this:

    String stringValue = new String(new byte[] { 0x00, 0x00, 0x00, 0x25 }, "273");
    byte[] valueEncoded = Arrays.copyOfRange(stringValue.getBytes("273"), 0, 4);
    int finalResult = ByteBuffer.wrap(valueEncoded).getInt();
    
    System.out.println("Result: "+finalResult);

I expect the result to be 37, however the result is 21. How come? Am I missing something? Or is my method not the way it is supposed to be and therefore this error pops up?

I tried many other numbers and all seem to work fine... As you can see I am using codepage 273 (IBM).

1 Answers

Looks to me like linefeed 0x25 got mapped to newline 0x15.

I assume that it went like this:

bytes to string: EBCDIC 0x25 -> UTF-16 0x000A

string to bytes: UTF-16 0x000A -> EBCDIC 0x15.

Why that's preferred, I can't guess. Well, actually I can guess (but it's only a guess). 0x000A is the standard line terminator on many systems, but it's generally output as "move to beginning of next line". Converting to IBM 273 is 'probably' because the text is destined for output on a device that uses that code page, and perhaps such devices want NL rather than LF for starting a new line.


Hypothesis validated:

 class D {
   public static void main(String... a) throws Exception {
       String lf = "\n";
       byte[] b = lf.getBytes("273");
       System.out.println((int)b[0]);
   }
}

Output is 21.

Related