Может глупое FileInputStream.available меня?
Этот FileInputStream.available () javadoc говорит:
Возвращает оценку числа остающихся байтов, которые могут быть считаны (или перескочиться) от этого входного потока, не блокируясь следующим вызовом метода для этого входного потока. Следующий вызов мог бы быть тем же потоком или другим потоком. Единственное чтение или пропуск этого много байтов не заблокируются, но могут считать или пропустить меньше байтов.
В некоторых случаях чтение неблокирования (или пропуск), может казаться, заблокировано, когда это просто медленно, например, при чтении больших файлов по медленным сетям.
Я не уверен если в этой проверке:
if (new FileInputStream(xmlFile).available() == 0)
я могу положиться, что пустые файлы будут всегда возвращать нуль?
--
Спасибо @SB, кто не делает точно, ответило на вопрос, но было первым для предоставления лучшей альтернативы:
Если xmlFile является java.io. Объект файла, можно использовать длину () метод для получения его размера.
4 ответа
Вы можете положиться на новый FileInputStream (fileName) .available () возвращает ноль, если названный файл пуст.
Вы не можете полагаться на new FileInputStream (fileName) .available () == 0 как на окончательную проверку того, что файл пуст.Если имя_файла является обычным файлом в локальной файловой системе, он, вероятно, будет работать. Но если имя_файла - это файл устройства или файл в удаленной файловой системе, available () может вернуть ноль, чтобы сообщить, что read () придется блокировать на срок. (Или, в случае удаленной файловой системы, может и нет.)
Более надежный способ проверить длину обычного файла - использовать new File (fileName) .length () == 0 . Однако для файла устройства или конвейера вызов length () может возвращать ноль, независимо от количества байтов, которые в конечном итоге могут быть прочитаны. И имейте в виду, что new File (fileName) .length () также возвращает ноль, если файл не существует.
РЕДАКТИРОВАТЬ Если вам нужен надежный тест, чтобы увидеть, является ли файл пустым, вы должны сделать несколько вызовов:
public static isEmptyFile(String fileName) {
File file = new File(fileName);
if (!file.exists()) {
return false;
} else if (file.length() != 0L) {
return false;
} else if (file.isFile()) {
return true;
} else if (file.isDirectory()) {
return false;
} else {
// It may be impossible to tell that a device file / named pipe is
// "empty" without actually reading it. This is not a failing of
// Java: it is a logical consequence of the way that certain
// devices, etc work.
throw new CannotAnswerException(...);
}
}
Но вам рекомендуется тщательно проверить это с помощью различных «файлов» типы на всех платформах, на которых вы запускаете свое приложение. Поведение некоторых предикатов файла задокументировано как зависящее от платформы; см. javadoc .
Мой логический ответ на вопрос "могу ли я рассчитывать, что пустые файлы всегда будут возвращать ноль?": "Да, для пустых файлов available() будет возвращать 0".
Но вы, вероятно, также хотите знать: "Могу ли я рассчитывать на то, что только пустые файлы вернут ноль?", и здесь ответ: "Нет, не по спецификации: available() может вернуть 0, даже если файл не пуст".
Кроме того, вы открываете поток на файле и не закрываете его снова. Это может привести к неожиданному и нежелательному поведению, например, вы не сможете переместить или удалить файл, пока работает ваша Java-программа. Это особенно неприятно, если ваша программа работает на сервере приложений, который обычно работает очень долго, делая файл фактически неизменяемым.
Если xmlFile является объектом java.io.File, вы можете использовать метод length() для получения его размера.
Я настоятельно не рекомендую использовать available() - она может вернуть 0, потому что поток заблокирован, хотя байт для чтения еще достаточно. Вероятно, с Files этого не произойдет, но API не гарантирует этого.
Тот же подход можно использовать с read():
if (new FileInputStream(xmlFile).read() == -1)
System.out.println("!!File empty!!");