JSON, TOML, YAML বা CSON: কনফিগারেশন ফরম্যাট বাছাই

মূল কথা: মেশিন বিনিময়ের জন্য JSON ব্যবহার করুন, আর মানুষের রক্ষণাবেক্ষণ করা কনফিগারেশনের জন্য ইকোসিস্টেম অনুযায়ী TOML বা YAML বেছে নিন (Kubernetes ও CI-তে YAML, সমতল কাঠামো বা নেটিভ তারিখে TOML); পাঠক ডায়ালেক্ট সমর্থন করে কি না নিশ্চিত না হলে JSONC-তে ফিরুন।

JSON আছে মেশিনের ডেটা বিনিময়ের জন্য; কনফিগারেশন ফাইল মানুষ মানুষের জন্য লেখে। দুইটিকে গুলিয়ে ফেললে আপনি পাবেন এমন config.json যা কমেন্ট ধরে না, আর যাকে ছাঁটতে কেউ সাহস করে না।

১. শুরু করুন দুই ভিন্ন ধরনের ফাইল থেকে

ডেটা বিনিময় ও কনফিগারেশন — একই মানুষ একই মেশিনে দুটোই লিখলেও লক্ষ্য এক নয়।

JSON বাঁ-দিকের কলামে প্রায় নিখুঁত স্কোর করে: ন্যূনতম ব্যাকরণ, প্রতিটি ভাষায় পার্সার, আর কমেন্ট না থাকায় "কমেন্ট মান থেকে সরে যাওয়া" সমস্যা নেই। ডান-দিকের কলামে তার কঠোরতা নিছক ঘর্ষণ: কমেন্ট নেই, ট্রেইলিং কমা নেই, তারিখ নেই, আর মাল্টি-লাইন টেক্সট \n দিয়ে এক লাইনে চেপে ফেলতে হয়।

২. চার প্রতিদ্বন্দ্বী ও তাদের সিনট্যাক্স

• JSON: RFC 8259 ও ECMA-404 দ্বারা সংজ্ঞায়িত, ঠিক ছয়টি ভ্যালু টাইপ: অবজেক্ট, অ্যারে, স্ট্রিং, সংখ্যা, বুলিয়ান ও null। এটি বাস্তব বিনিময় মান এবং একমাত্র ফরম্যাট যার জন্য কোনো নির্বাচন-সিদ্ধান্ত লাগে না।
• TOML: টম প্রেস্টন-ভার্নার তৈরি, v1.0.0 প্রকাশিত জানুয়ারি ২০২১-এ। এর ঘোষিত লক্ষ্য হলো স্পষ্ট অর্থসহ ন্যূনতম কনফিগারেশন ফরম্যাট যা হ্যাশ টেবিলে দ্ব্যর্থতিহীনভাবে মেলে। Cargo.toml ও pyproject.toml ডিফল্টভাবে এটি ব্যবহার করে।
• YAML: বর্তমান স্পেসিফিকেশন 1.2.2। ইনডেন্টেশন শ্রেণিবিন্যাস প্রকাশ করে, আর এটি কমেন্ট, অ্যাঙ্কর ও একাধিক ডকুমেন্ট সমর্থন করে। Kubernetes ম্যানিফেস্ট, GitHub Actions ও Ansible সবই এর উপর নির্ভর করে, দাম হিসেবে বড় স্পেসিফিকেশন ও বাস্তবায়নের পার্থক্য।
• CSON: CoffeeScript Object Notation, যা CoffeeScript অবজেক্ট লিটেরাল দিয়ে কনফিগারেশন লেখে। Atom-এর config.cson এটি ব্যবহার করত। এটি কমেন্ট, আনকোয়োটেড কি ও ট্রেইলিং কমা সমর্থন করে, তবে এর ইকোসিস্টেম কখনো JavaScript জগতের বাইরে যায়নি।

২.১ সক্ষমতা তুলনা

দুটি সেল নোটের যোগ্য। TOML-এ null নেই, যা JSON থেকে রূপান্তরে সবচেয়ে সাধারণ ব্যর্থতা। YAML-এর "নেটিভ তারিখ" আচরণ মানে ১.১ পার্সার 2026-10-31-কে স্বয়ংক্রিয়ভাবে ডেট অবজেক্টে বদলায়, ফলে ভাষাভেদে টাইপ সরে যায়।

৩. কমেন্ট: JSON-এর একমাত্র দুর্বলতা

