Не принимает валидатор

Вторая часть вопроса скорее не к конкретной задаче была, а более общая. Например тут нужно было посчитать количество английских символов в файле. Читаем мы по байту, можно буфферами, можно всякими DataInputStream'ами, но все они, я так понял, неявно, например читают 8 байт и кастят в лонг. То есть в любом случае нам нужно знать сколько байт занимает та сущность, которую мы собираемся приводить и столько вычитать. Для конкретно той задача я сделал так

private static int getLatinLettersCount(InputStream is) throws IOException {
    int latinCount = 0;

    byte[] byteReadBuffer = new byte[128];
    ByteArrayOutputStream byteReadStream = new ByteArrayOutputStream();
    byte[] allReadBytes;
    int bytesReadCount = 0;

    while ((bytesReadCount = is.read(byteReadBuffer))!=-1){
        byteReadStream.write(byteReadBuffer,0,bytesReadCount);
    }

    allReadBytes = byteReadStream.toByteArray();

    for (byte singleByte:
         allReadBytes) {
        if(Character.toString((char)singleByte).matches("[a-zA-Z]")){
            latinCount++;
        }
    }




    return latinCount;
}

Так вот, а если там будет записан какой-то иероглиф, который тремя байтами кодируется(такое же бывает, я так понял?). Тогда я каждый байт, который его кодирует возьму и приведу в чар и получу совсем другой символ, вернее три других символа вместо одного, который подразумевал тот кто в файл писал. Вот в чем было недопонимание, как в таком случае быть? Наверное тут нужно смотреть в сторону символьных потоков, там где кодировку можно в конструктор передать, но я пока не уверен.

например читают 8 байт и кастят в лонг. То есть в любом случае нам нужно знать сколько байт занимает та сущность, которую мы собираемся приводить и столько вычитать. Нам нужно знать только одно, мы работаем с байтами или текстом и числами. За количество байт отвечает обертка. Вспомни первые уровни. Когда ты использовал readLine() ридера или nextLine() сканера, ты думал про количество байт, кодировки и тд? :) Надо текст, считал текст. Надо байт, считал байт. Та задача которая по ссылке акцентирует специально в условиях о английском тексте, чтобы показать что он отлично может читаться и побайтово. Во всех остальных случаях было бы чтение через чары или строки.

который тремя байтами кодируется(такое же бывает, я так понял?).
Тогда я каждый байт, который его кодирует возьму и приведу в
 чар и получу совсем другой символ, вернее три других символа вместо одного,

совершенно верно.

Тогда я каждый байт, который его кодирует возьму и приведу в чар и
получу совсем другой символ, вернее три других символа вместо одного,
который подразумевал тот кто в файл писал. Вот в чем было недопонимание,
как в таком случае быть?

То о чем я говорю, читать не побайтово :)

FileReader fileReader = new FileReader("Wladyslaw");
    while (fileReader.ready()) {
      System.out.println((char) fileReader.read());
}

или

FileReader fileReader = new FileReader("Wladyslaw");
BufferedReader reader = new BufferedReader(fileReader);
     while (reader.ready()) {
          System.out.println(reader.readLine());
}

выдаст: 漢 字 и 漢字 соответственно для файла в котором два иероглифа. Зачем думать о кодировках, количествах байт и тд ) За это у нас думают обертки. Надо байты - читай байты, надо числа/текст - пользуйся обертками.

Ну, символьные потоки юзать, то бишь, значит. Спасибо за инфу. Понятно, но пока не до конца. Например:

public static void main(String[] args) throws Exception {
    writeRoundedDoublesToFile(new DataInputStream(new FileInputStream(new File("F:\\Documents\\IdeaProjects\\JavaRushTasks\\JavaRushTasks\\2.JavaCore\\src\\com\\javarush\\task\\task18\\task1820\\file1820_1"))),
            new DataOutputStream(new FileOutputStream(new File("F:\\Documents\\IdeaProjects\\JavaRushTasks\\JavaRushTasks\\2.JavaCore\\src\\com\\javarush\\task\\task18\\task1820\\file1820_2"))));
}


private static void writeRoundedDoublesToFile(DataInputStream is, DataOutputStream os) throws Exception{
    double read = is.readDouble();
}

В файле и в переменной вышли разные значения. Вот пока не могу понять почему

