آپ کا API کال JSONDecodeError: Expecting property name enclosed in double quotes کے ساتھ ناکام ہو گیا۔ گھڑی چل رہی ہے۔ ڈیٹا LLM سے آیا تھا، اور اس 2,000-ٹوکن ردعمل میں کہیں، ایک واحد ٹریلنگ کامے نے آپ کی پوری پائپ لائن کو تباہ کر دیا۔
مئی 2026 تک، خراب JSON فائلز کو ٹھیک کرنے کا تیز ترین طریقہ خودکار لائبریریوں جیسے json_repair (Python) یا jsonrepair (npm) کا استعمال ہے۔ یہ آلات خاص طور پر LLM سے پیدا شدہ نحوی غلطیوں کو فوری طور پر ٹھیک کرنے کے لیے بنائے گئے ہیں۔ دستی مرمت کے لیے، معمول کے مجرم ٹریلنگ کامے، سنگل کوٹس، یا غیر کوٹڈ کلیدز ہیں — یہ RFC 8259 معیار کی خلاف ورزی کے تین سب سے عام طریقے ہیں۔
تیز ترین حل: LLM آؤٹ پٹس کے لیے json_repair
Python کے json.loads() جیسے معیاری پارسر ڈیزائن کے لحاظ سے سخت ہیں۔ ایک غلط مقام پر موجود کریکٹر JSONDecodeError کو متحرک کر دیتا ہے اور سب کچھ رک جاتا ہے۔ یہ 2026 میں روزانہ کا مسئلہ ہے کیونکہ LLMs اکثر JSON کو گفتگو کے متن میں لپیٹ دیتے ہیں، ردعمل کو جملے کے بیچ میں کاٹ دیتے ہیں، یا ایسے تبصرے شامل کر دیتے ہیں جو اسپیک کو توڑ دیتے ہیں۔
json_repair لائبریری ترجیحی حل ہے۔ GitHub کے مطابق، اس پروجیکٹ کے 2026 تک 4,700 سے زیادہ اسٹارز ہیں۔ یہ اسٹرنگ کے ارادے کو "اندازہ لگا کر” کام کرتا ہے — غائب بریکٹس بند کرنا، کوٹس شامل کرنا، اور JSON بلاک کے ارد گرد اضافی متن کو ہٹانا۔
Python: پہلے اور بعد میں
انسٹال کریں: pip install json-repair
خراب ان پٹ:
import json_repair
bad_json = '{"user": "Alice", "status": tru'
decoded_object = json_repair.loads(bad_json)
پردے کے پیچھے کیا ہوا: json_repair نے دیکھا کہ tru غالباً true تھا، غاختہ بند کرنے والا بریس شامل کیا، اور ایک درست Python ڈکشنری واپس کی۔ صفر دستی مداخلت۔
Salvage موڈ: جب ڈیٹا واقعی بہت برا ہو
مشکل کیسز کے لیے، json_repair (v0.59.5+) میں Salvage موڈ شامل ہے۔ جیسا کہ پروجیکٹ دستاویزات میں نوٹ کیا گیا ہے، یہ موڈ خاص طور پر کٹے ہوئے AI ردعمل یا خراب لاگز کے لیے بنایا گیا ہے۔ یہ اریز کو آبجیکٹس میں تبدیل کر سکتا ہے یا ایسے آئٹمز کو چھوڑ سکتا ہے جو بچانے کے لیے بہت زیادہ خراب ہیں، اس بات کو یقینی بناتے ہوئے کہ آؤٹ پٹ آپ کے اسکیمے کے مطابق ہو۔
import json_repair
# Salvage mode for severely truncated data
result = json_repair.loads(
'{"items": [{"id": 1, "name": "Widget"}, {"id": 2, "na',
salvage_mode=True
)
# Result: {'items': [{'id': 1, 'name': 'Widget'}, {'id': 2}]}
# Dropped the incomplete 'na' but saved everything else
npm متبادل
Node.js پروجیکٹس کے لیے، jsonrepair CLI اسی کام کو انجام دیتا ہے:
# Fix a file in place
npx jsonrepair broken.json > fixed.json
# Fix a string in a script
const { jsonrepair } = require('jsonrepair');
const fixed = jsonrepair('{"name": "test",}');
دستی ڈیبگنگ: معلوم کریں کہ کیا چیز نے اسپیک کو توڑا
جب خودکاری کام نہیں کرتی، تو آپ کو بالکل یہ معلوم کرنے کی ضرورت ہے کہ فائل کہاں RFC 8259 کی خلاف ورزی کرتی ہے۔ JSON، YAML یا JavaScript سے کہیں کم معاف کرنے والا ہے۔ جیسا کہ JSONParser تشخیصی ٹیم وضاحت کرتی ہے: "پارسر پہلے ایسے کریکٹر پر ناکام ہو جاتا ہے جسے وہ سمجھ نہیں سکتا، اور یہ اکثر کئی لائنوں پہلے پیش آنے والے کسی مسئلے کا نیچے کی طرف علامت ہوتا ہے۔”
تین JSON قاتل
قاتل 1: ٹریلنگ کامے
DEV Community کے مطابق، ٹریلنگ کامے پارسنگ ناکامیوں کا نمبر ایک سبب ہیں۔ وہ JavaScript میں ٹھیک ہیں لیکن JSON اری یا آبجیکٹ میں آخری آئٹم کے بعد غیر قانونی ہیں۔
// BROKEN - trailing comma after "active"
{
"name": "Alice",
"status": "active",
}
// FIXED - no comma before closing brace
{
"name": "Alice",
"status": "active"
}
قاتل 2: سنگل کوٹس
JSON، کلیدز اور اسٹرنگ ویلیوز دونوں کے لیے ڈبل کوٹس (") کا تقاضا کرتا ہے۔ بہت سے Python اور JavaScript ڈویلپرز غلطی سے سنگل کوٹس (') استعمال کر لیتے ہیں۔ جیسا کہ TidyCode نوٹ کرتا ہے، یہ ایک لازمی اصلاح ہے۔
// BROKEN - single quotes
{'name': 'Alice'}
// FIXED - double quotes
{"name": "Alice"}
قاتل 3: غیر کوٹڈ کلیدز
JavaScript میں آپ { name: "Alice" } لکھ سکتے ہیں۔ JSON میں، ہر کلید کو ڈبل کوٹس کی ضرورت ہے۔
// BROKEN - unquoted key
{name: "Alice"}
// FIXED - quoted key
{"name": "Alice"}
"Unexpected Token” غلطی
جب کوئی ویلیڈیٹر "Unexpected Token” پر نشان زد کرتا ہے، تو اس کا مطلب ہے کہ پارسر NaN، Infinity، یا undefined سے ٹکرا گیا ہے — یہ JavaScript مستقل ہیں جنہیں JSON سپورٹ نہیں کرتا۔ JSON صرف null، true، false، اور نمبرز کی اجازت دیتا ہے۔
// BROKEN - NaN is not valid JSON
{"score": NaN, "result": Infinity}
// FIXED - replace with null or valid values
{"score": null, "result": null}
سخت پارسنگ بمقابلہ مرمت پارسنگ: کب کون سی استعمال کریں
صحیح طریقہ اس بات پر منحصر ہے کہ آپ کا ڈیٹا کہاں سے آتا ہے۔ انسانی طور پر ایڈٹ شدہ کنفیگرشن فائلز سخت پارسنگ کی مستحق ہیں تاکہ مصنف کو غلطیاں ٹھیک کرنے پر مجبور کیا جا سکے۔ LLMs یا API لاگز سے آنے والے مشین-جنریٹڈ ڈیٹا کو مرمت پر مبنی پارسنگ کی ضرورت ہے۔
| خصوصیت |
سخت (json.loads) |
مرمت (json_repair) |
| ٹریلنگ کامے |
JSONDecodeError اٹھاتا ہے |
خودکار طور پر ہٹائے جاتے ہیں |
| سنگل کوٹس |
ناکام ہو جاتا ہے |
ڈبل کوٹس میں تبدیل ہوتے ہیں |
| کٹا ہوا ڈیٹا |
ناکام ہو جاتا ہے |
کھلے بریکٹس/کوٹس بند کرتا ہے |
| تبصرے |
ناکام ہو جاتا ہے |
خودکار طور پر ہٹائے جاتے ہیں |
| بہترین استعمال کیس |
انسانی طور پر ایڈٹ شدہ کنفیگرشن فائلز |
LLM آؤٹ پٹس، API لاگز |
Pydantic کے ساتھ اسکیم-گائیڈڈ مرمت
آپ Pydantic v2 یا JSON Schema کا استعمال کرتے ہوئے مرمت کے عمل کی رہنمائی کر سکتے ہیں۔ json_repair کو ایک اسکیمہ دے کر، یہ آلہ نحو سے زیادہ کرتا ہے — یہ اقسام کو درست کر سکتا ہے (اسٹرنگ "1" کو نمبر 1 میں بدلنا) اور غالباً ضروری فیلڈز کو ڈیفالٹس سے بھر سکتا ہے۔
from pydantic import BaseModel
import json_repair
class User(BaseModel):
id: int
name: str
active: bool = True
# Broken JSON with wrong types
raw = '{"id": "42", "name": "Alice"}'
repaired = json_repair.loads(raw)
# Validate against schema
user = User(**repaired)
# user.id is now int(42), user.active defaults to True
جیسا کہ Stefano Baccianella نے اپنے 2025 کے پروجیکٹ حوالے میں نوٹ کیا، یہ طریقہ ان "زیادہ تر درست لیکن تکنیکی طور پر غیر درست” JSON کے لیے بہترین بنایا گیا ہے جو زبان کے ماڈلز عام طور پر پیدا کرتے ہیں۔
ملٹی-گیگابائٹ فائلز کو کریش کیے بغیر سنبھالنا
ایک 10KB اسنیپٹ کی مرمت آسان ہے۔ ایک 2GB فائل کو ٹھیک کرنے کے لیے ایک ایسی حکمت عملی کی ضرورت ہے جو آپ کی ساری RAM نہ کھا جائے۔ پوری فائل کو میموری میں لوڈ کرنے سے Out-of-Memory (OOM) غلطیاں پیدا ہوتی ہیں۔
حکمت عملی 1: ijson کے ساتھ اسٹریمنگ
بہت بڑے ڈیٹا سیٹس کے لیے، ijson کا استعمال کریں تاکہ ڈیٹا ٹکڑے ٹکڑے پروسیس ہو سکے۔ جیسا کہ Scrapfly بیان کرتا ہے، ijson ڈیٹا کو بتدریج پروسیس کرتا ہے۔ اسے ایک کلین اپ اسکرپٹ کے ساتھ ملائیں جو پارسنگ سے پہلے مسائل کو لائن بہ لائن ٹھیک کرے۔
import ijson
# Stream through a large JSON file
with open('huge_broken.json', 'r') as f:
for item in ijson.items(f, 'records.item'):
# Process each item individually
process(item)
حکمت عملی 2: زیادہ سے زیادہ کارکردگی کے لیے CLI پائپ
بڑی فائلز کے لیے سب سے میموری-کارآمد طریقہ jsonrepair CLI کا استعمال کرنا اور آؤٹ پٹ کو براہ راست ایک نئی فائل میں پائپ کرنا ہے:
# Streams repair, never loads full file into memory
jsonrepair large_broken.json > fixed.json
یہ فائل کو Python یا براؤزر میں لوڈ کرنے سے کہیں زیادہ میموری-کارآمد ہے۔
نتیجہ
json_repair جیسی AI-آگاہ لائبریریوں کی بدولت خراب JSON کو ٹھیک کرنا اب کوئی دستی کام نہیں رہا۔ آپ کو اب بھی RFC 8259 کی بنیادیات کو سمجھنے کی ضرورت ہے — کوئی ٹریلنگ کامے نہیں، کوئی سنگل کوٹس نہیں، کوئی غیر کوٹڈ کلیدز نہیں — لیکن 2026 میں پیمانے پر ڈیٹا کے لیے خودکاری ہی واحد عملی طریقہ ہے۔
ورک فلو سادہ ہے: پہلے ایک مرمت لائبریری آزمائیں۔ اگر وہ ناکام ہو جائے، تو عین نحوی غلطی کو تلاش کرنے کے لیے ایک ویلیڈیٹر استعمال کریں۔ اس طرح آپ کی ایپلی کیشنز اس وقت بھی چلتی رہتی ہیں جب آنے والا ڈیٹا کم از کم درست ہو۔
اکثر پوچھے جانے والے سوالات
کیا JSON باضابطہ طور پر تبصرے یا سنگل کوٹس کی سپورٹ کرتا ہے؟
نہیں۔ RFC 8259 معیار سختی سے تبصرے کی منع کرتا ہے۔ سنگل کوٹس بھی غیر درست ہیں — کلیدز اور اسٹرنگز کے لیے صرف ڈبل کوٹس کی اجازت ہے۔ تاہم، json_repair جیسے آلات تبصرے ہٹا اور کوٹس کو خودکار طور پر تبدیل کر سکتے ہیں تاکہ فائلز کو معیاری لائبریریوں کے ذریعے پارس کیا جا سکے۔
میں بہت بڑی خراب JSON فائلز کو کریش کیے بغیر کیسے سنبھالوں؟
ڈیٹا کو حصوں میں پروسیس کرنے کے لیے ijson جیسے اسٹریمنگ پارسر کا استعمال کریں۔ پوری خراب اسٹرنگ کو ایک ہی متغیر میں لوڈ کرنے سے گریز کریں۔ تیز ترین نتائج کے لیے CLI مرمت آلات استعمال کریں جو آؤٹ پٹ کو براہ راست ڈسک پر نئی فائل میں پائپ کرتے ہیں بغیر سب کچھ میموری میں رکھے۔
خراب JSON اور غیر درست JSON میں کیا فرق ہے؟
خراب (malformed) JSON نحوی قواعد کی خلاف ورزی کرتا ہے — غائب بریکٹس، غیر کوٹڈ کلیدز، ٹریلنگ کامے — جس کی وجہ سے اسے پارس کرنا ناممکن ہو جاتا ہے۔ غیر درست (invalid) JSON تمام نحوی قواعد پر عمل کرتا ہے لیکن کسی مخصوص JSON Schema سے مماثل نہیں ہوتا (مثلاً، کوئی فیلڈ اسکیمے میں نمبر کی توقع کرے لیکن اسٹرنگ ہو)۔ خراب JSON کو ٹھیک کرنا ساختی مرمت ہے؛ غیر درست JSON کو ٹھیک کرنا ڈیٹا کی سالمیت کے بارے میں ہے۔
کیا میں json_repair کو Pydantic توثیق کے ساتھ استعمال کر سکتا ہوں؟
ہاں۔ پہلے نحوی غلطیاں ٹھیک کرنے کے لیے json_repair.loads() چلائیں، پھر قسم کی توثیق اور اسکیمہ نافذ کرنے کے لیے مرمت شدہ ڈکشنری کو اپنے Pydantic ماڈل کو پاس کریں۔ یہ دو مرحلہ طریقہ ساختی اور معنوی دونوں مسائل کو سنبھالتا ہے۔
JavaScript طرز کے تبصروں والے JSON کا کیا ہوگا؟
معیاری JSON تبصرے کی سپورٹ نہیں کرتا، لیکن json_repair // اور /* */ تبصرے خودکار طور پر ہٹا سکتا ہے۔ اگر آپ کو اپنی کنفیگرشن فائلز میں تبصرے کی ضرورت ہے، تو JSONC (تبصروں والا JSON) فارمیٹ اور json5 (Python) جیسے مطابق پارسر استعمال کرنے پر غور کریں۔
