ডেটা কনভার্টার

CSV, JSON, YAML, আর XML-এর মধ্যে ডেটা সরানো

ডেটা খুব কমই একটা ফরম্যাটে স্থির থাকে। একটা রিপোর্ট আসে স্প্রেডশিট হিসেবে, একটা API চায় JSON, একটা ডিপ্লয়মেন্ট পাইপলাইন YAML প্রত্যাশা করে, আর কোথাও নিচতলায় একটা লেগ্যাসি সেবা এখনও XML বলে। ডেটা নিয়ে দৈনন্দিন কাজের বেশিরভাগ ঘর্ষণ ডেটাটা নিজে নয়, এটাকে আপনার কাছে থাকা আকৃতি থেকে অন্য কিছুর চাহিদামতো আকৃতিতে নিয়ে যাওয়া। এটাই একটা ডেটা কনভার্টারের পুরো কাজ: এক নোটেশনে কাঠামোবদ্ধ টেক্সট নিয়ে অর্থ না হারিয়ে অন্য নোটেশনে আবার প্রকাশ করা।

Speedor-এর কনভার্টার পুরোপুরি আপনার ব্রাউজারে চলে। আপনি পেস্ট করেন, ক্লিক করেন, ফলাফল কপি করেন। কিছুই আপলোড হয় না, লগ হয় না, আর আপনার মেশিন ছেড়ে যায় না। যে কেউ কখনো একটা গ্রাহক এক্সপোর্ট কোনো এলোমেলো ওয়েবসাইটে ফেলার আগে দ্বিধায় পড়েছেন, তার জন্য সেই শুধু-স্থানীয় ডিজাইনটাই আসল কথা।

প্রতিটা ফরম্যাট আসলে কীসে ভালো

বদল করা শুরু করার আগে এই ফরম্যাটগুলো কেন আছে তা জানা সাহায্য করে, কারণ প্রতিটা আলাদা একটা কাজের জন্য বানানো হয়েছিল।

CSV হলো সমতল, কমা দিয়ে আলাদা করা গ্রিড যা স্প্রেডশিট পছন্দ করে। এটা স্বভাবতই সারণীভিত্তিক: সারি আর কলাম, কোনো নেস্টিং নেই। Excel, Google Sheets, বা Numbers-এ খুলুন আর এটা এমনিই কাজ করে। সমস্যা হলো CSV-তে টাইপের কোনো ধারণা নেই। 007 মানটা একটা স্ট্রিং, একটা সংখ্যা, বা একটা জিপ কোড হতে পারে, আর CSV আপনাকে বলবে না কোনটা।

JSON হলো আধুনিক ওয়েবের সাধারণ ভাষা। আপনি যত API কল করবেন প্রায় সবই এটা বলে। JSON নেস্টিং, অ্যারে, আর কয়েকটা আসল টাইপ (স্ট্রিং, সংখ্যা, বুলিয়ান, নাল) সামলায়, যা এটাকে একটা সমতল টেবিলের চেয়ে অনেক বেশি প্রকাশক্ষম করে তোলে। এটা কম্প্যাক্ট, মেশিন-বান্ধব, আর সবখানে সমর্থিত।

YAML হলো JSON-এর পড়ার-সহজ চাচাতো ভাই। এটা বন্ধনীর বদলে ইনডেন্টেশন ব্যবহার করে, মন্তব্য সমর্থন করে, আর কনফিগারেশন ফাইল, Docker Compose, Kubernetes ম্যানিফেস্ট, আর CI পাইপলাইনের জন্য পছন্দের ফরম্যাট হয়ে থাকে। যখন একজন মানুষকে হাতে কিছু এডিট করতে হয়, YAML সাধারণত চোখের জন্য বেশি সদয়।

XML হলো বয়োজ্যেষ্ঠ। শব্দবহুল, ট্যাগ-ভারী, আর এখনও এন্টারপ্রাইজ সিস্টেম, SOAP সেবা, আর্থিক বার্তা, আর RSS-এর মতো ডকুমেন্ট স্ট্যান্ডার্ডে গভীরভাবে প্রোথিত। নতুন প্রজেক্টে আপনি এটার সাথে কম দেখা করবেন, কিন্তু যখন দরকার হয়, সত্যিই দরকার হয়।

রূপান্তর আসলে কোথায় ঘটে

দৃশ্যগুলো একবার দেখতে শুরু করলে বেশ নির্দিষ্ট মনে হয়। ধরুন মার্কেটিং আপনাকে ৪,০০০ কন্টাক্টের একটা স্প্রেডশিট দেয় আর সাইনআপ API শুধু একটা JSON অ্যারে গ্রহণ করে। আপনি শিটটা CSV-তে এক্সপোর্ট করেন, CSV থেকে JSON-এর মধ্য দিয়ে চালান, আর আপনার POST করার জন্য একটা পেলোড প্রস্তুত হয়ে যায়। কোনো গ্লু স্ক্রিপ্ট নেই, pandas নেই, ইঞ্জিনিয়ারের জন্য অপেক্ষা নেই।

