try {output.close();} catch (Exception e1) {};

      return;

    }

    try {input.close();} catch (Exception e) {};

    output.close();

  }

Логика обработки исключений здесь подобна логике, предложенной в предыдущем разделе. Ошибки на этапе чтения или записи (методы read()/write()) считаются приоритетными – при появлении таких ошибок дальнейшие исключения при закрытии файла игнорируются. В случае нормального выполнения всех методов read()/write() ошибки при закрытии исходного файла также игнорируются (ведь он уже успешно прочитан), а ошибки при закрытии выходного файла передаются наружу (пока файл не закрыт, нельзя быть уверенными, что он действительно появится на диске именно в таком виде – из-за возможного кэширования операций записи на диск).

Неочевидным в данном решении является использование класса RandomAccessFile вместо традиционных FileInputStream и FileOutputStream. На самом деле RandomAccessFile здесь использован ради возможности вызвать метод output.setLength(), отсутствующий в классе FileOutputStream.

Зачем нужен вызов метода output.setLength()? Казалось бы, это совершенно излишняя операция – ведь в итоге скопированный файл все равно будет иметь правильный размер.

Секрет здесь заключается в организации современных операционных систем, таких как Windows NT/2000/XP. Если сразу после создания файла «проинформировать» операционную систему о желаемой итоговой длине файла вызовом setLength(), то она сможет более эффективно выделить место на диске под этот файл, сведя к минимуму возможную фрагментацию диска. Если же наращивать файл постепенно, как получилось бы при отсутствии вызова setLength(), то операционная система будет резервировать под файл достаточно случайные свободные фрагменты дискового пространства. Возможно, первого выделенного свободного фрагмента не хватит для записи всего файла, и операционной системе придется выделять дополнительные фрагменты – файл окажется фрагментированным.

Другой плюс вызова setLength(): уже в самом начале копирования операционная система сможет сообщить об ошибке, если окажется, что места на дисковом носителе недостаточно для размещения полного файла.

С другой стороны, вызов setLength() приводит к тому, что в случае каких-либо ошибок результирующий файл получится либо полной (правильной) длины, но с неверным содержимым, либо длины 0. Как правило, в таком поведении нет ничего страшного – ошибки при копировании файлов вообще редкость. Тем не менее это следует иметь в виду.

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

Приведенную функцию копирования файла можно очевидным образом усовершенствовать – добавить стирание результирующего файла, если при копировании были исключения.

Чтение и запись текстового файла: кодировки

Работа с текстовыми файлами в Java далеко не так тривиальна, как с бинарными. Внутри Java текстовые данные всегда хранятся в кодировке Unicode – 16 бит на каждый символ. Но на диске текстовые файлы могут храниться в самых разных кодировках. Для преобразования кодировок файлов в Unicode и обратно нужны специальные классы-преобразователи: InputStreamReader и OutputStreamWriter.