خلاصه مقاله: JSON یا JavaScript Object Notation یک قالب متنی سبک و مستقل از زبان برنامهنویسی برای نمایش و تبادل دادههای ساختیافته است. این قالب در APIها، ارتباط بین سرویسها، فایلهای پیکربندی و بسیاری از برنامههای وب و موبایل استفاده میشود. در این راهنما با ساختار object و array، انواع مجاز داده، خطاهای رایج، اعتبارسنجی، نمونههای عملی، JSON در API و کاربرد JSON-LD آشنا میشوید.
JSON چیست؟
JSON مخفف JavaScript Object Notation است؛ یعنی «نشانهگذاری شیء جاوااسکریپت». با وجود نام آن، JSON به جاوااسکریپت محدود نیست و برنامههای نوشتهشده با زبانهای مختلف میتوانند آن را تولید یا پردازش کنند. JSON در واقع قالبی برای نمایش متنمحور دادههاست، نه یک زبان برنامهنویسی و نه جایگزین منطق اجرایی برنامه.
مزیت اصلی این قالب، ساختار ساده و قابلخواندن آن است. یک سامانه میتواند دادهای را در قالب JSON ارسال کند و سامانهای دیگر، حتی اگر با زبان دیگری نوشته شده باشد، همان داده را با تجزیهگر مناسب بخواند. این ویژگی JSON را برای تبادل داده بین مرورگر، سرور، برنامه موبایل و سرویسهای مستقل مناسب کرده است.
قواعد استاندارد JSON در مشخصاتی مانند RFC 8259 و استاندارد ECMA-404 تعریف شدهاند. این مشخصات دستور زبان نمایش داده را تعیین میکنند؛ معنای هر فیلد، مانند اینکه مقدار price قیمت نهایی است یا قیمت پایه، باید در قرارداد داده یا مستندات برنامه مشخص شود.
JSON چگونه ساخته شد و چرا فراگیر شد؟
JSON از شیوه نمایش objectها در جاوااسکریپت الهام گرفته، اما برای تبادل داده میان زبانها طراحی شده است. گسترش برنامههای تحت وب، ارتباط ناهمگام مرورگر و سرور، APIها و معماری سرویسگرا باعث شد قالبی سبک و آسان برای خواندن و تولید اهمیت بیشتری پیدا کند. JSON به دلیل قواعد نسبتاً کوچک، پشتیبانی گسترده در ابزارها و سازگاری با زبانهای گوناگون به یکی از قالبهای رایج تبادل داده تبدیل شد.
این محبوبیت به معنای برتری JSON برای همه مسئلهها نیست. برای دادههای جدولی ساده ممکن است CSV مناسبتر باشد؛ برای اسناد نشانهگذاریشده با نیازهای خاص، XML هنوز در بعضی سامانهها استفاده میشود؛ و برای ارتباطات فشرده یا قراردادهای باینری، قالبهای دیگری نیز وجود دارند. انتخاب قالب باید بر اساس نیاز، ابزارهای دو طرف، خوانایی، حجم و قواعد اعتبارسنجی انجام شود.
ساختار اصلی JSON: شیء و آرایه
شیء یا Object
شیء JSON میان آکولادهای { } قرار میگیرد و از جفتهای نام و مقدار تشکیل میشود. نام هر فیلد باید رشتهای باشد که با علامت نقلقول دوتایی نوشته میشود؛ نام و مقدار با دونقطه از هم جدا میشوند و جفتها با ویرگول از یکدیگر فاصله میگیرند.
{
"name": "Varianet",
"active": true,
"employees": 12
}
در این مثال، name یک رشته، active یک مقدار بولی و employees یک عدد است. نام فیلدها بخشی از قرارداد داده محسوب میشود؛ بنابراین بهتر است نامگذاری در کل API یکدست باشد، مثلاً از الگوی camelCase یا snake_case بهصورت ثابت استفاده شود.
آرایه یا Array
آرایه JSON درون کروشههای [ ] قرار میگیرد و مجموعهای مرتب از مقادیر را نمایش میدهد. مقادیر آرایه میتوانند رشته، عدد، مقدار بولی، null، شیء یا آرایه دیگری باشند.
{
"services": ["Networking", "Monitoring", "Security"],
"ports": [80, 443, 8080]
}
ترتیب عناصر آرایه مهم است؛ اما نباید به ترتیب فیلدهای یک object برای انتقال معنا یا اولویت تکیه کرد. اگر ترتیب خاصی در یک مجموعه اهمیت دارد، آن را در قالب آرایه یا در قرارداد داده بهصراحت مشخص کنید.
انواع داده مجاز در JSON
JSON شش گروه مقدار اصلی دارد: رشته، عدد، مقدار بولی، مقدار تهی، شیء و آرایه. همین مجموعه کوچک برای ساختاردهی به دادههای ساده و پیچیده کافی است.
- رشته (String): متن داخل نقلقول دوتایی، مانند
"Tehran". - عدد (Number): عدد صحیح یا اعشاری، مانند
12یا19.5. - بولی (Boolean): فقط
trueیاfalseبا حروف کوچک. - null: نشاندهنده مقدار تهی، وقتی قرارداد داده چنین معنایی را تعریف کرده باشد.
- شیء (Object): مجموعهای از جفتهای نام و مقدار.
- آرایه (Array): فهرستی مرتب از مقادیر.
JSON بهطور مستقیم نوعهای ویژهای مانند تاریخ، تابع، undefined یا کلاسهای سفارشی جاوااسکریپت را تعریف نمیکند. برای تاریخ معمولاً از رشتهای با قالب توافقشده، مانند زمان استانداردشده ISO 8601، استفاده میشود. در مورد مقدارهای تهی نیز باید مشخص باشد که null با حذف کامل فیلد چه تفاوتی دارد.
قواعد مهم نگارش JSON و خطاهای رایج
- نام فیلدها و رشتهها باید با نقلقول دوتایی نوشته شوند؛
'name'قالب معتبر JSON نیست. - پس از آخرین فیلد یک object یا آخرین عضو یک array ویرگول اضافه نگذارید.
- JSON استاندارد شامل توضیح خطی یا بلوکی مانند
// commentو/* comment */نیست. - مقدارهای بولی باید دقیقاً با حروف کوچک، یعنی
trueوfalseنوشته شوند؛Trueمعتبر نیست. undefined،NaNوInfinityمقدارهای معتبر JSON نیستند.- در نمایش عدد، صفرهای ابتدایی مانند
007مجاز نیستند؛ اگر کد ملی، شماره تلفن یا شناسهای ممکن است با صفر شروع شود، آن را معمولاً بهصورت رشته ذخیره کنید. - رشتهها باید از نقلقول و نویسههای کنترلی بهدرستی escape شوند. برای مثال، نقلقول داخل متن باید به شکل
\"نمایش داده شود.
نمونه زیر عمداً نامعتبر است، چون از نقلقول تکی، ویرگول انتهایی و توضیح استفاده میکند:
{
'name': 'Varianet', // نام شرکت
"active": true,
}
نسخه معتبر آن به این شکل است:
{
"name": "Varianet",
"active": true
}
اگر داده از یک سامانه دیگر دریافت میشود، صرفاً به ظاهر مرتب آن اعتماد نکنید. یک تجزیهگر استاندارد و سپس اعتبارسنجی متناسب با قرارداد داده را اجرا کنید تا خطاهای نحوی و خطاهای معنایی از هم تشخیص داده شوند.
نمونه JSON کاربردی برای اطلاعات یک سرویس
نمونه زیر اطلاعات یک سرویس را نمایش میدهد. ساختار تو در تو اجازه میدهد اطلاعات مرتبط در گروههای منطقی قرار بگیرند و آرایه برای نگهداری چند ویژگی یا چند نشانی استفاده شود.
{
"service": {
"id": "NET-001",
"name": "Network Monitoring",
"enabled": true,
"monthlyPrice": 1250000,
"currency": "IRR",
"features": ["Availability", "Alerts", "Reports"],
"support": {
"email": "support@example.com",
"responseHours": 8
}
}
}
این متن از نظر نحو JSON معتبر است، اما معتبر بودن نحوی تضمین نمیکند که داده از نظر کسبوکار درست باشد. برای مثال، سامانه باید تعریف کند آیا monthlyPrice بر حسب ریال است یا تومان، آیا مقدار منفی مجاز است، و responseHours ساعت کاری را بیان میکند یا ساعت تقویمی. این قواعد بخشی از قرارداد برنامه یا schema هستند.
JSON در API و ارتباط بین سامانهها
یکی از پرکاربردترین محلهای استفاده JSON، API است. یک کلاینت ممکن است درخواست HTTP به سرور بفرستد و سرور در پاسخ، اطلاعات را به شکل JSON برگرداند. برای اعلام قالب بدنه معمولاً از سرآیند Content-Type: application/json استفاده میشود؛ سرآیند Accept نیز میتواند قالب پاسخ مورد انتظار کلاینت را مشخص کند.
برای نمونه، پاسخ API مربوط به یک مشتری ممکن است چنین باشد:
{
"id": 42,
"name": "مشتری نمونه",
"status": "active",
"createdAt": "2026-10-15T10:30:00Z"
}
در طراحی API باید نام و نوع فیلدها، فیلدهای الزامی و اختیاری، معنای مقدار تهی، قالب تاریخ، واحد پول، روش نمایش خطا و نسخهبندی قرارداد مشخص شود. تغییر نام فیلد یا تبدیل آن از عدد به رشته میتواند کلاینتهای قبلی را دچار خطا کند؛ بنابراین تغییرات ناسازگار را با برنامه نسخهبندی و اطلاعرسانی مدیریت کنید.
JSON فقط بدنه داده را قالببندی میکند؛ احراز هویت، مجوزدهی، رمزنگاری، کنترل دسترسی و مدیریت خطا وظایف جداگانهای هستند. استفاده از JSON بهتنهایی هیچ API را امن نمیکند.
خواندن و ساخت JSON در JavaScript
جاوااسکریپت دو متد شناختهشده برای این کار دارد: JSON.parse() برای تبدیل متن معتبر JSON به مقدار جاوااسکریپت، و JSON.stringify() برای تبدیل مقدار قابلسریالسازی به متن JSON.
const text = '{"name":"Varianet","active":true}';
const data = JSON.parse(text);
console.log(data.name); // Varianet
const output = JSON.stringify({ name: "Varianet", active: true });
console.log(output);
اگر متن ورودی JSON معتبر نباشد، JSON.parse() معمولاً خطا ایجاد میکند؛ در برنامه واقعی آن را مدیریت کنید و پیام خطای داخلی یا داده محرمانه را بیجهت به کاربر نمایش ندهید. JSON.stringify() نیز همه انواع جاوااسکریپت را بدون تغییر حفظ نمیکند: برای نمونه، بعضی مقدارها مانند undefined در object حذف میشوند و در array ممکن است به null تبدیل شوند.
هرگز برای خواندن متن JSON از eval() استفاده نکنید. تابع eval() کد را اجرا میکند و خطرهای غیرضروری ایجاد میکند؛ برای JSON از تجزیهگر استاندارد و اعتبارسنجی مناسب بهره ببرید.
کار با JSON در Python
در پایتون، ماژول استاندارد json امکان تبدیل بین متن JSON و ساختارهای داده پایتون را فراهم میکند. متد json.loads() متن را میخواند و json.dumps() یک مقدار را به رشته JSON تبدیل میکند.
import json
text = '{"name": "Varianet", "active": true, "services": ["Network", "Security"]}'
data = json.loads(text)
print(data["name"])
output = json.dumps(data, ensure_ascii=False, indent=2)
print(output)
در JSON، مقدارهای بولی با true و false نوشته میشوند، در حالی که در کد پایتون از True و False استفاده میشود؛ اما هنگام خواندن متن JSON، کتابخانه تبدیل این تفاوت را مدیریت میکند. گزینه ensure_ascii=False به نمایش مستقیم حروف فارسی در خروجی کمک میکند و indent=2 قالب را خواناتر میسازد.
برای آموزش بیشتر زبان و ابزارهای مورد استفاده در نمونههای داده، مطلب آشنایی با زبان برنامهنویسی پایتون را ببینید. همچنین مقاله زبانهای برنامهنویسی رایج و کاربرد آنها برای انتخاب ابزار مناسب، دید کلیتری ارائه میدهد.
اعتبارسنجی JSON با ابزار و Schema
اعتبارسنجی JSON دو سطح دارد. سطح نخست، صحت نحو است: آیا متن مطابق قواعد JSON نوشته شده است؟ سطح دوم، صحت ساختار و معناست: آیا فیلدهای لازم وجود دارند، نوع آنها درست است، مقدارها در محدوده مجاز قرار میگیرند و ارتباط بین فیلدها منطقی است؟
ابزارهای اعتبارسنجی JSON میتوانند خطاهایی مانند ویرگول اضافه، نقلقول نامعتبر یا کروشه بستهنشده را پیدا کنند. اما برای بررسی قواعد اختصاصی یک API، تعریف قرارداد و استفاده از JSON Schema یا اعتبارسنجی سمت سرور لازم است. JSON Schema میتواند نوع فیلد، الزامی بودن، قالب، محدوده عددی و ساختارهای تو در تو را توصیف کند؛ پشتیبانی دقیق از هر قابلیت به نسخه و ابزار validator وابسته است.
اعتبارسنجی باید در سمت سرور نیز انجام شود، حتی اگر رابط کاربری قبلاً داده را بررسی کرده باشد؛ زیرا درخواست میتواند مستقیماً از طریق ابزارهای دیگر ارسال شود. پیام خطا بهتر است روشن و کاربردی باشد، اما جزئیات داخلی سامانه یا اطلاعات محرمانه را آشکار نکند.
تفاوت JSON با XML و CSV
JSON برای ساختارهای تو در تو، مجموعه فیلدهای نامدار و پاسخهای API مناسب است. XML از تگها و ویژگیها استفاده میکند و در بعضی محیطها به namespaceها، اسناد ساختاریافته یا سامانههای قدیمی متکی است. CSV برای دادههای جدولی با ردیف و ستون ساده خواناست، اما برای مدلکردن objectهای تودرتو به قراردادهای جانبی نیاز پیدا میکند.
از نظر حجم، سرعت یا مصرف حافظه نمیتوان گفت JSON در همه شرایط از قالبهای دیگر بهتر است؛ نتیجه به اندازه داده، پیادهسازی، فشردهسازی، زبان و الگوی مصرف بستگی دارد. برای انتخاب قالب، ساختار موردنیاز، سازگاری، قابلیت اعتبارسنجی، خوانایی، امنیت و هزینه نگهداری را در کنار هم بسنجید.
JSON-LD و دادههای ساختیافته در سئو
JSON-LD روشی برای بیان دادههای ساختیافته با استفاده از قالب JSON است. در صفحات وب میتواند اطلاعاتی مانند سازمان، مقاله یا محصول را با واژگان استانداردی مثل Schema.org توصیف کند. این دادهها معمولاً در یک عنصر script با نوع application/ld+json قرار میگیرند؛ در این حالت JSON بخشی از نشانهگذاری صفحه است، نه متنی که الزاماً به بازدیدکننده نمایش داده میشود.
نمونه ساده زیر فقط شکل کلی JSON-LD را نشان میدهد؛ برای استفاده واقعی باید نوع موجودیت، نشانیها، تصویر، تاریخها و سایر فیلدها با محتوای واقعی صفحه مطابقت داشته باشند:
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Organization",
"name": "واریان شبکه گستر",
"url": "https://varianet.ir/"
}
</script>
وجود نشانهگذاری JSON-LD تضمین نمیکند که موتور جستوجو نتیجه غنی نمایش دهد. داده باید صحیح، مرتبط و مطابق سیاستهای جاری موتور جستوجو باشد و با محتوای قابل مشاهده صفحه تناقض نداشته باشد. پس از افزودن داده ساختیافته، آن را با ابزارهای معتبر آزمایش و وضعیت آن را در گزارشهای مرتبط پایش کنید. نشانهگذاری ساختیافته را برای محتوایی که واقعاً در صفحه وجود ندارد، به کار نبرید.
امنیت و نکات عملی هنگام استفاده از JSON
- ورودی را معتبرسنجی کنید: داده ورودی را قابل اعتماد فرض نکنید؛ نوع، اندازه و مقادیر فیلدها را کنترل کنید.
- محدودیت اندازه داشته باشید: JSON بسیار بزرگ یا عمیق میتواند مصرف حافظه و زمان پردازش را افزایش دهد.
- داده را بیاحتیاط به HTML وارد نکنید: خروجی باید متناسب با محل استفاده escape یا ایمنسازی شود؛ معتبر بودن JSON به معنی امن بودن HTML نیست.
- از اجرای متن دریافتی خودداری کنید: JSON را با parser استاندارد بخوانید، نه با
eval()یا سازوکار اجرای کد. - اطلاعات حساس را افشا نکنید: رمز عبور، توکن دسترسی، کلید API و اطلاعات شخصی نباید بیدلیل در لاگها یا پاسخهای عمومی قرار بگیرند.
- قرارداد داده را مستند کنید: نوع فیلد، واحدها، منطقه زمانی، معنا و رفتار مقدارهای تهی را مشخص کنید.
- نسخهبندی و آزمون داشته باشید: تغییرات ساختاری API را با آزمون سازگاری و برنامه انتشار مدیریت کنید.
در زیرساخت سازمانی، JSON اغلب در لاگهای برنامه، ابزارهای مانیتورینگ، فایلهای تنظیمات و پاسخ سرویسها دیده میشود. برای تحلیل دادههای عملیاتی، ضروری است قالب لاگ پایدار بماند و اطلاعات محرمانه پیش از ذخیره یا ارسال حذف یا پوشانده شوند. برای آشنایی با نگاه مدیریتی به استفاده از داده، مقاله راهنمای جامع تحلیل داده برای مدیران اجرایی میتواند مکمل این بحث باشد.
پرسشهای متداول درباره JSON
آیا JSON یک زبان برنامهنویسی است؟
خیر. JSON قالبی برای نمایش و تبادل داده است و بهتنهایی دستورهای اجرایی، حلقه، شرط یا تابع تعریف نمیکند.
آیا JSON فقط برای JavaScript کاربرد دارد؟
خیر. JSON مستقل از زبان است و کتابخانهها و ابزارهای آن در زبانهایی مانند Python، PHP، Java، C#، Go و بسیاری زبانهای دیگر وجود دارند.
چرا JSON من خطای Parse میدهد؟
علتهای متداول شامل نقلقول تکی، ویرگول انتهایی، کامنت، مقدارهای غیرمجاز مانند undefined یا NaN، و براکت یا آکولاد بستهنشده هستند. پیام خطای parser و شماره خط و ستون را بررسی کنید.
آیا JSON برای ذخیره رمز عبور مناسب است؟
JSON فقط قالب داده است و سازوکار امن ذخیرهسازی رمز عبور فراهم نمیکند. رمزها باید طبق اصول امنیتی مناسب و با سازوکارهای مخصوص هش رمز عبور نگهداری شوند؛ از قرار دادن اطلاعات محرمانه در فایل یا پاسخ عمومی JSON پرهیز کنید.
آیا JSON و JSON-LD یکی هستند؟
JSON قالب عمومی نمایش داده است؛ JSON-LD از این قالب برای بیان دادههای پیوندخورده و ساختیافته با واژگان مشخص استفاده میکند. بنابراین JSON-LD نوعی کاربرد استانداردشده JSON است، نه همان مفهوم عمومی JSON.
جمعبندی
JSON یکی از قالبهای مهم تبادل داده در وب و نرمافزار است؛ ساختار object و array آن برای انتقال دادههای ساده و تو در تو مناسب است و در APIها، برنامههای مختلف، فایلهای تنظیمات و دادههای ساختیافته کاربرد دارد. برای استفاده صحیح، قواعد نحوی را رعایت کنید، داده را با parser معتبر بخوانید، قرارداد معنایی را مستند کنید و ورودیها را اعتبارسنجی کنید.
در پروژه واقعی، خوانایی و سادگی JSON فقط بخشی از راهحل است. امنیت، نسخهبندی، کنترل دسترسی و سازگاری بین سرویسها باید جداگانه طراحی شوند. برای انتخاب زبان یا ابزار مناسب، از نیازهای پروژه شروع کنید و سپس قابلیت کتابخانهها، نگهداری و مهارت تیم را بسنجید.
منابع معتبر برای مطالعه بیشتر
- RFC 8259 — The JavaScript Object Notation (JSON) Data Interchange Format: مشخصات استاندارد قالب و قواعد نحوی JSON.
- ECMA-404 — The JSON Data Interchange Syntax: استاندارد نحوی JSON.
- MDN Web Docs — JSON in JavaScript: راهنمای متدهای JSON.parse و JSON.stringify.
- JSON Schema: اطلاعات و مستندات اعتبارسنجی ساختار داده JSON.
- Google Search Central — Structured data: راهنمای دادههای ساختیافته در جستوجو.