অথবা আপনি সেই একই API থেকে একগুচ্ছ JSON টেনে আনেন আর সেটা আপনার সার্ভিস স্টার্টআপে যে কনফিগ ফাইল পড়ে সেখানে রাখতে চান। JSON থেকে YAML দিয়ে রূপান্তর করুন আর আপনি এমন কিছু পাবেন যা পরিষ্কার, মন্তব্যযোগ্য, আর আপনার রিপোতে ঠিকঠাক বসে যায়। উলটোদিকেও কাজ করে যখন একটা টুল শুধু JSON গ্রহণ করে কিন্তু আপনার কনফিগ YAML-এ থাকে।

আর তারপর আছে সেই ইন্টিগ্রেশন যা কেউ উপভোগ করে না: একটা পার্টনার সিস্টেম যা শুধু XML গ্রহণ করে। আপনি আপনার পেলোড JSON-এ বানান কারণ আপনার অ্যাপ সেভাবেই ভাবে, তারপর সীমানায় XML-এ রূপান্তর করেন। আকৃতি একই থাকে, শুধু সিনট্যাক্স বদলায়।

জানার মতো সমস্যাগুলো

ফরম্যাট রূপান্তর সবসময় লসলেস নয়, আর বিপরীত ভান করলে বাগ তৈরি হয়। মনে রাখার মতো কিছু জিনিস:

CSV টাইপ ভুলে যায়। প্রতিটা সেল শুধু টেক্সট বলে, সংখ্যা, বুলিয়ান, আর তারিখ সবই স্ট্রিং হিসেবে বের হয়, যদি না কনভার্টার আপনার জন্য অনুমান করে। true-কে "true" শব্দ না হয়ে বুলিয়ান হতে হলে, পাঠানোর আগে আউটপুট যাচাই করুন।

YAML হোয়াইটস্পেস নিয়ে সচেতন। YAML-এ ইনডেন্টেশন কোনো প্রসাধনী নয়, এটা কাঠামোগত। একটা ছুটকো স্পেস কোন কী কোন ভ্যালুর অংশ তা বদলে দিতে পারে, আর ট্যাব সম্পূর্ণ নিষিদ্ধ। যেকোনো JSON থেকে YAML রাউন্ড-ট্রিপের পর, একটা দ্রুত চোখ বুলিয়ে নেওয়া, অথবা কাঠামো টিকে আছে কিনা নিশ্চিত করতে ফলাফলটা একটা JSON ফরম্যাটার-এর মধ্য দিয়ে আবার চালানো ভালো।

XML আর JSON পরিষ্কারভাবে মেলে না। JSON-এর অ্যারে আছে; XML-এর পুনরাবৃত্ত এলিমেন্ট আছে। JSON-এর কোথাও অ্যাট্রিবিউট নেই; XML-এর সবখানে আছে। বেশিরভাগ কনভার্টার একটা যুক্তিসঙ্গত কনভেনশন বাছাই করে, কিন্তু আপনার XML যদি অ্যাট্রিবিউট বেশি ব্যবহার করে, তাহলে এটা যে JSON তৈরি করবে তা হাতে-লেখা JSON-এর চেয়ে একটু আলাদা দেখাবে। এটা প্রত্যাশিত, কোনো ত্রুটি নয়।

নেস্টিং গভীরতা গুরুত্বপূর্ণ। CSV সমতল বলে, গভীরভাবে নেস্ট করা JSON কী ফ্ল্যাটেন না করে সবসময় কলামে সংকুচিত হতে পারে না (মনে করুন address.city)। উলটোদিকে গেলে, একটা সমতল CSV একটা সমতল অ্যারে হয়, কখনো একটা ট্রি নয়।

এখানে শুধু-স্থানীয় কেন গুরুত্বপূর্ণ

আপনি যে অনেক ডেটা রূপান্তর করতে চাইবেন তা শেয়ার করার মতো আপনার নিজের নয়। গ্রাহক রেকর্ড, অভ্যন্তরীণ কনফিগ, একটা রেসপন্সে পোঁতা API কী, আর্থিক সারি। প্রচুর অনলাইন কনভার্টার চুপচাপ আপনার পেস্ট একটা সার্ভারে পাঠিয়ে কাজটা করে। Speedor তা করে না। রূপান্তরের যুক্তি আপনার ব্রাউজার ট্যাবেই চলে, ডেটা কখনো নেটওয়ার্ক পার হয় না, আর ট্যাব বন্ধ করাই যথেষ্ট পরিষ্কার-পরিচ্ছন্নতা। এটা দ্রুতও, কারণ কোনো আপলোড রাউন্ড-ট্রিপ নেই, আর পেজ একবার লোড হয়ে গেলে এটা অফলাইনেও কাজ করে। বিনামূল্যে, সাইনআপ নেই, কোটা নেই।

প্রায়শই জিজ্ঞাসিত প্রশ্ন