ফাইল I/O — Path, Files আর java.nio.file

১ · প্রোগ্রাম থামলে ডেটা কোথায় যায় — ফাইল কেন দরকার

পর্ব ২২-এ আপনি “হিসাব খাতা” বানিয়েছিলেন — একটি CLI টুল, যেখানে প্রতিদিনের খরচ লেখা যায় আর মোট দেখা যায়। একটা সমস্যা তখনই চোখে পড়েছিল: প্রোগ্রাম বন্ধ করলে সব খরচ উধাও। পরদিন খুলে আবার শূন্য থেকে শুরু। কারণ, প্রোগ্রামের সব ভ্যারিয়েবল, array আর object থাকে RAM-এ। আর RAM হলো ক্ষণস্থায়ী মেমরি: প্রোগ্রাম থামলে JVM তার মেমরি অপারেটিং সিস্টেমকে ফেরত দেয়, আর বিদ্যুৎ গেলে তো কথাই নেই।

ফাইল আসলে ডিস্কে (SSD বা হার্ডডিস্কে) রাখা কিছু byte-এর একটি নামযুক্ত সারি। অপারেটিং সিস্টেম এগুলো ফোল্ডারে সাজিয়ে রাখে, আর প্রতিটির একটি ঠিকানা থাকে, যেমন /home/rahim/khata.csv বা C:\Users\Rahim\khata.csv. প্রোগ্রাম ফাইলে সরাসরি হাত দিতে পারে না; প্রতিবার অপারেটিং সিস্টেমকে অনুরোধ করতে হয় — খোলো, লেখো, বন্ধ করো। Java-র ফাইল API এই অনুরোধগুলোর একটি নিরাপদ মোড়ক।

Java-র তিন প্রজন্মের ফাইল API

Java-তে ফাইল নিয়ে কাজের উপায় তিন ধাপে বদলেছে, আর ইন্টারনেটে (এবং AI-এর উত্তরে) তিনটিই দেখবেন:

এই পর্বের মূল মডেলটি এক লাইনে: Path হলো ঠিকানা লেখা চিরকুট, আর Files হলো সেই ঠিকানায় গিয়ে কাজ করে আসা পিয়ন। চিরকুট বানালেই বাড়ি তৈরি হয় না — Path.of("khata.csv") লিখলে কোনো ফাইল তৈরি হয় না, ফাইল আছে কি না তাও দেখা হয় না। কাজ শুরু হয় যখন আপনি চিরকুটটি Files-এর কোনো method-এ দেন। আর যেহেতু বাইরের জগতে অনেক কিছু ভুল হতে পারে — ফাইল নেই, অনুমতি নেই, ডিস্ক ভরা — প্রায় প্রতিটি Files method পর্ব ২৯-এর checked exception IOException ঘোষণা করে।

আপনার কোড     Path p = Path.of("data", "khata.csv");     ← শুধু ঠিকানা, ডিস্ক ছোঁয় না
                 List<String> lines = Files.readAllLines(p);  ← এখানে আসল কাজ
                        │
java.nio.file    ফাইল খোলা → byte পড়া → UTF-8 দিয়ে অক্ষর বানানো → লাইনে ভাগ → বন্ধ
                        │   (কোথাও ব্যর্থ হলে IOException-এর একটি subclass)
অপারেটিং সিস্টেম  open(), read(), close() — system call
                        │
ডিস্ক            byte: e0 a6 9a e0 a6 be e0 a6 b2 ...

২ · Path — ফাইলের ঠিকানা লেখা, জোড়া আর পরিষ্কার করা

Path.of (Java 11 থেকে; আগে একই কাজ করত Paths.get) একটি বা কয়েকটি টুকরো নিয়ে ঠিকানা বানায়: Path.of("data", "2026", "jan.csv") হয় data/2026/jan.csv. টুকরোগুলো আলাদা দিলে Java নিজেই চলতি অপারেটিং সিস্টেমের বিভাজক বসায় — Linux ও Mac-এ /, Windows-এ \. এজন্য হাতে "data\\" + name লিখে ঠিকানা জোড়া একটি ক্লাসিক ভুল: Windows-এ চলে, Linux সার্ভারে গিয়ে পুরো লেখাটি একটি অদ্ভুত নামের ফাইল হয়ে যায় (Wandbox-এর Linux-এ যাচাই করা: Path.of("C:\\data\\jan.csv").getFileName() পুরো লেখাটিই ফেরত দেয়)।

relative বনাম absolute

