تبدیل JSON به CSV زمانی لازم میشود که دادهای ساختیافته از API، فایل تنظیمات، خروجی یک سرویس یا پایگاه داده در اختیار دارید، اما مقصد نهایی شما یک جدول قابل بازشدن در Excel، Google Sheets، نرمافزارهای تحلیل داده یا ابزارهای گزارشگیری است. این تبدیل در ظاهر ساده به نظر میرسد: هر ویژگی به یک ستون و هر شیء به یک ردیف تبدیل میشود. بااینحال، تفاوت بنیادی میان ساختار درختی JSON و ساختار دوبعدی CSV باعث میشود موضوعاتی مثل آرایههای تودرتو، objectهای داخلی، کلیدهای نامنظم، مقدارهای null، کاراکترهای جداکننده، کوتیشن و Encoding اهمیت زیادی پیدا کنند.
پاسخ سریع: برای تبدیل JSON به CSV، ورودی مناسب معمولاً آرایهای از objectها است. مجموعه کلیدهای objectها بهعنوان Header انتخاب میشود، هر object یک ردیف میسازد و مقدار هر کلید در ستون متناظر قرار میگیرد. مقدارهایی که شامل ویرگول، کوتیشن یا خط جدید هستند باید طبق قواعد CSV داخل کوتیشن قرار گیرند و کوتیشن داخلی آنها دو برابر شود. دادههای تودرتو نیز پیش از تبدیل باید Flatten، انتخاب یا به رشته تبدیل شوند.
تبدیل JSON به CSV دقیقاً چه کاری انجام میدهد؟
JSON میتواند String، Number، Boolean، null، Array و Object را بهصورت ترکیبی و در چند سطح نگه دارد. CSV در سادهترین تعریف، مجموعهای از ردیفها و ستونها است. بنابراین تبدیل JSON به CSV نوعی نگاشت از یک ساختار احتمالا درختی به یک ساختار جدولی است. در این نگاشت باید مشخص شود چه چیزی ردیف، چه چیزی ستون و مقدار هر سلول چگونه نمایش داده شود.
برای نمونه، این JSON از سه رکورد همشکل تشکیل شده است:
[
{
"id": 101,
"name": "سارا",
"active": true
},
{
"id": 102,
"name": "امیر",
"active": false
},
{
"id": 103,
"name": "مینا",
"active": true
}
]
خروجی طبیعی آن در CSV چنین است:
id,name,active
101,سارا,true
102,امیر,false
103,مینا,true
در این مثال هر object یک ردیف است، کلیدهای id، name و active Header را میسازند و مقدارها مستقیماً در سلول قرار میگیرند. مسئله از زمانی پیچیده میشود که objectها کلیدهای متفاوت داشته باشند یا مقدار یک کلید خودش object یا array باشد.
JSON مناسب برای تبدیل به CSV چه ساختاری دارد؟
بهترین ورودی برای تبدیل مستقیم، یک آرایه در سطح ریشه است که اعضای آن objectهای نسبتاً همشکل باشند. منظور از همشکل این نیست که همه رکوردها الزاماً تمام کلیدها را داشته باشند، بلکه بهتر است هر کلید معنای ثابتی داشته باشد. برای مثال price در تمام رکوردها قیمت باشد و گاهی بهجای عدد، object یا متن توضیحی نباشد.
حالت ایدهآل: آرایهای از objectهای تخت
[
{"sku": "A-10", "title": "کیبورد", "price": 1250000},
{"sku": "A-11", "title": "ماوس", "price": 790000}
]
این ساختار بدون تصمیم اضافی به جدول تبدیل میشود، زیرا ردیفها و ستونها واضحاند.
یک object منفرد
اگر ورودی فقط یک object باشد، بسیاری از مبدلها آن را یک ردیف در نظر میگیرند:
{"id": 15, "name": "گزارش روزانه", "status": "ready"}
خروجی میتواند شامل یک Header و یک ردیف داده باشد. بااینحال، برخی ابزارها فقط آرایه را میپذیرند؛ در این حالت object را داخل آرایه قرار دهید.
آرایهای از مقدارهای ساده
["red", "green", "blue"]
چنین آرایهای ستونهای معنایی ندارد. مبدل ممکن است یک ستون با نامی مانند value بسازد یا هر عضو را در یک ردیف بدون Header قرار دهد. بهتر است پیش از تبدیل، ساختار را صریح کنید:
[
{"color": "red"},
{"color": "green"},
{"color": "blue"}
]
الگوریتم استاندارد تبدیل JSON به CSV
یک تبدیلکننده قابلاعتماد معمولاً این مراحل را انجام میدهد:
- متن JSON را Parse میکند. اگر Syntax نامعتبر باشد، تبدیل باید متوقف شود.
- مشخص میکند ریشه ورودی object است یا array.
- رکوردهای قابلتبدیل را استخراج میکند.
- مجموعه ستونها را از کلیدهای رکوردها به دست میآورد.
- برای هر رکورد، مقدار متناظر هر ستون را پیدا میکند.
- مقدارهای تودرتو را بر اساس سیاست انتخابی Flatten یا Serialize میکند.
- هر مقدار را طبق قواعد escaping فرمت CSV ایمن میکند.
- Header و ردیفها را با Delimiter انتخابی کنار هم قرار میدهد.
- خروجی را با Encoding مناسب، معمولاً UTF-8، ذخیره میکند.
نکته مهم این است که Formatter یا Validator JSON جایگزین این تبدیل نیست. Formatter فقط ظاهر JSON را خواناتر میکند، Validator صحت Syntax را بررسی میکند و تبدیلکننده ساختار داده را از مدل درختی به مدل جدولی نگاشت میکند.
انتخاب ستونها وقتی کلید رکوردها یکسان نیست
در دادههای واقعی، همه objectها لزوماً کلیدهای یکسان ندارند:
[
{"id": 1, "name": "علی", "email": "ali@example.test"},
{"id": 2, "name": "نگار", "phone": "09120000000"},
{"id": 3, "name": "رضا", "email": "reza@example.test", "city": "شیراز"}
]
دو راه اصلی برای ساخت Header وجود دارد:
| روش | نحوه ساخت ستونها | مزیت | محدودیت |
|---|---|---|---|
| کلیدهای رکورد اول | فقط کلیدهای اولین object | سریع و قابل پیشبینی | ممکن است داده رکوردهای بعدی حذف شود |
| اجتماع همه کلیدها | تمام کلیدهای مشاهدهشده در همه رکوردها | از حذف داده جلوگیری میکند | برای داده بزرگ نیازمند اسکن کامل یا مدیریت پویا است |
برای خروجی عمومی و بدون اتلاف، اجتماع همه کلیدها انتخاب امنتری است. سلول مربوط به کلیدی که در یک رکورد وجود ندارد معمولاً خالی میماند. این وضعیت با مقدار صریح null از نظر معنایی یکسان نیست، اما در CSV هر دو غالباً به سلول خالی تبدیل میشوند؛ اگر این تفاوت مهم است باید یک قرارداد مشخص مثل رشته NULL تعریف کنید.
قواعد کوتیشن و Escape در CSV
بخش مهم تبدیل JSON به CSV، تولید سلولهای معتبر است. اگر جداکننده ویرگول باشد، مقداری که شامل ویرگول، کوتیشن دوتایی یا خط جدید است باید داخل کوتیشن دوتایی قرار گیرد. هر کوتیشن دوتایی داخل مقدار نیز باید دو برابر شود.
| مقدار اصلی | نمایش درست در CSV | دلیل |
|---|---|---|
Tehran | Tehran | کاراکتر ویژه ندارد |
تهران، ایران | "تهران، ایران" | در حالت ویرگول انگلیسی، فقط وجود ویرگول انگلیسی الزامآور است؛ بااینحال کوتیشنگذاری محافظهکارانه مجاز است |
Tehran, Iran | "Tehran, Iran" | مقدار شامل Delimiter است |
او گفت "سلام" | "او گفت ""سلام""" | کوتیشن داخلی دو برابر میشود |
| متن چندخطی | کل مقدار داخل کوتیشن | شکست خط نباید ردیف جدید تلقی شود |
نمونه صحیح:
id,title,note
1,"تهران, ایران","او گفت ""سلام"""
2,شیراز,"خط اول
خط دوم"
نمونه غلط:
id,title,note
1,تهران, ایران,او گفت "سلام"
در نمونه غلط، نرمافزار مقصد ممکن است مقدار تهران, ایران را دو ستون ببیند و تعداد سلولهای ردیف با Header هماهنگ نباشد.
تبدیل objectهای تودرتو
CSV ذاتاً ساختار تودرتو ندارد. برای این داده باید یک سیاست مشخص انتخاب شود:
[
{
"id": 1,
"name": "مریم",
"address": {
"city": "تبریز",
"postalCode": "51368"
}
}
]
روش اول: Flatten کردن مسیرها
id,name,address.city,address.postalCode
1,مریم,تبریز,51368
این روش برای تحلیل داده و فیلترکردن ستونها مناسب است. جداکننده مسیر میتواند نقطه، زیرخط یا قرارداد دیگری باشد. باید مراقب برخورد نامها باشید؛ برای مثال کلید واقعی address.city ممکن است با مسیر Flattenشده همنام شود.
روش دوم: تبدیل object داخلی به JSON String
id,name,address
1,مریم,"{""city"":""تبریز"",""postalCode"":""51368""}"
این روش ساختار داخلی را حفظ میکند، اما تحلیل آن در ابزارهای جدولی دشوارتر است. همچنین کوتیشنهای JSON باید دوباره برای CSV Escape شوند.
روش سوم: انتخاب چند فیلد مشخص
در گزارشهای تجاری معمولاً فقط ستونهای موردنیاز استخراج میشوند؛ مثلا id، name و address.city. این روش خروجی تمیزتر و پایدارتر میسازد و از تولید دهها ستون کماستفاده جلوگیری میکند.
آرایههای تودرتو را چگونه به CSV تبدیل کنیم؟
آرایه داخلی مهمترین منبع ابهام است:
[
{
"orderId": 5001,
"customer": "سامان",
"items": [
{"sku": "P10", "qty": 2},
{"sku": "P22", "qty": 1}
]
}
]
سه مدل رایج وجود دارد:
| مدل | خروجی | کاربرد |
|---|---|---|
| Join کردن اعضا | یک ردیف سفارش و یک سلول مانند P10:2 | P22:1 | نمایش انسانی و گزارش خلاصه |
| JSON String | کل آرایه داخل یک سلول | حفظ جزئیات برای پردازش بعدی |
| تکثیر ردیف | برای هر item یک ردیف با تکرار orderId | تحلیل اقلام سفارش |
در مدل تکثیر ردیف، خروجی میتواند چنین باشد:
orderId,customer,item.sku,item.qty
5001,سامان,P10,2
5001,سامان,P22,1
هیچیک از این روشها بهطور مطلق بهترین نیست. انتخاب باید بر اساس هدف فایل CSV انجام شود. برای Pivot Table یا جمعزدن تعداد کالا، تکثیر ردیف مناسبتر است. برای آرشیو موقت، نگهداری JSON String میتواند اطلاعات بیشتری را حفظ کند.
تفاوت مقدار گمشده، null و رشته خالی
در JSON سه حالت زیر متفاوتاند:
[
{"id": 1},
{"id": 2, "note": null},
{"id": 3, "note": ""}
]
- در ردیف اول کلید
noteاصلاً وجود ندارد. - در ردیف دوم کلید وجود دارد و مقدار آن
nullاست. - در ردیف سوم مقدار یک String خالی است.
CSV نوع داده و مفهوم null را بهصورت استاندارد و یکنواخت نگه نمیدارد. اگر هر سه حالت به سلول خالی تبدیل شوند، تفاوت آنها از بین میرود. در سامانهای که این تفاوت اهمیت دارد، میتوانید برای null از یک Token توافقی مثل \N یا NULL استفاده کنید و مقدار گمشده را خالی بگذارید. این قرارداد باید برای مصرفکننده فایل مستند باشد.
حفظ نوع دادهها در تبدیل JSON به CSV
JSON بین Number، Boolean و String تفاوت روشن دارد، اما CSV در اصل متن است. نرمافزار مقصد ممکن است هنگام بازکردن فایل، نوع ستون را حدس بزند. این حدس همیشه درست نیست.
- کد پستی
"00123"ممکن است به عدد 123 تبدیل شود. - شناسه بزرگ ممکن است در صفحهگسترده به نمایش علمی تبدیل یا گرد شود.
- تاریخ
03/04/2026ممکن است بسته به Locale سوم آوریل یا چهارم مارس تفسیر شود. - رشتههایی مثل
TRUEممکن است Boolean تلقی شوند. - مقدارهای شروعشونده با
=،+،-یا@ممکن است در برخی صفحهگستردهها بهعنوان Formula بررسی شوند.
برای دادههای حساس به قالب، نوع مقصد را از قبل مشخص کنید یا خروجی را در مرحله Import نرمافزار مقصد با تنظیم نوع ستون وارد کنید. افزودن علامت یا کوتیشن بهتنهایی همیشه جلوی تبدیل خودکار نوع را نمیگیرد.
Encoding فارسی در فایل CSV
برای متن فارسی، UTF-8 انتخاب مناسب و رایج است. بااینحال بعضی نسخهها یا تنظیمات نرمافزارهای صفحهگسترده ممکن است فایل UTF-8 بدون BOM را اشتباه تشخیص دهند. راهکارهای عملی عبارتاند از:
- ذخیره فایل با UTF-8 و در صورت نیاز افزودن UTF-8 BOM.
- استفاده از قابلیت Import Text/CSV بهجای بازکردن مستقیم فایل.
- انتخاب صریح Encoding برابر UTF-8 در نرمافزار مقصد.
- بررسی جداکننده مناسب با Locale؛ در برخی محیطها semicolon بهتر از comma تشخیص داده میشود.
BOM جزو محتوای منطقی داده نیست، اما میتواند به تشخیص Encoding کمک کند. در Pipelineهای برنامهنویسی که BOM انتظار نمیرود، باید این گزینه قابلکنترل باشد.
Delimiter؛ ویرگول، semicolon یا tab؟
نام CSV به ویرگول اشاره دارد، اما در عمل جداکنندههای دیگری نیز استفاده میشوند. اگر مقدارهای متنی شما ویرگول فراوان دارند، semicolon یا tab میتواند خوانایی خام فایل را بهتر کند؛ البته escaping همچنان باید درست انجام شود.
| جداکننده | پسوند رایج | مزیت | نکته |
|---|---|---|---|
| Comma | .csv | رایج و قابلحمل | در متنهای انگلیسی و اعداد قالببندیشده زیاد دیده میشود |
| Semicolon | .csv | در برخی Localeها سازگارتر | مصرفکننده باید جداکننده را بداند |
| Tab | .tsv | مناسب متنهای دارای ویرگول | Tab داخل مقدار نیازمند مدیریت است |
تبدیل JSON به CSV در JavaScript
نمونه زیر اجتماع کلیدهای سطح اول را میسازد و قواعد اصلی escape را رعایت میکند. این نسخه برای objectهای تخت طراحی شده است:
function escapeCsv(value, delimiter = ",") {
if (value === null || value === undefined) return "";
const text =
typeof value === "object"
? JSON.stringify(value)
: String(value);
const mustQuote =
text.includes(delimiter) ||
text.includes('"') ||
text.includes("\n") ||
text.includes("\r");
const escaped = text.replace(/"/g, '""');
return mustQuote ? `"${escaped}"` : escaped;
}
function jsonToCsv(input, delimiter = ",") {
const rows = Array.isArray(input) ? input : [input];
if (!rows.every(
row => row && typeof row === "object" && !Array.isArray(row)
)) {
throw new TypeError("ورودی باید object یا آرایهای از objectها باشد.");
}
const headers = [...new Set(rows.flatMap(row => Object.keys(row)))];
const lines = [
headers.map(h => escapeCsv(h, delimiter)).join(delimiter),
...rows.map(row =>
headers.map(h => escapeCsv(row[h], delimiter)).join(delimiter)
)
];
return lines.join("\n");
}
const data = [
{ id: 1, name: "سارا", note: 'تهران, منطقه ۲' },
{ id: 2, name: "امیر", active: true }
];
console.log(jsonToCsv(data));
این کد objectها و arrayهای داخلی را با JSON.stringify داخل یک سلول نگه میدارد. برای Flatten واقعی باید پیش از ساخت Header، تابعی بازگشتی برای تولید مسیرهای کلید اضافه شود.
تبدیل JSON به CSV در Python
ماژول استاندارد csv در Python قواعد quoting را مدیریت میکند:
import csv
import json
from io import StringIO
def json_to_csv(data):
rows = data if isinstance(data, list) else [data]
if not all(isinstance(row, dict) for row in rows):
raise TypeError("Input must be an object or a list of objects")
headers = []
seen = set()
for row in rows:
for key in row:
if key not in seen:
seen.add(key)
headers.append(key)
output = StringIO()
writer = csv.DictWriter(output, fieldnames=headers)
writer.writeheader()
for row in rows:
normalized = {
key: (
json.dumps(value, ensure_ascii=False)
if isinstance(value, (dict, list))
else value
)
for key, value in row.items()
}
writer.writerow(normalized)
return output.getvalue()
data = [
{"id": 1, "name": "سارا", "tags": ["vip", "newsletter"]},
{"id": 2, "name": "امیر", "active": True},
]
print(json_to_csv(data))
ensure_ascii=False باعث میشود حروف فارسی در JSON String داخلی به توالیهای Unicode escape تبدیل نشوند. هنگام نوشتن فایل نیز Encoding را صریحاً UTF-8 قرار دهید.
تبدیل JSON به CSV در محیط Node.js برای داده بزرگ
ساخت کل خروجی در حافظه برای چند هزار رکورد معمولاً مشکلی ندارد، اما فایلهای بسیار بزرگ میتوانند مصرف حافظه را افزایش دهند. برای داده بزرگ بهتر است پردازش Streaming باشد. بااینحال Streaming یک چالش دارد: اگر Header بر اساس اجتماع همه کلیدها ساخته شود، باید پیش از نوشتن اولین ردیف تمام داده بررسی شود.
راهکارها:
- Schema یا فهرست ستونها را از قبل تعریف کنید.
- یک Pass اول فقط برای کشف ستونها و Pass دوم برای نوشتن انجام دهید.
- برای داده نامنظم، خروجی را به چند فایل با Schemaهای متفاوت تقسیم کنید.
- از NDJSON استفاده کنید تا رکوردها خطبهخط خوانده شوند.
- Backpressure جریان نوشتن را رعایت کنید تا تولید داده از سرعت دیسک جلو نزند.
اگر ترتیب ستونها اهمیت دارد، آن را به ترتیب اولین مشاهده یا یک Schema ثابت نگه دارید. مرتبسازی الفبایی ستونها قابل پیشبینی است، اما ممکن است ستونهای مرتبط را از هم دور کند.
خطاهای رایج در تبدیل JSON به CSV
JSON نامعتبر
کاما اضافه، کوتیشن تکی، کلید بدون کوتیشن یا بستهنشدن براکت باعث شکست Parse میشود. پیش از تبدیل، Syntax JSON را بررسی کنید. معتبر بودن Syntax به این معنی نیست که ساختار برای CSV مناسب است؛ آرایهای از آرایهها میتواند JSON معتبر باشد، اما به سیاست نگاشت جداگانه نیاز دارد.
استفاده از کلیدهای رکورد اول و حذف ستونهای بعدی
اگر رکورد دوم کلیدی داشته باشد که در رکورد اول نیست، الگوریتم ساده ممکن است آن مقدار را نادیده بگیرد. برای جلوگیری از اتلاف، اجتماع کلیدها یا Schema صریح استفاده کنید.
Escape نکردن کوتیشن و خط جدید
این خطا باعث جابهجایی ستونها یا شکستهشدن یک رکورد به چند ردیف میشود. تابع escaping را یکبار و بهصورت مرکزی پیادهسازی کنید؛ از چسباندن دستی رشتهها در چند بخش برنامه خودداری کنید.
فرض اینکه CSV نوع داده را حفظ میکند
CSV نوع Number، Boolean یا Date را بهصورت ذاتی نگه نمیدارد. اگر round-trip دقیق لازم است، همراه CSV یک Schema یا Data Dictionary نگه دارید یا از فرمت مناسبتری استفاده کنید.
نادیدهگرفتن Formula Injection
وقتی CSV توسط صفحهگسترده باز میشود، سلولی که با کاراکترهای فرمول شروع شده ممکن است بهعنوان فرمول تفسیر شود. اگر داده از کاربر یا منبع غیرقابلاعتماد میآید، فقط escaping استاندارد CSV برای خنثیکردن این رفتار کافی نیست. باید سیاست امنسازی مخصوص مقصد داشته باشید؛ برای مثال پیشوندگذاری کنترلشده یا Import بهصورت Text. این کار ممکن است مقدار اصلی را تغییر دهد، بنابراین باید آگاهانه انجام شود.
تبدیل آرایه داخلی بدون قرارداد
Join کردن با ویرگول میتواند مبهم باشد، زیرا خود اعضا نیز ممکن است ویرگول داشته باشند. برای دادهای که باید دوباره Parse شود، JSON String یا جدول جداگانه مطمئنتر است.
نکات امنیتی هنگام ساخت CSV از JSON
- ورودی را از نظر اندازه محدود کنید تا Parse یا Flatten بازگشتی باعث مصرف بیش از حد حافظه نشود.
- عمق objectهای تودرتو را محدود کنید تا ساخت مسیرهای بسیار عمیق کنترل شود.
- نام فایل را از ورودی خام کاربر نسازید و از مسیرهای امن استفاده کنید.
- برای داده محرمانه، فایل خروجی را بیدلیل در فضای عمومی یا Log ذخیره نکنید.
- مقدارهای حساس مثل Token، Password، کلید API یا اطلاعات شناسایی را پیش از Export حذف یا Mask کنید.
- در Export قابل دانلود، Header مناسب Content-Type و Content-Disposition تنظیم کنید.
- برای فایل بازشونده در Spreadsheet، خطر Formula Injection را در مدل تهدید لحاظ کنید.
بهترین روشهای تبدیل JSON به CSV
- هدف خروجی را مشخص کنید: تحلیل، آرشیو، انتقال یا نمایش انسانی.
- Schema ستونها را ترجیح دهید: برای Pipeline پایدار، ستونها را صریح تعریف کنید.
- سیاست null و مقدار گمشده را مستند کنید: مشخص کنید سلول خالی چه معنایی دارد.
- Flatten را کنترلشده انجام دهید: جداکننده مسیر، حداکثر عمق و برخورد نامها را تعیین کنید.
- قواعد CSV را کامل رعایت کنید: Delimiter، کوتیشن و شکست خط را escape کنید.
- UTF-8 را صریح انتخاب کنید: مخصوصاً برای فارسی و داده چندزبانه.
- خروجی را با مصرفکننده واقعی تست کنید: بازشدن در یک ابزار به معنی سازگاری با همه ابزارها نیست.
- داده بزرگ را Stream کنید: از نگهداری کل ورودی و خروجی در حافظه پرهیز کنید.
- نمونههای مرزی داشته باشید: کوتیشن، ویرگول، newline، null، کلید گمشده و object داخلی را تست کنید.
چکلیست قبل از دانلود یا انتشار CSV
- آیا JSON بدون خطای Syntax Parse میشود؟
- آیا ریشه ورودی با مدل تبدیل سازگار است؟
- آیا تمام ستونهای لازم در Header وجود دارند؟
- آیا ترتیب ستونها درست و ثابت است؟
- آیا مقدارهای دارای ویرگول، کوتیشن و newline درست Escape شدهاند؟
- آیا objectها و arrayهای داخلی طبق قرارداد تبدیل شدهاند؟
- آیا تفاوت null، مقدار گمشده و رشته خالی اهمیت دارد؟
- آیا UTF-8 و نمایش فارسی در مقصد بررسی شده است؟
- آیا شناسهها، کدهای پستی و اعداد بزرگ بهاشتباه عددی نشدهاند؟
- آیا خطر Formula Injection برای داده غیرقابلاعتماد بررسی شده است؟
- آیا تعداد ستونهای همه ردیفها با Header هماهنگ است؟
چه زمانی CSV انتخاب مناسبی نیست؟
اگر لازم است ساختار تودرتو، نوع دقیق داده، چند جدول مرتبط، metadata یا تفاوت null و مقدار گمشده بدون قرارداد اضافی حفظ شود، CSV انتخاب ایدهآلی نیست. JSON برای انتقال ساختارهای درختی مناسبتر است. CSV زمانی بهترین نتیجه را میدهد که داده ذاتاً جدولی باشد یا بتوان آن را بدون اتلاف مهم به ردیفها و ستونهای مشخص تبدیل کرد.
همچنین برای دادهای که باید بارها بین سیستمها رفتوبرگشت کند، باید Round-trip را آزمایش کنید. ممکن است JSON به CSV تبدیل شود، اما تبدیل دوباره CSV به JSON نتواند objectهای داخلی، نوع عدد و Boolean یا ترتیب و شکل اولیه را بازسازی کند.
جمعبندی تبدیل JSON به CSV
تبدیل JSON به CSV بیش از جایگزینی براکتها با ویرگول است. یک تبدیل درست باید ردیف و ستون را تعریف کند، کلیدهای نامنظم را مدیریت کند، برای objectها و arrayهای تودرتو تصمیم بگیرد، قواعد کوتیشن را رعایت کند، Encoding فارسی را حفظ کند و محدودیت نوع داده در CSV را بشناسد. برای دادههای تخت، آرایهای از objectها مستقیماً به جدول تبدیل میشود؛ برای دادههای پیچیده، Flatten، انتخاب فیلد یا تولید چند جدول نتیجه مطمئنتری میدهد.
برای تبدیل سریع داده، میتوانید از ابزار داخلی تبدیل JSON به CSV استفاده کنید. پیش از تبدیل داده نامطمئن نیز بررسی Syntax با ابزار اعتبارسنج JSON کمک میکند خطاهای ساختاری زودتر مشخص شوند.