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.

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
FileReadertillämpade plattformens standardteckenuppsättning. Skicka en teckenuppsättning explicit, till exempelnew 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.
