انواع داده در JSON؛ String، Number، Boolean، null، Object و Array

هنگام کار با JSON، فقط درست‌بودن آکولادها و ویرگول‌ها کافی نیست. هر مقدار در JSON یک نوع داده مشخص دارد و انتخاب اشتباه نوع می‌تواند باعث خطا در پردازش، مقایسه، اعتبارسنجی، ذخیره‌سازی یا نمایش داده شود. برای مثال مقدار "42" یک رشته است، اما 42 یک عدد؛ این دو از نظر ظاهری نزدیک‌اند ولی در برنامه رفتار یکسانی ندارند. شناخت دقیق انواع داده در JSON کمک می‌کند داده‌ای تولید کنید که هم از نظر Syntax معتبر باشد و هم معنای مورد انتظار را به مصرف‌کننده منتقل کند.

پاسخ سریع: JSON چه انواع داده‌ای دارد؟

JSON شش نوع مقدار اصلی دارد: String برای متن، Number برای عدد، Boolean برای مقادیر منطقی true و false، مقدار null برای نبودن آگاهانه مقدار، Object برای مجموعه‌ای از جفت‌های کلید و مقدار، و Array برای فهرستی مرتب از مقادیر. کلیدهای Object همیشه String هستند، اما مقدارها می‌توانند از هر یک از این شش نوع باشند. JSON نوع مستقلی برای تاریخ، زمان، باینری، عدد صحیح، Decimal یا Undefined ندارد و این داده‌ها باید با یک قرارداد مشخص نمایش داده شوند.

چرا نوع داده در JSON اهمیت دارد؟

نوع داده تعیین می‌کند یک مقدار پس از Parse شدن چگونه در حافظه نمایش داده شود و چه عملیات‌هایی روی آن منطقی باشد. عدد را می‌توان جمع کرد، Boolean را می‌توان در شرط به‌کار برد، Array را می‌توان پیمایش کرد و Object را می‌توان بر اساس کلید خواند. اگر نوع به‌اشتباه انتخاب شود، برنامه ممکن است بدون خطای Syntax داده را بپذیرد اما نتیجه‌ای نادرست تولید کند.

• محاسبه: رشته "10" لزوماً مانند عدد 10 جمع نمی‌شود.
• مرتب‌سازی: مرتب‌سازی رشته‌ای مقادیر "2" و "10" با مرتب‌سازی عددی فرق دارد.
• اعتبارسنجی: Schema می‌تواند عدد را بپذیرد و رشته عددی را رد کند.
• پایگاه داده: نگاشت اشتباه نوع ممکن است ایندکس، Query و گزارش را خراب کند.
• رابط کاربری: مقدار false با رشته "false" یکسان نیست؛ رشته غیرخالی در بسیاری از زبان‌ها truthy محسوب می‌شود.

نمای کلی شش نوع داده JSON

نوع	نمونه	کاربرد معمول	نکته مهم
String	"Tehran"	نام، متن، شناسه، تاریخ قراردادی	باید داخل کوتیشن دوتایی باشد
Number	19.75	تعداد، قیمت، امتیاز، مختصات	NaN و Infinity مجاز نیستند
Boolean	true	وضعیت روشن/خاموش یا بله/خیر	بدون کوتیشن و با حروف کوچک
null	null	نبودن آگاهانه مقدار	با حذف فیلد یکسان نیست
Object	{"id": 7}	رکورد و موجودیت دارای ویژگی	کلیدها همیشه String هستند
Array	["a", "b"]	فهرست مرتب از مقادیر	می‌تواند نوع‌های متفاوت داشته باشد

String در JSON چیست؟

String دنباله‌ای از نویسه‌های Unicode است که میان کوتیشن دوتایی قرار می‌گیرد. نام کاربر، توضیح، ایمیل، کد محصول و حتی شناسه‌ای که نباید روی آن محاسبه انجام شود معمولاً String هستند. کوتیشن تکی در JSON استاندارد جایگزین کوتیشن دوتایی نیست.

