אין מיפוי סטנדרטי בין השניים. XML 1.0 בעל תכונות, מרחבי שמות, תוכן מעורב מסודר והערות; RFC 8259 בעל שישה סוגים וללא תכונות כל ממיר ממציא גשר משלו, וזו הסיבה ששניים מהם לא מסכימים.
האינטגרציה שלימדה אותי לכבד המרת XML ל-JSON הייתה ספקית משלוח 's API. REST מודרני בכל מקום אחר בערימה, ואז נקודת הקצה האחת הזו מדור קודם שדיברה SOAP והחזירה מעטפות של XML שהייתי צריך לקפל לצינור JSON. "It's רק XML ל-JSON," חשבתי, והגעתי לממיר בשורה אחת. ואז הגיעו מקרי הקצה: א <Package> אלמנט שהיה לפעמים אובייקט בודד ולפעמים רשימה, תלוי כמה חבילות היו בסדר. An id תכונה שהממיר הנאיבי שלי ירד לחלוטין כי הוא הסתכל רק על טקסט אלמנט. א <Description> עטוף ב-CDATA כי הוא הכיל אמפרסנד. כל אחד מאלה השחית בשקט את הנתונים - ה-JSON יצא נראה סביר וטעה בדרכים שהופיעו רק שלושה שירותים במורד הזרם.
XML ו-JSON נראים כאילו הם צריכים להמיר טריוויאלי זה לזה, והם עושים 't, כי הם מדגמים נתונים עם פרימיטיבים שונים. ל-JSON יש אובייקטים, מערכים, מחרוזות, מספרים, בוליאנים ו-null - קבוצה קטנה ונקייה. ל-XML יש אלמנטים, תכונות, צמתי טקסט, תוכן מעורב, מרחבי שמות, CDATA, הערות והוראות עיבוד, ובאופן מכריע יש לו אין מערכים ו בלי סוגים. אז ממיר צריך לקבל החלטות שפורמט ללא הפסדים 't: לאן הולכות תכונות כאשר ל-JSON אין מושג עליהן? איך אתה מבחין בין אלמנט בודד מרשימה של פריט אחד כאשר XML מסמן את שניהם באותו אופן? מה קורה לאלמנט שיש לו גם תכונות וגם טקסט?
An ממיר XML ל-JSON זה מקבל את ההחלטות האלה בכוונה - ובעקביות - הוא ההבדל בין אינטגרציה נקייה לשבוע של ניפוי באגים במורד הזרם. זה שבניתי עבור מפות Toolz.dev מייחס למפתחות עם קידומת כך ששום דבר לא הולך לאיבוד, ממוטט תגים חוזרים ונשנים לתוך מערכי JSON כך שהמבנה נשמר, שומר טקסט מעורב תוכן תחת מפתח ייעודי וקורא CDATA מילה במילה. וזה עושה את הכל עם מנתח נטול תלות שפועל בדפדפן שלך, מה שחשוב כי מטענים של אינטגרציה הם בדיוק סוג הנתונים שאתה צריך ' להעלות לשרת stranger's.
מדריך זה מכסה כיצד ההמרה מטפלת ב-XML' מוזרויות מבניות, כאשר אלמנטים חוזרים הופכים למערכים, כיצד להתמודד עם תכונות ומרחבי שמות, וזרימות העבודה של SOAP ו-RSS שבהן המרה זו מתרחשת ללא הרף.
TL;DR: הדבק XML לתוך Toolz.dev XML כדי JSON ממיר, בחר הזחה, ונקה JSON במקום שבו תכונות הופכות
@-מקשים עם קידומת, תגים חוזרים הופכים למערכים, טקסט מעורב תוכן יושב מתחת#text, ו-CDATA נקרא מילה במילה. סוג אופציונלי ניתוח הופך"44.95"לתוך מספר אמיתי. הוא משתמש במנתח נטול תלות, מריץ 100% בצד הלקוח כך שמטעני SOAP ואינטגרציה לעולם לא עולים, ומשתלב עם JSON ל-YAML וה פורמט JSON לשלב הבא בצנרת שלך.
מדוע 't XML ל-JSON הוא מיפוי פשוט אחד לאחד?
האינטואיציה ש-XML ו-JSON ניתנים להחלפה מגיעה מהעבודה המשותפת שלהם - המייצגת נתונים מובנים - ונשברת באבני הבניין השונות שלהם. חוסר ההתאמה מופיע בארבעה מקומות ספציפיים, וממיר ' האיכות עוסקת לחלוטין באופן שבו הוא מטפל בהם.
לתכונות אין מקבילה ל-JSON. <book id="bk101">War and Peace</book> בעל תכונה (id) ותוכן טקסט (War and Peace). ל-JSON אין מושג של תכונה; הכל הוא זוג מפתח-ערך. ממיר חייב להמציא מוסכמה, והנפוץ הוא קידומת מפתחות תכונה - { "book": { "@id": "bk101", "#text": "War and Peace" } }. זרוק את התכונות, כפי שעושים ממירים תמימים, ואתה ' איבדת נתונים בשקט.
ל-JSON יש מערכים; XML does't. ב-XML, רשימה היא בדיוק אותו תג שחוזר על עצמו: שלוש <item> אלמנטים תחת הורה אחד. אבל יחיד <item> נראה זהה מבחינה מבנית לרשימה של אחד. JSON צריך לדעת אם לפלוט אובייקט או מערך, והאות היחיד הזמין הוא התרחשות - כך שתגים חוזרים הופכים למערכים ותגים בודדים נשארים אובייקטים.
תוכן מעורב. אלמנט יכול להכיל גם אלמנטים של ילד וגם טקסט רופף. אובייקטי JSON יכולים't מייצגים באופן טבעי את " לאובייקט זה יש גם ערך מחרוזת חשופה," כך שהטקסט עובר מתחת למפתח שמור כמו #text.
סוגים don'לא קיימים ב-XML. כל ערך ב-XML הוא טקסט. <price>44.95</price> הוא המחרוזת "44.95", לא מספר, אלא אם ממיר בוחר לכפות אותו - והבחירה הזו יכולה להיות שגויה, כי <zip>08544</zip> חייב להישאר מחרוזת או לאבד את האפס המוביל שלה.
ה ממיר מטפל בכל אחד מאלה במפורש במקום להעמיד פנים שהם עושים ' לא קיימים. That's מדוע הפלט נשאר נאמן למקור במקום להפיל בשקט את חלקי ה-XML של-JSON אין חריץ עבורם.
מתי אלמנטים חוזרים הופכים למערכים?
זהו החלק המבלבל ביותר בהמרת XML ל-JSON, וזה ' שווה להבין במקום להיות מופתע. הכלל ה ממיר השימושים מבוססים על התרחשות: בתוך אב נתון, אם שם תג מופיע יותר מפעם אחת, הערכים שלו קורסים למערך JSON; אם הוא מופיע בדיוק פעם אחת, הוא נשאר אובייקט או ערך בודד.
אז א <catalog> עם שניים <book> ילדים מייצרת { "catalog": { "book": [ {...}, {...} ] } } - מערך. אבל א <catalog> עם אחד <book> מייצרת { "catalog": { "book": {...} } } - אובייקט רגיל, ללא מערך.
התוצאה שיש לתכנן עבורה: רשימה של פריט אחד does't נראה כמו רשימה. אם הקוד במורד הזרם שלך מצפה catalog.book להיות תמיד מערך וחוזר מעליו, תגובה של ספר בודד תשבור אותו, כי book יהיה אובייקט בזמן המסוים הזה. This isn't באג בהמרה - it's תוצאה בלתי נמנעת של XML לא סימון רשימות - אבל it's ממש gotcha באינטגרציות שבהן ספירת הפריטים משתנה אסון המשלוח-נשא שלי היה בדיוק זה: הזמנות של חבילה אחת החזירו אובייקט שבו הזמנות מרובות חבילות החזירו מערך, והקוד שלי הניח מערך.
דפוס ההגנה בקוד הצריכה שלך הוא לנרמל: אם שדה יכול להיות אחד מהם, כפה אותו על מערך לפני איטרציה ([].concat(catalog.book)). לדעת למה הצורה משתנה היא מה שמאפשר לך לכתוב את השומר הזה במקום להישרף ממנו.
כיצד מטפלים בתכונות ומרחבי שמות?
תכונות מומרים למפתחות אובייקט עם א @ קידומת. <user role="admin" active="true"> הופך { "user": { "@role": "admin", "@active": "true" } }. הקידומת שומרת על תכונות שונות מבחינה ויזואלית ממרכיבי צאצא ומונעת התנגשות כאשר תכונה ורכיב צאצא חולקים שם. אם אתה עושה ' לא צריך תכונות בכלל - אתה רוצה רק את נתוני האלמנט - ה ממיר יש "התעלם מתכונות" אפשרות שמפילה אותם לחלוטין לתוצאה נקייה יותר.
מרחבי שמות מגיעים כחלק משם התג. <soap:Body> הופך למפתח שממש נקרא "soap:Body", ו xmlns:soap="..." הוא תכונה כמו כל אחר, נוחת תחת @xmlns:soap. זו הבחירה הפרגמטית: פתרון מלא של מרחבי שמות ל-URI שלהם ייצור מפתחות מסורבלים ולעיתים רחוקות תואם את מה שקוד האינטגרציה באמת רוצה, כלומר לטפל בו soap:Body בשם הקידומת המוכר שלו. אם אתה ' מעבדים SOAP או SVG או אוצר מילים כלשהו בקצב שמות, הקידומות שאתה מכיר מה-XML הן המפתחות שאתה מקבל ב-JSON.
קטעי CDATA - ה <![CDATA[ ... ]]> בלוקים המאפשרים ל-XML לשאת טקסט גולמי עם תווים מיוחדים - נקראים מילה במילה, ללא פענוח ישות, וזו בדיוק מטרתם. א <script> או <description> עטוף ב-CDATA כדי להגן על חולות האמפרסנד וסוגרי הזווית שלו מגיע עם התווים האלה שלמים. מחוץ ל-CDATA, ישויות סטנדרטיות (<, &, וחברים) והפניות מספריות (é, é) מפוענחים לתווים האמיתיים שלהם.
איך ממירים XML ל-JSON עם הכלי?
שלב 1: הדבק את ה-XML שלך
כל XML מעוצב היטב עובד - עם או בלי <?xml ?> הצהרה, עם או בלי מרחבי שמות ההצהרה, DOCTYPE, הערות והוראות עיבוד מזוהים ודילג, כך שתוכל להדביק מסמך מלא ישר מתגובת API או קובץ כפתור טען מדגם נותן לך קטלוג עם תכונות, אלמנטים מקוננים, ותג חוזר, כך שתוכל לראות כל התנהגות המרה בבת אחת.
שלב 2: בחר את האפשרויות שלך
בחר הזחה של 2 או 4 רווחים עבור ה-JSON. החליטו אם לכלול תכונות או שחרר אותן. ובחרו אם לנתח סוגים: השאר אותו כבוי וכל ערך נשאר מחרוזת (בטוח, ללא הפסדים); הפעל אותו ומספרים ובוליאנים חד משמעיים הופכים למספרי JSON ובוליאנים אמיתיים. כבוי הוא ברירת המחדל הנכונה כאשר לערכים כמו מיקוד או מזהים עשויים להיות אפסים מובילים שאתה צריך לשמר.
שלב 3: המר וסקירה
הממיר מנתח תחילה ומדווח על סימון שגוי - תג סגירה לא תואם, אלמנט לא סגור, בלוק CDATA לא מופסק - עם הודעה ספציפית במקום לייצר זבל JSON. בהצלחה, ה-JSON מופיע עם ספירת שורות ובייטים. דלג עליו כדי לאשר שהחלטות מערך מול אובייקט תואמות את הציפיות שלך.
שלב 4: העתק או הורד
העתק את ה-JSON ללוח שלך להדבקה בקוד, או הורד אותו בתור א .json קובץ. מכאן הוא נופל לגוף בקשה, למאגר נתונים או לשלב הבא של הצינור שלך. אם השלב הבא הוא פורמט תצורה, ה ממיר JSON ל-YAML לוקח את זה הלאה.
מהם זרימות העבודה הנפוצות עבור המרה זו?
שילוב ממשקי API של סבון מדור קודם
SOAP עדיין נמצא בכל מקום במערכות ארגוניות, בנקאיות, לוגיסטיקה וממשל, והוא מדבר XML באופן בלעדי כאשר שירות JavaScript או Node מודרני צריך לצרוך תגובת SOAP, המרת מעטפת ה-XML ל-JSON היא שלב ראשון. משמעות ההמרה לשמירה על מרחב השמות soap:Body ו soap:Envelope שמור על השמות המוכרים שלהם, והטיפול בתכונות שומר על המטא נתונים ש-SOAP אוהב לתלות אלמנטים. זוהי אותה קטגוריה של עבודת דבק המכוסה ב- מדריך איתור באגים ב-API.
קריאת הזנות RSS ו-Atom
הזנות RSS ו-Atom הן XML, ומשיכתן לאפליקציית JavaScript פירושה המרתן. עדכון 's <item> אלמנטים הם מקרה התג החוזר של ספרי הלימוד - הם הופכים למערך JSON של פריטים, בדיוק מה שאתה רוצה .map() מעל לעיבוד רשימה. תכונות כמו מארז 's url ו type נשמרים תחת המקשים עם הקידומת שלהם, כך שעדכוני פודקאסט ומדיה שומרים על קישורי האודיו שלהם שלמים.
העברת קבצי תצורה ונתונים
יישומים ישנים יותר מאחסנים תצורה ונתונים ב-XML - חשבו .config קבצים, מפות אתר, מערכי נתונים מיוצאים, קטעי XML של Office Open.המרת אלה ל-JSON היא המהלך הראשון בעת מודרניזציה של מערכת או ייבוא נתונים מדור קודם לחנות מקורית של JSON. אפשרות ניתוח הסוג שימושית כאן כשאתה לדעת השדות המספריים הם מספריים באמת ורוצים שיקלדו אותם ביעד.
בדיקה ויצירת אב טיפוס
כאשר אתה' מחדש חיווט זרימת נתונים ורק צריך לראות את הצורה של מטען XML כמו JSON - לעצב ממשק TypeScript, ללעוג תגובה, לבדוק נתיב שדה - המרה מהירה בדפדפן פעימות כתיבת קוד מנתח לזרוק המר, לקרוא את המבנה, לכתוב סוגים שלך נגד זה.
XML לעומת JSON: מתי כל פורמט מתאים?
| XML | JSON | |
|---|---|---|
| עידן ראשוני & מערכת אקולוגית | ארגונים, סבון, מסמכים | ממשקי API של אינטרנט, JavaScript, config |
| תכונות | מחלקה ראשונה | אין - ממופה למקשים עם קידומת |
| מערכים | אין - תגיות חוזרות מרמזות על רשימות | מחלקה ראשונה |
| סוגים | כל הטקסט | מחרוזות, מספרים, בוליאנים, null |
| תגובות | נתמך | לא במפרט |
| מרחבי שמות | מחלקה ראשונה | אין - נשמר כשמות מפתח עם קידומת |
| מִשׁפָּעִיוּת | גבוה יותר - סגירת תגיות, תכונות | תחתון - פלטה וסוגריים |
| בית גידול טבעי | SOAP, RSS/Atom, פורמטים של Office, config | ממשקי API של REST, נתונים חזיתיים, package.json |
הדפוס מאחורי הטבלה: XML נבנה עבור מסמכים והחלפת ארגונים שבהם מבנה, אימות ותיאור עצמי חשובים; JSON נבנה עבור האינטרנט שבו קלות ומפה ישירה לאובייקטי JavaScript חשובים. כיוון ההמרה הוא ברובו המכריע XML-to-JSON מכיוון שהתנועה בתעשייה היא ממערכות ישנות יותר מבוססות XML לעבר קצוות קדמיים ושירותים מקוריים של JSON - you' הם פוגשים נתונים מדור קודם היכן שהוא חי ומביאים אותו לצינור מודרני. הסט הרחב יותר של כלי פורמט עבור הצינור הזה נמצא ב- מדריך כלי קידוד.
האם זה בטוח להמיר XML המכיל נתונים רגישים?
מטענים אינטגרציה צפופים עם דברים שאתה don' t רוצה לדלוף: תגובות SOAP נושאות רשומות של לקוחות, קבצי תצורה עם נקודות קצה פנימיות ואישורים, ייצוא נתונים עם מידע אישי. ואלה בדיוק מה שמודבק בממירים מקוונים, בדרך כלל באמצע האינטגרציה, בדרך כלל ממהרים.
ה Toolz.dev ממיר מנתח וממיר לחלוטין בדפדפן שלך עם מנתח נטול תלות - לא DOMParser, אין שיחת שרת, אין נתונים עוזבים את הדף.נתק את הרשת שלך לאחר טעינת הדף וזה עדיין עובד. That's עובדה ארכיטקטונית על אופן בניית הכלי, לא הבטחה במסמך מדיניות, ו- 's העיקרון הראשון של הדפדפן מאחורי ארגז הכלים כולו, המפורט ב- מדריך פרטיות נתונים.
האזהרה הסטנדרטית חלה: המרה בצד הלקוח מגינה על שלב ההמרה. מה שאתה עושה עם ה-JSON לאחר מכן - היכן שאתה מדביק אותו, למה אתה שולח אותו - הוא החלטה נפרדת. אבל הטרנספורמציה עצמה שומרת את ה-XML שלך במחשב שלך.
שָׁוא
כיצד אוכל להמיר XML ל-JSON באינטרנט?
הדבק את ה-XML שלך ב-XML to JSON Converter ולחץ על המר הכלי מנתח את ה-XML, ממיר אותו ל-JSON עם ההזחה והאפשרויות שבחרת, ומאפשר לך להעתיק או להוריד את התוצאה העיבוד הוא 100% בדפדפן - שום דבר לא מועלה.
כיצד מיוצגות תכונות XML בפלט JSON?
תכונות הופכות למפתחות אובייקט עם קידומת @, אז רכיב ספר עם id="bk101" ממיר ל-"@id" מַפְתֵחַ. זה שומר על תכונות שונות ממרכיבי צאצא. אתה יכול לכבות את פלט התכונות לחלוטין עם האפשרות ignor-attributes אם אתה צריך רק את נתוני האלמנטים.
מדוע רכיבי XML מסוימים הופכים למערכים ואחרים נשארים אובייקטים?
ל-JSON אין דרך לסמן שאלמנט יכול לחזור על עצמו, ולכן הממיר משתמש בהתרחשות: אם תג מופיע יותר מפעם אחת תחת אותו אב הוא הופך למערך, ואם הוא מופיע ברגע שהוא נשאר אובייקט בודד. זה משקף את המקור נאמנה, אם כי זה אומר שרשימה עם פריט אחד נראית כמו אובייקט בודד ולא מערך.
האם הממיר מטפל במקטעי cdata וישויות XML?
כן. בלוקים של CDATA נקראים מילה במילה ללא פענוח ישויות, וזו מטרתם. מחוץ ל-CDATA, הישויות הסטנדרטיות כמו <, >, &, " ו-' והפניות לתווים מספריים כמו é ו-é מפוענחים לתווים האמיתיים שלהם.
האם אוכל להמיר תגובת SOAP או הזנת RSS ל-JSON?
כן. SOAP מעטפות והזנות RSS או Atom הם XML רגיל, אז הם להמיר כמו כל מסמך אחר. Namespaced תגיות לשמור על הקידומת שלהם בשם המפתח - סבון: הגוף הופך "soap:Body" מפתח - ו אלמנטים חוזרים כמו פריטי RSS להפוך מערך JSON אתה יכול למפות מעל.
האם מספרים ובוליאנים יישארו כטקסט לאחר ההמרה?
כברירת מחדל כן, מכיוון של-XML אין מערכת סוגים וערכים כמו "007" או "1.10" עשוי להיות משמעותי כטקסט. אפשר את אפשרות ניתוח הסוג להמיר טקסט מספרי ובוליאני חד משמעי למספרי JSON אמיתיים ובוליאנים כאשר זה מה שאתה רוצה.
האם זה בטוח להמיר XML שמכיל נתונים רגישים?
כן. המנתח פועל כולו ב-JavaScript בדפדפן שלך - אף בקשת רשת לא נושאת את הנתונים שלך, שום דבר לא נרשם או מאוחסן, והכלי עובד במצב לא מקוון. XML עם רשומות לקוחות, מזהים פנימיים או סודות אינטגרציה לעולם לא עוזב את המחשב שלך.
מה ההבדל בין XML ל-JSON?
XML היא שפת סימון עם תגי פתיחה וסגירה, תכונות, מרחבי שמות והערות, המיועדת למסמכים וחילופי נתונים ארגוניים.JSON הוא פורמט קל יותר הבנוי מאובייקטים, מערכים וערכים פרימיטיביים, ומהווה את ברירת המחדל עבור ממשקי API מודרניים באינטרנט. המרת XML ל-JSON נפוצה בעת שילוב מערכות SOAP או מבוססות הזנה ישנות יותר עם קצוות קדמיים של JavaScript.
XML ו-JSON נראים ניתנים להחלפה ו-aren't, מכיוון של-JSON אין תכונות, אין מערכים לפי חזרה, ואין טקסט לצד ילדים - המקומות המדויקים שהמרה נאיבית מאבדת נתונים בשקט ממיר שמטפל במקרים האלה בכוונה נותן לך JSON ש' נאמן למקור: הדבק את ה-XML שלך, בדוק כיצד הוא מיפה את התכונות והתגים החוזרים, והכנס נתונים נקיים לצינור שלך במקום השחתה סבירה למראה.