আগে সিদ্ধান্ত: যদি মানুষ ফাইলটি রক্ষণাবেক্ষণ করে এবং একটি মান কী তাই তা ব্যাখ্যা করতে হয়, স্ট্যান্ডার্ড JSON ব্যবহার করবেন না।

চারটি বাস্তব পথ আছে, আক্রমণাত্মকতার ক্রমে:

1. JSONC-তে যান, যা স্ট্যান্ডার্ড JSON প্লাস কমেন্ট ও ট্রেইলিং কমা। VS Code-এর settings.json ও tsconfig.json এটি ব্যবহার করে। দাম হলো পাঠককে jsonc-parser-এর মতো কমেন্ট-সচেতন পার্সার ব্যবহার করতে হবে; সাধারণ JSON.parse ব্যর্থ হয়। বিস্তারিত JSON5 ও JSONC: কমেন্টসহ JSON-এ।
2. সাইডকার ডকুমেন্ট রাখুন। config.json মেশিন-পাঠযোগ্য থাকে, আর config.md ব্যাখ্যা করে প্রতিটি ফিল্ডের অর্থ কী এবং কেন ওই মান। দুটোই একই ডিরেক্টরিতে থাকে ও একই কমিটে বদলায়।
3. ব্যাখ্যা স্কিমায় রাখুন। JSON Schema-র description ও $comment কি-ওয়ার্ড ফিল্ড ডকুমেন্ট করতে পারে, তবে স্কিমা সাধারণত রানটাইম কনফিগারেশনের সঙ্গে যায় না, তাই কনফিগ পড়া মানুষ সেগুলো কখনো দেখে না।
4. TOML বা YAML-এ যান, ফরম্যাটকেই কমেন্ট দিতে দিন যা প্রতিটি পার্সার বোঝে।

复制{
  // Fixed at 8080: the frontend build script reads this port for its proxy
  "port": 8080,
  // Disable watching to avoid exhausting inodes in CI
  "watch": false
}

JSONC এখনও একটি ডায়ালেক্ট: এক্সটেনশন .json থাকে, অথচ কেবল কিছু টুল এটি বোঝে। ডেটা দল ছাড়লে বা সার্ভিস সীমানা পার হলে JSONC ও স্ট্যান্ডার্ড JSON-এর মধ্যকার রেখা ডকুমেন্ট করতে হবে।

৪. তারিখ ও মাল্টি-লাইন স্ট্রিং: TOML-এর নিজের মাঠ

TOML তারিখ-সময়কে প্রথম-শ্রেণির টাইপে উন্নীত করে, চারটি রূপে: অফসেট তারিখ-সময়, লোকাল তারিখ-সময়, লোকাল তারিখ ও লোকাল সময়। মাল্টি-লাইন স্ট্রিংয়ের আছে নিবেদিত সিনট্যাক্স যা লাইন ব্রেক সংরক্ষণ করে:

复制title = "json-toolkit"
created = 2026-10-31T09:00:00+08:00
description = """
A JSON toolkit for developers.
Every operation runs locally in the browser.
"""

JSON-এ একই তথ্য তারিখকে স্ট্রিং-এ নামিয়ে লাইন ব্রেক এস্কেপ করতে হয়:

复制{
  "title": "json-toolkit",
  "created": "2026-10-31T09:00:00+08:00",
  "description": "A JSON toolkit for developers.\nEvery operation runs locally in the browser."
}

JSON-এ "created" কেবল একটি স্ট্রিং যা দেখতে তারিখের মতো, তাই টাইপ তথ্য ফিল্ড চুক্তিতে থাকতে হয়: দুই প্রান্তকে একমত হতে হবে যে ফিল্ডটি সবসময় RFC 3339। TOML পার্সারকে প্রকৃত ডেট অবজেক্ট দেয়, কোনো মৌখিক চুক্তি ছাড়াই।

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

৫. সংখ্যা: সবচেয়ে উপেক্ষিত পার্থক্য

JSON স্পেসিফিকেশন সংখ্যার প্রিসিশনে কোনো সীমা দেয় না, তবে RFC 8259 সতর্কও করে যে সংখ্যাকে IEEE 754 ডাবল ধরে নিলেই আন্তঃকার্যক্ষমতা সবচেয়ে নিরাপদ। JavaScript-এ 2^53 - 1-এর বেশি ইন্টিজার নীরবে নির্ভুলতা হারায়:

复制JSON.parse('{"id":9007199254740993}').id
// 9007199254740992: the last digit is gone