{
  "name": "Amirhossein",
  "city": "تهران",
  "productCode": "00158"
}

در مثال بالا، productCode عمداً String است. اگر آن را Number بنویسیم، صفرهای ابتدایی معنا و نمایش خود را از دست می‌دهند. شماره تلفن، کد ملی، کد پستی و شماره کارت نیز با وجود داشتن رقم، معمولاً عدد محاسباتی نیستند و بهتر است String باشند.

Escape کردن نویسه‌ها در String

برای قرار دادن کوتیشن، Backslash یا برخی نویسه‌های کنترلی داخل String باید از Escape استفاده شود. رایج‌ترین توالی‌ها عبارت‌اند از "، \، ، و . نویسه‌های کنترلی خام در String مجاز نیستند.

{
  "message": "او گفت: "سلام"",
  "path": "C:\data\report.json",
  "multiline": "خط اول
خط دوم"
}

نمونه صحیح و غلط String

نمونه	وضعیت	دلیل
"hello"	صحیح	کوتیشن دوتایی دارد
'hello'	غلط	JSON کوتیشن تکی را برای String نمی‌پذیرد
"a b"	صحیح	خط جدید Escape شده است
String دارای خط جدید خام	غلط	نویسه کنترلی باید Escape شود

Number در JSON چیست؟

Number برای نمایش اعداد صحیح، اعشاری و نمایی استفاده می‌شود. JSON میان Integer و Float نوع جداگانه‌ای تعریف نمی‌کند؛ همه در سطح Syntax از نوع Number هستند. این Runtime یا کتابخانه مقصد است که تصمیم می‌گیرد مقدار را به چه نوع عددی نگاشت کند.

{
  "quantity": 12,
  "price": 349.95,
  "temperature": -4.5,
  "distance": 1.2e6
}

قواعد مهم Number

• عدد نباید داخل کوتیشن باشد، مگر اینکه عمداً رشته باشد.
• علامت مثبت ابتدایی مانند +12 مجاز نیست.
• صفر ابتدایی در عدد صحیح مانند 007 مجاز نیست؛ خود 0 مجاز است.
• ممیز باید رقم قبل و بعد داشته باشد؛ .5 و 5. معتبر نیستند.
• NaN، Infinity و -Infinity جزو JSON استاندارد نیستند.
• جداکننده هزارگان مانند 1,000 در یک Number مجاز نیست.

محدودیت دقت عددی

استاندارد JSON Syntax عدد را تعریف می‌کند، اما دقت عملی به Parser مقصد وابسته است. در JavaScript نوع Number معمولاً بر پایه IEEE 754 double است؛ بنابراین همه اعداد صحیح بسیار بزرگ را دقیق نگه نمی‌دارد. شناسه‌های ۶۴ بیتی، مبالغ مالی حساس یا Decimalهای دقیق ممکن است هنگام عبور میان سیستم‌ها گرد شوند.

برای شناسه‌های بزرگ یا مقادیری که حفظ رقم‌ها از انجام محاسبه مهم‌تر است، استفاده از String همراه با قرارداد روشن معمولاً امن‌تر است. برای پول نیز بهتر است مقدار را به کوچک‌ترین واحد صحیح، مانند ریال یا سنت، ذخیره کنید یا از قرارداد Decimal مشخصی استفاده کنید.

{
  "orderId": "9223372036854775807",
  "amountInCents": 129900
}

Boolean در JSON چیست؟

Boolean فقط دو مقدار دارد: true و false. این کلمات باید با حروف کوچک و بدون کوتیشن نوشته شوند. Boolean برای وضعیت‌هایی مناسب است که واقعاً دوحالته‌اند؛ مانند فعال‌بودن حساب، پذیرش قوانین یا نمایش یک بخش.

{
  "isActive": true,
  "emailVerified": false
}

