টেক্সট আসলে কী, আর টুলগুলো কেন এ নিয়ে একমত হয় না
একটি টেক্সট ফাইল হলো বাইট আর একটি এনকোডিং, আর এনকোডিংটি ফাইলে সংরক্ষিত থাকে না। একটি নির্দিষ্ট বাইট যে “é” বোঝায়, তা প্রোগ্রামকে প্রথা ছাড়া আর কিছুই বলে দেয় না — এ কারণেই একই ফাইল এক জায়গায় ঠিকঠাক খোলে, আরেক জায়গায় দেখায় “é”। UTF-8 হলো আধুনিক সমাধান: সাধারণ লাতিন অক্ষর রাখে এক বাইটে, অ্যাকসেন্টওয়ালা অক্ষর দুই বাইটে, আর চীনা, জাপানি, আরবির বেশিরভাগ ও প্রতিটি ইমোজি তিন বা চার বাইটে। UTF-16 হলো Windows ও JavaScript ভেতরে যা ব্যবহার করে — প্রায় সবকিছু দুই বাইটে, বাকিটা চার বাইটে। Windows-1252 ও Latin-1 হলো সেই এক-বাইটের এনকোডিং, যা পুরোনো সিস্টেমগুলো এখনো তৈরি করে, আর এলোমেলো অক্ষরের (mojibake) সাধারণ উৎস এগুলোই। এই পেজগুলো সম্পর্কে জেনে রাখা ভালো: CSV ভিউয়ার আপনার দেওয়া ফাইলের এনকোডিং শনাক্ত করে, UTF-16 ও Windows-1252-সহ, এবং আপনাকে তা বদলাতেও দেয়। সাধারণ টেক্সট বক্সগুলো তা করে না — ছেড়ে দেওয়া ফাইল UTF-8 হিসেবে পড়া হয়, তাই Latin-1 এক্সপোর্টের অ্যাকসেন্টওয়ালা অক্ষর ভুল দেখাবে, আর সমাধান হলো আগে সেটি কনভার্ট করে নেওয়া।
“অক্ষর”-এর চারটি অর্থ আছে, আর আপনার কোনটি দরকার তা নির্ভর করে সীমাটা কে বেঁধে দিচ্ছে তার ওপর। মানুষ যাকে একটি অক্ষর হিসেবে দেখে, তা একটি গ্রাফিম ক্লাস্টার। রেগুলার এক্সপ্রেশন যা মেলায়, তা কোড পয়েন্ট। JavaScript-এর string.length যা জানায়, তা UTF-16 ইউনিট। ডেটাবেস কলাম বা HTTP হেডার যা মাপে, তা UTF-8 বাইট। সাধারণ ইংরেজিতে চারটিই মিলে যায়, তাই কেউ খেয়াল করে না — তারপর একটি পরিবারের ইমোজি হয় একটি গ্রাফিম, সাতটি কোড পয়েন্ট, এগারোটি UTF-16 ইউনিট আর পঁচিশটি বাইট, আর ২০০ অক্ষরের একটি মেসেজ ২৫৫ অক্ষরের ফিল্ডে প্রত্যাখ্যাত হয়। ঠিক এই কারণেই অক্ষর গণনা চারটিই দেখায়।
অদৃশ্য অক্ষরও আসল অক্ষর। নন-ব্রেকিং স্পেস দেখতে সাধারণ স্পেসের মতোই, অথচ সম্পূর্ণ আলাদা একটি অক্ষর — ওয়েব পেজ বা ওয়ার্ড প্রসেসর থেকে কপি করা লেখায় এটি হরদম আসে, আর সার্চ, CSV পার্সিং ও স্পেস ধরে ভাগ করা কোড ভেঙে দেয়। জিরো-উইডথ জয়নারই কয়েকজন মানুষের একটি ইমোজিকে একসাথে ধরে রাখে। সফট হাইফেন, দিক-নির্দেশক চিহ্ন আর বাইট-অর্ডার মার্ক — সবই পেস্ট করা লেখার সঙ্গে চলে আসে। এগুলোর কোনোটিই স্ক্রিনে দেখা যায় না, তাই একমাত্র সংকেত হলো এমন একটি গণনা, যা আপনার চোখে দেখা লেখার সঙ্গে মেলে না — অক্ষর গণনার একটি সৎ ব্যবহার এটাই। মনে রাখবেন, টেক্সট তুলনার স্পেসিং উপেক্ষার অপশন সাধারণ স্পেস ও ট্যাবকে এক করে দেখে; নন-ব্রেকিং স্পেসকে স্পেস হিসেবে ধরে না, কারণ এ দুটি এক জিনিস নয়।
লাইন এন্ডিংই কারণ, যে জন্য ডিফ কখনো কখনো প্রতিটি লাইনকে বদলানো দেখায়। Windows লাইন শেষ করে ক্যারেজ রিটার্ন ও লাইন ফিড দিয়ে; বাকি সবাই শুধু লাইন ফিড দিয়ে। Windows-এর কোনো এডিটর থেকে একটি LF ফাইল সেভ করলে এর প্রতিটি লাইনে একটি অদৃশ্য বাইটের পার্থক্য তৈরি হয়, ফলে বাইট-পর্যায়ের তুলনা — git diff, diff(1) — পুরো ফাইলটিকে নতুন করে লেখা বলে দেখায়, আর আপনার আসল একটি পরিবর্তনটি চাপা পড়ে যায়। আমাদের টেক্সট তুলনা ও ডুপ্লিকেট লাইন রিমুভ তুলনার আগে তিনটি প্রথাতেই লাইন ভাগ করে, তাই শুধু লাইন এন্ডিং বদলানো একটি ফাইল এখানে লাল রঙের দেয়াল হয়ে দেখা দেয় না। পড়ার টুলে এটা সুবিধা, আর রিপোজিটরিতে ফাঁদ: উৎসেই ঠিক করুন, আপনার এডিটর বা git-এর নিজস্ব লাইন-এন্ডিং সেটিংস দিয়ে।
হুবহু একই রকম দেখতে দুটি স্ট্রিং তুলনায় আলাদা হতে পারে, আর সাধারণত এর কারণ নরমালাইজেশন। Unicode “é” দুইভাবে লিখতে পারে: একটি কোড পয়েন্ট হিসেবে, অথবা একটি সাধারণ “e”-র পরে একটি কম্বাইনিং অ্যাকিউট অ্যাকসেন্ট হিসেবে। দেখতে একই, কিন্তু বাইটের ক্রম আলাদা, তাই তুলনা, ডুপ্লিকেট সরানো বা ডেটাবেস লুকআপ এগুলোকে দুটি আলাদা মান হিসেবে ধরে। ফাইলের নামে কোন রূপ ব্যবহার হবে, তা নিয়ে macOS ও Windows ঐতিহাসিকভাবে একমত নয় — এভাবেই দুটি মেশিন থেকে জোগাড় করা একটি তালিকায় এমন কিছু দেখা যায় যা হুবহু ডুপ্লিকেট মনে হয়, অথচ ডুপ্লিকেট হিসেবে সরে না। অক্ষর গণনা দিয়েই আপনি এটা ধরতে পারেন — দুই রূপের গ্রাফিম সংখ্যা একই, কোড পয়েন্ট সংখ্যা আলাদা। এই টুলগুলোর কোনোটিই এক রূপ থেকে আরেক রূপে বদলায় না; সেটি Unicode লাইব্রেরিসহ একটি স্ক্রিপ্টের এক লাইনের কাজ, যেমন Python-এর unicodedata.normalize।
“শব্দ গণনা” একটি বিচার, মাপ নয়। স্পেস ধরে ভাগ করা একটি ইংরেজি নিয়ম, আর চীনা, জাপানি বা থাই ভাষায় — যেখানে শব্দের মাঝে স্পেস থাকে না — এটি প্রয়োগ করলে একটি দীর্ঘ লেখাকে একটি শব্দ বলে জানায়। আমাদের কাউন্টার তার বদলে ব্রাউজারের Unicode ওয়ার্ড সেগমেন্টেশন ব্যবহার করে, যা প্রতিটি লিপিতে শব্দ কোথায় শুরু হয় তা জানে। বাকি মতভেদগুলো হাইফেন নিয়ে (“well-known” এখানে ও Word-এ একটি শব্দ, কিছু টুলে দুটি), একা দাঁড়ানো সংখ্যা নিয়ে, আর বাক্য কাকে বলে তা নিয়ে — “We met Dr. Smith” একটি বাক্য, অথচ সরল একটি বিভাজক বলে দুটি। পড়ার সময় তার ওপর আরেকটি অনুমান: নীরবে পড়ার জন্য মিনিটে ২৩৮ শব্দ, একটি মেটা-অ্যানালাইসিস থেকে নেওয়া, ব্লগ পোস্ট থেকে ব্লগ পোস্টে কপি হওয়া গোল সংখ্যা থেকে নয়।
যেখানে ব্রাউজার সত্যিই ভুল টুল
এই মডিউলের কিছুই কখনো পাঠানো বা সংরক্ষণ করা হয় না, আর এ কারণেই অপ্রকাশিত খসড়া বা মালিকানাধীন সোর্স কোড এখানে পেস্ট করা নিরাপদ। সীমাটাও এখান থেকেই আসে, আর মাঝপথে আপনি টের পাওয়ার চেয়ে আমরা আগেই বলে দেওয়া ভালো মনে করি সীমাটা কোথায়।
বড় ফাইল। পুরো লেখা ট্যাবের মেমোরিতে রাখা হয় এবং টাইপ করার সঙ্গে সঙ্গে আবার পরীক্ষা করা হয়। কয়েক মেগাবাইট স্বচ্ছন্দে চলে; কয়েকশো মেগাবাইটের লগ ফাইল চলে না, আর ল্যাপটপের আগেই ফোন হাল ছেড়ে দেয়। কমান্ড লাইনে এই সমস্যা নেই, কারণ সেটি স্ট্রিম করে: grep ও ripgrep আপনার মেমোরির চেয়ে বড় ফাইলেও খোঁজে, sed ও awk লাইন ধরে ধরে বদলায়, আর unique ফ্ল্যাগসহ sort ডিস্কে ঢেলে দিয়ে কয়েক কোটি লাইনের তালিকা থেকেও ডুপ্লিকেট সরায়। এগুলোর সবই বিনামূল্যে এবং macOS ও Linux-এ আগে থেকেই ইনস্টল করা থাকে।
খুব আলাদা দুটি ডকুমেন্ট। টেক্সট তুলনা ৮,০০০ পার্থক্যে থেমে যায়, কারণ এর পরে অ্যালগরিদমের মেমোরি খরচ এত দ্রুত বাড়ে যে ট্যাব জমে যায়, আর এত বড় ডিফ এমনিতেও পড়া যায় না। একই ডকুমেন্টের দুটি সংস্করণ প্রায় কখনোই সেখানে পৌঁছায় না; সম্পর্কহীন দুটি ডকুমেন্ট সঙ্গে সঙ্গেই পৌঁছে যায়। কোড রিভিউয়ের জন্য diff ও git diff যেকোনো সাইজ সামলায়, আর একটি ভালো থ্রি-ওয়ে মার্জ টুল এমন কাজ করে, যা এই পেজ একেবারেই পারে না।
এনকোডিং বদলানো, বা Unicode নরমালাইজ করা। এই পেজগুলো পড়ে ও জানায়; এক এনকোডিং থেকে আরেকটিতে কনভার্ট করে না। iconv সব এনকোডিংয়ের মধ্যে কনভার্ট করে, file কমান্ড অনুমান করে আপনার কাছে কী আছে, আর Unicode নরমালাইজেশন হলো Python-এর এক লাইন বা ICU-র uconv-এর একটি কল। এলোমেলো অক্ষরে ভরা এক্সপোর্ট ঠিক করতে চাইলে এগুলোই আপনার টুলসেট।
বারবার করার মতো যেকোনো কাজ। এই টুলগুলো চলে কেউ ক্লিক করলে। চারশো ডকুমেন্টে শব্দ গোনা, বা প্রতিটি কমিটে একটি ডিরেক্টরি মিনিফাই করা — এটা স্ক্রিপ্ট বা বিল্ড ধাপের কাজ; আর বিশেষ করে মিনিফাই করার ক্ষেত্রে আপনার বিল্ড টুল একই মিনিফাই করে, সঙ্গে দেয় সোর্স ম্যাপ, ওয়াচ মোড আর ক্যাশিং, যা একটি পেস্ট বক্স দিতে পারে না। এই পেজ আপনার সামনে থাকা একটি ফাইলের জন্য।
আধুনিক CSS। CSS মিনিফায়ার নেটিভ নেস্টিং ও আধুনিক মিডিয়া রেঞ্জ সিনট্যাক্স মিনিফাই না করে প্রত্যাখ্যান করে, কারণ এর পেছনের মিনিফায়ারটি এ দুটির আগের, আর যা বোঝে না তা নিঃশব্দে মুছে ফেলে। এটা কোনো ফিচার নয়, বরং সৎ প্রত্যাখ্যান, আর সমাধান হলো আগে Sass, PostCSS বা Lightning CSS দিয়ে নেস্টিং কম্পাইল করে সরিয়ে ফেলা — যা আপনার বিল্ড টুল প্রায় নিশ্চিতভাবেই আগে থেকে করছে।
একই রকম শোনায় এমন টুলগুলোর মধ্যে বাছাই
শব্দ গণনা (ওয়ার্ড কাউন্টার) বনাম অক্ষর গণনা (ক্যারেক্টার কাউন্টার)। একই গণনা, আলাদা প্রধান সংখ্যা। শব্দ গণনা শুরুতে দেখায় শব্দ, বাক্য, অনুচ্ছেদ আর পড়ার সময় — প্রবন্ধ, আর্টিকেল বা বক্তৃতা এগুলো দিয়েই মাপা হয়। অক্ষর গণনা শুরুতে দেখায় অক্ষর, স্পেস ছাড়া অক্ষর আর UTF-8 বাইট — মেটা ডেসক্রিপশন, SMS সেগমেন্ট বা ডেটাবেস ফিল্ড এগুলো দিয়েই মাপা হয়। কোনো কিছু যদি অতিরিক্ত দীর্ঘ বলে আপনার লেখা প্রত্যাখ্যান করে থাকে, আপনার দরকার অক্ষর গণনা, বিশেষ করে এর বাইট সংখ্যা।
টেক্সট তুলনা বনাম ডুপ্লিকেট লাইন রিমুভ। তুলনা উত্তর দেয় “এই দুই সংস্করণের মধ্যে কী বদলেছে”, আর এর জন্য দুটি লেখা লাগে। ডুপ্লিকেট রিমুভার একটি তালিকায় কাজ করে এবং উত্তর দেয় “এখানে কী একাধিকবার আছে”; এটি আরও জানাতে পারে কোন এন্ট্রিগুলো কতবার পুনরাবৃত্ত হয়েছে, স্বাভাবিক ক্রমে সাজাতে পারে যাতে item2 আসে item10-এর আগে, অথবা শুধু ঠিক একবার আসা লাইনগুলো রাখতে পারে। দুটি তালিকার একটিতে কেবল যে এন্ট্রিগুলো আছে, সেগুলো খুঁজে বের করা ডুপ্লিকেট রিমুভারের কাজ, তুলনাকারীর নয়।
HTML মিনিফায়ার বনাম CSS মিনিফায়ার বনাম JavaScript মিনিফায়ার। তিনটি ভাষা, তিনটি মিনিফায়ার, আর একটি ওভারল্যাপ যা জেনে রাখা ভালো: HTML মিনিফায়ার style ব্লকের ভেতরের CSS আর script ব্লকের ভেতরের JavaScript-ও মিনিফাই করে, অন্য দুটি পেজের মতো একইভাবে। তাই একটি HTML ফাইলের জন্য একটি টুলই যথেষ্ট, তিনটি নয়। আলাদা .css ও .js ফাইলের জন্য তাদের নিজস্ব পেজ লাগবে।
XML ভিউয়ার বনাম XML ফরম্যাটার ও XML ভ্যালিডেটর। এখানকার ভিউয়ার ঘুরে দেখার জন্য একটি ভাঁজ করা যায় এমন ট্রি দেয় — ডকুমেন্ট বড় হলে আর কিছু খুঁজতে থাকলে এটাই চাই। ডেভেলপার টুলসের ফরম্যাটার ও ভ্যালিডেটর দেয় ফাইলে আবার পেস্ট করার মতো ইনডেন্ট করা টেক্সট, আর কোথায় ভেঙেছে তার সঠিক লাইন ও কলাম। একদিকে পড়া, অন্যদিকে এডিট ও ঠিক করা।
CSV ভিউয়ার বনাম Excel-এ ফাইল খোলা। প্রতিদ্বন্দ্বী টুল নয়, কিন্তু মানুষ আসলে এই তুলনাটাই করেন। Excel খোলার সময়ই কনভার্ট করে ফেলে, জিজ্ঞেসও করে না: 00123 প্রোডাক্ট কোড হয়ে যায় 123, 5-3 পার্ট নম্বর হয়ে যায় ৫ মার্চ, লম্বা অর্ডার নম্বর হয়ে যায় বৈজ্ঞানিক স্বরলিপি, আর জার্মান কোনো সিস্টেমের সেমিকোলন-বিভক্ত এক্সপোর্ট পুরোটাই গিয়ে পড়ে কলাম A-তে। ভিউয়ার প্রতিটি মান টেক্সট হিসেবে দেখায়, ঠিক যেভাবে সংরক্ষিত, যাতে আপনাকে আসলে কী পাঠানো হয়েছে তা দেখতে পান।
Markdown প্রিভিউ বনাম Markdown থেকে PDF। প্রিভিউ হলো একটি README GitHub যেভাবে দেখাবে সেভাবেই দেখাচ্ছে কি না, টাইপ করতে করতে সরাসরি যাচাই করার জন্য। ডকুমেন্ট টুলসের Markdown থেকে PDF হলো পেজ ব্রেকসহ একটি সম্পূর্ণ ডকুমেন্ট তৈরির জন্য। এখানে যাচাই, ওখানে প্রকাশ।