Obsługa uszkodzonych plików, odzyskiwanie danych

1. Przesłanki uszkodzenia plików

W idealnym świecie pliki zawsze są odczytywane i zapisywane bez błędów, a dane w nich — jak świeżo upieczone bułeczki: miękkie, pachnące, równe, całe. W rzeczywistości jednak pliki potrafią być „uszkodzone”, „krzywe”, „połowiczne” albo „w niewłaściwym formacie”. Przyczyny mogą być różne. Na przykład awaria podczas zapisu na dysk (przy nagłej utracie zasilania), błędy sieci przy przesyłaniu pliku, uszkodzenie nośnika (stary, niedobry bad sector). Ręczna edycja pliku w nieodpowiednim programie także może go uszkodzić, podobnie jak rozbieżność między oczekiwanym a faktycznym formatem danych.

W Javie takie sytuacje zwykle ujawniają się poprzez wyjątki przy odczycie/zapisie, a czasem — poprzez dziwne zachowanie programu (na przykład dane nagle się kończą albo pojawiają się „krzaki”).

Wyjątki podczas odczytu

Najbardziej oczywisty znak — nieoczekiwane wyjątki. Oto niektóre z nich:

• EOFException — nieoczekiwany koniec pliku (End Of File). Oczekiwano, że w pliku są jeszcze dane, a ich tam nie ma.
• MalformedInputException (lub, w starszych API, MalformedInputException z NIO) — plik nie odpowiada oczekiwanemu kodowaniu lub strukturze.
• ZipException — jeśli próbujesz czytać archiwum jak zwykły plik.
• StreamCorruptedException — podczas odczytu serializowanych obiektów, jeśli plik jest uszkodzony.

Niezgodność formatu danych

Czasem plik daje się odczytać bez wyjątku, ale zawartość nie odpowiada oczekiwanemu formatowi:

• Oczekiwano wiersza, a otrzymano ciąg niezrozumiałych znaków.
• Oczekiwano określonej liczby wartości, a jest ich mniej.
• Oczekiwano pliku w formacie CSV, a jest JSON (albo odwrotnie).

Przykład z życia

Załóżmy, że piszesz aplikację, która przechowuje listę zadań w pliku tekstowym. Program oczekuje, że każda linia to osobne zadanie. Ale użytkownik otworzył plik w Excelu, wprowadził zmiany, zapisał w innym formacie... i teraz Twój program nie może odczytać pliku.

2. Strategie obsługi uszkodzonych plików

Logowanie i informowanie użytkownika

Pierwsza zasada: nie panikować! (i nie pozwalać panikować użytkownikowi). Zawsze loguj błąd i informuj użytkownika, jeśli coś poszło nie tak. Opisywanie mu wszystkich okropności stosu Javy nie jest konieczne.

try {
    // odczyt pliku
} catch (EOFException e) {
    System.err.println("Plik zakończył się niespodziewanie. Możliwe, że jest uszkodzony.");
    // logujemy szczegóły
    e.printStackTrace();
}

Próba częściowego odzyskania

Czasem można „uratować” chociaż część danych. Na przykład jeśli plik jest czytany linia po linii, można przetworzyć wszystkie wiersze do pierwszego błędu.

Korzystanie z kopii zapasowych (backup)

Solidne programy często tworzą kopie zapasowe ważnych plików przed zapisem. Jeśli plik główny jest uszkodzony, można spróbować przywrócić dane z backupu.

3. Praktyka: odczyt pliku z nieoczekiwanym końcem (EOF)

Klasyczna sytuacja

Załóżmy, że mamy plik binarny, w którym kolejno zapisano liczby typu int. Program oczekuje, że będzie ich dokładnie 5, ale plik został uszkodzony i zapisano tylko 3.

import java.io.*;

public class DamagedFileExample {
    public static void main(String[] args) {
        String filename = "numbers.bin";

        // Dla przykładu: tworzymy plik z 3 liczbami (zamiast 5)
        try (DataOutputStream out = new DataOutputStream(new FileOutputStream(filename))) {
            out.writeInt(42);
            out.writeInt(7);
            out.writeInt(2024);
            // out.writeInt(1); out.writeInt(2); // celowo nie zapisujemy!
        } catch (IOException e) {
            System.err.println("Błąd podczas tworzenia pliku: " + e.getMessage());
        }

        // Teraz spróbujemy odczytać 5 liczb
        try (DataInputStream in = new DataInputStream(new FileInputStream(filename))) {
            for (int i = 0; i < 5; i++) {
                int number = in.readInt();
                System.out.println("Przeczytano liczbę: " + number);
            }
        } catch (EOFException e) {
            System.err.println("Plik zakończył się niespodziewanie! Możliwe, że jest uszkodzony.");
        } catch (IOException e) {
            System.err.println("Błąd odczytu: " + e.getMessage());
        }
    }
}

Wynik:

Przeczytano liczbę: 42
Przeczytano liczbę: 7
Przeczytano liczbę: 2024
Plik zakończył się niespodziewanie! Możliwe, że jest uszkodzony.

Odczyt do pierwszego błędu

Często rozsądnie jest czytać dane w pętli, dopóki nie wystąpi wyjątek. W ten sposób można uzyskać przynajmniej część informacji.

try (DataInputStream in = new DataInputStream(new FileInputStream(filename))) {
    while (true) {
        try {
            int number = in.readInt();
            System.out.println("Przeczytano liczbę: " + number);
        } catch (EOFException e) {
            System.out.println("Dane się skończyły (lub plik jest uszkodzony).");
            break;
        }
    }
} catch (IOException e) {
    System.err.println("Błąd odczytu: " + e.getMessage());
}

4. Praca z plikami tekstowymi i kodowaniami

Problem z kodowaniem

Jeśli plik został zapisany w jednym kodowaniu, a jest odczytywany w innym, możliwe są błędy dekodowania:

import java.nio.charset.*;

try (BufferedReader reader = new BufferedReader(
        new InputStreamReader(new FileInputStream("tasks.txt"), "UTF-8"))) {
    String line;
    while ((line = reader.readLine()) != null) {
        System.out.println(line);
    }
} catch (MalformedInputException e) {
    System.err.println("Błąd kodowania! Plik jest uszkodzony lub zapisany nie w UTF-8.");
} catch (IOException e) {
    System.err.println("Błąd odczytu: " + e.getMessage());
}

Ważne: Czasem zamiast wyjątku zobaczysz „krzaki” — to także oznaka uszkodzenia lub nieprawidłowego kodowania.

Jak to obsłużyć?

• Poinformować użytkownika o problemie.
• Spróbować otworzyć plik w innym kodowaniu.
• Jeśli dane są krytyczne — zaproponować przywrócenie z kopii zapasowej.

5. Odzyskiwanie danych: strategie

Odczyt częściowo poprawnych danych

Jeśli struktura pliku na to pozwala, można „wyciągnąć” przynajmniej te dane, które udało się odczytać do momentu błędu. Na przykład jeśli plik to lista wierszy (jedno zadanie — jeden wiersz), można przetworzyć wszystkie wiersze do awarii.

try (BufferedReader reader = new BufferedReader(new FileReader("tasks.txt"))) {
    String line;
    while ((line = reader.readLine()) != null) {
        // przetwarzanie linii
    }
} catch (IOException e) {
    System.err.println("Błąd odczytu: " + e.getMessage());
    // Można zapisać już odczytane dane albo zaproponować użytkownikowi odzyskanie
}

Używanie plików kopii zapasowych

Jeśli wcześniej tworzysz kopię pliku (na przykład tasks.txt.bak), możesz przywrócić dane z niej:

File original = new File("tasks.txt");
File backup = new File("tasks.txt.bak");

if (!original.exists() && backup.exists()) {
    // Kopiujemy backup w miejsce oryginału
    Files.copy(backup.toPath(), original.toPath(), StandardCopyOption.REPLACE_EXISTING);
    System.out.println("Przywracanie z kopii zapasowej zakończone.");
}

Sumy kontrolne i walidacja

Dla ważnych plików można przechowywać sumę kontrolną (na przykład MD5 lub SHA-256) i przy każdym otwarciu pliku porównywać ją z aktualną. Jeśli się nie zgadza — plik jest uszkodzony.

// Schemat poglądowy (implementacja haszowania pominięta dla prostoty)
String expectedHash = "..."; // wcześniej zapisana suma
String actualHash = calculateFileHash("tasks.txt");
if (!expectedHash.equals(actualHash)) {
    System.out.println("Plik tasks.txt jest uszkodzony! Spróbuj przywrócić go z kopii zapasowej.");
}

6. Typowe błędy przy obsłudze uszkodzonych plików

Błąd nr 1: Brak weryfikacji formatu pliku. Jeśli oczekujesz, że każda linia to na przykład liczba, a jest tam tekst — wystąpi NumberFormatException. Lepiej walidować dane w trakcie odczytu.

Błąd nr 2: Brak try-with-resources. Jeśli nie używasz try-with-resources, plik może pozostać „zawieszony” (niezamknięty) nawet przy błędzie, co utrudni odzyskanie lub usunięcie.

Błąd nr 3: Nadpisywanie uszkodzonego pliku bez stworzenia kopii zapasowej. Jeśli przy błędzie od razu nadpisujesz plik, szansa na odzyskanie maleje. Lepiej najpierw zapisać backup.

Błąd nr 4: Nieinformatywne odzyskiwanie. Użytkownik powinien wiedzieć, że plik był uszkodzony i został przywrócony z kopii, — inaczej może nie zrozumieć, dlaczego część danych zniknęła.