Absolute path শুরু হয় ফাইল-সিস্টেমের মূল থেকে — /home/rahim/khata.csv. Relative path শুরু হয় “এখান থেকে” — data/khata.csv. প্রশ্ন হলো, “এখান” মানে কোথায়? উত্তর: working directory, অর্থাৎ যে ফোল্ডার থেকে প্রোগ্রাম চালানো হয়েছে। IDE-তে চালালে সাধারণত প্রজেক্টের মূল ফোল্ডার; terminal-এ চালালে যেখানে দাঁড়িয়ে java লিখেছেন। একই প্রোগ্রাম দুই জায়গা থেকে চালালে একই relative path দুটি আলাদা ফাইল দেখাতে পারে — “আমার মেশিনে তো চলে!” সমস্যার এটি বড় উৎস। toAbsolutePath() দেখায় relative path-টি আসলে কোথায় গিয়ে দাঁড়াচ্ছে; ডিবাগ করার সময় এটি ছাপিয়ে দেখা খুব কাজের।

resolve আর normalize — ধাপে ধাপে

দুটি method প্রায় প্রতিদিন লাগবে। resolve(other) একটি ঠিকানার পেছনে আরেকটি জোড়ে — Path.of("data").resolve("jan.csv") হয় data/jan.csv. আর normalize() ঠিকানা থেকে অপ্রয়োজনীয় অংশ ছেঁটে ফেলে: . মানে “এই ফোল্ডারেই”, আর .. মানে “এক ধাপ ওপরে”। একটি এলোমেলো ঠিকানা দিয়ে দেখা যাক (প্রতিটি ফল Java 21-এ যাচাই করা; শেষ ধাপের absolute path শুধু উদাহরণ, কারণ সেটি নির্ভর করে কোথা থেকে চালানো হলো তার ওপর):

1Path p = Path.of("data/../reports/./jan.csv");2p.getFileName();   // শেষ টুকরো3p.getParent();     // শেষ টুকরো বাদে4Path n = p.normalize();5Path a = Path.of("archive").resolve(n);6a.toAbsolutePath();

পুরোনো File class — চিনে রাখুন, নতুন কোডে নয়

পুরোনো কোডে সবখানে দেখবেন new File("khata.csv"). java.io.File একসাথে ঠিকানা আর কাজ — দুটোই করত, আর এর নকশায় কয়েকটি বড় দুর্বলতা ছিল। file.delete() ব্যর্থ হলে শুধু false দেয় — ফাইল নেই, নাকি অনুমতি নেই, নাকি অন্য প্রোগ্রাম খুলে রেখেছে, জানার উপায় নেই। listFiles() ব্যর্থ হলে দেয় null, যা পরের লাইনে NullPointerException হয়ে ফাটে। তুলনায় Files.delete(path) ব্যর্থ হলে নির্দিষ্ট exception ছোড়ে, যার নাম দেখেই কারণ বোঝা যায়। পুরোনো API থেকে File পেলে file.toPath(); উল্টো দিকে path.toFile().

৩ · ছোট ফাইল পড়া-লেখা — readString, writeString, readAllLines

কয়েক কিলোবাইট থেকে কয়েক মেগাবাইটের ফাইল — config, নোট, ছোট CSV — পুরোটা একবারে মেমরিতে আনা সবচেয়ে সহজ। এর জন্য চারটি method:

প্রতিটিই নিজে ফাইল খোলে আর কাজ শেষে বন্ধ করে, তাই আপনাকে close নিয়ে ভাবতে হয় না। লেখার method-গুলো ডিফল্টে ফাইল না থাকলে বানায়, আর থাকলে আগের সব লেখা মুছে নতুন করে লেখে। শেষে যোগ করতে চাইলে বলতে হয় — একটু পরে দেখবেন। কিন্তু প্রথমে compiler-এর একটি আপত্তি:

import java.nio.file.*;

class Main {
    public static void main(String[] args) {
        String text = Files.readString(Path.of("khata.csv"));
        System.out.println(text);
    }
}

Main.java:5: error: unreported exception IOException; must be caught or declared to be thrown
        String text = Files.readString(Path.of("khata.csv"));
                                      ^
1 error

পর্ব ২৯-এর সেই পাহারাদার। readString ঘোষণা করে throws IOException, তাই আপনাকে হয় try-catch লিখতে হবে, নয়তো নিজের method-এ throws IOException ঘোষণা করতে হবে। ছোট উদাহরণে main-এ throws IOException লেখা চলে; আসল অ্যাপে ব্যবহারকারীকে বোঝার মতো বার্তা দেখাতে ধরুন। throws দিয়ে চালালে, আর ফাইলটি না থাকলে, এই trace আসে (ভেতরের JDK-লাইনগুলো সংক্ষেপ করা):

