Как метод write в FileOutputStream усекает аргумент типа int

Question

Метод write() в FileOutputStream принимает int, но усекает первые 3 байта и записывает этот байт в поток. Если файл содержит символы, значение ASCII которых превышает 127, и из него считываются байты, а затем записываются в выходной поток (другой текстовый файл), как он будет отображаться, поскольку в байтах Java может быть максимальное значение +127.

Если текстовый файл (input.text) имеет символ "› ", значение ASCII которого равно 155. Входной поток,input, читает из него:int in= new FileInputStream("input.txt").read();//in = 155

Теперь он пишет в другой текстовый файл (output.txt)

new FileOutputStream("output.txt").write(in);

Здесь целое число "in" усекается до байта, который будет иметь соответствующее десятичное значение: -101. Как успешно удается записать символ в файл, хотя информация о нем, кажется, была потеряна?

Только сейчас я прошел описание метода write(int) в java docs, и то, что я заметил, было

Общий контракт на запись заключается в том, что в выходной поток записывается один байт. Записываемый байт - это восемь младших битов аргумента b. 24 старших бита b игнорируются.

Поэтому я считаю, что вопреки тому, что я думал ранее (int в write() усекается, как это происходит при понижении целого числа до байта для значений, превышающих 127), 24 старших бита игнорируются и рассматриваются только 8 младших значащих бит, Усечения и преобразования в байты не происходит. Я думаю, что я прав.

Answer 1

Я думаю, что ваша путаница вызвана тем фактом, что спецификации для наборов символов обычно принимают представление, что байты не подписаны, в то время как Java рассматривает байты как подписанные.

по факту 155 как неподписанный байт -101 как подписанный байт. (256 - 101 == 155). Битовые шаблоны идентичны. Вопрос лишь в том, считаете ли вы их подписанными или неподписанными.

То, как усечение кодируется, зависит от конкретной реализации. Но нет потери информации... при условии, что у вас был 8-битный код.