בפעם הראשונה XML כמעט הרס לי את אחר הצהריים, זה היה תגובת SOAP משער תשלום שורה אחת אחד עשר אלף תווים אין newlines, אין הזחה, רק קיר לא שבור של סוגריים זווית כי המסוף שלי עטוף לתוך לבנה בלתי קריא איפשהו ב היה אלמנט שגוי יחיד גורם אי התאמה חתימה, והייתי אמור למצוא אותו על ידי עין בניתי הרבה דברים מאז - תוספי וורדפרס, ממשקי API של Laravel, כלי React מאחורי [Toolz.dev] (/ - ואני יכול להגיד לך כי טוב XML formatter הוא אחד מאותם כלי עזר שקטים אתה לא מעריך עד הרגע שאתה בוהה קיר של תגים עם תאריך יעד מאחוריך.
המדריך הזה הוא המדריך שהלוואי שהיה לי באותו אחר הצהריים. זה מכסה את מה שמעצב XML עושה בפועל, מדוע מייפות ומיניפיקציה הם שני צדדים של אותו מטבע, כלל הרווח הלבן שהופך את העיצוב לבטוח, וקומץ שגיאות האימות שמסבירות כמעט כל "למה ניצח ' בניתוח" זה; רֶגַע. אתה יכול לעקוב בדפדפן עם החינם פורמט XML - הוא פועל כולו על המכונה שלך, כך שאפילו מטען תשלום לעולם לא עוזב את המחשב הנייד שלך.
TL;DR: מעצב XML כותב מחדש מסמך 's רווח לבן לא משמעותי - הרווח בין תגיות - מבלי לגעת במשמעותו.Beautify מוסיף מעברי שורות והזחה כדי שתוכל לקרוא את ההיררכיה; minify strips את כל זה כך שהקובץ יהיה קטן ככל האפשר. מעצב טוב שומר הערות, CDATA, הצהרת XML וסדר תכונות, ומאמת צורה טובה (תגיות תואמות, אלמנטים סגורים, קטעים שהסתיימו) לאורך הדרך. זה עושה לא בדוק את המסמך שלך מול סכימת DTD או XSD - זו עבודה אחרת.
מה עושה למעשה מעצב XML?
Whitespace הוא המקום שבו העיצוב נעשה מעניין, כי XML 1.0 דורש מנתח להעביר כל תו בתוך אלמנט דרך האפליקציה - וזו הסיבה שמעצב צריך לדעת במה בטוח לגעת. בבסיסו, מעצב XML מנתח את המסמך שלך לעץ של צמתים - אלמנטים, טקסט, הערות, קטעי CDATA, הוראות עיבוד - ולאחר מכן מבצע בסידרה את העץ הזה בחזרה עם מרווחים עקביים. הנסיעה הלוך ושוב היא כל הטריק. מכיוון שהכלי מבין את המבנה במקום לעשות חיפוש והחלפה עיוור, הוא יכול להכניס מקונן עמוק <order><items><item> שרשרת נכונה, לשים כל אח על הקו שלו, ולדעת שהטקסט בפנים <price>44.95</price> צריך להישאר על אותו קו כמו התגים שלו במקום להשתרע על פני שלושה.
הסיבה שזה משנה מסתכמת בכלל הקבור במפרט ה-XML: רוב הרווח הלבן בין האלמנטים הוא חסר חשיבות. כאשר מנתח קורא <a>\n <b/>\n</a>, הקווים החדשים והחללים מסביב <b/> האם יש לבני אדם ואינם נושאים נתונים. מותר לפורמט להוסיף, להסיר או לשנות את הרווח הלבן הזה בחופשיות. מה שאסור לו לגעת בו הוא משמעותי רווח לבן - התווים בתוך צומת טקסט כמו <note>Call me at 9am</note>, או כל דבר בתוך בלוק CDATA - כי התוכן הזה הוא נתונים אמיתיים. כל החלטת עיצוב ה פורמט XML עושה זרימות מכיבוד הקו הזה.
אז מייפה זה לא מוך קוסמטי. כאשר אתה מכניס מחדש את לבנת ה-SOAP הזו בת אחד-עשר אלף התווים, היררכיית האלמנטים הופכת גלויה, ופתאום לא במקום <Amount> צומת שלוש רמות עמוקות מדי ברור. עיצוב הוא כלי איתור באגים כמו כלי קריאה.
למה שאמזער XML במקום לייפות אותו?
Beautify ו-minify הם אותו מנוע מכוון לכיוונים מנוגדים. Beautify מוסיף רווח לבן לבני אדם; minify מסיר אותו עבור מכונות. אתה מושיט יד ל-minify כאשר הגודל או התחבורה חשובים: כיווץ קובץ תצורה שנשלח בתוך חבילת אפליקציות לנייד, חיתוך גוף בקשה לפני שהוא עובר חיבור איטי, או נרמול מסמך כך שניתן להשוות שתי גרסאות בתים-עבור- בייט מבלי שרעש הזחה יפריע.
החיסכון הוא אמיתי אך לעתים רחוקות דרמטי. XML' המילוליות חיה בשמות התגים החוזרים ונשנים שלה, לא ברווח הלבן שלה, כך שהקטנה בדרך כלל חותכת איפשהו בין חמישה לעשרים אחוז, תלוי עד כמה המקור היה מחורץ בכבדות. זה שווה, אבל אם אתה צריך דחיסה רצינית, gzip על החוט עושה הרבה יותר - מזעור ואז gzipping היא גישת החגורה והפלטה שבה משתמשים ממשקי API רבים.
הנה המודל המנטלי שאני משתמש בו כשאני מחליט באיזו דרך לכוון את הכלי:
| מצב | לְיַפֵּף | למזער |
|---|---|---|
| קריאה או איתור באגים בתגובה בעין | כן | לא |
| התחייבות קובץ תצורה לבקרת גרסאות | כן (הבדלים נקיים) | לא |
| משלוח XML בתוך חבילת אפליקציות או דרך הרשת | לא | כן |
| אחסון מסמכים קטנים רבים בעמודת מסד נתונים | לא | כן |
| הכנת מסמך להפרש בייט לבייט | או, בעקביות | או, בעקביות |
| מסירת XML למפתח אחר | כן | לא |
משמעת המפתח היא עקביות אם אתה diffing שני מסמכים, לרוץ שניהם דרך אותו מצב עם אותן אפשרויות תחילה - אחרת אתה משווה סגנונות הזחה, לא תוכן.
כיצד עיצוב נמנע משינוי הנתונים שלי?
זו החרדה שכל מעצב צריך להרוויח את דרכו בעבר: " אם הכלי הזה משכתב את ה-XML שלי, איך אני יודע שהוא לא שבר משהו בשקט?" התשובה הכנה היא שמעצב בנוי היטב משנה רק את הרווח הלבן בין התגים, ומשאיר ארבעה דברים לבד.
הראשון הוא תוכן טקסט. התווים בתוך אלמנט מועתקים מילה במילה. זה כולל ישויות - מילולית & נשאר &, זה אף פעם לא מפוענח בצורה מועילה & (שייצר XML לא חוקי) או מקודד כפול ל &amp;. ה פורמט XML מתייחס לטקסט שלך כאטום, וזה בדיוק מה שאתה רוצה.
השני הוא קטעי CDATA. א <![CDATA[ ... ]]> בלוק קיים בדיוק כדי שתוכל להוריד תוכן גולמי שלא נמלט - קטע של JavaScript, נתח של HTML, מחרוזת מלאה ב < ו & - לתוך מסמך XML מבלי לברוח ממנו מעצב פולט את התוכן הזה בדיוק כפי שמצא אותו, ללא בריחה, ללא כניסה חוזרת לתוך הבלוק.
השלישי הוא הערות וההצהרה. הערות (<!-- ... -->), ה <?xml version="1.0"?> הצהרה, וכל הוראות עיבוד נשמרות וממוקמות בצורה הגיונית אתה יכול לבחור להסיר הערות כאשר אתה רוצה קובץ רזה יותר, אבל זו ההחלטה שלך, לא משהו שהכלי עושה מאחורי הגב שלך.
הרביעי הוא סדר תכונות וציטוט. כברירת מחדל, המעצב שומר את התכונות שלך בסדר שכתבת אותן, עם סגנון הציטוט שבו השתמשת, מכיוון שמפרט ה-XML מתייחס לסדר התכונות כחסר משמעות ואין סיבה לחבוט בו. כאשר אתה לעשות רוצה סדר קנוני - עבור הבדלים נקיים יותר, או להשוות בין שני אלמנטים הנושאים את אותן תכונות בסדרים שונים - "מיין תכונות" האפשרות מציבה אותם בסדר אלפביתי עבורך.
מכיוון שכל זה פועל בצד הלקוח ב-JavaScript, יש גם דיבידנד פרטיות: מסמך מלא במחרוזות חיבור, מזהים פנימיים או רשומות לקוחות מעוצב במחשב שלך ולעולם לא מועלה. אם אכפת לך לשמור על נתוני עבודה מאנשים אחרים's שרתים - ואתה צריך - כדאי להבין את המודל הזה, וכתבתי עליו יותר ב- מדריך פרטיות נתונים לכלים מקוונים.
אילו שגיאות XML תופס המעצב?
לפני שמעצב יכול להדפיס משהו יפה, עליו לנתח את המסמך, והניתוח הוא המקום שבו מתרחש האימות השימושי. זהו צורה טובה בדיקה - הכללים המבניים שכל מסמך XML חייב לציית להם - ומניסיוני שלוש טעויות מהוות את הרוב המכריע של הכישלונות.
הנפוץ ביותר ללא ספק הוא א אמפרסנד חשוף. עתודות XML & כדי להקים ישות, אז גולמי & בטקסט - מהסוג שמתגנב פנימה דרך כתובת URL כמו ?a=1&b=2 או שם חברה כמו "Marks & Spencer" - גורם למנתח לצפות לשם ישות ואז להיחנק כשהוא לא מוצא אחד. התיקון הוא לכתוב &, והודעת שגיאה טובה תכוון אותך לקו כך שאתה לא צד עיוור.
השני הוא א תג לא תואם או לא סגור. פתח א <div> ולסגור אותו עם </section>, או פתח א <span> ולעולם אל תסגור אותו כלל, והמסמך כבר לא מעוצב היטב. המעצב עוקב אחר ערימת האלמנטים הפתוחים בזמן שהוא מנתח, כך שהוא יכול להגיד לך בדיוק איזה תג הוא ציפה לראות סגור ואיזה הוא באמת מצא. ההודעה הבודדת הזו - "צָפוּי </book> אבל נמצא </author> בשורה 14" - בדרך כלל מספיק כדי לפתור את הבעיה בשניות.
השלישי הוא an קטע לא מופסק: תגובה נפתחה עם <!-- שלעולם לא מגיע -->, או בלוק CDATA שלעולם לא מגיע ]]>. קל ליצור אותם כשאתה עורך ביד ומוחק קצת יותר מדי. שוב, הפורמט מדווח על השורה שבה התחיל הקטע הבורח.
מה שהפורמט עושה לא האם זה לבדוק את המסמך שלך מול סכימה. Well-formness שואל " האם זה XML תקף מבחינה מבנית?" תוקף שואל " האם XML זה פועל לפי הכללים של הפרטיקולרי שלי סוג מסמך - האלמנטים הנכונים, בסדר הנכון, עם סוגי הנתונים הנכונים - כפי שהוגדרו על ידי DTD או XSD?" אלה שכבות נפרדות מסמך יכול להיות מעוצב בצורה מושלמת ועדיין להיות שטויות למטרה המיועדת לו אימות סכימה צריך את הסכימה, וזה כלי אחר המעצב מבטיח את השכבה הראשונה, שהיא זו שעוצרת את קריסת המנתח שלך.
כיצד אוכל לעצב XML בעורך שלי או לבנות צינור?
כלי הדפדפן הוא הנתיב המהיר ביותר עבור מסמך חד פעמי, אך כדאי לדעת את החלופות כדי שתוכל לבחור את המתאים לתפקיד.
רוב העורכים מעצבים XML באופן מקורי. בקוד VS, הפקודה המובנית "Format Document" הפקודה (Shift+Alt+F) מטפלת ב-XML, והרחבות כמו Red Hat's שרת שפת XML מוסיפות עיצוב מודע לסכימה למעלה. IntelliJ ואחיו פורמטים מחדש עם Ctrl+Alt+L. אלה אידיאליים כאשר הקובץ כבר פתוח מולך.
בשורת הפקודה, xmllint --format file.xml (חלק מ-libxml2, שנשלח ברוב מערכות יוניקס) מייפה, ו xmllint --noblanks file.xml מקרב אותך לפלט ממוזער בפרויקט Node, ספריות כמו xml-formatter או prettier עם חריץ תוסף XML לשלב בנייה מפתחי Python להגיע ל xml.dom.minidom.parseString(s).toprettyxml(), אם כי יש להזהיר, זה ידוע לשמצה בהוספת שורות ריקות נוספות סביב הרווח הלבן הקיים.
אז למה להשתמש ב פורמט XML בכלל? שלוש סיבות שאני כל הזמן חוזר אליהן. זה לא צריך התקנה, לא תצורה ולא פרויקט - אתה מדביק והולך. זה שומר את הנתונים במחשב שלך, מה שחשוב כאשר ה-XML הוא מטען אמיתי ולא דוגמה לצעצוע. וזה משתלב באופן טבעי עם הכלים השכנים: ברגע שה-XML שלך נקי ותקף, המרתו ל-JSON עם ממיר XML ל-JSON הוא קליק אחד, והנסיעה לאחור דרך JSON ל-XML משתמש באותן מוסכמות אם היום שלך הוא בעיקר JSON, ה פורמט JSON הוא המקביל לפורמט הזה, וכל המשפחה מקוטלגת ב- ערכת כלים למפתחי אינטרנט.
מתי עלי לפרמט לעומת להמיר את ה-XML שלי?
שאלה שאני מקבל מאנשים חדשים יותר לזה: אם JSON קל יותר לקריאה, למה לעצב XML במקום רק להמיר אותו? התשובה היא שעיצוב והמרה פותרים בעיות שונות.
פורמט כאשר אתה צריך לשמור ה-XML - כי נקודת קצה SOAP דורשת זאת, כי הזנת RSS או Atom היא XML בהגדרה, כי קובץ התצורה שלך, פריסת האנדרואיד שלך או ה-Maven שלך pom.xml פשוט הוא XML ותמיד יהיה. עיצוב הופך את ה-XML הזה לקריאה או קומפקטית תוך השארתו כ-XML. שום דבר במורד הזרם לא חייב להשתנות.
המר כשתרצה עבודה עם הנתונים בפורמט אחר - משיכת ערכים לקצה הקדמי של JavaScript, טעינת הזנה למערכת שמדברת JSON, או נרמול מספר מקורות לצורה אחת. המרה משנה את הפורמט, ואיתה חלק מהנאמנות: לתכונות XML, לתוכן מעורב ולסדר אלמנטים אין מקבילות JSON נקיות, כך שממיר עושה בחירות מכוונות (תכונות הופכות למפתחות עם קידומת, תגים חוזרים הופכים למערכים) שכדאי להבין לפני שאתה מסתמך עליהם.
כלל האצבע שלי: פורמט ראשון, תמיד. קל יותר לנמק מסמך נקי ומאומת אם השלב הבא שלך הוא עריכה, שינוי או המרתו. עיצוב הוא הפעולה הזולה, הבטוחה, ללא הפסדים; המרה היא האובדן שאתה עושה ברגע שאתה יודע שהמבנה תקין. מפות אתר הן דוגמה נחמדה ל-XML שאתה מעצב במקום להמיר - אם אתה בונה אחת, הייעודית מחולל sitemap מייצר פלט תקף ומעוצב היטב ישירות.
שאלות נפוצות
איך אני מפרמט XML באינטרנט?
הדבק את ה-XML שלך בחלונית הקלט, בחר BeautiFy, בחר רוחב הזחה ולחץ על פורמט. הכלי מנתח את המסמך, מכניס אותו מחדש ומאפשר לך להעתיק או להוריד את התוצאה. כל העיבוד מתרחש בדפדפן שלך - שום דבר לא מועלה.
מה ההבדל בין ייפוי למזער XML?
ייפוי מוסיף מעברי שורות והזחה כך שההיררכיה של האלמנטים קלה לקריאה, וזה אידיאלי לעריכה וניפוי באגים. Minifying מסיר את כל הרווח הלבן בין התגים כדי לייצר את הקובץ הקטן ביותר האפשרי, שהוא אידיאלי לאחסון או שליחה דרך הרשת. שניהם משמרים את המסמך's משמעות; רק הרווח הלבן חסר המשמעות משתנה.
האם העיצוב משנה את המשמעות של ה-XML שלי?
לֹא . רק הרווח הלבן בין התגים משתנה - האלמנטים, התכונות, תוכן הטקסט, ההערות וה-cdata אינם משתנים. מכיוון שרווח לבן משמעותי בתוך צמתי טקסט ו-CDATA נשמר, מסמך מעוצב היטב מתנהג באופן זהה לפני ואחרי העיצוב.
האם קטעי הערות ו-cdata נשמרים?
כן הערות, קטעי CDATA, הצהרת XML והוראות עיבוד נשמרים כולם הערות מוזחות לצד האלמנטים שהם יושבים איתם, ותוכן CDATA נפלט מילה במילה ללא כל בריחה אתה יכול גם לבחור להסיר הערות אם אתה רוצה פלט רזה יותר.
האם הכלי הזה יכול לאמת את ה-XML שלי?
כן. לפני העיצוב, המסמך מנותח במלואו, ובעיות מבניות - אלמנט לא סגור, תג סגירה שאינו תואם את תג הפתיחה שלו, או הערה ללא סיום או קטע cdata - עם מספר שורה כדי שתוכל לתקן אותם במהירות. הוא בודק צורה טובה, לא תוקף מול סכימת DTD או XSD.
מדוע ה-XML שלי לא מצליח לעצב?
כמעט כל הכשלים הם שגיאות מעוצבות היטב הנפוצים ביותר הם אמפרסנד חשוף בטקסט (יש לכתוב אותו כישות, או שהנתח קורא אותו כהתחלה של ישות), תג סגירה שאינו תואם לאלמנט שהוא סוגר, ואלמנט שנפתח אך לעולם לא נסגר הודעת השגיאה מצביעה על הקו כך שתוכל לקפוץ ישר אליו.
האם זה בטוח לעצב XML שמכיל נתונים רגישים?
כן. המנתח פועל כולו ב-JavaScript בדפדפן שלך - שום בקשת רשת לא נושאת את הנתונים שלך, שום דבר לא נרשם או מאוחסן, והכלי עובד במצב לא מקוון לאחר טעינה. XML החזקת מפתחות API, מחרוזות חיבור או רשומות לקוחות לעולם לא עוזבת את המחשב שלך.
האם אוכל להמיר את ה-XML המעוצב ל-JSON לאחר מכן?
כן. ברגע שה-XML נקי ותקף, ממיר ה-XML ל-JSON הופך אותו ל-JSON שווה ערך, מיפוי תכונות למפתחות עם קידומת ותגים חוזרים למערכים. העיצוב תחילה הופך את המבנה לברור, מה שעוזר לך להבין כיצד הוא ימופה לפני שתמיר.
נכתב על ידי ליטון - בונה של Toolz.dev, WP Adminify, ורשימה ארוכה של פרויקטים של Laravel ו-React.כל כלי שהוזכר כאן פועל בחינם ומלא בדפדפן שלך בכתובת [Toolz.dev] (/.
