FileInputStream и FileReader

Просто тут на примере работы FileReader тоже читает байты, не понимаю где тут символы?

FileReader reader = new FileReader("c:/data.txt");
 FileWriter writer = new FileWriter("c:/result.txt");

 while (reader.ready()) //пока есть непрочитанные байты в потоке ввода
 {
  int data = reader.read();
  writer.write(data);
 }

Нет. Reader читает символы, передает их во Writer и он их записывает. Они оба работают с символами. Их можно заменить на FileInputStream и FileOutputStream. Результат будет тот же, но между объектами будут передавать "байтовые" данные. Эта пара классов работает с байтами. Но это не наглядный пример, особенно с числовыми данными. Попробуйте создать файл с текстом, прочитать его с помощью FileReader и вывести на экран считанные данные. Потом прочитать этот же файл с помощью FileInputStream и также вывести на экран. Тут и будет видна разница.

public class Test {
    public static void main(String[] args) throws Exception {
        FileReader fis = new FileReader("D:/Test/test.txt");
        //FileInputStream fis = new FileInputStream("D:/Test/test.txt");


        while (fis.ready()) {
            int data = fis.read();
            System.out.print(data);
            System.out.print(" ");
        }
    }
}

//    239 187 191 97 98 99    FileInputStream
//              65279 97 98 99    FileReader
//  в файле abc

В файле три символа abc.Концовки одинаковые 97 98 99 это эти символы. А вот начало разное у FileInputStream 239 187 191 . А у FileReader 65279. Что это значит?

это значит что FileReader читает символы, а FileInputStream байты. поэтому последние 3 совпадают, а первый символ состоит из 3х байт, поэтому в первом случае он выводится как 3 элемента, а во втором как 1

239 187 191 специальный символ из стандарта Юникод, вставляемый в начало текстового файла или потока для обозначения того, что в файле (потоке) используется Юникод, а также для косвенного указания кодировки и порядка байтов, с помощью которых символы Юникода были закодированы. 65279 этот символ который находится в начале файла с кодировкой UTF-8, и возможно некоторых других юникодных кодировок. Используется для индикации порядка байтов. Чтоб показать 16-битные или 32-разрядных числа используются. Открывая файл текстовый, этот символ не увидитеть, даже если он есть. Пересохранив файл через Notepad++ в UTF-8 без BOM проблема решается. Если взять все это во внимания то остаются те самые байты 97 98 99 что у FileInputStream и что FileReader при считывание символов abc

В начале вашего файла стоит BOM-символ. Если открыть файл через какой-нибудь hex-редактор, то первые 3 байта будут иметь значение: EF BB BF или 239 187 191 в десятиричной системе. FileInputStream никак не анализирует данные и просто побайтово их выдает. В этом примере - 3 байта с BOM и дальше данные. Reader же разбирается в том, что он читает: он видит, что в первых трёх байтах хранится один символ и пытается все 3 байта прочитать как один символ. Прочитанные символы он приводит к числу в диапазон от 0 до 65535. Если перевести 65279 в шестнадцатиричную систему, то получится FEFF. Найдём этот код в Unicode-таблице и увидим, что это как раз BOM-символ. Интереснее ситуация обстоит с кириллицей. Если для латиницы Reader возвращает также Unicod-код символа и результат Reader и Stream совпадают, то у кириллицы данные, возвращаемые Reader и Stream будут разными. Stream вернет коды символов в той кодировке, в какой они записаны в файле. Reader же, по крайней мере в моём случае, вернул коды каких-то левых символов. Но это уже связано с кодировками и это уже другая история.

поставьте кодировку UTF-16 а лучше UTF-32 и сравните результат.

а почему все читают из 7 версии ? в девятой же более свежее?

1. не все перешли на 9 и выше, многие ещё на 8 сидят. 2. Что-то в 9 и дальше изменилось капитального?

Конечно !! Я уже давно на ней сижу. Все изменилось кардинально благодаря этому окошку в которому мне не надо три часа искать свои любимые классы)

у гугла это окошко есть уже много лет