رشته‌های "true" و "false" Boolean نیستند. همچنین اعداد 0 و 1 در JSON Boolean محسوب نمی‌شوند، حتی اگر برنامه مقصد قراردادی برای تفسیر آن‌ها داشته باشد.

چه زمانی Boolean کافی نیست؟

اگر وضعیت بیش از دو حالت دارد، Boolean انتخاب ضعیفی است. برای نمونه وضعیت سفارش فقط «ارسال شده یا نشده» نیست و ممکن است حالت‌های pending، paid، shipped، delivered و cancelled داشته باشد. در چنین حالتی String محدودشده به مجموعه‌ای از مقادیر، مدل دقیق‌تری ایجاد می‌کند.

مقدار null در JSON چیست؟

null نشان می‌دهد مقدار عمداً وجود ندارد یا در حال حاضر مشخص نیست. این مقدار بدون کوتیشن نوشته می‌شود. null با رشته خالی، صفر، false و Array خالی تفاوت دارد.

{
  "middleName": null,
  "discount": 0,
  "notes": "",
  "isGift": false,
  "items": []
}

مقدار	معنای معمول
null	مقدار نیست، ناشناخته است یا عمداً تهی شده
""	مقدار متنی وجود دارد اما طول آن صفر است
0	مقدار عددی معتبر و برابر صفر است
false	وضعیت منطقی منفی است
[]	فهرست وجود دارد اما عضوی ندارد
حذف کلید	فیلد ارسال نشده؛ ممکن است «بدون تغییر» یا «نامعلوم» معنا دهد

null و فیلد حذف‌شده یکسان نیستند

در APIهای ویرایشی، تفاوت این دو بسیار مهم است. در یک درخواست PATCH، نبودن کلید ممکن است یعنی «مقدار فعلی را تغییر نده»، در حالی که ارسال "avatarUrl": null ممکن است یعنی «تصویر فعلی را حذف کن». این معنا را خود JSON تعیین نمی‌کند؛ قرارداد API باید آن را شفاف کند.

Object در JSON چیست؟

Object مجموعه‌ای بدون ترتیب معنایی از جفت‌های کلید و مقدار است. Object با آکولاد باز و بسته می‌شود، کلیدها String هستند و میان کلید و مقدار علامت Colon قرار می‌گیرد. اعضا با Comma جدا می‌شوند.

{
  "user": {
    "id": 42,
    "name": "Sara",
    "active": true,
    "profile": null
  }
}

مقدار هر کلید می‌تواند هر نوع JSON، از جمله Object یا Array دیگر باشد. همین قابلیت امکان ساخت ساختارهای تودرتو را فراهم می‌کند. برای شرح کامل‌تر ساختار و قوانین، مقاله JSON Object چیست؟ را بخوانید.

کلیدهای تکراری در Object

برخی Parserها JSON دارای کلید تکراری را Parse می‌کنند، اما رفتار یکسانی ندارند: ممکن است اولین مقدار، آخرین مقدار یا خطا را انتخاب کنند. به همین دلیل کلیدهای Object باید یکتا باشند، حتی اگر Parser خاص شما ورودی تکراری را بپذیرد.

{
  "role": "user",
  "role": "admin"
}

نمونه بالا قابل اتکا نیست و می‌تواند پیامد امنیتی داشته باشد؛ زیرا سامانه‌های مختلف شاید مقدار متفاوتی را معتبر بدانند.

Array در JSON چیست؟

Array فهرستی مرتب از مقدارهاست که با براکت باز و بسته نوشته می‌شود. ترتیب اعضا بخشی از داده است و هر عضو با اندیس عددی قابل دسترسی است. اعضای Array می‌توانند از هر نوع JSON باشند.

{
  "tags": ["json", "api", "data"],
  "scores": [18, 19.5, 20],
  "users": [
    {"id": 1, "name": "Ali"},
    {"id": 2, "name": "Neda"}
  ]
}

