মূল বিষয়বস্তুতে যান
CuteJSON
↑↓ নেভিগেট Enter নির্বাচন Esc বন্ধ

JSON vs YAML: পার্থক্য এবং কখন কোনটি ব্যবহার করবেন

প্রকাশিত 3 মিনিট পড়ুন Akash Kinkar Pandey দ্বারা

YAML হলো JSON-এর ডেটা মডেলের একটি সুপারসেট: প্রতিটি বৈধ JSON ডকুমেন্ট শব্দ শব্দে বৈধ YAML। পার্থক্য হলো প্রতিটি ফরম্যাট কী উপস্থাপন করতে পারে, তায় নয়, বরং প্রতিটি কীভাবে লেখা হয় এবং প্রতিটি হাতে লেখার সময় কতটা আরামদায়ক।

একই ডেটা, দুই উপায়

{
  "name": "web-app",
  "version": "1.0.0",
  "scripts": { "build": "vite build", "test": "vitest" },
  "dependencies": ["react", "vite"]
}
name: web-app
version: 1.0.0
scripts:
  build: vite build
  test: vitest
dependencies:
  - react
  - vite

একই ডকুমেন্ট, বিশ্লেষণের পর একই ডেটা। YAML ব্রেস, ব্র্যাকেট, সাধারণ স্ট্রিং চারপাশের কোটেশন এবং বেশিরভাগ কমা বাদ দেয়, এবং নেস্টিং দেখানোর জন্য ইন্ডেন্টেশন ব্যবহার করে।

প্রকৃত পার্থক্য কোথায়

মন্তব্য। YAML-এ আছে, # এভাবে। JSON-এ ডিজাইন অনুযায়ী কোনোটিই নেই; কোনো .json কনফিগ ফাইলে একটি সেটিংসের পাশে ব্যাখ্যা রাখতে হলে সেটি অন্যত্র রাখতে হয়, সাধারণত README-তে, কারণ পার্সার // বা # লাইনকে সরাসরি প্রত্যাখ্যান করবে। এটিই একমাত্র কারণ যে হাতে মেইনটেইন করা কনফিগ (CI পাইপলাইন, Docker Compose, Kubernetes ম্যানিফেস্ট) ডিফল্টে YAML ব্যবহার করে: এক বছর পরে এটি সম্পাদনা করার ব্যক্তিকে জানতে হবে কেন একটি সেটিংস যেমন আছে, এবং মন্তব্যই একমাত্র জায়গা যা মানের পাশে টিকে থাকে।

শূন্যস্থান সংবেদনশীলতা। YAML-এর ইন্ডেন্টেশন স্ট্রাকচারাল, Python-এর মতো। দুই স্পেসের বদলে চার, অথবা যেখানে স্পেস প্রত্যাশিত সেখানে একটি ট্যাব এলে ডকুমেন্টের অর্থ বদলে যায় বা ভেঙে যায়, এবং খারাপ ইন্ডেন্টেশনের এরর মেসেজ প্রায়ই JSON পার্সারের “অনাকাঙ্ক্ষিত টোকেন লাইন 4, কলাম 12” অপেক্ষা কম নির্দিষ্ট। JSON-এর ব্রেস এবং ব্র্যাকেট স্পষ্ট, তাই ইন্ডেন্টেশন শুধু কসমেটিক, যা JSON-কে মেশিন তৈরি করে এবং খাওয়ার ফরম্যাট হওয়ার একটি কারণ: একটি স্ক্রিপ্ট পাঠ্যতার কথা ভাবে না এবং অস্পষ্ট ডিলিমিটার পছন্দ করে।

একই মান লেখার একাধিক উপায়। YAML-এ আছে একটি প্লেইন স্কেলার, একটি একক কোটেড স্ট্রিং, একটি ডাবল কোটেড স্ট্রিং, মাল্টি-লাইন টেক্সটের জন্য ব্লক স্কেলার, রেফারেন্স দ্বারা মান পুনরাবৃত্তি করার জন্য অ্যাঙ্কর এবং অ্যালিয়াস, এবং কিছু অমূর্ত ধরন রূপান্তর (yes এবং no YAML 1.1-এ বুলিয়ান হিসাবে পার্স হতো, যা ঠিক সেই ধরনের সারপ্রাইজ যার ফলে “নরওয়ে সমস্যা”, একটি কান্ট্রি কোড NO মিথ্যা বুলিয়ান হিসাবে পড়া, একটি পরিচিত YAML সমস্যা হয়ে দাঁড়াল)। JSON-এ স্ট্রিং লেখার এক উপায়, সংখ্যা লেখার এক উপায়, এবং কোনো অমূর্ত রূপান্তর নেই। একই জিনিস লেখার কম উপায় মানে ভুল লেখার কম উপায়, এবং এটিই মেশিন-থেকে-মেশিন পেলোডে JSON-এর প্রকৃত যুক্তি।

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

কখন কোনটি ব্যবহার করবেন

  • JSON যেকোনো জিনিসের জন্য যা একটি প্রোগ্রাম তৈরি করে এবং অন্য একটি প্রোগ্রাম খায় মাঝে কোনো মানুষ না পড়ে: API পেলোড, ডেটা বিনিময়, যেকোনো জিনিস যা একই রিকোয়েস্ট-রেসপন্স চক্রে সিরিয়ালাইজ এবং ডিসিরিয়ালাইজ হয়।
  • YAML যেকোনো জিনিসের জন্য যা কোনো ব্যক্তি নিয়মিত হাতে সম্পাদনা করে এবং টেক্সটাইল রাখতে মন্তব্য বা মাল্টি-লাইন স্ট্রিংয়ের প্রয়োজন: CI কনফিগ, Kubernetes ম্যানিফেস্ট, অ্যাপ্লিকেশন কনফিগ ফাইল যা ইনলাইন ডকুমেন্টেশন নিয়ে আসে।

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

একটি থেকে অন্যটিতে রূপান্তর

JSON থেকে YAML রূপান্তরকারী দুই দিকে কাজ করে: এটি অ্যাঙ্কর, অ্যালিয়াস এবং মাল্টি-ডকুমেন্ট স্ট্রিম সঠিকভাবে লেখে সবকিছু প্লেইন স্কেলারে সমতল করার বদলে, এবং YAML আবার পড়ার সময় যেসব জিনিস তার শুরুর ধরনের রূপে রাউন্ড ট্রিপ করবে না সেগুলো কোট করে (যেমন "1.0.0" ভার্সন স্ট্রিং স্ট্রিংই থাকে, সংখ্যা 1 হয় না)। আপনি যা রূপান্তর করেন তা আপলোড হয় না; রূপান্তর আপনার ব্রাউজারে চলে, ঠিক এই সাইটের প্রতিটি টুলের মতো।

সব পোস্টে ফিরুন