فورمه لېږل کېږي، څرخوونکی ښکاري، او کنسول وايي چې په JSON کې د 0 په موقعیت کې ناڅاپي < نښه ده. پاڼه پخپله ښه بارېږي، له همدې کبله لومړنۍ فکر دا وي چې پارسر یا تونل ملامت کړو. معمولاً له دواړو هیڅ یو ښکېل نه وي: لېږل د پاڼې له بارېدو جلا غوښتنه ده، او دا له هغه څه سره راستنه شوه چې JSON نه دی. په هغه ترتیب کار وکړئ چې براوزر یې په رښتیا ښکاره کوي، ځکه چې څلورممکن ځوابونه څلور جلا سمونونه غواړي.

مرحله 1: هغه لېږل ونیسئ چې په رښتیا پېښ شول

د لېږلو دمخه د شبکې پینل پرانیزئ، لاګ داسې تنظیم کړئ چې د تګ راتګ په اوږدو کې یادښتونه وساتي، بیا په هغه حساب چې اجازه لرئ یوه بې ضرره ازموینه لېږنه وکړئ. د پاڼې د سند غوښتنه نه، بلکې هغه غوښتنه وټاکئ چې فورمې پخپله پیل کړې.

له فلټرونو څخه ځان وساتئ. د XHR یا Fetch فلټر اسانه دی، خو که چوکاټ لا هم د پټ iframe یا په متحرک ډول جوړ شوي فورمې له لارې لېږي، فلټر به یوازینې مهمه غوښتنه پټه کړي. لومړی یو ځل پرته له فلټر ولېږئ او وګورئ څه راغلل.

د ټاکل شوې غوښتنې لپاره له هر تفسیر دمخه شپږ شیان ولیکئ: طریقه، بشپړ URL د پوښتنې تار سره، حالت، د بدلولو زنځیر، د ځواب Content-Type، او د بدن لومړي کرښې. د Chrome DevTools د شبکې پینل لارښود هغه Headers، Response او Initiator لیدونه رانغاړي چې دا پکې دي، او په نورو براوزرونو کې ورته پینلونه همدغه ساحې ښيي.

مرحله 2: ډاډ ترلاسه کړئ چې دا هغه غوښتنه ده چې تاسو یې فکر کوئ

د حیرانتیا وړ ډېرې JSON تېروتنې په رښتیا د لارښوونې تېروتنې دي. که د لېږلو سمبالونکی د preventDefault له غږولو دمخه استثنا وغورځوي، براوزر د action ځانګړنې ویلي شوي پته ته اصلي فورمه POST کوي، او سرور په بشپړه HTML پاڼه ځواب ورکوي. سمبالونکی هېڅکله نه ګرځي، نو JSON هېڅکله ونه غوښتل شو.

د پینل URL د خپل JavaScript هغه URL سره پرتله کړئ چې غږ یې کوي. هغه بدلون ولټوئ چې بل ځای ته پای ته رسېږي، ورکه یا اضافي پای سلیش، د طریقې ناسمون، یا هغه فورمه چې له لېږدول شوې پاڼې څخه نسبي لارې ته لېږي. د بدلون زنځیر تر پایه تعقیب کړئ او لومړی نه، بلکې وروستی URL ولیکئ.

بیا پیل کوونکی وګورئ. که غوښتنه ستاسو له سکریپټ څخه نه، بلکې د سند له تګ راتګ څخه راغلې وي، ستونزه مو وموندله، او د ځواب پارسر کې هېڅ بدلون به مرسته ونه کړي.

مرحله 3: پایله په څلورو ډلو ووېشئ

هره پایله په دغو کې یوازې یوې ته ورځي، او ډله ټاکي چې بل چېرې وګورئ.

What you seeCategoryWhere to look
Request never finishes, TLS or connection errorNo usable responseEndpoint reachability, certificate, front-end timeout
Request completes, script gets an opaque failureAccess blockedCross-origin policy, credentials mode, missing response header
200 with an HTML body or a login formWrong representationRedirect, expired session, route fallback, error handler
Body begins with a notice then valid JSONWrong representationServer-side warning output before serialisation
Valid JSON, framework rejects itContract mismatchEnvelope shape, field names, value types

مینځې کرښې هغه دي چې خلک یې ناسم تشخیص کوي، ځکه حالت 200 دی. هغه ننوتنې پاڼه چې له بدلون وروسته ورته رسېږو، بشپړه ښه HTTP ځواب او ډېر بد JSON سند دی. application/json د منځپانګې ډول دا نه سمولای شي: دا یوازې نښه ده، او ناسمه نښه شوې بدن بیا هم نه پارس کېږي. لاسرسی بند هغه کرښه ده چې بشپړه غوښتنه ښکاري: پینل حالت ښيي، خو د بېلابېلو سرچینو تګلاره بدن نیسي، نو د غږ کوونکي سکریپټ لپاره دا د وخت له پای ته رسېدو هم بې ګټې ده.