JSON اجازه می‌دهد یک Array نوع‌های متفاوت داشته باشد، مانند [1, "two", true, null]؛ اما در بیشتر APIها Array همگن خواناتر و قابل‌اعتبارسنجی‌تر است. توضیح کامل‌تر در مقاله JSON Array چیست؟ آمده است.

Array خالی یا null؟

اگر فیلد ذاتاً فهرست است و فقط عضوی ندارد، [] معمولاً انتخاب روشن‌تری از null است. مصرف‌کننده می‌تواند بدون بررسی null روی Array پیمایش کند. با این حال اگر «فهرست هنوز بارگذاری نشده» با «فهرست بارگذاری شده و خالی است» تفاوت دارد، ممکن است قرارداد سه‌حالته لازم باشد.

JSON چه نوع‌هایی ندارد؟

بسیاری از داده‌های رایج نوع داخلی JSON نیستند. آن‌ها معمولاً به شکل String، Number یا Object نمایش داده می‌شوند و معنا از طریق قرارداد، نام فیلد یا JSON Schema مشخص می‌شود.

مفهوم	نمایش رایج	نمونه	ریسک
Date/Time	String استانداردشده	"2026-08-06T10:30:00Z"	ابهام منطقه زمانی و قالب
Decimal دقیق	String یا واحد صحیح کوچک	"19.99" یا 1999	گردشدن اعشاری
Binary	Base64 String یا URL فایل	"SGVsbG8="	افزایش حجم و نبود تشخیص نوع
Undefined	حذف کلید یا null	وابسته به قرارداد	تفاوت معنایی
Enum	String یا Number قراردادی	"pending"	مقادیر خارج از مجموعه
Big Integer	String	"9007199254740993"	از دست رفتن دقت
Map با کلید غیرمتنی	Array از جفت‌ها	[[1,"a"],[2,"b"]]	نیاز به تبدیل سفارشی

تاریخ و زمان را چگونه در JSON ذخیره کنیم؟

JSON نوع Date ندارد. متداول‌ترین راه استفاده از String با قالب ISO 8601 و منطقه زمانی صریح است. برای زمان جهانی، پسوند Z استفاده می‌شود. اگر Offset محلی مهم است، آن را نیز ثبت کنید.

{
  "createdAt": "2026-08-06T06:45:00+03:30",
  "processedAt": "2026-08-06T03:15:00Z"
}

رشته‌هایی مانند 06/08/2026 مبهم‌اند، چون ممکن است روز/ماه یا ماه/روز تفسیر شوند. Timestamp عددی نیز بدون مشخص‌کردن واحد خطرناک است؛ مقدار ممکن است ثانیه یا میلی‌ثانیه از Epoch باشد. نام فیلد یا مستندات باید واحد را مشخص کند، مانند createdAtUnixSeconds.

نمونه واقعی: مدل‌سازی یک سفارش

{
  "orderId": "ORD-2026-00421",
  "customer": {
    "id": 1842,
    "name": "مریم احمدی",
    "email": "maryam@example.test"
  },
  "items": [
    {
      "sku": "BK-001",
      "title": "کتاب آموزش API",
      "quantity": 2,
      "unitPriceRials": 850000,
      "available": true
    }
  ],
  "couponCode": null,
  "paid": false,
  "status": "pending",
  "createdAt": "2026-08-06T06:45:00+03:30"
}

در این مدل، شناسه سفارش String است چون برای محاسبه نیست، مشتری Object است، اقلام Array هستند، تعداد و قیمت Number هستند، وضعیت موجودی و پرداخت Boolean هستند، نبود کوپن با null بیان شده و زمان با String قراردادی ذخیره شده است. این تفکیک باعث می‌شود مصرف‌کننده بدون حدس‌زدن نوع هر فیلد را بفهمد.

مثال صحیح و غلط در انتخاب نوع

قیمت به‌صورت متن

{
  "price": "1,299,000 تومان"
}