Ну у тебя и пути файлов, посмотри как я работаю с файлом выше, это ж удобней, создай в Идее в корне проекта пару файлов временных и работай с ними , путь к ним - только имя. Также, не нагромождай столько всего даже при личных тестах - вызов метода на 400 символов ) это пятая часть машинописной страницы )) Правила клинкод придумали не для понтов, дискретность ведет к четкости, у тебя здесь что-то могло бы пойти не так, и час можно дебажить только одну строку. Ты отнимаешь ресурсы своего интеллекта не на учебу и решение задач , а на преодоление визуально-смысловых барьеров, которые сам себе ставишь. Вот например мой код для подобного теста:

public static void main(String[] args) throws Exception {
   FileInputStream inputStream = new FileInputStream("OtherFile");
   DataInputStream dataInputStream = new DataInputStream(inputStream);

   FileOutputStream outputStream = new FileOutputStream("SomeFile");
   DataOutputStream dataOutputStream = new DataOutputStream(outputStream);

   double d = dataInputStream.readDouble();
   dataOutputStream.writeDouble(d);

   System.out.println(d);
}

Я в любой момент могу подменить инпутСтрим другим, потом вернутся к прежнему, снова другим, поменять одно имя файла на другое и тд, смотрю на код ничто не отвлекает от главного - разбора механизма как работает. У меня тоже может не ахти, но ты должен понимать что то как у тебя, это гиря. Ты все-равно достинешь своих целей в контексте джава обучения, но сделаешь это позже тех, у кого этих гирь нету. затратив больше сил и ресурсов. А относительно разных значений, почитай: Пара слов о числах с плавающей точкой в Java

Знаю, это так, как только в голову пришло - сразу написал, чисто проверки ради. Если что-то пошло не так, я такие веши переписываю. По поводу файлов тоже в курсе дела, ты же и подсказал в свое время. За чтиво спасибо, еще не до конца дочитал, в общем-то я знал что при арифметических операциях с примитивами double и float на точность не стоит надеяться из-за двоичного представления, но лишний раз освежить знания не помешает. Но, по сабжу - проблема была в другом. Я создал файл из IDE, забил его с клавиатуры, соответственно там были строки. Просто строки. Это я глазами вижу там дробные числа, но там - строки. Если бы я DataOutputWriter'ом это дело записал, то вышло бы считать так как я хотел ибо там в файле лежали бы числа представленные в байтах - а так не выйдет, там строки представленные в байтах. А если считать все байты, например и передать конструктору строки - потом строку засплитить по пробелу и все это дело запарсить в дабл - вот так получится. Я еще в процессе, но именно то что вызывало вопросы уже сделал.

ByteArrayOutputStream byteStream = new ByteArrayOutputStream();
byte[] byteBuffer = new byte[256];
int bytesRead;

while ( (bytesRead = is.read(byteBuffer)) != -1  ){
    byteStream.write(byteBuffer,0,bytesRead);
}

String allDataString = new String( byteStream.toByteArray());

Дальше - дело техники

Это все разве что чтобы познакомится с таким инструментом как DataInputStream, поскольку подключать 5-10 классов потоков чтобы запарсить дабл это уже слишком. Как я понял DataInputStream используется как механизм для того, чтобы формировать/обрабатывать файлы состоящие из определенных примитивов для удобной машинной/пакетной обработки. А значит, если нам просто с файла нужно будет напарсить даблы, мы этим классом пользоваться не будем.

Именно так я эту ситуацию и понял. Это что-то типа серализации, в которой я еще не разбирался. Просто если нужно из рантайма что-то где-то сохранить именно в виде Java примитивов, а потом это удобно вычитать.

Scanner scanner = new Scanner(inputStream);
   while (scanner.hasNext()) {
     System.out.println(scanner.nextDouble());
}

Получаешь именно то, согласно твоей задачи - даблы в человеческом обличии читаются. Токенизированное простое считывание. Записать можно через токенизированный PrintWriter и его метод print(double)

FileOutputStream outputStream = new FileOutputStream("SomeFile");
PrintWriter printWriter = new PrintWriter(outputStream);
double d = 3.4545454d;
printWriter.print(d);
printWriter.close();

вот инструменты думаю наиболее близкие твоей условной задаче.

Пробелы в таком случае у сканнера в буффере(или что там у него? как-то не особо ним пользуюсь) останутся, насколько я понимаю? Чем записывать еще не думал, но спасибо за наводку. Тем не менее, посмотрю чем еще можно, так интереса ради.

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

По идее пробелы пропустит Сканер Единственное, я бы заменил

scanner.hasNext()

на

scanner.hasNextDouble()

ибо может эксепшн кинуть

спаведливо. Я сканером вообще не пользуюсь ) хорошо хоть так смог вычитать ))))