מחולל טבלאות Markdown

ארבעה פורמטים בכניסה, פורמט אחד ביציאה

טבלת Markdown קל לכתוב וקשה לתחזק. הוספת מילה אחת לתא מוציאה כל קו אנכי מתחתיה מהשורה, ובניית טבלה מנתונים שכבר יש לכם — תוצאת שאילתה, ייצוא מגיליון, תשובה של API — פירושה להקליד הכול מחדש ביד. הכלי הזה מקבל את הנתונים בצורה שבה הם נמצאים אצלכם ומחזיר טבלה נקייה בניב Markdown של GitHub.

הוא קורא ארבעה פורמטים, ואומר לכם באיזה מהם הוא בחר במקום להחליט בשקט:

• טבלת Markdown, כך שטבלה שיצאה מהיישור פשוט מודבקת בחזרה ומיושרת מחדש.
• CSV, מנותח לפי RFC 4180 — שדה במרכאות יכול להכיל פסיקים, מרכאות ואפילו שורות חדשות, וכולם שורדים.
• TSV, שזה מה שמקבלים כשמעתיקים טווח מגיליון אלקטרוני או מלקוח של מסד נתונים.
• מערך JSON, בין של אובייקטים (המפתחות הופכים לעמודות) ובין של מערכים (השורה הראשונה הופכת לכותרת).

הזיהוי מחפש קודם את הראיה המובהקת ביותר: סוגר מרובע פותח יכול להיות רק JSON, שורה של מקפים יכולה להיות רק שורת מפריד של Markdown, וטאב בשורה הראשונה יכול להיות רק TSV. הפרדה בפסיקים היא מה שנשאר, ולכן היא מדווחת כברירת מחדל ולא כזיהוי — אם הכלי נאלץ לנחש, הוא אומר זאת, ובורר הפורמט גובר עליו.

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

תא מרופד לפי רוחב, לא לפי אורך

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

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

'日本語'.length          // 3  UTF-16 code units
[...'日本語'].length     // 3  code points
displayWidth('日本語')   // 6  columns in the editor

לכן הריפוד נמדד בעמודות תצוגה. הטקסט מפוצל תחילה לאשכולות גרפיים — מה שקורא סופר כתו אחד, כך שאימוג׳י הבנוי מכמה נקודות קוד מחוברות נשאר יחידה אחת — וכל אשכול נמדד מול המאפיין East_Asian_Width מבסיס הנתונים של Unicode. זה הדבר היחיד שדפדפן אינו יכול לענות עליו בעצמו: JavaScript חושפת קטגוריה, כתב ורישיות דרך ביטויים רגולריים, אבל לא את המאפיין הזה, ולכן טבלה קטנה של טווחי הרוחב הכפול נשלחת עם העמוד. כל השאר מגיע מהמנוע.

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

מה שטבלת Markdown לא יכולה להכיל

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

שניהם נכתבים מחדש, וכל כתיבה מחדש מדווחת עם מספר התאים שנפגעו ומיקומו של הראשון. זו כל הנקודה: כלי שהופך בשקט כתובת בת שתי שורות לשורה אחת פגע בנתונים שלכם בלי לומר. שורה חדשה הופכת כברירת מחדל לתג שבירה, שזה מה ש-GitHub, GitLab ורוב המעבדים מציגים כשורה חדשה בתוך התא; אם המעבד שלכם מסיר HTML, החליפו אותו ברווח.

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

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

היישור חי בשורת המפריד

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

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

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

מרופד או קומפקטי, ולמה טקסט מימין לשמאל שונה

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

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

מאותה סיבה פלט ה-Markdown בעמוד הזה מוצג תמיד משמאל לימין, גם כשקוראים את האתר בעברית או בערבית. זה קוד מקור, ולקוד מקור יש כיוון משלו.

איפה זה רץ

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