JSON পার্সিং ও প্রসেসিং লাইব্রেরির তুলনা

মূল কথা: আগে প্রয়োজনের শ্রেণি ঠিক করুন, তারপর ইমপ্লিমেন্টেশন তুলনা করুন — শুধু মান পড়তে নেটিভ JSON.parse, অফসেট দরকার বা মূল ফরম্যাটিং রাখতে হলে jsonc-parser, আর কেবল যেখানে দরকার সেখানে কুয়েরি বা প্যাচ লাইব্রেরি যোগ করুন; বড় লাইব্রেরি পেজ অনুযায়ী lazy-load করুন আর রক্ষণাবেক্ষণহীনগুলো বাদ দিন।

প্রতিটি লাইব্রেরি দাবি করে সে "দ্রুত, ছোট ও পূর্ণাঙ্গ"। আসলে তাদের আলাদা করে দেয় এইটা — কিছু ভুল হলে তারা আপনাকে কত তথ্য দিতে পারে।

১. উদ্দেশ্য অনুযায়ী চার শ্রেণি

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

২. পাশাপাশি তুলনা

JSON.parse-এর এরর মেসেজ ইঞ্জিনভেদে অনেক বদলায়। V8 মোটামুটি Unexpected token } in JSON at position 42 দেয়, তবে position নিখুঁত কি না নির্ভর করে ইঞ্জিন সংস্করণের উপর; jsonc-parser এর বদলে স্থির কাঠামোবদ্ধ { error, offset, length } দেয়, যা এডিটর মার্কারের জন্য উপযুক্ত।

৩. চারটি মূল সিদ্ধান্ত-বিন্দু

৩.১ অফসেট দরকার কি

এডিটর বানাচ্ছেন আর "এররে ক্লিক করলে সংশ্লিষ্ট লাইনে যাবে" চান, তবে অফসেট থাকতেই হবে। পরীক্ষা সহজ: এরর মেসেজ কেবল "invalid JSON" ছাপতে পারলে ব্যবহারকারীকে নিজে খুঁজতে হবে।

复制import { parse, printParseErrorCode } from 'jsonc-parser';

const errors: Array<{ error: number; offset: number; length: number }> = [];
parse(text, errors, { allowTrailingComma: true, disallowComments: false });

if (errors.length > 0) {
  const firstError = errors[0];
  console.error(`${printParseErrorCode(firstError.error)} at offset ${firstError.offset}`);
}

৩.২ মূল টেক্সট সংরক্ষণ দরকার কি

শুধু মান পড়া → যেকোনো পার্সার চলবে। "একটি ফিল্ড বদলে বাকি সব আগের মতোই রাখা" → সম্পাদনা-ধাঁচের API লাগবে, "parse → অবজেক্ট বদলান → serialize" নয়।

পরেরটায় হারায়: কমেন্ট, কি-ক্রম (কিছু ইমপ্লিমেন্টেশনে), ইনডেন্টেশন স্টাইল, সাংখ্যিক লিটেরাল নোটেশন (1e3 হয় 1000), আর এস্কেপ রূপ (\u4e2d আসল অক্ষর হয়ে যায়)।

৩.৩ সীমানার আচরণ স্পষ্ট কি

লাইব্রেরি বাছার আগে ডকুমেন্টেশনে তিনটি বিষয় দেখুন:

1. ডুপ্লিকেট কি কীভাবে হ্যান্ডল হয় (শেষটি রাখা / এরর দেওয়া);
2. বড় ইন্টিজার নির্ভুলতা হারায় কি না (বেশিরভাগ JS লাইব্রেরি হারায়, কারণ সবই Number দিয়ে যায়);
3. BOM, কমেন্ট ও ট্রেইলিং কমার সমর্থিত পরিসর।

ডকুমেন্টেশন না থাকলে ছোট নমুনা লিখে নিজে টেস্ট করুন। README পড়ার চেয়ে এটাই বেশি নির্ভরযোগ্য।

৩.৪ রক্ষণাবেক্ষণের অবস্থা

JSON লাইব্রেরির ঝুঁকি ফিচার কম থাকা নয়, বরং দীর্ঘমেয়াদি অবহেলা: নিরাপত্তা প্যাচ (প্রোটোটাইপ পলিউশন, ReDoS) আর কেউ দেবে না।

৪. অন্য ভাষার সঙ্গে তুলনা

ভাষা-থেকে-ভাষা ডেটা বিনিময়ে সবচেয়ে সহজে পা পিছলে যায় সংখ্যার নির্ভুলতা ও সময়ের ফরম্যাটে; লাইব্রেরি বাছাই কেবল তা লাঘব করতে পারে, দূর করতে পারে না।

৫. টিপিক্যাল সমন্বয়

বিকল্প ১: টুল সাইট (ব্রাউজার দিক)

