Java BufferedReader: Hur man läser en fil med exempel

⚡ Smart sammanfattning

Java BufferedReader läser text från en indataström genom att buffra tecken, vilket gör rad-för-rad-filläsning snabb och enkel.ping en FileReader inuti BufferedReader och toalettping på readLine tills den returnerar null skriver ut en hel fil.

  • ???? Kärnsyfte: BufferedReader omsluter alla läsare vars läsoperationer är kostsamma, vilket minskar antalet individuella läsningar mot den underliggande strömmen.
  • 🔁 Läs loop: readLine returnerar en rad per anrop och null i slutet av filen, så en while-loop på det resultatet går igenom hela filen.
  • 🧱 Undkomna vägar: A Windows väg inuti en Java Strängen behöver ett dubbelt omvänt snedstreck, annars avvisar kompilatorn den ogiltiga escape-sekvensen.
  • ♻️ Resursfrisättning: Att stänga läsaren frigör den underliggande filreferensen; try-with-resources utför den stängningen automatiskt.
  • ⌨️ Konsolinmatning: Wrapping System.in i en InputStreamReader låter samma klass läsa tangentbordsinmatning snarare än en fil.
  • ⚖️ Skannerkontrast: BufferedReader är snabbare och returnerar råa rader, medan Scanner analyserar tokens och primitiva typer direkt.
  • 🔤 Teckenuppsättnings-varning: FileReader använder standardteckenuppsättningen, så om man uttryckligen anger en sådan undviks förvrängda tecken på olika maskiner.

BufferedReader in Java

Hur man läser en fil i Java?

Java erbjuder flera mekanismer för att läsa från en fil. Det mest användbara paketet för detta är java.io, vars magmusklertract Reader klassen definierar teckenströmsläsning. java.io.BufferedReader är den konkreta underklassen som används för effektiv radbaserad läsning.

Vad är BufferedReader in Java?

BufferedReader är en Java klass som läser text från en indataström, till exempel en fil, genom att buffra tecken så att tecken, arrayer och rader läses effektivt. Utan buffring utlöser varje läsförfrågan från en läsare en motsvarande läsförfrågan mot den underliggande tecken- eller byteströmmen.

Det är därför lämpligt att linda BufferedReader runt vilken Reader som helst vars read() operationer kan vara kostsamma, såsom FileReader och InputStreamReaderEn typisk användning skickar filsökvägen till läsaren enligt följande:

// Note the doubled backslash: a single \ starts an escape sequence
objReader = new BufferedReader(new FileReader("D:\\DukesDiary.txt"));

Detta laddar filen in i objReaderDu itererar sedan igenom innehållet i filen och skriver ut varje rad. While-loopen i koden nedan läser filen tills den når slutet av filen.

while ((strCurrentLine = objReader.readLine()) != null) {
    System.out.println(strCurrentLine);
}

strCurrentLine håller den nuvarande linjen, och objReader.readLine() returnerar en sträng. Loopen fortsätter därför att iterera så länge det returnerade värdet inte är null, och stannar vid det första nullvärdet, vilket signalerar slutet på filen.

BufferExempel på edReader

Koden nedan är en komplett Java BufferedReader-exempel:

import java.io.BufferedReader;
import java.io.FileReader;
import java.io.IOException;

public class ReadFileExample {

    public static void main(String[] args) {
        BufferedReader objReader = null;
        try {
            String strCurrentLine;

            objReader = new BufferedReader(new FileReader("D:\\DukesDiary.txt"));

            while ((strCurrentLine = objReader.readLine()) != null) {
                System.out.println(strCurrentLine);
            }

        } catch (IOException e) {
            e.printStackTrace();

        } finally {
            try {
                if (objReader != null)
                    objReader.close();
            } catch (IOException ex) {
                ex.printStackTrace();
            }
        }
    }
}

Obs: Ocuco-landskapet finally blockfrågor. Det garanterar att objReader.close() körs oavsett om ett undantag utlöstes eller inte, vilket frigör den underliggande filreferensen och behåller minneshantering förutsägbar. Det kapslade försöket inuti finally krävs eftersom close() själv förklarar IOException.

BufferedReader JDK7 Exempel

Från och med JDK 7 tar try-with-resources bort finally blockera helt. Alla resurser som deklareras inom parenteser try satsen stängs automatiskt när blocket avslutas, i omvänd ordning mot skapandet, även om ett undantag sprids:

import java.io.BufferedReader;
import java.io.FileReader;
import java.io.IOException;

public class ReadFileExample_jdk7 {

    private static final String FILENAME = "D:\\DukesDiary.txt";

    public static void main(String[] args) {

        try (BufferedReader br = new BufferedReader(new FileReader(FILENAME))) {

            String strCurrentLine;

            while ((strCurrentLine = br.readLine()) != null) {
                System.out.println(strCurrentLine);
            }

        } catch (IOException e) {
            e.printStackTrace();
        }
    }
}

Den här versionen är kortare och säkrare, så det är den form man föredrar i ny kod. Att läsa en fil är bara en användning av klassen; nästa avsnitt jämför den med det alternativ som de flesta nybörjare först siktar på.

BufferedReader vs Scanner: Vilken ska man använda

Båda klasserna läser text, och nybörjare väljer ofta en godtyckligt. De löser olika problem, och fel val visar sig antingen som klumpig manuell parsning eller dålig dataflöde när inmatningen växer till tusentals rader. Tabellen nedan ställer dem sida vid sida.