این مقدار برای نمایش مناسب است اما برای محاسبه، فیلتر و مرتب‌سازی مناسب نیست. مدل بهتر داده خام را از متن نمایشی جدا می‌کند:

{
  "priceRials": 12990000,
  "currency": "IRR"
}

Boolean به‌صورت String

{
  "isAdmin": "false"
}

در برخی زبان‌ها هر String غیرخالی در شرط true تلقی می‌شود. شکل درست:

{
  "isAdmin": false
}

شناسه عددی بسیار بزرگ

{
  "eventId": 9223372036854775807
}

اگر داده از محیطی عبور کند که دقت عدد صحیح محدود دارد، رقم‌ها ممکن است تغییر کنند. برای شناسه‌ای که عملیات حسابی ندارد:

{
  "eventId": "9223372036854775807"
}

نوع داده پس از Parse در زبان‌های مختلف

JSON یک قالب مستقل از زبان است، اما هر Parser مقدارها را به نوع‌های همان زبان نگاشت می‌کند. این نگاشت همیشه یک‌به‌یک نیست.

JSON	JavaScript	Python	C# با System.Text.Json
String	string	str	string یا JsonElement
Number	number	int/float	int/long/decimal/double طبق مدل
Boolean	boolean	bool	bool
null	null	None	null برای نوع nullable
Object	object	dict	کلاس، Dictionary یا JsonElement
Array	Array	list	Array/List یا JsonElement

JavaScript

const data = JSON.parse('{"count":2,"active":true}');
console.log(typeof data.count);  // number
console.log(typeof data.active); // boolean

JSON.parse تاریخ را خودکار به Date تبدیل نمی‌کند؛ تاریخ همچنان String باقی می‌ماند، مگر اینکه پس از Parse تبدیل سفارشی انجام دهید.

Python

import json

data = json.loads('{"count": 2, "active": true, "note": null}')
print(type(data["count"]).__name__)   # int
print(type(data["active"]).__name__)  # bool
print(data["note"] is None)           # True

C#

public sealed class OrderDto
{
    public string OrderId { get; set; } = string.Empty;
    public long AmountRials { get; set; }
    public bool Paid { get; set; }
    public DateTimeOffset CreatedAt { get; set; }
}

در مدل Strongly Typed، Serializer تلاش می‌کند JSON را با نوع Propertyها هماهنگ کند. اگر API گاهی Number و گاهی String بفرستد، Deserialization می‌تواند خطا دهد یا به Converter سفارشی نیاز پیدا کند. ثبات نوع در قرارداد API از این پیچیدگی جلوگیری می‌کند.

اعتبار Syntax با اعتبار نوع و معنا فرق دارد

JSON زیر از نظر Syntax معتبر است:

{
  "age": "twenty",
  "paid": "yes",
  "items": null
}

اما اگر قرارداد انتظار داشته باشد age Number، paid Boolean و items Array باشد، داده از نظر معنایی یا Schema نامعتبر است. یک JSON Validator معمولی معمولاً Syntax را بررسی می‌کند؛ برای اجبار نوع‌ها، فیلدهای الزامی، محدوده عدد و الگوهای String به JSON Schema یا اعتبارسنجی برنامه نیاز دارید.

خطاهای رایج مربوط به انواع داده JSON