Exception in thread "main" java.nio.file.NoSuchFileException: khata.csv
	at java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:92)
	... (আরও ৭টি JDK-র ভেতরের লাইন)
	at java.base/java.nio.file.Files.readString(Files.java:3305)
	at Main.main(Main.java:6)

NoSuchFileException-এর বার্তায় শুধু path — khata.csv. ওপরের UnixException লাইন বলছে এটি Linux-এ (বা Mac-এ) চালানো; Windows-এ নাম আলাদা হবে, কিন্তু exception একই। পুরোনো new FileReader("nai.txt") দেয় java.io.FileNotFoundException: nai.txt (No such file or directory) — “নেই” আর “অনুমতি নেই” দুটোতেই একই exception-টাইপ, পার্থক্য শুধু বার্তার লেখায়।

হিসাব খাতা সেভ আর আবার লোড

এবার পর্ব ২২-এর খাতার একটি সরল রূপকে ফাইলে টিকিয়ে রাখা যাক। প্রতিটি খরচ একটি record (পর্ব ২৫); ফাইলে প্রতিটি খরচ এক লাইন, ঘরগুলো কমা দিয়ে আলাদা — এই ফরম্যাটের নাম CSV. প্রোগ্রামটি দুটি খরচ লেখে, তৃতীয়টি শেষে যোগ করে, তারপর ফাইল থেকে পড়ে record-এ ফেরত আনে, যেন পরদিন অ্যাপ খুলেছেন:

import java.io.IOException;
import java.nio.file.*;
import java.util.List;

record Expense(String date, String item, int taka) {
    String toCsv() { return date + "," + item + "," + taka; }
    static Expense fromCsv(String line) {
        String[] p = line.split(",");
        return new Expense(p[0], p[1], Integer.parseInt(p[2]));
    }
}
class Main {
    public static void main(String[] args) throws IOException {
        Path file = Path.of("khata.csv");
        List<Expense> today = List.of(new Expense("2026-10-18", "চাল", 850),
                                      new Expense("2026-10-18", "রিকশা ভাড়া", 60));
        Files.write(file, today.stream().map(Expense::toCsv).toList());
        Files.writeString(file, "2026-10-19,বিদ্যুৎ বিল,1200\n", StandardOpenOption.APPEND);
        List<Expense> loaded = Files.readAllLines(file).stream().map(Expense::fromCsv).toList();
        loaded.forEach(e -> System.out.println(e.item() + " → " + e.taka() + " টাকা"));
        int total = loaded.stream().mapToInt(Expense::taka).sum();
        System.out.println("মোট " + loaded.size() + "টি খরচ, " + total + " টাকা");
        Files.delete(file);
    }
}

খোলার ধরন — StandardOpenOption

লেখার method-গুলোর শেষে কয়েকটি StandardOpenOption দেওয়া যায়, যা বলে ফাইল কীভাবে খোলা হবে। কিছু না দিলে ডিফল্ট হলো CREATE, TRUNCATE_EXISTING আর WRITE — অর্থাৎ “না থাকলে বানাও, থাকলে খালি করে লেখো”।

শুধু APPEND দিলে আর ফাইল না থাকলে সত্যিই ব্যর্থ হয় — যাচাই করা বার্তা java.nio.file.NoSuchFileException: log.txt. তাই একটি দোকানের অর্ডার-লগ, যেখানে প্রতিটি অর্ডার এক লাইন হিসেবে জমতে থাকবে, এভাবে লিখুন:

static void log(String message) throws IOException {
    Files.writeString(Path.of("orders.log"), message + System.lineSeparator(),
                      StandardOpenOption.CREATE, StandardOpenOption.APPEND);
}

প্রথম ডাকে ফাইল তৈরি হয়, পরের প্রতিটি ডাক শেষে একটি লাইন জোড়ে। System.lineSeparator() চলতি অপারেটিং সিস্টেমের line separator দেয়; পড়ার সময় readAllLines দুই রকম বিরতিই চেনে (Windows-এর \r\n লেখা ফাইল পড়েও পরিষ্কার লাইন দেয় — যাচাই করা)।

৪ · charset — ফাইলে byte থাকে, অক্ষর নয়

