Я понимаю, что этому вопросу уже больше года, но я добавлю к нему то, что знаю, на тот случай, если другие, кто столкнулся с этой проблемой, столкнутся с ним, как и я.
Символы NUL, описанные в этом вопросе, появляются из-за асинхронной записи в файл, из которого выполняется чтение.Точнее говоря, пакеты данных от удаленного устройства записи файлов поступили не по порядку, и буфер NAS зафиксировал более поздний пакет и заполнил область для непринятых данных символами NUL.Когда пропущенный пакет получен, буфер NAS фиксирует его, перезаписывая эти нулевые символы.
В приложении, где мы впервые столкнулись с этим, мы построчно читаем файл и отслеживаем номер последней строки.успешно прочитал (так что мы можем остановиться в любой момент и начать снова, где мы остановились).Наше временное решение для этого - просто проверять наличие «\ 0» при каждом чтении и, когда это происходит, закрыть файл, подождать 1 секунду и снова открыть файл, ставя в очередь до того места, где мы остановились.Обычно, когда мы снова читаем строку, фактический текст уже зафиксирован.
Хотя закрытие и повторное открытие файла может показаться драматичным, восстановление без этого проблематично.Вы не можете пометить / сбросить BufferedReader, чтобы разрешить его, потому что как только символы будут считаны в буфер читателя, они не будут перечитаны из файла, а только изрыгнуты каждый раз, когда вы пытаетесь прочитать снова.
Получение лежащего в основе FileChannel, а также чтение и установка позиции () также завершаются ошибкой, поскольку ваша позиция в файле включает символы, считанные в буфер, которые вы, возможно, еще не видели, и в итоге вы пропустите эти невидимые данные.
Мы тестируем решение, в котором мы расширили класс InputStreamReader и перезаписали метод read (char [], int, int), чтобы использовать файловый канал для получения позиции перед каждым чтением, вызывая метод read суперкласса,проверьте \ 0 и сбросьте позицию файлового канала, если она найдена, возвращая 0 как количество прочитанных символов.