ভূমিকা

এই টুল বানানোর কারণ খুব সরল। প্রতি বার হাত দিয়ে একই কাজ করা ভীষণ কষ্টকর হয়ে যাচ্ছিল।

internal system থেকে আসা CSV, Excel থেকে রূপান্তর করা CSV, Linux/Windows/DB থেকে বের হওয়া config file—উৎস বদলালেই encoding, line ending, BOM-এর অবস্থা বদলে যায়।

  • UTF-8 ভেবেছিলাম, আসলে Shift_JIS
  • LF ভেবেছিলাম, আসলে CRLF
  • কিছু সিস্টেম BOM চাই, কিছু সিস্টেম BOM দেখলেই ভেঙে যায়

মানুষের চোখ আর আন্দাজ দিয়ে বারবার যাচাই-রূপান্তর করা স্কেল করে না। তাই এমন টুল বানালাম যা যেকোনো উৎসের ফাইল নেয়, আর destination import requirement অনুযায়ী output ঠিক করে দেয়।

আসল সমস্যা একবারের mojibake নয়

একটা ফাইল নষ্ট হলে সাধারণত সামলে নেওয়া যায়। কঠিন হয় যখন ১০টা, ১০০টা ফাইল একসঙ্গে আসে—এবং উৎস আলাদা আলাদা।

আরও কঠিন বিষয়: প্রতিটি import system-এর “সঠিক” ফরম্যাট এক নয়।

  • System A: শুধু UTF-8 (BOM ছাড়া)
  • System B: UTF-8 (BOMসহ) এ বেশি স্থিতিশীল
  • System C: Shift_JIS ধরে; UTF-8 পড়া গেলেও import fail করে

এখানে “সব UTF-8 করে দাও” ধরনের সাধারণ উপদেশ কাজ করে না। দরকার গন্তব্যভিত্তিক, নিরাপদ, repeatable অপারেশন।

এই টুল দিয়ে আমি কী চাইছিলাম

মূলনীতি মাত্র তিনটি:

  1. যেকোনো উৎস গ্রহণ করা
  2. destination requirement অনুযায়ী convert করা
  3. batch processing-এ incident না বাড়ানো

এটা conversion কৌশল দেখানোর টুল নয়; অপারেশনাল friction কমানোর টুল।

আমি বাস্তবে যে ধাপ অনুসরণ করি

1. আগে output specification স্থির করুন

ইনপুট নয়, আউটপুট আগে ঠিক করুন। এই ৩টি জিনিস লক করুন:

  • Encoding (UTF-8 / Shift_JIS ইত্যাদি)
  • Line ending (LF / CRLF)
  • BOM (with / without)

এখানে অস্পষ্টতা থাকলে operator বদলালেই ফল বদলে যাবে।

2. conversion target ছোট ভাগে ভাগ করুন

শুরুতেই সব ফাইল একসঙ্গে চালাবেন না। System, period, file type অনুযায়ী ভাগ করে ছোট batch দিয়ে শুরু করুন।

কারণ সহজ: failure হলে rollback করা যায়। Full-volume one-shot সফল হলে দ্রুত, ব্যর্থ হলে বড় ক্ষতি।

3. condition ফিক্স করে bulk conversion চালান

Character Encoding Converter এ ব্যবহারভিত্তিক condition স্থির করুন। মাঝপথে setting বদলাবেন না। একই condition বারবার চালানো যায়—এটাই গুরুত্বপূর্ণ।

4. শুধু চোখে দেখে success ধরবেন না

“ফাইল খুলছে, তাই ঠিক আছে”—এটাই incident-এর শুরু হতে পারে। কমপক্ষে যাচাই করুন:

  • আগে-পরে row count একই কি না
  • CSV/TSV column count ভেঙেছে কি না
  • � (replacement character) বেড়েছে কি না
  • key column (ID/code)-এর length ও character type বজায় আছে কি না

যাচাই পাস না করলে import-এ যাবেন না।

BOM মতবাদ নয়; counterpart requirement

BOM নিয়ে তর্ক মাঠের কাজে খুব কাজে লাগে না। মূল বিষয় একটাই: counterpart system কীভাবে ফাইল গ্রহণ করে।

  • counterpart BOM সহ স্থিতিশীল হলে BOM দিন
  • counterpart BOM এ ভেঙে গেলে BOM ছাড়া দিন

“তাত্ত্বিকভাবে সঠিক” ফরম্যাটের চেয়ে “counterpart ভাঙে না”—এটাই অগ্রাধিকার। অপারেশন বাস্তবে এমনই।

এই টুলের আসল মূল্য শুধু conversion নয়

আসল মূল্য দুইটি:

  • ব্যক্তিভেদে সিদ্ধান্ত বদলে যায় না
  • বারবার verification খরচ কমে

Encoding incident একেবারে শূন্যে নামানো যায় না। কিন্তু একই ভুল বারবার হওয়া বন্ধ করা যায়। সেই লক্ষ্যেই এমন টুল করেছি যা সব গ্রহণ করে, ব্যবহারের প্রয়োজনে ঠিক করে ফেরত দেয়।

উপসংহার

এই টুল আদর্শ তত্ত্ব থেকে আসেনি। বাস্তব কাজে বারবার হওয়া ক্লান্তিকর encoding adjustment বন্ধ করার জন্যই এসেছে।

বিভিন্ন উৎসের ফাইল নিয়ে, destination requirement অনুযায়ী encoding/line ending/BOM মিলিয়ে, একরকম output ফেরত দেয়। শুধু এই flow automate করলেই অপারেশন অনেক সহজ হয়।

Mojibake সামলানো ইচ্ছাশক্তির পরীক্ষা নয়। এটাকে reproducible procedure-এ নামাতে হবে, যাতে যে-ই করুক একই ফল পায়। তবেই বলা যাবে—bulk recovery নিরাপদ।