Aspect BufferedReader Scanner
Returer Hela rader som sträng Parsade tokens och primitiv
Inbyggd parsning Nej — du splittrar eller konverterar dig själv Ja — nästaInt, nästaDouble, nästa rad
Standardbuffert 8192 tecken 1024 tecken
Hastighet på stora filer Snabbare Långsammare på grund av regex-tokenisering
Trådsäkerhet Synckroniserad Inte synkroniserad
Bäst för Läser stora filer rad för rad Liten interaktiv inmatning som behöver skrivna värden

Välja BufferedReader när målet är att snabbt kunna navigera igenom en fil och hantera texten själv, och Scanner när du vill ha skrivna värden utan att skriva konverteringskod. Dela upp varje returnerad rad med Strängdelningsmetod ger BufferedReader utnyttjar det mesta av skannerns bekvämlighet med högre hastighet.

Hur man läser konsolinmatning med hjälp av BufferedReader

Samma klass läser tangentbordsinmatning, vilket är användbart för små kommandoradsprogram och för inmatning som kräver kodning. System.in är en byteström, så den kan inte överlämnas till BufferedReader direkt. En InputStreamReader överbryggar byte till tecken, och BufferedReader lägger sedan till effektiv radläsning ovanpå den bryggan.

import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;

public class ReadConsoleExample {

    public static void main(String[] args) throws IOException {

        // Bridge the System.in byte stream to a character stream
        try (BufferedReader reader =
                new BufferedReader(new InputStreamReader(System.in))) {

            System.out.print("Enter your name: ");
            String name = reader.readLine();

            System.out.print("Enter your age: ");
            // readLine always returns text, so convert it explicitly
            int age = Integer.parseInt(reader.readLine().trim());

            System.out.println("Hello " + name + ", age " + age);
        }
    }
}

Tre detaljer är värda att komma ihåg. För det första, readLine() returnerar alltid en sträng, så numerisk inmatning måste konverteras med Integer.parseInt eller liknande, och en icke-numerisk inmatning kastar NumberFormatException — radbryter konverteringen om inmatningen inte är betrodd. För det andra, anrop .trim() tar bort den efterföljande vagnreturen som Windows konsoler lägger till, en vanlig orsak till parsningsfel. För det tredje, undvik att stänga en läsare som är lindad runt System.in om programmet fortfarande behöver konsolindata senare, eftersom stängning av omslaget stänger den underliggande strömmen permanent för den processen.

För program som läser många värden går det mycket snabbare att läsa en rad och dela den än att anropa readLine() upprepade gånger, eftersom varje anrop endast går in i operativsystemet när bufferten töms. Detta är den främsta anledningen till att konkurrenskraftiga programmerare föredrar BufferedReader över Scanner för bulkinmatning.

Även med korrekt kod dyker en handfull fel upp upprepade gånger.

Gemensam BufferedReader-fel och hur man åtgärdar dem

bro BufferedReader-fel beror på filsökvägar, resurshantering eller teckenkodning snarare än på själva läsloopen. Varje fel nedan anger sitt undantag och dess åtgärd.

  • Olaglig flyktkaraktär: sökvägen använder ett enda bakåtsnedstreck, som i "D:\DukesDiary.txt". Double den till "D:\\DukesDiary.txt", eller använd ett snedstreck, vilket Java accepterar den Windows.
  • FilInteFunnenUndantag: Sökvägen är relativ till arbetskatalogen, inte källfilen. new File(name).getAbsolutePath() för att se var Java tittar faktiskt.
  • NullPointerException vid första läsningen: Läsaren tilldelades aldrig eftersom konstruktorn kastade, och undantaget svaldes. Kontrollera undantagshantering före loopen.
  • Förvrängda tecken eller frågetecken: filen är UTF-8 men FileReader tillämpade plattformens standardteckenuppsättning. Skicka en teckenuppsättning explicit, till exempel new InputStreamReader(new FileInputStream(f), StandardCharsets.UTF_8).
  • Strömmen stängd: Läsaren stängdes inuti loopen eller återanvändes efter att try-with-resources avslutades. Öppna en ny läsare för varje pass över filen.

Vanliga frågor

Ja. Ett andra konstruktorargument anger bufferten i tecken, till exempel new BufferedReader(reader, 16384)Standardvärdet 8192 passar de flesta filer; att höja det hjälper bara vid mycket stora sekventiella läsningar.

För små filer, ja — den returnerar en lista med rader i ett anrop. För stora filer föredras Files.newBufferedReader or Files.lines, eftersom readAllLines lagrar hela filen i minnet samtidigt.

Ja. AI Assistenterna skriver om finally-block cleanup till try-with-resources och föreslår NIO-ekvivalenter. Verifiera teckenuppsättningen och undantagsbeteendet efteråt, eftersom genererade konverteringar ofta tar bort den explicita kodningen.

AI läser stacken trace och identifierar om orsaken är felaktig arbetskatalog, saknad behörighet eller en kodningsmatchning. Det förkortar diagnosen, även om korrigeringen fortfarande behöver verifieras mot den riktiga filen.

Nej. readLine tar bort radavslutaren, så en returnerad sträng innehåller ingen avslutande radbrytning. En tom rad i filen returnerar därför en tom sträng snarare än null.

Sammanfatta detta inlägg med: