Ребят,нужно прочитать файл в одной кодировке Windows-1251 и записать в другой UTF-8. В чем у меня ошибка?

1. думаю да. если тесты валятся - значит где-то ошибка. 2. если читаем не из файла - тоже все ок. BufferedReader-у без разницы что за источник данных. главное - что к нему открыт какой-то символьный поток (Reader). из консоли же читаем BufferedReader-ом, и все ок :) 3. можно. вот так, как у вас - вполне неплохо, если бы вас интересовали именно байты, а не символы. для работы с символами лучше пользоваться более подходящими инструментами. да и вообще, лучше не изобретать велосипед, а пользоваться уже готовыми классами из самой джавы, которые много раз протестированы, и миллиарды раз проверены на практике миллионами разработчиками со всего мира)

по п.1 - проблема в том,что результат зависит от размера буфера, что не есть норма. по п.2 - а в какой момент он считывает строку, если у потока нет символа возврата строки

public class Solution {
    public static void main(String[] args) throws IOException {
        String fileName = args[0];
        String fileNameOut = args[1];

        FileInputStream is = new FileInputStream(fileName);
        InputStreamReader isr = new InputStreamReader(is, "windows-1251");
        BufferedReader buffReader = new BufferedReader(isr);

        FileOutputStream fos = new FileOutputStream(fileNameOut);
        OutputStreamWriter outputStreamWriter = new OutputStreamWriter(fos);
        BufferedWriter bufferedWriter = new BufferedWriter(outputStreamWriter);

        while (buffReader.ready()){
            String s = buffReader.readLine();
            bufferedWriter.write(s + "\n");
        }
        bufferedWriter.close();
        outputStreamWriter.close();
        fos.close();
    }
}

1. вы ж читаете побайтово. некоторые символы занимают несколько байт. если последний байт из 1000 это первый байт символа, а второй байт получится в новом буфере - символ не соберется, я думаю. 2. тут не понял вопроса. в символьном потоке могут быть разные символы. в том числе и символ новой строки

по п.1 - и как тогда гарантировано читать так что бы не получилось описанной вами ситуации? по п.2 - нет символа переноса строки, вот, допустим, сплошной текст, сколько прочитает буферриадер?

1. как я уже и сказал, использовать более подходящие для этого инструменты. а именно - ридеры, которые сразу работают с символами 2. до конца потока символов. используя при этом буфер. вы что, никогда им не пользовались и не знаете как он работает? даже если так - то сходите сначала почитайте о нем, погоняйте его сами, а потом уже что непонятно - тогда уже можно и спросить)

Буфередридером пользовался, но никогда не задавался гипотетическим вопросом о размере его собственного буффера. Кстати, вот, что по этому поводу написано в его описании "The buffer size may be specified, or the default size may be used. The default is large enough for most purposes." Я посмотрел в исходниках, его размер по умолчанию: defaultCharBufferSize = 8192; Я попробовал поставить маленький размер буфера, вплоть до 1 байта. В отличие от byte[] buffer = new byte[10]; он отработал нормально. Ладно, думаю пора заканчивать с этой задачей, она и так заняла много времени. РЕЗЮМЕ: хотите решить задачу без плясок с бубном, используйте BufferedReader

благодарю, в итоге я так потом и написал,валидатор принял,но я хочу понять в чем ошибка в моем первом решении

FileInputStream is meant for reading streams of raw bytes such as image data. For reading streams of characters, consider using FileReader. https://docs.oracle.com/javase/10/docs/api/java/io/FileInputStream.html#

так я хочу ошибку в своем коде найти, а не бежать от проблемы и искать др способы,хочу понять причину что у меня не так

все верно, так я эти байты помещаю в строку и потом перекодирую ее и получаю набор байт в новой кодировке(так и было в примере в лекции о том как сменить кодировку)

count = fin.read(buffer);
String s = new String(buffer, "Windows-1251");
buffer = s.getBytes("UTF-8");
if(count!=-1) fout.write(buffer,0,count);

Ну непосредственно декод и энкод должны были сработать нормально. В прочем, у меня IDE сматерилась на UTF8 и сказала поменять на StandardCharsets.UTF_8 Очень интересная хрень у тебя с буфером творится. Он ведь постоянно превращается в другой массив. Например вычитал ты N байт в кириллице, а после метода getBytes получаешь уже массив n+k байт. Следующий раз ты читаешь уже в этот массив. И... начинаются чудеса. Погоняй в дебаггере вот такой код:

public static void main(String[] args) {
    File in = new File("/path/to/in");
    File out = new File("/path/to/out");
    try(InputStream fin = new FileInputStream(in); OutputStream fout = new FileOutputStream(out)){
        byte[] buffer = new byte[4];
        int count;
        while (fin.available()>0){
            count = fin.read(buffer);
            String s = new String(buffer, "Windows-1251");
            buffer = s.getBytes(StandardCharsets.UTF_8);
            if(count!=-1) fout.write(buffer,0,count);
        }
    }catch (Exception ignored){}
}

В качестве ввода я использовал строку "привед мед" Уже на второй итерации цикла станет интересно. Далее, раз длина буфера разная, не правильно делать вот так: fout.write(buffer,0,count); Количество прочтенных байт и байт к записи может отличаться. Ну и вишенка на торте. Если например у тебя буфер 4, а вычитал ты 2 байта, то у тебя будет в буфере 2 байта и два нуля... (или, если ты переиспользовал старый буфер то два байта из старого чтения) ты их тоже так запишешь, а нужно писать только правильные данные. Например вот так выглядит третья итерация моей фразы: [-48, -75, -48, -76, 0, 0]

Я там всякого еще дописал выше. Резюмирую, всегда проверяй граничные случаи. Байт туда. байт сюда, погоняй в дебаггере что бы понять какие реальные данные лежат в твоих переменных. Зачастую всплывают вот такие вот нежданчики :) Лишний повод отделять мух от котлет.