TOML সাইনড ৬৪-বিট ইন্টিজারকে নির্ভুলভাবে সামলাতে ও নীরবে ছাঁটার বদলে এরর দিতে বাধ্য করে; ফ্লোট বাইনারি৬৪ অনুসরণ করে আর inf বা nan-ও হতে পারে। YAML 1.1 একটি পুরোনো বোঝা বহন করে: 1:30 ৯০ (সেক্সাজেসিমাল) হিসেবে পার্স হয়, আর বুলিয়ান yes, no, on ও off গ্রহণ করে। এখান থেকেই ক্লাসিক "Norway সমস্যা", যেখানে দেশের কোড NO false হয়ে যায়।

টাকার জন্য এই কোনো ফরম্যাটেই ফ্লোটিং পয়েন্টের উপর নির্ভর করবেন না: ইন্টিজার উপ-একক, স্ট্রিং, বা ডেটাবেসের দশমিক টাইপ ব্যবহার করুন। ফরম্যাটিং ও প্রিসিশন আরও গভীরে আলোচিত JSON, YAML ও XML রূপান্তরের সীমানা-এ।

৬. টেবিল ও নেস্টিং: TOML-এর কঠোর সীমানা

TOML টেবিল ও টেবিলের অ্যারে দিয়ে নেস্টিং প্রকাশ করে:

复制[server]
port = 8080

[[routes]]
path = "/parse"
method = "POST"

[[routes]]
path = "/minify"
method = "POST"

রূপান্তরের আগে জানা আবশ্যক দুটি কঠোর সীমানা আছে:

• TOML ডকুমেন্টের রুট একটি টেবিল, তাই যে JSON ডকুমেন্টের টপ লেভেল অ্যারে (যেমন [1, 2, 3]) তার কোনো বৈধ TOML রূপ নেই; সেটিকে {"items": [...]} হিসেবে মুড়তে হবে;
• TOML-এ null নেই, তাই JSON-এর null ফিল্ড হয় বাদ দিতে হবে, নয় খালি স্ট্রিং বা সেন্টিনেল মান দিয়ে প্রতিস্থাপন করতে হবে, আর অর্থটা ভোক্তার ঘাড়ে চাপাতে হবে।

YAML ঠিক উল্টো: নেস্টিং গভীরতা অসীম, আর অ্যাঙ্কর প্লাস মার্জ কি খণ্ড পুনরায় ব্যবহার করতে পারে:

复制defaults: &defaults
  retries: 3
  timeoutMs: 5000

server:
  <<: *defaults
  port: 8080

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

৭. পরিস্থিতি অনুযায়ী বাছাই

একটি হাতের নিয়ম: ইকোসিস্টেমকে কনফিগারেশন ফরম্যাট বেছে নিতে দিন, ব্যক্তিগত পছন্দকে নয়। Rust লেখেন মানে Cargo.toml, Kubernetes-এ ডিপ্লয় করেন মানে YAML, VS Code এক্সটেনশন বানান মানে JSONC। কেবল ইকোসিস্টেম-বাধা নেই এমন নতুন প্রকল্পেই "কোনটি লিখতে সুন্দর" প্রকৃত প্রশ্ন।

৮. রূপান্তরের সীমানা

রূপান্তর টুল মান নিশ্চিত করে, কমেন্ট কখনো নয়। তাই এমন দুইমুখী পাইপলাইন নকশা করবেন না যেখানে "JSON হলো উৎস আর YAML হলো বিল্ড আর্টিফ্যাক্ট"। হয় কেবল এক দিকে জেনারেট করুন, নয় একটি একক উৎস ফাইল রক্ষণাবেক্ষণ করুন।

৯. চেকলিস্ট

• [ ] কোন ফাইল টাইপ কোন ফরম্যাট ব্যবহার করে ডকুমেন্ট করুন, এবং অনুমোদিত ডায়ালেক্টের তালিকা দিন;
• [ ] মানুষের রক্ষণাবেক্ষণ করা কনফিগারেশনে TOML বা YAML-কে অগ্রাধিকার দিন, আর মেশিন বিনিময়ে JSON;
• [ ] JSON-এ তারিখ RFC 3339 স্ট্রিং হিসেবে রাখুন এবং স্কিমায় ফরম্যাট চিহ্নিত করুন;
• [ ] টাকা ও 2^53-এর বেশি ইন্টিজার স্ট্রিং বা উপ-একক হিসেবে প্রকাশ করুন, কখনো ফ্লোট হিসেবে নয়;
• [ ] CI-তে প্রতিটি ফরম্যাট তার নিজের পার্সার দিয়ে যাচাই করুন, YAML-এর জন্য কখনো JSON.parse নয়;
• [ ] ফরম্যাট কেবল এক দিকে মাইগ্রেট করুন, আর পুরোনো ফাইল মুছুন যাতে দুটো সরে না যায়।