څلورمه کرښه په زړو PHP او چوکاټونو کې هم همدومره عامه ده. هغه خبرداری چې د کوډ شوي بار دمخه چاپېږي، داسې بدن جوړوي چې هیڅ JSON پارسر به یې ونه مني، او ډېری وختونه همدغه خبرداری ټوله تشریح ده.

مرحله 4: د پارسر تېروتنه لفظي ولولئ

د تېروتنې متن هغه لومړنی توری نوموي چې پارس کول یې مات کړل، او دا معمولاً پرته له کوم اټکل ډله پېژني.

Error text (Chrome/V8)What it means
Unexpected token < in JSON at position 0The body starts with markup: an HTML page or an error document
Unexpected end of JSON inputEmpty body, or the response was truncated
Unexpected token o in JSON at position 1You parsed something already parsed, typically an object rather than text
Unexpected token uThe body starts with the bare word undefined, usually an empty response rendered as a string

له 200 سره تش بدن جلا پېښه ده: پای ټکی وګرځېد، هېڅ یې تولید نه کړ، او یو څه لاندې دغه بریا وګڼله. دا د اپلیکیشن تړون نیمګړتیا ده نه د لېږد، او ځای یې په بل ګام کې دی نه په پروکسي کې. Firefox او Safari همدغه څلور نیمګړتیاوې بېل ډول بیانوي، نو پر توري یا تش بدن سره سمون ورکړئ نه پر دقیق تار.

مرحله 5: هغه پوړ سم کړئ چې شواهد ورته اشاره کوي

د لارښوونې ستونزه لپاره غوښتنه سمه کړئ: action سم کړئ، سمبالونکی له لوېدو وژغورئ، پای ټکی او طریقه سره برابر کړئ، او بیا ازموینه وکړئ. د استازیتوب ستونزه لپاره هغه څه سم کړئ چې بدن یې جوړ کړ، او ومومئ چې ولې د تېروتنې سند هغه ځای ته راځي چېرې چې ډاټا تمه کېده. د تړون ستونزه لپاره د هغه نسخې لپاره چې تاسو یې ګرځوئ د چوکاټ ریښتینی تمه شوی جوړښت ولولئ، او د کلاینټ سستولو پرځای ځواب همغه ته برابر کړئ.

لاسرسی بند ځواب خپل پړاو غواړي، ځکه غوښتنه پخپله سمه کېدای شي او بدن به ستاسو کوډ ته هېڅکله ونه رسېږي. د ځواب Access-Control-Allow-Origin د براوزر لېږل شوي دقیق Origin سره پرتله کړئ، او په یاد ولرئ چې وایلدکارډ د اعتبارنامې لرونکې غوښتنې نه پوره کوي. په کلاینټ کې credentials: 'include' له سرور کې Access-Control-Allow-Credentials: true سره یوځای کړئ، او وګورئ چې غږ اچونه no-cors حالت کارولی که نه، چېرې چې ناڅرګند بدن نیمګړتیا نه، بلکې مستند پایله ده.

پارسر په یو څه نرم بدلول یوازینی سمون دی چې باید ترې ډډه وشي. ځواب د کوډ په توګه ارزول، یا متن تر پارسېدو پورې سپکول، د تړون ناسمون پټوي او د چوپتیا په بدل کې د انجیکشن سطحه زیاتوي. همدارنګه حالت باید له بدن څخه جلا وکتل شي: اپلیکیشن کچې تېروتنې شی سره 200 په ډېرو API کې نورمال دی او باید د بار لوستلو سره سمبال شي.

کله چې بل چا مرستې ته اړتیا ولرئ، د خام صادراتو پرځای لږترلږه یادښت شریک کړئ — طریقه، URL، حالت، د بدلون وروسته وروستی URL، د ځواب منځپانګې ډول، د بدن بڼه او تمه شوی تړون. د شبکې آرشیفونه کوکیز، ټوکنونه، د پوښتنې تارونه او هغه شخصي ډاټا لري چې په فورمه کې وې، او اتومات پاکوونکی بیا کتنه نه ده.

  • له هر کوډ بدلون دمخه غوښتنه پرته له فلټر ونیسئ.
  • ډاډ ترلاسه کړئ چې پیل کوونکی ستاسو سکریپټ و او وروستی URL ستاسو پای ټکی دی.
  • پارسر ته له لاس وهلو دمخه ځواب ډلبندي کړئ.
  • لارښوونه، لاسرسی، استازیتوب یا تړون سم کړئ، او هېڅکله د پارسر سستولو سره نه.

اړوندې مقالې