תאמינו או לא, על אף השקט המחפיר (שעליו אני מתנצל) ששׂרר פה לאחרונה, קיבלתי שאלה מ„ציבור הקוראים”. בוא נכנה את השואל בשם הקוד „אמיר”, כי זה איך שהוא חתם על ה–SMS.
כן, קיבלתי שאלה ב–SMS…
שלום שחר, שמי אמיר- איך עשית את הסי פלוס פלוס בכיוון הנכון בעמוד האודות בבלוגך? לא ראיתי מארקאפ מיוחד בקוד
תשובה קצרה – וואו! יש לי עמוד „אודות” בבלוג! שכחתי לגמרי מקיומו! אולי הגיע הזמן לעדכן אותו, עכשיו שלינגנו מתה? נו, זה לא היה כזה כואב, נכון? ולשאלתך – שמתי LRM אחרי שני הפלוסים.
תשובה יותר ארוכה:
שלום אמיר. רואים שאתה לא קורא קבוע בבלוג שלי. לאור העובדה שאני לא כותב קבוע בבלוג שלי, אין לך במה להתבייש או על מה להתנצל.
כאשר אנחנו מקלידים את התו C, ואחריו פעמיים את התו +, מי שמחליט להיכן הולכת כל אות הוא אלגוריתם שמוגדר ע״י תקן Unicode. בפרט, האלגוריתם מוגדר בנספח טכני מספר 9 של התקן, ומכונה „Unicode Bidirectional Algorithm”, או בקיצור, UBA. לאור העובדה שבימינו כמעט כל מערכת שתומכת בעברית מממשת גרסה כזו או אחרת של UBA, משתלם להכיר כמה מהתכונות הבסיסיות שלו. רק לצורך הטריויה, התוכנה היחידה שאני מכיר שלא משתמשת ב–UBA כדי להציג עברית היא MS Word.
תיאור מלא של UBA הוא מעבר להיקף סביר של הבלוג הזה. הוא גם מיותר: מי שמבקש באמת להבין את UBA מוזמן לעשות תרגיל פשוט (יחסית). תקראו את התיאור של האלגוריתם, ואז נסו לכתוב מחרוזות שמפעילות את כל החוקים המתוארים שם. נסו לנבא איך המחרוזות עומדות להראות. לעזרתכם, באתר Unicode יש גם מנגנון שמאפשר לשחק עם מחרוזות שונות, ולראות מה עומד UBA לעשות איתן, ומה שיותר חשוב, בגלל אלו חוקים. פה, למשל, תמצאו את הניתוח של הכותרת של הפוסט הזה.
בכל זאת, למי שלא מעוניין ללמוד בעל פה אלגוריתם שמכיל 41 שלבים שונים, הנה תיאור מקוצר של האלגוריתם שאמור להספיק לחיי היום–יום של כל משתמש מחשב ממוצע.
הבסיס של האלגוריתם הוא קטלוג האותיות של Unicode. לכל אות התקן מייחס תכונת BiDi. יש די הרבה תכונות אפשריות, אבל בהכללה גסה לצורך הדיון הזה האותיות מתחלקות לשלוש קבוצות. אותיות שהן שמאל ימין מטבען (כמו כל האותיות הלטיניות), אותיות שהן ימין שמאל מטבען (כמו כל האותיות בעברית), ואותיות ניטרליות. בנוסף לכך, ושוב, תוך הפשטה שעלולה לעלות לי בחברותי בפורום התקינה של מכון התקנים, בזמן הכתיבה מסתכלים על כיוון הפיסקה.
Pet peeve: רבים טועים לחשוב ש–UBA דורש שכיוון הפיסקה ייקבע ע״י כיוון האות הכיוונית הראשונה בפיסקה (ומצביעים על חוק P3 כסימוכין). הניתוח הזה של התקן פשוט שגוי. אכן התקן מציע את השיטה הזו, אבל אומר במפורש, הן מיד אחרי P3 והן ב–HL1, שמותר להשתמש בכל שיטה אחרת. בפרט, בחלונות משתמשים ב–CTRL+SHIFT (כאשר השימוש הוא ב–Shift הימני או השמאלי) כדי להחליף את כיוון הפיסקה להיות ימין–שמאל או שמאל–ימין. ב–HTML מסמנים את כיוון הפיסקה באמצעות ה–attribute „dir” (או „text-direction” ב–CSS). שני השימושים האלו אינם מהווים הפרה של התקן.
לסיום התסקיר המהיר של UBA, האלגוריתם עובר ומחלק רמות לכל אות. הרמות הזוגיות פירושן טקסט שייכתב, בסופו של דבר, משמאל לימין. הרמות האי–זוגיות פירושן טקסט שייכתב מימין לשמאל. אם הפיסקה היא פיסקה עברית, הרמות מתחילות באחת. אם אנגלית באפס.
בהמשך ההסבר אני עומד להשתמש הרבה בניתוח באתר של יוניקוד של כותרת הבלוג הזה. אני ממליץ לשמור את הקישור פתוח בדפדפן נפרד, כדי שתוכלו להתייחס אליו בזמן שאתם קוראים את הטקסט פה. כמו כן, מידי פעם אני אתייחס לחוקים בשמות כמו N1 או W6. אלו שמות החוקים כפי שמוגדרים על פי ה–UBA. הם מיועדים בעיקר למי שמעוניין להעמיק. כל השאר מוזמנים להתעלם.
בקישור לעיל מבצעים ניתוח של הכותרת של הפוסט הזה. כפי שניתן לראות, כיוונתי את כיוון הפיסקה להיות ימין שמאל באופן מפורש. הטקסט עצמו מופיע פעמיים. פעם אחת בסדר לוגי (כל האותיות משמאל לימין אחת אחרי השניה – סדר ההקלדה). השני מופיע בסדר ויזואלי, כשמעליו שני מספרים. השורה העליונה ממספרת את המיקום הסופי. השורה התחתונה נותנת את המיקום המקורי, בתוך הבאפר הלוגי. חזרה לחלק העליון, אנחנו רואים שורה שנקראת Bidi Class. זוהי הקטגוריה של האות. במידה והופעל חוק כדי לשנות את הקטגוריה בזמן הטיפול, הוא יופיע בשורה שמתחת. השורה האחרונה מציגה את רמת ה–bidi שהאות קיבלה בסופו של דבר. שוב – רמות זוגיות פירושן סידור משמאל לימין בסופו של דבר. רמות אי זוגיות פירושן סידור מימין לשמאל.
ישנם רק שלושהארבעה חוקים של UBA שצריך באמת לזכור:
- אותיות בעלות כיווניות מובהקת יקבלו רמה זוגית או אי–זוגית, בהתאם לכיווניות שלהן (I1 ו–I2).
- השוליים של הפיסקה נחשבים כמו אותיות בעלות כיווניות מובהקת בכיוון הפיסקה (N1)
- אותיות ניטרליות שנמצאות בין אותיות בעלות כיווניות מובהקת באותו הכיוון יקבלו את הכיוון שעוטף אותן (N1).
- אותיות ניטרליות שנמצאות בין אותיות בעלות כיווניות מנוגדת יקבלו את כיווניות הפיסקה (N2).
עכשיו, משאנחנו יודעים את זה, בואו ננתח את הכותרת של הפוסט הזה. ברור שהמילים בעברית מקבלות רמה אי–זוגית (במקרה הזה: 1). באותו האופן, ברור שהאות C מקבלת רמה זוגית (במקרה הזה: 2). בואו נסתכל על תו הרווח שנמצא במיקום לוגי 4. הקטגוריה שלו היא „WS”, שפירושה „White space”. זוהי קטגוריה ניטרלית. אנחנו רואים שהופעל על הרווח חוק N1, שהפך אותו ל–R, והוא קיבל את הכיוון 1. זה מכיוון שהוא נמצא בין שתי אותיות שהן R. זה בדיוק מה שחוק N1 אומר.
בואו נסתכל על עוד שני רווחים. זה שנמצא במיקום 18 וזה שנמצא במיקום 23. מצד אחד שלהם יש אות בכיווניות L, ומצד שני R. על פי כללי האצבע לעיל, הם אמורים לקבל את כיווניות הפיסקה (חוק N2). מכיוון שהפיסקה שלנו היא עברית, זהו כיוון 1. אותו הניתוח חל גם על סימן השאלה שבסוף הפיסקה, במיקום 30. הקטגוריה שלו היא ON, שפירושה „Other neutral”, מה שמרמז לנו שגם הוא ניטרלי:-). גם הוא קיבל את רמה 1. מה שקורה זה שאחריו יש אות בכיוון ימין–שמאל (סוף הפיסקה), ולפניו אות בכיוון שמאל–ימין (C). מכיוון שהכיווניות משני צדדיו שונה, הוא מקבל את הכיווניות של הפיסקה, שהיא ימין–שמאל. עד כאן האלגוריתם התנהג בדיוק כפי שרצינו שיתנהג, ואין לנו תלונות.
עכשיו בואו נפנה את תשומת ליבנו לשני סימני הפלוס שנמצאים בסוף הפיסקה, במיקומים 28 ו–29. הקטגוריה שלהם היא ES, שפירושה „European separator”. אם היה צמוד אליהם מספר הם היו יכולים להחשב כסימנים בעלי כיווניות שמאל ימין, אבל מכיוון שאין לידם מספר הם הופכים (על פי חוק W6) ל–ON. כמובן שמרגע שהחלטנו שהם ניטרלים, הטיפול בהם זהה לטיפול בסימן השאלה, והם מקבלים רמה 1. זה מה שגורם לפלוסים להופיע בצד הלא נכון בכותרת שלנו.
אבל בכותרת שלנו יש עוד סט של שני פלוסים. גם הם מופיעים אחרי ה–C. בכל זאת, הם מוצגים מימינו, כמו שאנחנו רוצים, ולא משמאלו. הסתכלות על החוקים שהופעלו מראה שעליהם, בניגוד לאחיהם שבאים אחריהם, הופעל חוק N1 כדי לתת להם את רמה 2. להזכירכם, חוק N1 מדבר על ניטרלי שנמצא בין שתי אותיות בעלות אותו כיוון מובהק. ברור לנו שלפניהם יש את האות C, שהיא בעלת כיוון מובהק L. אחריהם, אבל, אנחנו לא רואים שום אות בעלת כיוון מובהק עד לאות אלף, שהיא בעלת כיוון R. לכאורה, גם פה היה אמור להכנס לתוקף חוק N2, וגם הפלוסים האלו היו אמורים לצאת הפוכים.
התמונה קצת מתבהרת ברגע שמסתכלים על שורת הקטגוריות. לאות במיקום 22, שנראית קצת כמו רווח, יש את הקטגוריה L. ברור שהיא הסיבה שהפלוסים האלו קיבלו רמה 2 ולא 1, ונמצאים במקום הנכון. עדיין, לא ברור מה זה התו הזה או איך הוא הגיע לשם. כמו כן, בעוד שהתו הזה נמצא בצורה ברורה בתצוגה באתר, בכותרת של הפוסט הזה יש רק רווח אחד בין ה–C++ לבין המילה שאחריו. ברור שבין הפלוס לרווח יש תו שאנחנו לא רואים שעושה את הקסם הזה.
למרבה השמחה, האתר עוזר לנו גם עם זה. אם נשהה את העכבר מעל כל אות יופיע לנו חלון קטן שמציג לנו את האות, שמה ומיקומה ביוניקוד. אם נשהה את העכבר מעל האות הראשונה, לדוגמא, יופיע לנו חלון שאומר: „U+05DE HEBREW LETTER MEM”. זה אומר שזו האות מם, ומספרה בבסיס 16 הוא 5de. באותו האופן, השהיית העכבר מעל האות ה–22 בשורה מציגה לנו: „U+200E LEFT-TO-RIGHT MARK”.
Left to right mark, או בשמו המקוצר, LRM, הינו תו ברוחב אפס. זה אומר שאין לו שום הצגה גרפית על המסך, והוספה שלו לא תשנה את הצורה שבה האותיות שסביבו נכתבות. כל תרומתו לפיסקה היא עצם העובדה שהתו מקוטלג כתו בעל כיווניות שמאל ימין חזקה. אני משוכנע שלא תופתעו לשמוע שבמיקום U+200F יש לו אח בשם Right to left mark, או RLM, שזהה לו בכל חוץ מאשר העובדה שכיוונו הוא ימין לשמאל.
השימושיות של התווים האלו היא בדיוק בשביל המטרה שהם משיגים בכותרת הפוסט הזה. הם מאפשרים לשים תו בעל כיווניות מובהקת במקום שבו UBA מבצע החלטה שלא תואמת את מה שאנחנו רוצים שהוא יציג. באתר הדוגמא שלנו ניתן להכניס אותם לטקסט ע״י לחיצה על RLM או LRM בכפתורים שמעל המקום שבו מקלידים. כמו כן, אם התקנתם את המקלדת החדשה של מכון התקנים, ניתן להקליד אותם ישירות מהמקלדת ע״י לחיצה על AltGr בשילוב עם הסוגריים (סוגר ימין בשביל RLM, סוגר שמאל בשביל LRM).
לסיכום, התוים RLM ו–LRM הם תווים שמאוד שימושיים כמעט בכל מקום שבו UBA לא מצליח באופן אוטומטי לעשות את מה שאנחנו רוצים שיעשה. הוספה שלהם בצורה חכמה מאפשרת לתקן תצוגה לא תקינה של טקסטים מעורבים בלי לשחק עם סדר האותיות (מה שדופק קוראי מסך, פעולות העתקה והדבקה ומנועי חיפוש). בפרישת המקשים החדשה של מכון התקנים ניתן להקליד את התווים האלו ישירות מהמקלדת. מומלץ ללמוד לעבוד איתם.
שחר
נ.ב.
כתבתי קודם ש–MS Word לא משתמש ב–UBA לתצוגה שלו. היה צריך להיות מובן, אבל אני אגיד בכל זאת, שהמשמעות היא שלא ניתן להשתמש ב–LRM וב–RLM כדי לתקן עיוותי תצוגה שהוא עושה. העיצה היחידה שיש לי לתת לכם במקרה ש–Word מחרבש לכם מילים היא להחליף את שפת המקלדת ולנסות להקליד את המילה עוד פעם. התרגיל הזה כן יעבוד על LibreOffice, OpenOffice, Notepad, Internet explorer, Android, iPhone, וכמעט כל תוכנה אחרת שרק תנסו.
תודה על התשובה 🙂 שכחתי מהתווים האלה לגמרי. נזכרתי בעקבות הפוסט שלך ב־abiword שלפי זכרוני עושה עבודה מצויינת עם כל ה־LTR/RTL והמילים המסובכות שאני לא יודע להגיד… ושוב תודה!
מאמר מלמד ומעמיק. עשה לי סחרחורת.
אפשר פשוט להתחכם ולכתוב ++C. שלהדיוט יראה כאילו פעלתי לפי החוקים אבל הדקדקן יגלה שכתבתי + + ואז את האות C . לפעמים זה הכי קל ככה לא?
במיוחד בתיבות טקסט כמו זו שבה אני כותב כרגע.
שלום דורון,
התייחסתי בדיוק לשאלה הזו בפסקה האחרונה. כשאתה כותב כך, אתה דופק קוראי מסך (שמקריאים את הטקסט לעוורים). אתה כותב מילה לא נכונה, ומקטין את החשיפה שלך למנועי חיפוש. אתה גם לא מאפשר לבצע העתקה של הטקסט למקום אחר.
שחר
רק רציתי להעיר שה-Outing לדפדפן ומערכת ההפעלה של ה”גולש” (== מין תבשיל), קצת פוגע בפרטיותי, לא?
מאמר טוב!
מר איד היקר (או שבסדר לקרוא לך פרנו?)
אני מודע לחששך, אולם איני מסכים איתו. מי שבאמת ובתמים מעוניין שלא ידעו באמצעות איזה דפדפן הוא גולש מסוגל בהחלט לזייף את הזיהוי שהוא שולח למשהו מפוברק כזה או אחר, או אף למשהו לא סביר בעליל. שימוש ב–NCSA Mosaic או, לחסרי המעוף, Netscape Navigator 1.0, עשוי לעשות את העבודה.
כל האחרים שולחים את מערכת ההפעלה והדפדפן שלהם עם כל בקשה, ועושים כן בין אם אני מציג את זאת באתר ובין אם לאו. אם כתוצאה מהעובדה שאני מראה את הנתונים האלו גרמתי לך לטרוח ולשנות את הזיהוי שאתה שולח, אולי בכלל עשיתי לך טובה בזאת שהפניתי את תשומת ליבך לכך שאתה דולף נתונים שאתה לא מעוניין לדלוף.
במישור הרחב יותר, הכנסתי את התוסף הזה בתקופה שהבלוג שלי הכיל תנועה יותר ערה בנושאי קוד פתוח. בתקופה ההיא, היה מתוך הצגת הנתון הזה שיקוף של האם פיו וליבו של הדובר דומים.
אני מקווה שתאמין לי שלא התכוונתי לפגוע.
שחר