সাধারণ প্রশ্ন

JSON থেকে TOML রূপান্তর কিছু ফিল্ডে ব্যর্থ হয় কেন?

TOML-এ null নেই, আর TOML ডকুমেন্টের রুট একটি টেবিল, তাই JSON-এর null ফিল্ড বাদ দিতে বা খালি স্ট্রিং/সেন্টিনেলে বদলাতে হয়, আর টপ-লেভেল অ্যারেকে {"items": [...]} হিসেবে মুড়তে হয়। উল্টো দিকে যাওয়ার সময় কমেন্ট, তারিখ টাইপ ও inf/nan-ও হারায়, এজন্যই রূপান্তর একমুখী হওয়া উচিত।

বিভিন্ন ফরম্যাটে দুটি কনফিগারেশন ফাইল রাখা উচিত?

না। রূপান্তর টুল মান নিশ্চিত করে কিন্তু কমেন্ট কখনো নয়, তাই "JSON উৎস আর YAML বিল্ড আর্টিফ্যাক্ট" পাইপলাইন সরে যাবে। হয় কেবল এক দিকে জেনারেট করুন, নয় একটি একক উৎস ফাইল রক্ষণাবেক্ষণ করুন এবং মাইগ্রেশনের পর পুরোনোটি মুছুন।

JSON কনফিগারেশন ফাইলে কমেন্ট কীভাবে যোগ করব?

স্ট্যান্ডার্ড JSON-এ কমেন্ট নেই। আপনি JSONC-তে যেতে পারেন (VS Code ডায়ালেক্ট, jsonc-parser দিয়ে পড়ুন), প্রতিটি ফিল্ড ব্যাখ্যা করা একটি সাইডকার ডকুমেন্ট রাখতে পারেন, বা TOML/YAML-এ যেতে পারেন। অন্য সিস্টেমে পাঠানো ফাইল স্ট্যান্ডার্ড JSON-ই থাকা উচিত, ব্যাখ্যা ডকুমেন্টেশন বা স্কিমায়।

অ্যাপ্লিকেশন কনফিগারেশনের জন্য TOML নাকি YAML ভালো?

কাঠামো সমতল, বেশিরভাগ কি-ভ্যালু জোড়া, আর নেটিভ তারিখ গুরুত্বপূর্ণ হলে TOML বাছুন; এর অর্থ আরও পূর্বানুমেয় আর পার্সার পার্থক্য ছোট। গভীর নেস্টিং, একাধিক ডকুমেন্ট, অ্যাঙ্কর পুনর্বিবার, বা লক্ষ্য ইকোসিস্টেম YAML-প্রথম (যেমন Kubernetes বা CI) হলে YAML বাছুন। দুটোই কমেন্ট সমর্থন করে, তাই প্রকৃত পার্থক্যকারী হলো কাঠামোগত জটিলতা ও ইকোসিস্টেমের বাঁধন।

YAML-এ NO কেন false হয়ে যায়?

YAML 1.1 yes, no, on, off, y ও n-কে বুলিয়ান ধরে, তাই নরওয়ের দেশের কোড NO false হিসেবে পার্স হয়। এটি "Norway সমস্যা"। YAML 1.2 অনুসরণকারী বাস্তবায়ন ব্যবহার করে, বা ভুল ব্যাখ্যা হতে পারে এমন প্রতিটি স্ট্রিং কোট করে এটি এড়ান।

CSON কি এখনও ব্যবহারের যোগ্য?

নতুন প্রকল্পে নয়। CSON CoffeeScript ইকোসিস্টেমের উপর নির্ভর করে, রক্ষণাবেক্ষণকৃত টুল কম, আর এডিটর ও CI সমর্থন সীমিত; Atom রক্ষণাবেক্ষণ বন্ধের পর এর ব্যবহার আরও কমেছে। প্রকল্পে ইতিমধ্যে CSON কনফিগ থাকলে আরও যোগ না করে JSON, TOML বা YAML-এ এককালীন মাইগ্রেশন নির্ধারণ করুন।