1. قرار دادن همه مقادیر داخل کوتیشن: تبدیل Number و Boolean به String و ایجاد نیاز به تبدیل در مصرف‌کننده.
2. استفاده از null برای هر حالت خالی: از بین بردن تفاوت میان مقدار ناشناخته، رشته خالی و فهرست خالی.
3. ارسال نوع متغیر برای یک فیلد: یک‌بار id به‌صورت Number و بار دیگر String.
4. استفاده از عدد برای شناسه: خطر حذف صفر ابتدایی یا از دست رفتن دقت.
5. فرض وجود Date: انتظار تبدیل خودکار رشته تاریخ به شیء Date.
6. استفاده از NaN یا Infinity: تولید خروجی‌ای که JSON استاندارد نیست.
7. کلید تکراری در Object: رفتار متفاوت Parserها و احتمال دورزدن کنترل‌ها.
8. Array ناهمگن بدون دلیل: پیچیده‌شدن مدل، UI و اعتبارسنجی.
9. ذخیره واحد در متن عدد: مقدارهایی مانند "12 kg" که محاسبه را دشوار می‌کنند.
10. ابهام Timestamp: مشخص نبودن ثانیه، میلی‌ثانیه یا منطقه زمانی.

راهنمای Troubleshooting

چرا جمع دو مقدار نتیجه متنی می‌دهد؟

احتمالاً یکی یا هر دو مقدار String هستند. JSON ورودی را بررسی کنید و مطمئن شوید عدد بدون کوتیشن ارسال شده است. تبدیل در سمت مصرف‌کننده می‌تواند مشکل را موقتاً حل کند، اما اصلاح قرارداد منبع بهتر است.

چرا Parser عدد بزرگ را تغییر می‌دهد؟

دقت نوع عددی Runtime محدود است. شناسه بزرگ را String منتقل کنید یا از Parser و نوع عددی دلخواه با دقت کافی استفاده کنید. تبدیل عدد آسیب‌دیده به String دقت ازدست‌رفته را برنمی‌گرداند.

چرا مقدار false به‌صورت true رفتار می‌کند؟

بررسی کنید مقدار واقعاً Boolean باشد، نه String "false". در بسیاری از زبان‌ها String غیرخالی در شرط truthy است.

چرا Deserialization در C# یا Java خطا می‌دهد؟

نوع JSON با نوع Property مدل هماهنگ نیست، فیلد null به نوع non-nullable رسیده یا یک Array/Object در جای نوع ساده ارسال شده است. خطای دقیق Serializer و مسیر Property را بخوانید و ورودی را با مدل مقایسه کنید.

چرا تاریخ پس از Parse هنوز String است؟

زیرا JSON نوع Date ندارد. تاریخ را پس از Parse با Parser تاریخ و قالب مشخص تبدیل کنید یا از مدل Strongly Typed و Serializer پیکربندی‌شده استفاده کنید.

نکات امنیتی انواع داده در JSON

• نوع ورودی را اعتماد نکنید: حتی JSON معتبر می‌تواند نوع غیرمنتظره داشته باشد. در مرز API اعتبارسنجی انجام دهید.
• کلیدهای تکراری را رد کنید: اختلاف Parserها می‌تواند موجب Parameter Smuggling یا دورزدن کنترل شود.
• محدوده Number را بررسی کنید: عدد بسیار بزرگ، منفی یا اعشاری ممکن است در منطق قیمت، موجودی یا مجوز خطر ایجاد کند.
• طول String و Array را محدود کنید: ورودی بسیار بزرگ می‌تواند حافظه و CPU را مصرف کند.
• null را صریح مدیریت کنید: Null Dereference یا نادیده‌گرفتن کنترل دسترسی ممکن است از فرض نادرست درباره مقدار ایجاد شود.
• نوع را جایگزین مجوز ندانید: معتبر بودن Boolean مانند isAdmin به معنی قابل اعتماد بودن آن نیست؛ مجوز باید در سرور تعیین شود.

نکات عملکرد و اندازه داده

انتخاب نوع بر حجم و سرعت پردازش اثر دارد، اما بهینه‌سازی نباید قرارداد را مبهم کند. Number معمولاً از نمایش متنی همان عدد کوتاه‌تر است، Boolean از رشته "true" کوچک‌تر است و حذف فیلدهای اختیاری ممکن است حجم را کاهش دهد. با این حال تبدیل مداوم نوع‌ها، Arrayهای بسیار بزرگ و Objectهای عمیق هزینه Parse و حافظه را افزایش می‌دهند.