এই অংশটি বাংলায় লেখেন এমন প্রত্যেকের জন্য সবচেয়ে জরুরি। ডিস্ক অক্ষর চেনে না; চেনে শুধু byte, অর্থাৎ ০ থেকে ২৫৫-এর সংখ্যা। “আমার” লিখে সেভ করলে ফাইলে যায় এই ১২টি byte: e0 a6 86 e0 a6 ae e0 a6 be e0 a6 b0. চারটি অক্ষর, ১২টি byte — কারণ UTF-8-এ প্রতিটি বাংলা অক্ষর তিন byte নেয়। অক্ষরকে byte বানানোর আর byte থেকে অক্ষর ফেরত আনার এই নিয়মের নাম charset (বা character encoding). Java 21-এ যাচাই করা: “আমার সোনার বাংলা” ১৬টি char, কিন্তু UTF-8-এ ৪৪ byte (দুটি space এক byte করে)।

সমস্যা হয় যখন লেখার charset আর পড়ার charset আলাদা। তখন byte একই থাকে, কিন্তু ভুল নিয়মে অনুবাদ হয়ে অর্থহীন অক্ষর বেরোয়। এই হিজিবিজির নাম mojibake:

ফাইলে byte:        e0 a6 86 | e0 a6 ae | e0 a6 be | e0 a6 b0

UTF-8 হিসেবে পড়া:   আ          ম          া          র        → আমার            ✓
Windows-1252 হিসেবে: à ¦ †      à ¦ ®      à ¦ ¾      à ¦ °    → আমার   ✗ mojibake

আর কখনো কখনো ভুল charset-এ পড়া একেবারে ব্যর্থ হয়। UTF-8-এর নিয়ম কঠোর — কিছু byte-এর সারি বৈধই নয়। পুরোনো ANSI ফাইল (যেমন বিজয়ের মতো ফন্ট-নির্ভর পুরোনো বাংলা লেখা, যা Unicode নয়) UTF-8 ধরে পড়লে Files.readAllLines দেয় java.nio.charset.MalformedInputException: Input length = 1 — একটি MalformedInputException. চুপচাপ হিজিবিজির চেয়ে এটি ভালো।

Java-তে ডিফল্ট charset কোনটি

এখানে একটি গুরুত্বপূর্ণ ইতিহাস আছে, যা পুরোনো কোড পড়তে লাগবে:

• Files-এর method (readString, readAllLines, lines, newBufferedReader, write…): charset ছাড়া রূপগুলো (Java 8 থেকে) সবসময় UTF-8; Java 7-এ charset দেওয়া বাধ্যতামূলক ছিল।
• পুরোনো java.io class (FileReader, FileWriter, InputStreamReader, PrintWriter): Java 17 পর্যন্ত charset না দিলে অপারেটিং সিস্টেমের ডিফল্ট — ইংরেজি Windows-এ সাধারণত Windows-1252, Linux-এ সাধারণত UTF-8. ফলে একই প্রোগ্রাম Linux-এ বাংলা ঠিক রাখত, Windows-এ নষ্ট করত।
• Java 18 থেকে (JEP 400): সব জায়গায় ডিফল্ট charset UTF-8, অপারেটিং সিস্টেম যা-ই হোক। (Wandbox-এর Java 21-এ Charset.defaultCharset() ছাপলে আসে UTF-8.) কনসোলে ছাপার encoding অবশ্য আলাদা বিষয় — সেটি এখনো টার্মিনালের ওপর নির্ভর করে।

৫ · বড় ফাইল — Files.lines, buffer আর বন্ধ করার দায়িত্ব

একটি ই-কমার্স সাইটের এক মাসের লগ ফাইল কয়েক গিগাবাইট হতে পারে। readAllLines পুরো ফাইল মেমরিতে আনে — প্রতিটি লাইন একটি String object, আর বাংলা বা ইংরেজি যা-ই হোক, মেমরিতে ফাইলের চেয়ে বেশি জায়গা লাগতে পারে। JVM-এর heap ছোট হলে প্রোগ্রাম OutOfMemoryError দিয়ে থেমে যাবে। বড় ফাইলের নিয়ম হলো: একবারে একটি লাইন — পড়ো, কাজ করো, ভুলে যাও।

এর আধুনিক পথ Files.lines(p) (Java 8): এটি একটি Stream<String> দেয় (পর্ব ৩৫)। Stream অলস — লাইন পড়া হয় তখনই, যখন পাইপের শেষ ধাপ চাইবে। তাই কয়েক গিগাবাইটের ফাইলেও মেমরিতে থাকে কয়েকটি লাইন মাত্র। কিন্তু একটি বড় পার্থক্য আছে: সাধারণ list.stream()-এর পেছনে থাকে মেমরির একটি তালিকা, আর Files.lines-এর পেছনে থাকে একটি খোলা ফাইল. অপারেটিং সিস্টেম প্রতিটি খোলা ফাইলের জন্য একটি file handle দেয়, আর এর সংখ্যা সীমিত। Stream শেষ হলেও ফাইল নিজে নিজে বন্ধ হয় না। তাই Files.lines সবসময় try-with-resources-এ (পর্ব ২৯):

try (Stream<String> lines = Files.lines(Path.of("orders.log"))) {
    long errors = lines.filter(l -> l.contains("ERROR")).count();
    System.out.println("ভুল: " + errors);
}   // এখানে lines.close() — ফাইল বন্ধ

বন্ধ না করলে কী হয়, তা Wandbox-এ যাচাই করা: একটি লুপে বারবার Files.lines খুলে বন্ধ না করায় একসময় এল java.nio.file.FileSystemException: log.txt: Too many open files. সার্ভারে এর মানে নতুন ফাইল তো বটেই, নতুন নেটওয়ার্ক সংযোগও আর খোলা যায় না, কারণ Linux-এ সেগুলোও file handle. Files.list আর Files.walk-এর জন্যও একই নিয়ম।

BufferedReader আর BufferedWriter

লাইন ধরে পড়ার পুরোনো ও এখনো জনপ্রিয় পথ BufferedReader — Files.newBufferedReader(p) দিয়ে পাওয়া যায়, আর readLine() প্রতিবার একটি লাইন দেয়, শেষে null. লেখার জোড়া BufferedWriter — Files.newBufferedWriter(p, options…). নামের “Buffered” অংশটাই আসল কথা। প্রতিটি write ডাকে সরাসরি ডিস্কে লিখলে প্রতিবার অপারেটিং সিস্টেমকে ডাকতে হতো — একটি system call, যা সাধারণ method ডাকের চেয়ে বহুগুণ দামি। Buffer মেমরিতে লেখা জমায় (BufferedWriter-এর ডিফল্ট ৮১৯২ অক্ষর), ভরলে বা বন্ধ করার সময় একবারে পাঠায়। ফলে লক্ষ লাইন লিখতে লক্ষ বার নয়, কয়েকশো বার অপারেটিং সিস্টেমকে ডাকতে হয়।

এর একটি পরিণতি নতুনদের প্রায়ই অবাক করে: write ডাকার পরেও লেখা ফাইলে নাও পৌঁছাতে পারে। যাচাই করা: newBufferedWriter দিয়ে একটি লাইন লিখে বন্ধ করার আগে Files.size দেখালে 0 byte; close()-এর পরে লাইনটি ফাইলে আছে। ধাপে ধাপে দেখুন — একটি দোকানের অর্ডার-লগে দুটি লাইন যোগ:

1try (BufferedWriter w = Files.newBufferedWriter(log,2        StandardOpenOption.CREATE, StandardOpenOption.APPEND)) {3    w.write("10:00 অর্ডার #101\n");4    w.write(nextOrderLine());   // #1025}   // Java নিজে w.close() ডাকে6// try ছাড়া, close() ছাড়া?

byte stream, character stream আর মোড়কের শিকল

পুরোনো java.io-তে দুই পরিবার: byte stream (InputStream/OutputStream) কাঁচা byte নিয়ে কাজ করে — ছবি, PDF, zip-এর জন্য; আর character stream (Reader/Writer) অক্ষর নিয়ে, ভেতরে একটি charset দিয়ে byte-কে অক্ষর বানিয়ে। এগুলো জোড়া লাগে decorator pattern-এ — প্রতিটি স্তর আগের স্তরকে মুড়ে একটি ক্ষমতা যোগ করে (পর্ব ৯-এ System.in-এর ওপর এমন শিকল দেখেছেন; নকশাটির বিস্তারিত পর্ব ৪৮-এ):

// java.io — তিন স্তরের মোড়ক: byte → অক্ষর (UTF-8) → buffer আর readLine
BufferedReader in = new BufferedReader(
        new InputStreamReader(
                new FileInputStream("khata.csv"), StandardCharsets.UTF_8));

// java.nio.file — একই শিকল, এক ডাকে
BufferedReader in2 = Files.newBufferedReader(Path.of("khata.csv"));

দুটি প্রায় এক, তবে একটি সূক্ষ্ম পার্থক্য আছে: InputStreamReader অবৈধ byte পেলে চুপচাপ � চিহ্ন বসিয়ে দেয়, আর Files.newBufferedReader MalformedInputException ছোড়ে। ডেটার সঠিকতা জরুরি হলে দ্বিতীয়টিই ভালো। ছবি বা অন্য binary ফাইলের জন্য Files.readAllBytes, Files.newInputStream আর Files.newOutputStream আছে — সেখানে charset-এর প্রশ্নই নেই।

৬ · একটি CSV থেকে রিপোর্ট — জেলাভিত্তিক বিক্রি

একটি পরিবেশক কোম্পানির বিক্রির CSV — প্রতিটি লাইনে জেলা, পণ্য আর টাকা — থেকে জানতে হবে কোন জেলায় মোট কত বিক্রি। পর্ব ৩৫-এর groupingBy আর Files.lines মিলে কাজটি কয়েক লাইনের। প্রথমে ধাপগুলো:

1try (Stream<String> lines = Files.lines(csv)) {2    byDistrict = lines.skip(1)3        .map(line -> line.split(","))4        .collect(groupingBy(p -> p[0], TreeMap::new,5                 summingInt(p -> Integer.parseInt(p[2]))));6}

এবার পুরোটা চালিয়ে দেখুন। প্রোগ্রামটি নিজেই BufferedWriter দিয়ে নমুনা ফাইল বানায়, তারপর পড়ে হিসাব করে, শেষে মুছে ফেলে:

import java.io.*;
import java.nio.file.*;
import java.util.*;
import java.util.stream.*;

class Main {
    public static void main(String[] args) throws IOException {
        Path csv = Path.of("sales.csv");
        try (BufferedWriter w = Files.newBufferedWriter(csv)) {
            w.write("district,product,taka\n");
            w.write("ঢাকা,চা,1200\nরাজশাহী,আম,3000\nঢাকা,বিস্কুট,800\n");
            w.write("খুলনা,চিংড়ি,2500\nরাজশাহী,চা,400\n");
        }
        Map<String, Integer> byDistrict;
        try (Stream<String> lines = Files.lines(csv)) {
            byDistrict = lines.skip(1)
                .map(line -> line.split(","))
                .collect(Collectors.groupingBy(p -> p[0], TreeMap::new,
                         Collectors.summingInt(p -> Integer.parseInt(p[2]))));
        }
        byDistrict.forEach((d, t) -> System.out.println(d + ": " + t + " টাকা"));
        Files.delete(csv);
    }
}

split(",")-এর সীমা — আসল CSV এত সরল নয়

উদাহরণের CSV পরিষ্কার, কিন্তু Excel থেকে আসা আসল CSV-তে তিনটি ফাঁদ প্রায়ই থাকে। প্রথমত, ঘরের ভেতরেই কমা: ঢাকা,"চা, বিস্কুট",500. CSV-র নিয়মে উদ্ধৃতি-চিহ্নের ভেতরের কমা আলাদা ঘর নয়, কিন্তু split(",") সেটা জানে না — চারটি টুকরো দেয়, আর parseInt(p[2]) ভেঙে পড়ে java.lang.NumberFormatException: For input string: " বিস্কুট"" দিয়ে (যাচাই করা)। দ্বিতীয়ত, শেষের ফাঁকা ঘর: "ঢাকা,চা,".split(",") দুটি টুকরো দেয়, তিনটি নয় — Java শেষের ফাঁকা টুকরো ফেলে দেয়, ফলে p[2]-এ ArrayIndexOutOfBoundsException: Index 2 out of bounds for length 2. সমাধান split(",", -1), যা ফাঁকা টুকরোও রাখে। তৃতীয়ত, Excel-এর সেভ করা CSV-র charset আর শুরুর অদৃশ্য BOM চিহ্ন।

নিজের বানানো সরল ফাইলে split যথেষ্ট। বাইরের CSV-র জন্য পরীক্ষিত লাইব্রেরি — যেমন Apache Commons CSV বা OpenCSV (JDK-র অংশ নয়; পর্ব ৪৬-এ Maven দিয়ে লাইব্রেরি যোগ করা শিখবেন)। আর একটি অবাক করা তথ্য: Integer.parseInt("১০০") সত্যিই ১০০ দেয় — Java যেকোনো Unicode অঙ্ক চেনে (যাচাই করা)।

৭ · ফাইল আর ফোল্ডার সামলানো — খোঁজা, কপি, সরানো, মোছা

পড়া-লেখার বাইরেও Files অনেক কাজ করে। সবচেয়ে বেশি লাগে এগুলো:

কপি আর সরানোর আচরণ বদলানো হয় StandardCopyOption দিয়ে: Files.copy(a, b, StandardCopyOption.REPLACE_EXISTING). প্রতিটি ব্যর্থতার নিজস্ব exception, সবই IOException-এর subclass. নিচের বার্তাগুলো Java 21-এ চালিয়ে পাওয়া:

নিরাপদে সেভ — temp ফাইলে লিখে এক ধাপে সরানো

হিসাব খাতা সেভ করার মাঝপথে প্রোগ্রাম crash করলে কী হবে? writeString আগে ফাইল খালি করে, তারপর লেখে — মাঝপথে থামলে পুরোনো আর নতুন, কোনো খাতাই থাকবে না। পেশাদার সফটওয়্যার তাই একই ফোল্ডারে একটি অস্থায়ী ফাইলে পুরো লেখা শেষ করে, তারপর Files.move(tmp, khata, StandardCopyOption.REPLACE_EXISTING, StandardCopyOption.ATOMIC_MOVE) দিয়ে এক ধাপে জায়গা বদল করে। অপারেটিং সিস্টেম নিশ্চয়তা দেয়, অন্য কেউ হয় পুরো পুরোনো ফাইল দেখবে, নয়তো পুরো নতুন — অর্ধেক লেখা কখনো নয়। (সব ফাইল-সিস্টেম ATOMIC_MOVE সমর্থন করে না; না পারলে exception আসে।)

সাময়িক কাজের জন্য Files.createTempFile("report", ".csv") অপারেটিং সিস্টেমের temp ফোল্ডারে অনন্য নামে একটি temporary file বানায়, আর Files.createTempDirectory একটি ফোল্ডার। নামটি এলোমেলো, আর কাজ শেষে মোছা আপনার দায়িত্ব।

ফোল্ডারের তালিকা — list, walk আর glob

একটি ফোল্ডারের সরাসরি ভেতরের জিনিস চাইলে Files.list(dir); ভেতরের ফোল্ডারের ভেতরেও, পুরো গাছ ধরে, চাইলে Files.walk(dir). দুটিই Stream<Path> দেয়, আর দুটির পেছনেই খোলা ফোল্ডার — তাই try-with-resources. আরও একটি কথা: ক্রমের কোনো নিশ্চয়তা নেই, অপারেটিং সিস্টেম যেভাবে দেয়। নিয়মিত ক্রম চাইলে sorted().

নাম ধরে ছাঁকতে আছে glob — terminal-এর *.csv-এর মতো সহজ নকশা। Files.newDirectoryStream(dir, "*.csv") একটি DirectoryStream দেয়, যা for-each দিয়ে ঘোরা যায়; পুরো গাছে খুঁজতে Files.walk-এর সাথে একটি PathMatcher:

// শুধু inbox-এর সরাসরি ভেতরের .csv
try (DirectoryStream<Path> ds = Files.newDirectoryStream(inbox, "*.csv")) {
    for (Path p : ds) System.out.println(p.getFileName());
}
// পুরো গাছে, ভেতরের ফোল্ডারসহ — ** ফোল্ডার পার হয়
PathMatcher csv = FileSystems.getDefault().getPathMatcher("glob:**.csv");
try (Stream<Path> all = Files.walk(inbox)) {
    all.filter(csv::matches).sorted().forEach(System.out::println);
}

যাচাই করা ফল: inbox-এ a.csv, b.CSV, c.csv, photo.jpg, notes.txt আর old/d.csv থাকলে প্রথম অংশ দেয় a.csv আর c.csv — b.CSV নয়, কারণ Linux-এ বড়-ছোট হাতের অক্ষর আলাদা ধরা হয় (Windows-এ সাধারণত ধরা হয় না)। দ্বিতীয় অংশ old/d.csv-ও পায়। আর একটি সূক্ষ্মতা: glob:*.{csv,txt} মেলে x.txt-এর সাথে, কিন্তু inbox/x.txt-এর সাথে নয়, কারণ * ফোল্ডারের / পার হয় না। তাই নাম মেলাতে প্রায়ই matcher.matches(p.getFileName()) লেখা হয়।

ফাইলের বৈশিষ্ট্য আর ফোল্ডার পাহারা

ফাইলের বিষয়বস্তুর বাইরের তথ্য — আকার, তৈরি ও বদলের সময়, মালিক, অনুমতি — হলো file attributes. Files.readAttributes(p, BasicFileAttributes.class) একবারে অনেকগুলো দেয়। Linux আর Mac-এ Files.setPosixFilePermissions(p, PosixFilePermissions.fromString("rw-------")) দিয়ে ঠিক করা যায় শুধু মালিক পড়তে-লিখতে পারবেন — গোপন key বা password-এর ফাইলের জন্য জরুরি। Windows-এ POSIX অনুমতি নেই, সেখানে এই method UnsupportedOperationException দেয়।

আর যদি জানতে চান কোনো ফোল্ডারে নতুন ফাইল এলো কি না — যেমন অফিসের স্ক্যানার যে ফোল্ডারে PDF রাখে — তাহলে বারবার ফোল্ডার ঘেঁটে দেখার দরকার নেই। Java 7-এর WatchService একটি ফোল্ডার নিবন্ধন করে রাখে আর তৈরি, বদল বা মোছার ঘটনা জানায়; Linux-এ এটি অপারেটিং সিস্টেমের নিজস্ব ব্যবস্থা (inotify) ব্যবহার করে। সীমা দুটি: শুধু নিবন্ধিত ফোল্ডার দেখে, ভেতরেরগুলো নয়; আর কিছু প্ল্যাটফর্মে ঘটনা জানাতে কয়েক সেকেন্ড দেরি হয়।

৮ · নিরাপত্তা — ব্যবহারকারীর দেওয়া নামে “../” থাকলে

ধরুন একটি অনলাইন দোকানের সার্ভার, যেখানে গ্রাহকেরা নিজেদের রসিদ নামাতে পারেন: /download?file=receipt-1042.pdf. কোড সহজ — uploads ফোল্ডারের সাথে নামটি জুড়ে ফাইল পাঠানো। এখন কেউ যদি নাম দেন ../../etc/passwd? জোড়া লাগালে ঠিকানাটি uploads থেকে দুই ধাপ ওপরে উঠে সার্ভারের সিস্টেম-ফাইলে পৌঁছায়। এই আক্রমণের নাম path traversal, আর এটি ওয়েব নিরাপত্তার সবচেয়ে পুরোনো আর এখনো সাধারণ ভুলগুলোর একটি। ২০১৮ সালে “Zip Slip” নামে একই ভুলের একটি রূপ বহু জনপ্রিয় লাইব্রেরিতে পাওয়া গিয়েছিল: zip ফাইলের ভেতরে ../-ওয়ালা নাম রাখলে খোলার সময় ফাইল ফোল্ডারের বাইরে লেখা হতো।

প্রতিরোধের নিয়ম তিন ধাপের: ভিত্তি-ফোল্ডারকে absolute আর normalize করুন; ব্যবহারকারীর নাম resolve করে আবার normalize করুন; তারপর যাচাই করুন ফলটি এখনো ভিত্তি-ফোল্ডারের ভেতরে কি না। ধাপে ধাপে দেখুন (সার্ভারের ঠিকানা /srv/shop ধরে নেওয়া উদাহরণ; সত্য-মিথ্যা ফলগুলো Java 21-এ যাচাই করা):

1Path base = Path.of("uploads").toAbsolutePath().normalize();2Path target = base.resolve(name).normalize();3if (!target.startsWith(base))4    throw new SecurityException("অনুমতি নেই: " + name);5return target;

আরও দুটি স্তর: ভিত্তির ভেতরে symbolic link থাকলে normalize তা ধরে না — কঠোরতম যাচাই toRealPath(). আর সম্ভব হলে ব্যবহারকারীকে ঠিকানা দিতেই দেবেন না — রসিদের নম্বর নিন, ফাইলের নাম আপনার কোড বানাক।

৯ · AI-এর যুগে — ফাইলের কোড রিভিউ করুন

“একটি CSV পড়ে রিপোর্ট বানাও” বললে AI-এর কোড ছোট নমুনা ফাইলে চলে যায়। সমস্যা লুকিয়ে থাকে নমুনার বাইরে: Windows-এ বাংলা, বড় ফাইল, টানা কয়েক দিন চলা সার্ভার, আর দুষ্ট ব্যবহারকারী। AI প্রশিক্ষিত হয়েছে বিশ বছরের কোডে, যার বড় অংশ java.io-যুগের — তাই new FileReader(...), হাতে জোড়া path আর বন্ধ না করা stream খুবই সাধারণ।

AI-এর কোড হাতে পেলে — যাচাইয়ের চেকলিস্ট

• প্রতিটি পড়া-লেখায় charset স্পষ্ট, অথবা নিশ্চিতভাবে Files-এর UTF-8 ডিফল্ট
• Files.lines/list/walk, reader আর writer — সবই try-with-resources-এ
• বড় হতে পারে এমন ফাইলে readAllLines/readString নেই
• কোথাও String জুড়ে path নেই; Path.of আর resolve
• ব্যবহারকারীর দেওয়া নাম normalize আর startsWith(base) দিয়ে যাচাই করা
• ফাঁকা catch নেই; exists দেখে তারপর কাজ — এমন TOCTOU নেই
• নিজে দুটি পরীক্ষা চালিয়েছি: বাংলা লেখা সহ একটি ফাইল, আর নেই এমন একটি ফাইল