שאלות נפוצות על שימוש בכלים: נתונים, קבצים וייצוא
האם הנתונים מועלים, איזה גודל קובץ עובד, האם משהו נשמר מקומית, ולמה סינית הופכת לקידודים: עשר שאלות שמפרטות את הגבולות האמיתיים של כלי JSON מקוון.
אוסף את השאלות הנפוצות ביותר על הכלים באתר הזה ועל מפרט JSON, מקובצות לפי תרחיש, עם תשובה שאפשר לפעול לפיה ישירות במקום מסקנה מעורפלת.
25 מאמריםהאם הנתונים מועלים, איזה גודל קובץ עובד, האם משהו נשמר מקומית, ולמה סינית הופכת לקידודים: עשר שאלות שמפרטות את הגבולות האמיתיים של כלי JSON מקוון.
האם הערות מותרות, למה פסיק בסוף גורם לשגיאה, האם מפתחות צריכים גרשיים, ולמה 9007199254740993 משתנה — שתים-עשרה מסקנות, כל אחת נבדקה מול RFC 8259.
האם שאילתות נתיב צריכות להשתמש ב-JSONPath או ב-Pointer, איך בוחרים בין Patch ל-Merge Patch, מה Schema יכול לחסום, ואיך בוחרים גרסת draft — הכל מוסבר במעבר אחד.
למה קובץ JSON של עשרות MB לא נפתח, כמה יקר שכפול עמוק, איך מונעים זיהום `__proto__`, ואיפה XSS נכנס — עשר מסקנות עזרה ראשונה מסודרות לפי תסמין.
סגנון שמות, פורמטי זמן, סמנטיקת null, צורות enum, פורמטי קונפיגורציה, ארגון fixtures וקונפליקטים במיזוג — שתים-עשרה פשרות שצוותים באמת מתווכחים עליהן.
ל-RFC 8259 אין תחביר להערות, כך ש-// והערות בלוק גורמות ל-JSON.parse לזרוק שגיאה. השתמשו ב-JSON5 או JSONC, בשדה _comment, ב-description של Schema או ב-YAML במקום.
פסיקים בסוף חוקיים באובייקטים ליטרליים של JavaScript והרסניים ב-JSON. הנה השגיאה המדויקת, הדקדוק של RFC 8259 שגורם לה, ושלושה תיקונים שבאמת מחזיקים.
BOM של UTF-8 הוא שלושה בייטים בלתי נראים, כך ש-JSON.parse נכשל בתו הראשון ומדווח שורה 1 עמודה 1, מה שגורם לקובץ להיראות ריק או קטוע.
ל-JSON יש רק ליטרלים של מספרים עשרוניים. JSON.stringify הופך NaN ו-Infinity ל-null בלי אזהרה, ולכן "שדה המספר לפעמים null" ממשיך להופיע בפרודקשן.
מספרים שלמים מעל 2^53-1 מאבדים דיוק ב-JSON.parse. מזהי snowflake, מספרי הזמנה ו-bigints ממסד נתונים כולם נתקלים בזה, אז שמרו אותם כמחרוזות לאורך כל הדרך.
קידוד \u4e2d\u6587 הוא Unicode חוקי, לא כשל בקידוד. שיבוש תווים אמיתי נראה אחרת, וההבחנה ביניהם קובעת מה באמת צריך לתקן.
על-קבוצות קפדניות לפי הסדר: JSONC מוסיף הערות; JSON5 מוסיף גרשיים בודדים, מפתחות בלי גרשיים, פסיקים בסוף ומספרים הקסדצימליים. בחירה שגויה שוברת API, לא את העורך.
JSON מפריד בעזרת סוגריים מסולסלים ו-YAML בעזרת הזחה: מכונות מקבלות JSON, בני אדם שעורכים קונפיגורציה מקבלים YAML. הערות, anchors ומבנה של כמה מסמכים לא שורדים את ההמרה.
JSON Pointer הוא כתובת ייחודית שאפשר לאחסן כמפתח; JSONPath היא שפת שאילתות. בחירה בדבר הלא נכון שוברת עדכוני קונפיגורציה או ממציאה JSONPath שבור.
Schema שולט במבנה ובטיפוסים, לא במשמעות עסקית. הוא עוצר שדות חסרים, טיפוסים שגויים ו-enums מחוץ לטווח, בעוד שכללים כמו סכום גדול מאפס נשארים בקוד.
2020-12 הוא העדכני ומוסיף `$defs`, `prefixItems` ו-`unevaluatedProperties`, אבל כלים רבים עדיין מדברים רק draft-07. בחרו לפי מה שכל שרשרת הכלים שלכם תומכת בו.
json-schema-to-typescript ו-quicktype מוציאים `.d.ts` בפקודה אחת, אבל זו טיוטה: אופציונליות, unions, additionalProperties ותאריכים צריכים מעבר אנושי.
אופטימיזציה בסדר הלא נכון הופכת כל החלפת ספרייה לחסרת תועלת. מדדו רשת, פירוס ורינדור בנפרד, ואז צמצמו פירוסים, כווצו payloads ועברו ל-streaming.
JSON.parse מתייחס ל-__proto__ כמפתח רגיל; הנזק קורה ב-merge רקורסיבי שכותב ל-Object.prototype, כך שכל אובייקט יורש מאפיינים של התוקף.
JSON לא מבצע שום דבר בעצמו. XSS קורה ברגע שמתייחסים אליו כ-HTML — חיבור מחרוזות בצד השרת, innerHTML בצד הלקוח, או הטמעת JSON ישירות בתג script.
אין צורך לקרוא מדיניות פרטיות כדי לגלות. פתחו את פאנל הרשת, נסו את הדף במצב לא מקוון, ורעננו כדי לראות אם משהו נשמר. שתי דקות, שלוש בדיקות, בלי צורך באמון.
אין מגבלה קבועה; האילוץ הוא תקציב הזיכרון של הטאב. קובץ של 20MB הופך בדרך כלל ל-60–100MB אחרי פירוס, וה-DOM המודגש יכול להכפיל זאת שוב.
אובייקטים חשופים הם נקיים עד שצריך metadata; envelopes מלאים בטוחים אבל מילוליים. ברוב הפרויקטים השתמשו בסטטוס HTTP לתוצאה וב-envelope יציב לנתונים.
למספרי epoch ולמחרוזות ISO יש כל אחד פשרות, אבל ערבוב שלהם הוא מה שבאמת שובר דברים. השתמשו ב-ISO 8601 עם offset, אחסנו UTC, והציגו באזור הזמן של המשתמש.
`null` אומר שהשדה קיים בלי ערך; השמטה אומרת שהשדה לא קיים. גופי PATCH, מיזוג קונפיגורציה ומילוי מוקדם של טפסים הם המקומות שבהם ההבדל נושך.