• ساختار را بیش از نیاز تودرتو نکنید.
• برای پاسخ‌های بزرگ Pagination یا Streaming در نظر بگیرید.
• داده باینری بزرگ را بی‌دلیل Base64 داخل JSON نگذارید؛ Base64 حجم را افزایش می‌دهد.
• در Arrayهای بزرگ، شکل ثابت Objectها پردازش و فشرده‌سازی را ساده‌تر می‌کند.
• قبل از بهینه‌سازی، اندازه واقعی Payload و هزینه Parse را اندازه‌گیری کنید.

بهترین روش‌های انتخاب نوع داده

1. بر اساس معنا انتخاب کنید، نه ظاهر: رشته‌ای از رقم‌ها لزوماً Number نیست.
2. نوع هر فیلد را ثابت نگه دارید: یک فیلد در همه پاسخ‌ها همان نوع را داشته باشد.
3. واحد را در نام یا قرارداد مشخص کنید: مانند durationSeconds و amountRials.
4. برای تاریخ قالب و منطقه زمانی تعیین کنید: ترجیحاً String استاندارد و بدون ابهام.
5. میان null، خالی و حذف‌شده تفاوت بگذارید: رفتار هرکدام را مستند کنید.
6. برای داده مالی درباره دقت تصمیم بگیرید: واحد صحیح کوچک یا Decimal قراردادی.
7. Array را تا حد ممکن همگن نگه دارید: نوع اعضا قابل پیش‌بینی باشد.
8. از Schema استفاده کنید: فقط Syntax کافی نیست؛ نوع و محدودیت‌ها را نیز اعتبارسنجی کنید.
9. نمونه‌های مرزی تست کنید: صفر، عدد منفی، String خالی، null، Array خالی و عدد بزرگ.
10. خروجی Serializer را بررسی کنید: برخی تنظیمات nullها را حذف یا Enum را عددی می‌کنند.

چک‌لیست بررسی انواع داده در JSON

• آیا متن‌ها با کوتیشن دوتایی نوشته شده‌اند؟
• آیا Numberها واقعاً برای محاسبه هستند؟
• آیا شناسه‌ها و کدهای دارای صفر ابتدایی String هستند؟
• آیا Booleanها بدون کوتیشن و با حروف کوچک‌اند؟
• آیا معنای null با حذف فیلد تفاوت مشخصی دارد؟
• آیا Arrayها نوع اعضای قابل پیش‌بینی دارند؟
• آیا Objectها کلید تکراری ندارند؟
• آیا تاریخ، Timestamp و واحد زمان بدون ابهام‌اند؟
• آیا اعداد بزرگ و مبالغ دقیق در همه Runtimeها سالم می‌مانند؟
• آیا نوع‌ها با JSON Schema یا اعتبارسنجی سرور کنترل می‌شوند؟
• آیا ورودی‌های بزرگ، عمیق یا غیرمنتظره محدود شده‌اند؟
• آیا نمونه JSON با ابزار Validator و Viewer بررسی شده است؟

جمع‌بندی

انواع داده در JSON شامل String، Number، Boolean، null، Object و Array هستند. انتخاب درست میان این نوع‌ها فقط برای معتبرشدن Syntax نیست؛ مستقیماً بر محاسبه، اعتبارسنجی، دقت، امنیت، سازگاری میان زبان‌ها و نگهداری API اثر می‌گذارد. داده را بر اساس معنای واقعی مدل کنید: شناسه را صرفاً به‌دلیل عددی‌بودن ظاهر Number نکنید، Boolean را String نفرستید، تفاوت null و مقدار خالی را تعریف کنید و برای تاریخ، Decimal و عدد بزرگ قرارداد صریح داشته باشید. برای مرور ساختار کلی می‌توانید مقاله JSON چیست؟ را بخوانید و برای بررسی عملی داده از ابزارهای JSON سایت استفاده کنید.