复制পার্সিং ও এরর লোকেশন: jsonc-parser
এডিটর: CodeMirror 6 + @codemirror/lang-json
কুয়েরি: jsonpath-plus
প্যাচ: fast-json-patch
শেয়ার লিংক: lz-string

এই সমন্বয়ের প্রধান বৈশিষ্ট্য সবকিছু স্থানীয়ভাবে চলে আর কোনো ডেটা আপলোড হয় না, যা ইউটিলিটি সাইটের গোপনীয়তা-প্রত্যাশার সঙ্গে মেলে।

বিকল্প ২: সার্ভার-সাইড API গেটওয়ে

复制ভ্যালিডেশন: Ajv (স্কিমা একবার কম্পাইল করে পুনর্ব্যবহার)
পার্সিং: নেটিভ JSON.parse (বডি আকারের সীমাসহ)
বড় ফিল্ডের বিলম্বিত পার্সিং: কাঁচা স্ট্রিং রাখুন, দরকার হলে কেবল পার্স করুন

ব্যবসায়িক লজিক বানাতে গেটওয়ে স্তরে কুয়েরি/প্যাচ লাইব্রেরি ঢোকাবেন না — সেটি ব্যবসায়িক স্তরের কাজ।

বিকল্প ৩: CLI ও স্ক্রিপ্ট

复制ফিল্ড বাছাই: jq
ফরম্যাট রূপান্তর: yq / dasel
ইন্টারঅ্যাকটিভ ব্রাউজিং: jless
ব্যাচ ভ্যালিডেশন: ajv-cli

৬. বান্ডেল আকার ও পারফরম্যান্সের আসল প্রভাব

• jsonc-parser খুব ছোট এবং মূল বান্ডেলে উপযুক্ত;
• json5 jsonc-parser-এর চেয়ে একটু বড়, কারণ বেশি সিনট্যাক্স সমর্থন করে;
• jsonpath-plus এক্সপ্রেশন মূল্যায়নসহ আসে এবং স্পষ্টভাবে বড়, তাই পেজ অনুযায়ী lazy-load করা উচিত;
• fast-json-patch মাঝারি আকারের, তুলনার ফিচার থাকলে কেবল দরকার।

অপ্টিমাইজেশন সরল: পেজ অনুযায়ী ডাইনামিক ইমপোর্ট করুন, প্রথম-স্ক্রিন চাঙ্কে রাখবেন না।

复制const { JSONPath } = await import('jsonpath-plus');

৭. চেকলিস্ট

• [ ] উদ্দেশ্য অনুযায়ী লাইব্রেরি বাছাই; পার্সিংয়ে কুয়েরি লাইব্রেরি ব্যবহার নয়;
• [ ] নিখুঁত এরর লোকেশন দরকার হলে jsonc-parser;
• [ ] কমেন্ট ও ফরম্যাটিং রাখতে হলে সম্পাদনা-ধাঁচের API;
• [ ] বাস্তবে তিনটি সীমানা আচরণ টেস্ট: ডুপ্লিকেট কি, বড় ইন্টিজার ও BOM;
• [ ] লাইব্রেরির রক্ষণাবেক্ষণ অবস্থা ও নিরাপত্তা সতর্কতা লক্ষ্য করুন;
• [ ] বড় লাইব্রেরি প্রয়োজনমতো ডাইনামিক ইমপোর্ট করুন।

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

প্রকল্পের আকার অনুযায়ী JSON লাইব্রেরি কীভাবে বাছব?

কেবল API ডেটা পড়া ছোট টুল নেটিভ JSON.parse-এ থাকতে পারে। এডিটর-মানের এরর লোকেশন দরকার বা মূল ফরম্যাটিং রাখতে হওয়া প্রকল্পে jsonc-parser ব্যবহার করুন। সার্ভার-সাইড গেটওয়েতে কেবল ভ্যালিডেশন ও পার্সিং দরকার, কুয়েরি ও প্যাচ লাইব্রেরি ব্যবসায়িক স্তরে থাকুক, আর CLI স্ক্রিপ্টে সরাসরি jq, yq ও ajv-cli চলবে।

ফিচার সংখ্যার চেয়ে রক্ষণাবেক্ষণের অবস্থা বেশি গুরুত্বপূর্ণ কেন?

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

একটি ফিল্ড বদলে কমেন্ট ও ইনডেন্টেশন রাখতে JSON.parse ব্যবহার করব?

না। পার্স করে অবজেক্ট বদলে আবার সিরিয়ালাইজ করলে কমেন্ট, কি-ক্রম, ইনডেন্টেশন স্টাইল, সাংখ্যিক লিটেরাল নোটেশন (1e3 হয় 1000) আর এস্কেপ রূপ (\u4e2d আসল অক্ষর হয়) হারায়। একটি ফিল্ড বদলে বাকি সব অক্ষত রাখতে jsonc-parser-এর modify ও applyEdits-এর মতো সম্পাদনা-ধাঁচের API দরকার।