השוואת ספריות לפרסור ולעיבוד JSON

שורה תחתונה: סווגו קודם את הצורך, אחר כך השוו מימושים — השתמשו ב-JSON.parse המקורי לקריאה בלבד, ב-jsonc-parser כשצריך היסטים או חייבים לשמר את הפורמט המקורי, והוסיפו ספריות שאילתה או patch רק במקום שנדרש; טענו עצלות ספריות גדולות לפי דף והשליכו כאלה שאינן מתוחזקות.

כל ספרייה מצהירה שהיא "מהירה, קטנה ושלמה". מה שבאמת מבדיל ביניהן הוא כמה מידע הן נותנות כשמשהו משתבש.

1. ארבע קטגוריות לפי מטרה

זהו קודם לאיזו קטגוריה אתם שייכים, אחר כך השוו מימושים קונקרטיים — אחרת קל להשתמש בספריית שאילתה כדי לעשות עבודה של מפרסר.

2. השוואה צד-לצד

הודעות השגיאה של JSON.parse משתנות מאוד בין מנועים. V8 מייצר משהו כמו Unexpected token } in JSON at position 42, אבל האם המיקום מדויק תלוי בגרסת המנוע; jsonc-parser לעומת זאת מחזיר { error, offset, length } מובנה ויציב, שמתאים לסמני עורך.

3. ארבע נקודות החלטה מרכזיות

3.1 האם צריך היסטים

אם אתם בונים עורך ורוצים "לחיצה על השגיאה קופצת לשורה המתאימה", חייבים היסט. הבדיקה פשוטה: אם הודעת השגיאה שלכם יכולה רק להדפיס "JSON לא תקין", משתמשים יצטרכו לחפש בעצמם.

复制import { parse, printParseErrorCode } from 'jsonc-parser';

const errors: Array<{ error: number; offset: number; length: number }> = [];
parse(text, errors, { allowTrailingComma: true, disallowComments: false });

if (errors.length > 0) {
  const firstError = errors[0];
  console.error(`${printParseErrorCode(firstError.error)} at offset ${firstError.offset}`);
}

3.2 האם צריך לשמר את הטקסט המקורי

קריאת ערכים בלבד → כל מפרסר מתאים. "שנו שדה אחד והשאירו כל השאר בדיוק כפי שהיה" → חייבים API בסגנון עריכה, לא "פרסור → שינוי האובייקט → סריאל".

האחרון מאבד: הערות, סדר מפתחות (בכמה מימושים), סגנון הזחה, צורת כתיבה של ליטרל מספרי (1e3 הופך ל-1000) וצורות הימלטות (\u4e2d הופך לתו עצמו).

3.3 האם התנהגויות הגבול מפורשות

לפני בחירת ספרייה, בדקו בתיעוד שלושה דברים:

1. איך מטפלים במפתחות כפולים (שמירת האחרון / זריקת שגיאה);
2. האם מספרים שלמים גדולים מאבדים דיוק (רוב ספריות ה-JS כן, כי כולן עוברות דרך Number);
3. ההיקף הנתמך של BOM, הערות ופסיקים בסוף.

אם אין תיעוד, כתבו דגימה קטנה ובדקו בעצמכם. זה אמין יותר מקריאת ה-README.

3.4 מצב תחזוקה

הסיכון של ספריית JSON אינו פונקציות חסרות, אלא הזנחה ארוכת טווח: אף אחד לא ישחרר עדכוני אבטחה (prototype pollution, ReDoS) יותר.

4. השוואה לשפות אחרות

בהחלפת נתונים בין שפות, הדברים הכי קלים להיתקל בהם הם עדיין דיוק מספרים ופורמטי זמן; בחירת ספרייה יכולה רק למתן אותם, לא לחסל אותם.

5. שילובים טיפוסיים

אפשרות 1: אתר כלי (צד דפדפן)

