ממיר JSON ל-XML

JSON ל-XML וחזרה: ממיר מעשי לשני עולמות נתונים

רוב המפתחים עובדים גם עם XML וגם עם JSON, בין אם הם רוצים בכך ובין אם לא. ממשקי API אינטרנטיים מודרניים מדברים JSON כמעט בלעדית, אבל ברגע שאתם נוגעים בבנק, בחברת ביטוח, בנקודת קצה ממשלתית, ב-ERP ארגוני, או בשירות SOAP ישן, XML מופיע שוב. הממיר JSON ל-XML בעמוד הזה הופך JSON ל-XML ו-XML בחזרה ל-JSON ישירות בדפדפן שלכם, כך שתוכלו לעבור בין שני הפורמטים בלי להעתיק מטענים רגישים לשירות מרוחק.

מה XML ו-JSON באמת

XML (Extensible Markup Language) הוא פורמט סימון בנוי סביב תגים מקוננים, מאפיינים ומרחבי שמות. הוא תוכנן עבור מסמכים והחלפת נתונים מובנית, והוא נושא הרבה מנגנונים: סכמות (XSD), מרחבי שמות, הוראות עיבוד, הערות, קטעי CDATA, והצהרה פורמלית בראש. העושר הזה הוא הסיבה ש-XML עדיין שולט במערכות ישנות וארגוניות. תמצאו אותו בשירותי אינטרנט SOAP, פידים RSS ו-Atom, קבצי קונפיגורציה (Spring, Maven, קבצי קונפיגורציה של אפליקציות .NET), פורמטים של מסמכי משרד, ותקני מסרים פיננסיים כמו SWIFT ו-ISO 20022, שבהם בנקים וחברות ביטוח ממשיכים להחליף XML כל יום.

JSON (JavaScript Object Notation) הרבה יותר פשוט: אובייקטים עם זוגות מפתח/ערך, מערכים, מחרוזות, מספרים, בוליאנים, ו-null. הוא ממופה כמעט אחד לאחד למבני הנתונים של כמעט כל שפת תכנות, וזו בדיוק הסיבה שהוא השתלט על ממשקי API אינטרנטיים מודרניים, נקודות קצה REST, אפליקציות מובייל, וקבצי קונפיגורציה כמו package.json. JSON בדרך כלל קטן ב-30 עד 50 אחוז מ-XML המקביל ומנותח מהר יותר באופן ניכר, בין השאר כי הוא משמיט את תגי הסגירה ומנגנוני המאפיינים שהופכים את XML למייגע.

ההבדלים המרכזיים שחשובים להמרה

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

• מאפיינים מול צמתי-בת. XML מבחין בין <user id="1"> (מאפיין) ל-<user><id>1</id></user> (אלמנט-בת). ל-JSON אין מושג כזה, כך שממירים ממציאים אחד. לפי מוסכמה, מאפיינים מקופלים למפתח כמו @attributes או עם קידומת @, בעוד תוכן טקסט של אלמנט נוחת במפתח כמו #text.
• מערכים. ל-JSON יש מערכים טבעיים. ל-XML אין. רשימה ב-XML היא פשוט אותו תג חוזר, כמו שלושה אלמנטי <item> ברצף. ממירים צריכים להסיק מתי אחים חוזרים צריכים לקרוס למערך JSON, ומתי אלמנט בודד צריך להישאר אובייקט רגיל.
• מרחבי שמות. XML משתמש במרחבי שמות (הקידומות xmlns:soap) כדי להימנע מהתנגשויות שמות בין סכמות. ל-JSON אין שום דבר מקביל, כך שקידומות או שורדות כתווים מילוליים במפתחות או מוסרות.
• מייגעות ומטא-נתונים. XML יכול לצרף מטא-נתונים לצומת דרך מאפיינים; JSON מבטא הכל כמפתחות וערכים. זה הופך את JSON לקומפקטי וקל יותר לקריאה, בעוד XML שומר על כוח אימות דרך סכמות XSD.

מלכודות המרה שכדאי לשים לב אליהן

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

• מאפיינים מתעוותים. כשאתם ממירים JSON ל-XML, הכלי צריך כלל לגבי אילו מפתחות הופכים למאפיינים לעומת אלמנטים. כשאתם הולכים בכיוון השני, מאפיינים חייבים לנחות איפשהו, וה"איפשהו" הזה (קידומת @, בלוק @attributes) שונה בין ספריות. אם מנתח במורד הזרם מצפה למוסכמה אחרת, הנתונים נראים שגויים גם אם שום דבר לא אבד.
• אלמנט בודד מול מערך. פיד XML עם <item> אחד מייצר אובייקט JSON; אותו פיד עם שני פריטים מייצר מערך JSON. קוד שמניח מערך נשבר במקרה של פריט בודד. זהו מקור נפוץ לבאגים בניתוח RSS ו-SOAP.
• מרחבי שמות דולפים או נעלמים. תלוי בכלי, soap:Body עשוי להפוך למפתח בשם מילולי soap:Body, או שהקידומת עשויה להיות מוסרת לחלוטין, ולשנות את משמעות המסמך.
• תוכן מעורב וסוגים. XML מתייחס לכל דבר כטקסט, כך שערך כמו true או 42 עשוי להישאר מחרוזת אחרי המרה ל-JSON, בעוד הכיוון ההפוך לא מציע מקום טבעי להערות או CDATA.

למה המרה מקומית-בלבד חשובה

מטענים של JSON ו-XML הם לעיתים קרובות הדבר הרגיש ביותר שמפתח מטפל בו: תגובות API עם אסימונים, הודעות SOAP עם מספרי חשבון, קבצי קונפיגורציה עם פרטי גישה. ממיר שפועל בדפדפן שלכם לעולם לא מעלה שום דבר מזה. הניתוח והסריאליזציה מתבצעים במכשיר שלכם, שום דבר לא נשלח לשרת, ותוכלו להשתמש בכלי במצב לא מקוון ברגע שהעמוד נטען. לניפוי באגים בנתוני ייצור או כל דבר תחת משטר ציות, זה ההבדל בין בדיקה מהירה בטוחה לדליפת נתונים בשוגג.

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

שאלות נפוצות