I convert float to byte[] following code:

 byte[] bytes = ByteBuffer.allocate(4).putFloat(number).array();

Accordingly, if I convert, for example, the number 0.02f I will receive bytes [60,-93,-41,10] Next, I try to write the received byte[] to the file with the following code:

 FileOutputStream fos = new FileOutputStream(file); fos.write(bytes); dbf.close();

On most platforms, the resulting file in the HEX editor looks like this: 3C A3 D7 0A . But on one of the devices instead of the required 4 bytes, I get 5: 3C A3 D7 0D 0A . Before each 0A character 0D 0A independently.

I know that 0A is a carriage return, and 0D is a newline character. But I do not understand how it can appear on its own, because I work with numbers and bytes, and not with strings.

What could be the reason for this behavior and how can I eliminate this bug?

  • How is your Russian? - JVic
  • Please translate your question into English. - 0xdb
  • I apologize, I missed a little with a language branch) translated into Russian) - Victor Churilov

1 answer 1

I suppose that somewhere a failure occurs and the file is perceived as a text file and the system dependent default comes into effect when the end of the line for Windows is a combination of <LF><CR> , and for Unix it is just <CR> . Try using RandomAccessFile

If everything is really as you described - the topic is worthy of posting a bug in Java

  • As it turned out, the file was formed correctly. The length of the byte array and the length of the file are the same. The problem was in the mail client, which, when sending a message, "broke" the attached file. - Victor Churilov