আপনার JSON যাচাই করুন
শুধু বৈধ বা অবৈধ নয় — লাইন, কলাম, অক্ষর, আর এ নিয়ে কী করবেন। কিছুই সংরক্ষণ করা হয় না; যাচাই এখানেই চলে।
- কখনো সংরক্ষণ করা হয় না
- কোনো লাইন নেই, অপেক্ষা নেই
- সাইনআপ নেই, ওয়াটারমার্ক নেই
JSON পেস্ট করুন — টাইপ করার সঙ্গে সঙ্গেই যাচাই হবে।
যেভাবে কাজ করে
আপনার JSON পেস্ট করুন
অথবা ফাইলটি ছাড়ুন। যেখানে আছে সেখানেই পড়া হয়; কিছুই কোথাও পাঠানো হয় না।
ফলাফল পড়ুন
বৈধ, ভেতরে কী কী আছে তার হিসাবসহ। অথবা অবৈধ, ঠিক জায়গাটি চিহ্নিত করে।
ঠিক করে আবার যাচাই করুন
সেখানেই এডিট করুন, টাইপ করার সঙ্গে সঙ্গে উত্তর আপডেট হয়।
JSON আসলে কী কী নিষেধ করে
JSON-এর ব্যাকরণ ইচ্ছে করেই খুব ছোট, আর প্রায় প্রতিটি ভ্যালিডেশন ব্যর্থতা হলো হাতে গোনা কয়েকটি জিনিসের একটি, যা মানুষ JavaScript থেকে ধার করে, অথচ JSON কখনো গ্রহণ করেনি। শেষ উপাদানের পরে বাড়তি কমা। ডাবলের বদলে সিঙ্গেল কোট। কোটেশন ছাড়া কি। কমেন্ট — JSON-এ কোনো কমেন্ট নেই, কখনো ছিলও না। NaN ও Infinity, যা JavaScript-এ বৈধ সংখ্যা, কিন্তু JSON-এ বৈধ নয়। আর শুরুতে একটি বাইট অর্ডার মার্ক, যা সব এডিটরেই অদৃশ্য, কিছু Windows টুল UTF-8 হিসেবে সেভ করার সময় যোগ করে, আর এর কারণে একেবারে ঠিকঠাক ডকুমেন্টও প্রথম অক্ষরেই ব্যর্থ হয়।
দুটি জিনিস বৈধ, তবু আপনাকে ঝামেলায় ফেলবে, আর এ কারণেই “বৈধ” মানে “সঠিক” নয়। স্পেসিফিকেশনে ডুপ্লিকেট কি নিষিদ্ধ নয় — আর প্রতিটি পার্সার এগুলো আলাদাভাবে মীমাংসা করে, বেশিরভাগ শেষেরটি নেয়, তাই পুনরাবৃত্ত কি-সহ একটি ডকুমেন্ট এখানে বৈধ হয় অথচ ভিন্ন ভিন্ন ভাষায় ভিন্ন অর্থ দেয়। আর JSON-এ সংখ্যার কোনো নির্ধারিত নির্ভুলতার সীমা নেই, অথচ বেশিরভাগ পার্সার এগুলোকে ফ্লোটিং পয়েন্ট হিসেবে পড়ে: প্রায় নয় কোয়াড্রিলিয়নের বেশি পূর্ণসংখ্যা চুপচাপ রাউন্ড হয়ে যায়, আর এ কারণেই বড় আইডেন্টিফায়ার প্রায়ই স্ট্রিং হিসেবে রাখা হয়।
আপনি ফেরত পান ঠিক কোন লাইন, কলাম ও অক্ষরে পার্সিং থেমেছে, যা সাধারণত বার্তাটির চেয়েও বেশি কাজের। পার্সার সেই জায়গা জানায়, যেখানে ডকুমেন্টটির অর্থ বোঝা বন্ধ হয়েছে, ভুলটি যেখানে হয়েছে সেখানে নয় — বন্ধনীর শেষ অংশ না থাকলে তা জানানো হয় ফাইলের শেষে, আর কমা না থাকলে তা জানানো হয় তার পরের টোকেনে। জানানো অবস্থানের ঠিক আগে খুঁজে দেখার অভ্যাসটিই সবচেয়ে বেশি সময় বাঁচায়।
গঠন ঠিক থাকা মানেই সঠিক নয়, আর এই পার্থক্যটা গুরুত্বপূর্ণ। এটি নিশ্চিত করে যে সিনট্যাক্স পার্স হয়। ডকুমেন্টে আপনার API-এর দরকারি ফিল্ডগুলো আছে কি না, কোনো মান সীমার মধ্যে আছে কি না, একটি তারিখ সত্যিই তারিখ কি না — এর কোনোটিই JSON-এর প্রশ্ন নয়। সেটা স্কিমা ভ্যালিডেশন, এর জন্য একটি স্কিমা লাগে, আর একটি ডকুমেন্ট এখানে নিখুঁত হয়েও যে সার্ভিসে পাঠাচ্ছেন সেখানে সঙ্গে সঙ্গে বাতিল হতে পারে।
অন্য কিছু দরকার হলে
ব্যাকরণের বদলে স্কিমার সঙ্গে ডকুমেন্ট যাচাই করতে JSON Schema হলো মানদণ্ড, আর ajv এর দ্রুততম বাস্তবায়ন — এটি জানিয়ে দেবে কোনো দরকারি ফিল্ড নেই বা কোনো মান সীমার বাইরে, আর সাধারণত আপনার আসল প্রশ্ন সেটাই। check-jsonschema একই যাচাই কমান্ড লাইন থেকে ও CI-তে চালায়।
কমান্ড লাইনের যেকোনো কাজে jq রাখার মতো টুল: jq empty file.json যাচাই করে এবং সফল হলে কিছুই প্রিন্ট করে না, যা একটি স্ক্রিপ্টের জন্য একদম সঠিক, আর jq . ফরম্যাট করে। মেমোরিতে রাখার পক্ষে খুব বড় ফাইলের জন্য jq --stream ও Python-এর ijson ধাপে ধাপে পার্স করে, যা পুরো ডকুমেন্ট লোড করা কোনো পেজ করতে পারে না।
সাধারণ প্রশ্নোত্তর
আমার JSON কি কোথাও সংরক্ষণ করা হয়?
না। কোনো সার্ভার কল নেই, কোনো লগ রাখা হয় না, আর কিছুই সংরক্ষণ করা হয় না। পেজ লোড হওয়ার পর ইন্টারনেট সংযোগ বিচ্ছিন্ন করলেও এটি কাজ করতে থাকে। এখানে এর গুরুত্ব যতটা মনে হয় তার চেয়ে বেশি: মানুষ অনলাইন ফরম্যাটারে যা পেস্ট করে, তা হলো API রেসপন্স, কনফিগ ফাইল আর এরর পেলোড — আর এগুলোতে প্রায়ই টোকেন, গ্রাহকের তথ্য ও ইন্টারনাল হোস্টনেম থাকে।
JSON ভাঙা হলে এটি কী জানায়?
লাইন, কলাম, ঠিক সেই অক্ষরের নিচে একটি ক্যারেট চিহ্নসহ লাইনটি, আর সেখানে কী আশা করা হচ্ছিল। বেশিরভাগ JSON ভাঙে চারটি কারণের একটিতে — শেষে বাড়তি কমা, ডাবলের বদলে সিঙ্গেল কোট, কোটেশন ছাড়া কি, বা স্ট্রিংয়ের ভেতরে আসল নিউলাইন — আর এগুলোর প্রতিটিকে সাধারণ সিনট্যাক্স এরর বলে না দেখিয়ে নাম ধরে জানানো হয়।
বৈধ বলতে কী বোঝায়?
কঠোরভাবে RFC 8259। অর্থাৎ ডাবল কোটেশনে কি, শেষে বাড়তি কমা নয়, কমেন্ট নয়, আর সংখ্যায় শুরুতে শূন্য বা হেক্স নয়। কঠোর হওয়াই ভ্যালিডেটরের মূল কথা: আপনার পার্সার যা বাতিল করবে, তা যদি এটি মেনে নিত, তাহলে এটি আপনাকে কিছুই জানাত না।
এটি কি স্কিমার সঙ্গে আমার JSON যাচাই করে?
না — এটি সিনট্যাক্স যাচাই করে, যা আলাদা প্রশ্ন। সিনট্যাক্স মানে লেখাটি আদৌ JSON কি না। স্কিমা মানে ডেটায় সঠিক ফিল্ড ও টাইপ আছে কি না। এই পেজ প্রথমটির উত্তর দেয়; এটি জানাবে ফাইলটি পার্স হয় কি না, আর যে কাঠামো পেয়েছে তা দেখাবে, কিন্তু আপনার ফিল্ডগুলো কী হওয়ার কথা, তা এটি জানে না।
বৈধ দেখাচ্ছে, অথচ আমার API তবু বাতিল করছে কেন?
কারণ বৈধ JSON আর আপনার API যে JSON চায়, তা আলাদা জিনিস। সিনট্যাক্সের দিক থেকে নিখুঁত একটি ডকুমেন্টেও কোনো দরকারি ফিল্ড না থাকতে পারে, সংখ্যার জায়গায় স্ট্রিং থাকতে পারে, বা এন্ডপয়েন্ট যেভাবে চায় তার চেয়ে ভিন্নভাবে নেস্ট করা থাকতে পারে। এই পেজে দেখানো কাঠামোর সারাংশটি API-এর ডকুমেন্টেশনের সঙ্গে মিলিয়ে পড়ুন — অমিলটি সাধারণত সঙ্গে সঙ্গে চোখে পড়ে।
বড় সংখ্যা কি ঠিকভাবে যাচাই হয়?
হ্যাঁ, অঙ্কে অঙ্কে — বেশিরভাগ ভ্যালিডেটর এগুলো চুপচাপ নষ্ট করে। JavaScript-এর সংখ্যা হলো ৬৪-বিট ফ্লোট, তাই এটি শুধু 9,007,199,254,740,991 পর্যন্ত পূর্ণসংখ্যা হুবহু রাখতে পারে। এর চেয়ে বড় যেকোনো কিছু — Twitter/X পোস্টের ID, Discord snowflake, ব্যাংক অ্যাকাউন্ট নম্বর, ৬৪-বিট ডেটাবেস কি — `JSON.parse`-এর ভেতর দিয়ে যাওয়ার মুহূর্তেই শেষের অঙ্কগুলো হারায়। সংখ্যাটি তবু বিশ্বাসযোগ্য দেখায়, আর বিপদটা সেখানেই: 7205759403792793600 চুপচাপ হয়ে যায় 7205759403792793000। এই পেজ আপনার পেস্ট করা অঙ্কগুলো হুবহু রাখে, আর কতগুলো সংখ্যা রক্ষা করতে হয়েছে তা জানায়।
কোনো সাইজ সীমা আছে?
আমাদের বেঁধে দেওয়া কোনো সীমা নয়, বরং উপলব্ধ মেমোরি। কয়েক মেগাবাইটের ডকুমেন্ট সঙ্গে সঙ্গে ফরম্যাট হয়; খুব বড়গুলোর সীমা নির্ভর করে একসাথে কতটা রাখা যায় তার ওপর, আমাদের দিকের কোনো কিছুর ওপর নয়।
জেনে রাখুন: এটি যাচাই করে JSON-এর গঠন ঠিক আছে কি না, এর কোনো অর্থ আছে কি না তা নয়। একটি ডকুমেন্ট পুরোপুরি বৈধ হয়েও আপনার API-এর চাওয়া ফিল্ডগুলো ছাড়া থাকতে পারে — সেটা স্কিমা ভ্যালিডেশন, যার জন্য একটি স্কিমা লাগে। এখানে আপনি পাবেন ঠিক কোন লাইন, কলাম ও অক্ষরে পার্সিং থেমেছে।
এই টুলটি আপনার ওয়েবসাইটে যোগ করুন
যেকোনো ব্লগ, ক্লাসের পেজ বা হেল্প আর্টিকেলের জন্য ফ্রি। একটি স্নিপেট পেস্ট করলেই আপনার ভিজিটররা আপনার পেজেই এটি ব্যবহার করতে পারবেন।