复制Parsing and error location: jsonc-parser
Editor: CodeMirror 6 + @codemirror/lang-json
Query: jsonpath-plus
Patch: fast-json-patch
Share links: lz-string

המאפיין המגדיר את השילוב הזה הוא שהכול רץ מקומית ואף נתון לא מועלה, מה שמתאים לציפיות הפרטיות של אתר כלי.

אפשרות 2: שער API בצד שרת

复制Validation: Ajv (compile the schema once, reuse it)
Parsing: native JSON.parse (together with a body size limit)
Deferred parsing of large fields: keep the raw string, parse only when needed

אל תכניסו ספריות שאילתה/patch לשכבת השער כדי לממש לוגיקה עסקית — זה תפקיד שכבת העסק.

אפשרות 3: CLI וסקריפטים

复制Pick fields: jq
Format conversion: yq / dasel
Interactive browsing: jless
Batch validation: ajv-cli

6. ההשפעה האמיתית של גודל החבילה והביצועים

• jsonc-parser קטן מאוד ומתאים לחבילה הראשית;
• json5 גדול מעט מ-jsonc-parser כי הוא תומך ביותר תחביר;
• jsonpath-plus כולל הערכת ביטויים וגדול במידה ניכרת, ולכן יש לטעון אותו בעצלות לפי דף;
• fast-json-patch בגודל בינוני ונדרש רק כשיש תכונת השוואה.

האופטימיזציה פשוטה: יבאו דינמית לפי דף, ואל תכניסו אותם ל-chunk של המסך הראשון.

复制const { JSONPath } = await import('jsonpath-plus');

7. רשימת בדיקה

• [ ] בחרו ספריות לפי מטרה; אל תשתמשו בספריית שאילתה לפרסור;
• [ ] השתמשו ב-jsonc-parser כשצריך מיקומי שגיאה מדויקים;
• [ ] השתמשו ב-API בסגנון עריכה כשההערות והפורמט חייבים להישמר;
• [ ] בדקו בפועל את שלוש התנהגויות הגבול: מפתחות כפולים, מספרים שלמים גדולים ו-BOM;
• [ ] עקבו אחרי מצב התחזוקה של הספרייה והתראות האבטחה;
• [ ] יבאו דינמית ספריות גדולות לפי דרישה.

FAQ

איך בוחרים ספריית JSON לפי גודל הפרויקט?

כלים קטנים שקוראים רק נתוני API יכולים להישאר עם JSON.parse המקורי. פרויקטים שצריכים מיקומי שגיאה ברמת עורך או חייבים לשמר את הפורמט המקורי צריכים להשתמש ב-jsonc-parser. שער בצד שרת צריך רק אימות ופרסור, ומשאיר ספריות שאילתה ו-patch לשכבת העסק, בעוד שסקריפטים ב-CLI יכולים להשתמש ישירות ב-jq, yq ו-ajv-cli.

למה מצב תחזוקה חשוב יותר ממספר הפונקציות?

הסיכון האמיתי של ספריית JSON הוא הזנחה ארוכת טווח, לא פונקציות חסרות: אף אחד לא ישחרר עדכוני אבטחה ל-prototype pollution או ל-ReDoS. כמה שהרשימה תהיה שלמה, ספרייה שנתקעה משאירה אתכם לתקן אותה בעצמכם. התייחסו לתחזוקה ולתראות אבטחה כקריטריונים קשיחים במקום להשוות טבלאות פונקציות.

כדאי להשתמש ב-JSON.parse כדי לשנות שדה אחד ולשמור הערות והזחה?

לא. פרסור, שינוי האובייקט ואז סריאל מאבדים הערות, סדר מפתחות, סגנון הזחה, צורת כתיבה של ליטרל מספרי (1e3 הופך ל-1000) וצורות הימלטות (\u4e2d הופך לתו עצמו). שינוי שדה אחד תוך שמירה על כל השאר דורש API בסגנון עריכה כמו modify ו-applyEdits ב-jsonc-parser.