שני הדגמים אינם מסתדרים: RFC 8259 מגדיר שישה סוגי JSON ללא תכונות, בעוד XML 1.0 בעל תכונות, מרחבי שמות ותוכן מעורב מסודר ללכת לכיוון הזה פירושו לבחור מה לעשות עם ההבדל.
בפעם הראשונה שהייתי צריך לשלוח נתוני JSON למערכת שדיברה רק XML, עשיתי את הדבר הנאיבי: כתבתי ביד את סוגרי הזווית בעורך טקסט. זה היה עדכון ספק שציפה למעטפת SOAP-ish, והמקור שלי היה מערך JSON מסודר שיצא מ-API של Laravel. עשרים דקות לאחר מכן, לא התאמתי לתג סגירה איפשהו סביב הרשומה הארבעים והמנתח המקבל זרק "זבל אחרי רכיב המסמך" שגיאה שלא אמרה לי עליה דבר איפה. באותו ערב לימד אותי לקח שיישמתי על כל אינטגרציה מאז: המרה בין JSON ל-XML היא לא מעשה יצירתי. זו בעיית מיפוי עם מספר קטן של כללים, וברגע שאתה רושם את הכללים האלה, כל העניין הופך למכני.
מדריך זה הוא הגרסה של אותו מיפוי הלוואי I' d had. i build [Toolz.dev] (/, ואחד הכלים שם הוא מבוסס דפדפן ממיר JSON ל-XML זה חל בדיוק את המוסכמות שלהלן. אבל הנקודה של מאמר זה היא לא הכפתור - זה 's הבנה למה מפתח הופך לאלמנט, מדוע א @-מפתח קידומת הופך לתכונה, ומדוע מערך הופך לתגים חוזרים ולא לרשימה ממוספרת. ברגע ששלושת הרעיונות האלה לוחצים, אתה יכול להמיר כל JSON ל-XML ביד אם אתה צריך, ותוכל לנפות באגים בפלט כאשר מערכת במורד הזרם דוחה אותו.
TL;DR: כדי להמיר JSON ל-XML, מפה כל מפתח אובייקט לאלמנט, כל אחד
@-מפתח מקודם לתכונה באלמנט האב שלה, וה-#textמפתח לאלמנט's תוכן טקסט. הרחב כל מערך לרכיבי אח חוזרים שחולקים את המפתח's name. בריחה&,<, ו>בטקסט (פלוס"בערכי תכונות), ולחטא כל מפתח שהוא 't שם XML חוקי. עשה זאת בדפדפן כך שמטענים עם אסימונים או נתוני לקוחות לעולם לא יעזבו את המחשב שלך.
למה שתמיר את JSON ל-XML מלכתחילה?
JSON ניצח במלחמת ה-API באינטרנט לפני שנים, ואם אתה מבלה את ימיך ב-React, Laravel או Node, אתה עשוי לשאול באופן סביר מתי אתה' אי פעם תזדקק ל-XML בכלל התשובה היא: כל הזמן, רק לא במקומות שאתה מסתכל. XML הוא השפה הצרפתית של בסיס מותקן ענק של מערכות שקודמות לעידן JSON ולא הולכות לשום מקום שירותי אינטרנט SOAP - עדיין עמוד השדרה של בנקאות, ביטוח, לוגיסטיקה ואינטגרציות ממשלתיות - נושאים את המטענים שלהם ב-XML. הזנות RSS ו-Atom הן XML. מפות אתר הן XML. פריסות אנדרואיד, .docx ו .xlsx פנימיות (Office Open XML), הזנות פודקאסטים SVG, RSS, ואינספור מרכזיות בסגנון B2B EDI הן כולן XML.
אז התרחיש בעולם האמיתי הוא כמעט תמיד אותה צורה: יש לך נתונים ב JSON כי זה ' זה מה שהערימה שלך מייצרת, ואתה צריך את זה ב XML כי זה's מה שהצד השני דורש.אולי אתה're דוחף נתוני מוצר לשוק שמקבל רק הזנת XML.אולי אתה' עוטפים תגובת API בגוף SOAP.אולי אתה' מייצרים הזנת RSS מיצוא תוכן JSON.בכל מקרה, אתה don' לא רוצה להמציא מחדש את הסידרה בכל פעם - אתה רוצה כלל צפוי שהופך כל מבנה JSON ל-XML חוקי, כדי שתוכל להפוך אותו לאוטומטי ולהפסיק לחשוב עליו.
There's גם סיבה שקטה יותר: קריאות במהלך ניפוי באגים. כאשר אתה 're בוהה בכתם JSON מקונן עמוק מנסה להבין היררכיה, המרתו ל-XML מחורץ לפעמים גורמת למבנה העץ לקפוץ החוצה, מכיוון שתגי XML's פתוחים/סגורים הופכים את הקינון למפורש באופן ש-JSON's סוגרים don't. אני שומר את ממיר JSON ל-XML וההפך ממיר XML ל-JSON פתח בכרטיסיות סמוכות לעתים קרובות יותר מאשר I'd ניחשו.
איך JSON ממפה ל-XML, בדיוק?
הנה הליבה של זה יש רק ארבעה כללים, וכל השאר זה פרט.
כלל 1: מפתחות אובייקט הופכים לאלמנטים. חפץ JSON { "book": { "title": "..." } } הופך <book><title>...</title></book>. המפתח הוא שם התג; הערך הוא מה שנכנס פנימה.
כלל 2: @-מקשים עם קידומת הופכים לתכונות. רכיבי XML יכולים לשאת תכונות, ול-JSON אין מושג מקורי לגביהם, אז אנחנו צריכים מוסכמה. האחד בשימוש נרחב - וזה שהכלי שלי משתמש בו - הוא תו קידומת, @ כברירת מחדל. כך { "book": { "@id": "bk101", "title": "..." } } הופך <book id="bk101"><title>...</title></book>. תכונות יכולות להחזיק רק ערכים פרימיטיביים (מחרוזות, מספרים, בוליאנים), מעולם לא מבנים מקוננים, מה שמתאים לאופן שבו תכונות XML פועלות בפועל.
כלל 3: ה #text מפתח הופך לתוכן טקסט. כאשר אלמנט צריך שניהם תכונות וטקסט - לחשוב <title lang="en">Hello</title> - אתה יכול't לבטא את זה עם ערך מחרוזת רגילה, כי המחרוזת לא משאירה מקום לתכונה המוסכמה היא מפתח שמור, #text: { "title": { "@lang": "en", "#text": "Hello" } }. אם לאלמנט יש רק טקסט וללא תכונות, אתה יכול לדלג #text ופשוט השתמש בערך מחרוזת רגילה.
כלל 4: מערכים הופכים לאלמנטים חוזרים. זה האחד שאנשים טועים בו לרוב ל-XML אין סוג מערך רשימה של דברים מתבטאת כאלמנטים חוזרים של אחים עם אותו שם תג. כך { "tags": { "tag": ["computer", "web"] } } הופך <tags><tag>computer</tag><tag>web</tag></tags> - לא <tag>0</tag> או כל שטות מבוססת אינדקס. the array's מפתח מספק את שם התג החוזר.
חבר אותם יחד על אובייקט ריאליסטי והפלט הוא בדיוק מה שמנתח XML במורד הזרם מצפה:
{
"catalog": {
"book": [
{ "@id": "bk101", "author": "Gambardella, Matthew", "price": 44.95 },
{ "@id": "bk102", "author": "Ralls, Kim", "price": 5.95 }
]
}
}
הופך
<?xml version="1.0" encoding="UTF-8"?>
<catalog>
<book id="bk101">
<author>Gambardella, Matthew</author>
<price>44.95</price>
</book>
<book id="bk102">
<author>Ralls, Kim</author>
<price>5.95</price>
</book>
</catalog>
שימו לב שהמפתח היחיד ברמה העליונה, catalog, הפך למסמך's אלמנט שורש. That's מכוון: מסמך XML מעוצב היטב חייב להיות בעל שורש אחד בדיוק. כאשר ל-JSON שלך כבר יש מפתח עטיפה בודד, המפתח הזה הוא השורש. When it doesn't - כאשר אתה מוסר לממיר אובייקט מרובה מפתחות או מערך חשוף - הכלי עוטף הכל תחת אלמנט שורש שניתן להגדרה (root כברירת מחדל) כך שהפלט יישאר מעוצב היטב.
מה לגבי בריחה ושמות לא חוקיים?
שני דברים שוברים בשקט יותר המרות מכל חרק קינון: דמויות מיוחדות שלא נמלטו ושמות אלמנטים לא חוקיים.
בריחה. XML שומר קומץ תווים. טקסט בתוך אלמנט, &, <, ו > חייב להיכתב כ &, <, ו >. בתוך ערך תכונה בציטוט כפול, אתה צריך בנוסף לברוח מהציטוט הכפול בתור ". אם מחרוזת ה-JSON שלך מכילה Tom & Jerry ואתה מפיל אותו ל-XML גולמי, האמפרסנד החשוף הופך את המסמך לפגום והמנתח מת. ממיר נכון בורח אוטומטית, אז "a < b & c" הופך a < b & c בפלט ובנסיעות הלוך ושוב חזרה לטקסט המקורי בעת ניתוח. זה לא אופציונלי ליטוש - it's ההבדל בין XML חוקי לבלתי חוקי.
שמות אלמנטים. ל-XML יש כללים נוקשים לגבי מה שם תג עשוי להכיל. שמות יכולים't כוללים רווחים, can't מתחילים בספרה, מקף או נקודה, ואינם כוללים את רוב סימני הפיסוק. למקשי JSON אין הגבלות כאלה - "first name", "123", ו "total($)" האם כל המפתחות JSON חוקיים לחלוטין וכל שמות XML לא חוקיים ממיר שמתעלם מכך מייצר מסמכים שאף מנתח לא יקבל התיקון הפרגמטי, ומה שהכלי שלי עושה, הוא לחטא: להחליף תווים לא חוקיים בקו תחתון ולהוסיף קו תחתון כאשר שם מתחיל בספרה אז "123 bad" הופך <_123_bad>. זה' לא זוהר, אבל זה מבטיח את ניתוחי הפלט, וזה כל העניין.
כיצד אוכל להשתמש בממיר מבוסס הדפדפן?
זרימת העבודה על Toolz.dev/tools/json-to-xml משקף את הכללים לעיל, עם כמה אפשרויות עבור מקרי הקצה המעשיים.
הדבק את ה-JSON שלך בקלט ולחץ על המר. אם ה-JSON שלך פגום, אתה מקבל שגיאת ניתוח ברורה ולא זבל שקט - אני נשען על הדפדפן ' משלו JSON.parse, אז הודעות השגיאה תואמות למה שאתה ' d לראות בקונסולה שלך בחר 2 או 4 רווחים של הזחה כאשר אתה רוצה מסמך קריא אנושי לבדיקה, או בחר Minify כדי למוטט את כל העניין על שורה אחת כאשר אתה 're משלוח זה על החוט וכל ספירת בתים (בקשות SOAP ומטעני הזנה במיוחד). הגדר את שם רכיב השורש למקרה שבו ל-JSON שלך אין מפתח עטיפה אחד. החלף את הצהרת ה-XML (<?xml version="1.0" encoding="UTF-8"?>) הפעלה או כיבוי תלוי אם הצרכן מצפה לפרולוג. ולהחליט אם צמתים ריקים צריכים להיסגר בעצמם <tag/> או להרחיב ל <tag></tag> - לכמה צרכנים קפדניים אכפת.
הכל פועל בצד הלקוח הממיר הוא serializer ללא תלות שנכתב ב-TypeScript, לא עטיפה סביב API מרוחק. זה חשוב יותר ממה שזה נשמע: תגובות API וקבצי תצורה מכילים באופן שגרתי אסימוני גישה, רשומות לקוחות ומזהים פנימיים, ו-"ממיר מקוון חינם" שמפרסם את המטען שלך למישהו 's שרת הוא דליפת נתונים שמחכה לקרות. מכיוון שזה אף פעם לא מבצע שיחת רשת, אתה יכול להמיר נתונים רגישים בבטחה, והוא ממשיך לעבוד ללא חיבור כלל. אם פרטיות בכלי דפדפן היא משהו שאתה חושב עליו - ואם אתה מטפל בנתונים אחרים של 's, זה צריך להיות - כתבתי על זה יותר ב- מדריך כלים לפרטיות נתונים.
JSON לעומת XML: השוואה מהירה
זה עוזר לשמור על שני הפורמטים ' פשרות במבט, כי ה סיבה המיפוי צריך מוסכמות כמו @ ו #text הוא ש-XML יכול לבטא דברים ש-JSON יכול't, ולהיפך.
| אספקט | JSON | XML |
|---|---|---|
| תכונות | אין מושג יליד | מחלקה ראשונה (<tag attr="v">) |
| מערכים / רשימות | יליד [ ] סוג |
אלמנטים אחים חוזרים |
| תגובות | אסור | <!-- ... --> נתמך |
| מרחבי שמות | אף אחד | תמיכה במרחב השמות המלא |
| תוכן מעורב (טקסט + אלמנטים) | מביך | יליד |
| סכימה / אימות | JSON Schema (תוספת) | XSD, DTD, RELAX NG (בוגר) |
| מִשׁפָּעִיוּת | קומפקטי | יותר מילולי (תגיות סגירה) |
| שימוש אופייני כיום | ממשקי API של אינטרנט, config | סבון, הזנות, מסמכים, ארגונים |
ה @ קידומת קיימת כדי לגשר על " תכונות" שׁוּרָה; כלל התג החוזר מגשר על "מערכים" שׁוּרָה; ו #text מגשר על " תוכן מעורב" שׁוּרָה. ברגע שאתה רואה את המיפוי כגשר על פני הפערים הספציפיים האלה, הוא מפסיק להרגיש שרירותי.
האם JSON ל-XML הלוך ושוב נקי?
בעיקר, כן - וזה's בעיצוב. שֶׁלִי JSON ל-XML ו XML ל-JSON כלים חולקים את אותו הדבר @ קידומת תכונה ו #text מפתח תוכן, אז המרת XML → JSON ובחזרה משחזרת בדרך כלל את המסמך המקורי. אם אתה ' בונים צינור שצריך להזיז נתונים לשני הכיוונים, כדאי להסתמך על הסימטריה הזו.
היכן שהטיול הלוך ושוב נעשה מטושטש הוא אותו מקום שכל מיפוי JSON/XML נעשה מטושטש: סדר ותוכן מעורב. אובייקטי JSON אינם מסודרים באופן רשמי, כך שממיר עשוי שלא לשמר את סדר האחים המדויק של אלמנטים בעלי שם שונה. XML שמשלב רכיבי טקסט וילד (<p>Hello <b>world</b>!</p>) doesn' t יש ייצוג JSON נקי וחוזר כקירוב. ואלמנט שלפעמים מופיע פעם אחת ולפעמים מופיע מספר פעמים אינו חד משמעי - האם זה ערך בודד או מערך של אחד? אלה aren't באגים בכל כלי מסוים; הם' טבועים בעובדה ששני דגמי הנתונים don't חופפים בצורה מושלמת. הידיעה היכן נמצאים התפרים מאפשרת לך לעצב את ה-JSON שלך כך שההמרה תישאר ללא הפסדים: היו עקביים לגבי האם דבר הוא תמיד מערך, והימנעו מתוכן מעורב היכן שאתם יכולים.
אם אתה עובד הרבה עם JSON, זה ' שווה לבנות שטף על פני כל משפחת ההמרות - אספתי את אלה שאני מגיע אליהם הכי הרבה ב מדריך אולטימטיבי לכלי JSON, והרחב יותר מדריך כלי קידוד מכסה היכן ממירי פורמטים מתאימים לזרימת עבודה יומיומית. עבור הכיוון ההפוך והפורמטים הסמוכים, ה ממיר JSON ל-YAML ומישור פורמט JSON לעגל את הסט.
טעויות נפוצות בעת המרת JSON ל-XML
כמה מלכודות I' פגעו או צפו באחרים מכים:
התייחסות למדדי מערך כשמות תגים. אם תראה <item0>, <item1> ב-someone's פלט, הם בנו את הממיר לא נכון. מערכים הופכים חוזר תגיות עם ה אותו שם, נלקח מהמפתח array's.
לשכוח שיכול להיות רק שורש אחד. מסירת אובייקט מרובה מפתחות ישר לסיריאליזר מבלי לעטוף אותו מייצרת מספר אלמנטים ברמה העליונה, וזה לא מסמך מעוצב היטב. לעטוף אותו.
דילוג על בריחה "כי הנתונים נראים נקיים." זה נראה נקי עד שתיאור מוצר אחד מכיל אמפרסנד או א <. תמיד לברוח; לעולם אל תניח.
הכנסת נתונים מובנים לתכונות. תכונות מחזיקות פרימיטיביות. אם אתה מנסה לדחוף חפץ מקונן לתוך @-מפתח קידומת, ממיר נכון (וצריך) להפיל אותו או להתעלם ממנו, כי אין ' אין XML חוקי עבורו. דגם אותו כאלמנט צאצא במקום זאת.
מתקדם: בחירת הזחה והצהרה לצרכן
הרגל אחד שחסך לי חזר הלוך ושוב עם שותפי אינטגרציה: התאם את הפלט בדיוק למה שהצרכן מצפה, אז תפסיק. כמה נקודות קצה של SOAP דוחות מסמך הכולל סימן סדר בתים או פרולוג בלתי צפוי; אחרים דורשים את <?xml ... ?> הצהרה ו-415 אתה בלעדיה. חלק ממאמת הזנות רוצים XML מודפס ומחורר עבור ניפוי באגים משלהם; רוב הובלות הייצור רוצות את זה ממוזער. במקום לטעון, אני יוצר את כל הגרסה שהמפרט מבקש. That' מדוע הממיר חושף הזחה (כולל אפשרות minify), החלפת ההצהרה והתנהגות סגירה עצמית כפקדים מהשורה הראשונה - הם' אינם קישוט, הם' הם הכפתורים שקובעים אם צרכן בררן מקבל את המסמך שלך בניסיון הראשון.
שָׁוא
כיצד אוכל להמיר JSON ל-XML?
הדבק את ה-JSON שלך בעורך ולחץ על המר מקשי אובייקט הופכים לרכיבי XML, מערכים הופכים לתגים חוזרים, והתוצאה נראית מוכנה להעתקה או הורדה אין העלאה - ההמרה מתרחשת בדפדפן שלך.
כיצד מיוצגות תכונות JSON ב-XML?
לפי המוסכמה, כל מפתח אובייקט שמתחיל ב-"@" הקידומת כתובה כתכונה על אלמנט האב שלו ולא כאלמנט צאצא. לדוגמה, {"book": {"@id": "bk101", "title": "..."}} הופך
כיצד הממיר מטפל במערכי JSON?
כל אלמנט של מערך נפלט כאלמנט אח חוזר החולק את המפתח 's name. אז {"tags": {"tag": ["a", "b"]}} מייצר
בשביל מה מפתח #טקסט?
כאשר אלמנט זקוק הן לתכונות והן לתוכן טקסט, הטקסט מאוחסן תחת "#טקסט" מַפְתֵחַ. {"title": {"@lang": "en", "#text": "Hello"}} הופך
האם אני יכול לקבל XML ממוזער במקום פלט מחורץ?
כן. הגדר את ההזחה ל-0 (minify) והממיר פולט את כל המסמך בשורה אחת ללא רווח לבן בין התגים. זה שימושי עבור בקשות SOAP או הזנות שבהן גודל המטען חשוב; עבור חזרה ל-2 או 4 רווחים כאשר אתה צריך מסמך קריא.
מה קורה למפתחות שאינם שמות רכיבי XML חוקיים?
שמות רכיבי XML אינם יכולים להכיל רווחים, אינם יכולים להתחיל בספרה, במקף או בנקודה, ואינם כוללים את רוב סימני הפיסוק. מפתחות המפרים כללים אלה עוברים חיטוי - תווים לא חוקיים הופכים לקו תחתון וקו תחתון מוביל מתווסף בעת הצורך - כך שהפלט תמיד מנתח, גם אם מפתחות ה-JSON שלך לא היו ידידותיים ל-XML.
האם JSON ל-XML הלוך ושוב עם הכלי XML ל-JSON?
עבור המבנים הנפוצים שהוא עושה כלי זה וכלי XML ל-JSON חולקים את אותו "@" קידומת תכונה ו-"#text" מפתח תוכן, כך שהמרת XML ל-JSON ובחזרה משחזרת בדרך כלל את אותו מסמך. פרטים בלתי תלויים בהזמנה ותוכן מעורב הם המקורות הרגילים להבדלים קטנים, כפי שהם בכל מיפוי XML/JSON.
האם זה בטוח להמיר JSON רגיש כאן?
כן. הממיר הוא JavaScript רגיל שפועל כולו בדפדפן שלך - שום דבר שאתה מדביק לא מועבר לשרת, מתועד או מאוחסן. זה הופך אותו לבטוח עבור תגובות API, קבצי תצורה ורשומות המכילות אסימונים או נתונים אישיים, והוא ממשיך לעבוד ללא חיבור לרשת.
