מלכודות גופנים ותווים יפניים — טיפול ב-JIS2004, IVS וגאיג'י ביישומים עסקיים

“התו 葛 ברשימת הלקוחות נראה שונה על המסך ועל הטופס המודפס. הלקוח התלונן שהנתונים חייבים להיות מושחתים.” — בתחזוקת מערכות עסקיות, ייעוץ מהסוג הזה אינו נדיר. נפוץ נוסף הוא “תו בשם אדם לא מוצג במסמך שאנחנו מגישים למשרד ממשלתי. הוא הוצג במחשב הישן; אחרי שהחלפנו, הוא הפך ל-□.”

שניהם נוטים להיקרא “mojibake” בשטח, אבל זו בעיה שונה מה-mojibake שמגיע מאי-התאמת קידוד. בראשון, אף ביט בנתונים לא השתנה ורק המראה השתנה; בשני, “גאיג’י” שהתקיים רק על אותו מחשב אבד.

flowchart TB
    accTitle: מה שני הייעוצים הנפוצים באמת
    accDescr: הייעוץ ש-葛 נראה שונה על המסך ועל הטופס הוא מקרה שבו רק המראה השתנה והנתונים נשארו זהים; הייעוץ שתו הפך ל-□ אחרי החלפת מחשב הוא מקרה שבו גאיג'י שהתקיים רק על אותו מחשב אבד; שניהם בעיה שונה מ-mojibake של אי-התאמת קידוד
    c1["ייעוץ 1: הצורה שונה על המסך ועל הטופס"] --> r1["הנתונים לא השתנו; רק המראה השתנה"]
    c2["ייעוץ 2: הפך ל-□ אחרי החלפה"] --> r2["גאיג'י שהתקיים רק על אותו מחשב אבד"]
    r1 --> diff["בעיה שונה מ-mojibake של קידוד"]
    r2 --> diff

איור 1: שני הייעוצים שנוטים להיקרא “mojibake” שניהם בעיה שונה מאי-התאמת קידוד.

ההבטחה של המאמר הזה פשוטה. אם מפרידים את שכבת קוד התו (נתונים) משכבת הגופן (מראה), רוב בעיות התווים היפניים נעשות ניתנות לטיפול. משינוי הגליף של JIS2004, בוררי וריאציה אידיאוגרפיים (IVS) וגאיג’י (EUDC), דרך פלטפורמת התווים של הממשלה, ועד בחירת גופנים והטמעתם, זה מסודר בצורה שמפתחות ומפתחי מערכות עסקיות ואנשי IT יכולים להשתמש בה להחלטות.

ה”mojibake” עצמו שקורה בהמרת Shift_JIS ↔ UTF-8 מכוסה במאמרים קיימים, לכן המאמר הזה מתרכז בבעיה של “הקודים עושים הלוך-חזור נכון, אבל המראה או יכולת התצוגה סטייה”.

1. השורה התחתונה קודם

• “Mojibake” ו”הגליף שונה” הן בעיות שונות. Mojibake הוא תאונה בשכבת הנתונים של פירוש שגוי של רצף בתים; הבדל גליף הוא תאונה בשכבת המראה של הבדל בגליפים שגופן מחזיק; התרופות שונות לגמרי.
• גם עם אותה נקודת קוד Unicode, הגליף שמוצג תלוי בגופן. JIS X 0213:2004 תיקן את הגליפים לדוגמה של 168 תווים כמו 葛, 辻 ו-飴 לצורות תקן הדפוס, וגם Windows הפך את גליפי JIS2004 לברירת המחדל ב-MS Gothic / MS Mincho מ-Vista ואילך.¹²
• האמצעי הסטנדרטי לנעול גליף כנתון הוא בורר וריאציה אידיאוגרפי (IVS). מציינים גליף ברצף של תו בסיס ועוד בורר מ-U+E0100 ואילך; אוספים כמו Adobe-Japan1, Hanyo-Denshi ו-Moji_Joho (פלטפורמת מידע התווים) רשומים ב-IVD של Unicode.³⁴
• בסביבה שאינה תומכת ההתנהגות המוגדרת של IVS היא שהבורר מתעלמים ממנו ומוצג גליף ברירת המחדל של תו הבסיס. עם זאת, תו נושא-IVS יכול להיות עד ארבע יחידות קוד ב-UTF-16, ולכן מימושי ספירת תווים וחיתוך דורשים זהירות.⁵
• לגאיג’י (EUDC) יש את הגורל “יכול להיות מוצג רק על אותו מחשב”. אין משמעות מוסכמת לנקודת קוד באזור השימוש הפרטי, וגליף שנרשם ב-eudc.tte לא נוסע למחשב אחר, לדואר או ל-PDF.⁶⁷
• מערכת שמטפלת בשמות אנשים צריכה להחליט על ערכת התווים המתקבלת ולציין אותה. בצד הממשלה, על בסיס תווי קוסקי מאוחדים ופלטפורמת מידע התווים, מערכות שתואמות לתקן נעות לכיוון שימוש ב”תווים הסטנדרטיים לעניינים מנהליים”.⁸⁹¹⁰
• לטפסים ול-PDF, “ליישר את הגופן עם המסך, ולהטמיע אותו” הוא הבסיס. האם הטמעה מותרת נקבע לפי רישיון הגופן (fsType), ו-PDF/A לשמירה ארוכת טווח דורש הטמעת גופן.¹¹¹²
• אל תיישמו נרמול (NFKC) בקלות על נתוני שמות אנשים. איחוד רוחב מלא וחצי-רוחב, והחלפת תווי תאימות, מאבדים הבחנות שצריך לשמור.¹³

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

2. לחשוב על נתונים ומראה בנפרד — נקודות קוד וגליפים

ב-Unicode, תו מיוצג במספר שנקרא נקודת קוד. 葛 הוא U+845B, והמספר הזה זהה בכל מחשב. איך המספר הזה מצויר על מסך או על נייר, לעומת זאת, מחליט הגליף שהגופן מחזיק. זו התנהגות רגילה שאותו U+845B ישתנה בפרטי הצורה בין גופן א לגופן ב.

עם שתי השכבות האלה כהנחה, אפשר לפצל סימפטומים בשטח כך.

כסימן לפיצול, כדאי לזכור את ההבדל בין “�” ל-“□”. “�” של U+FFFD ‏(REPLACEMENT CHARACTER) הוא עקבות של כשל המרה בשכבת הנתונים, והתו המקורי כבר אבד. “□”, לעומת זאת, במקרים רבים הוא רק שהנתונים עדיין שם אבל לגופן אין גליף, והחלפת הגופן עשויה להפוך אותו לניתן-לתצוגה.

flowchart TB
    accTitle: פיצול הסימפטום לפי � מול □
    accDescr: כשתו לא מוצג נכון, � הוא עקבות של כשל המרה בשכבת הנתונים שבה התו המקורי אבד; □ הוא רק שהנתונים עדיין שם אבל לגופן אין גליף, והחלפת הגופן עשויה להפוך אותו לניתן-לתצוגה
    symptom["תו לא מוצג נכון"] --> which{"מה רואים?"}
    which -->|"רואים �"| datalayer["תאונת שכבת נתונים"]
    datalayer -.-> lost["עקבות כשל המרה（התו המקורי אבד）"]
    which -->|"רואים □"| viewlayer["תאונת שכבת מראה"]
    viewlayer -.-> noglyph["רק שלגופן אין גליף"]
    noglyph --> fixable["החלפת הגופן עשויה להציג"]

איור 2: � הוא סימן לתאונת שכבת נתונים, □ לתאונת שכבת מראה, ונקודת הכניסה לחקירה משתנה.

יסודות הקידודים עצמם (CP932 ו-UTF-8, BOM, קודי שורה חדשה) מכוסים ב”מבוא לקידודי טקסט ב-Windows - ה-mojibake שקורה באינטגרציה עם Linux” וב”קידודי טקסט וסופי שורה ב-Windows - היסודות של mojibake ו-CRLF/LF”. מכאן והלאה זו שכבת המראה, והבעיות שקורות בגבול שלה.

3. מ-JIS90 ל-JIS2004 — הגליף השתנה והקוד נשאר זהה

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

בעקבות דוח מועצת הלשון הלאומית משנת 2000 “Hyogai Kanji Jitaihyo” (טבלת צורות לקאנג’י מחוץ לרשימת הג’ויו), תיקון 2004 ‏JIS X 0213:2004 (המוכר כ-JIS2004) תיקן את הגליפים לדוגמה של 168 קאנג’י לצורות תקן הדפוס, קרובות למה שנקרא צורות מילון קאנגשי. 葛, 辻, 飴, 芦, 溢, 餅 וכדומה הם דוגמאות מייצגות.¹

Windows התיישר עם זה והפך את גליפי JIS2004 לברירת המחדל ב-MS Gothic / MS Mincho (וב-Meiryo שהוצג אז) מ-Windows Vista ואילך. גם MS Gothic הנוכחי יש לו גליף ברירת מחדל מבוסס-JIS2004, עם המבנה שגליפי עידן JIS90 נגישים דרך תכונת OpenType ‏jp90.²¹

flowchart TB
    accTitle: מבנה הגליפים של MS Gothic הנוכחי
    accDescr: מ-Vista ואילך, ל-MS Gothic יש גליפי JIS2004 כברירת מחדל, והגישה לגליפי עידן JIS90 דרך תכונת OpenType jp90 היא המבנה
    msg["MS Gothic（מ-Vista ואילך）"] --> def["גליף ברירת מחדל: מבוסס-JIS2004"]
    msg --> feat["דרך תכונת jp90"]
    feat --> old["גליפי עידן JIS90"]

איור 3: ל-MS Gothic הנוכחי יש גליפי JIS2004 כברירת מחדל, והוא יכול לעבור לגליפי JIS90 עם תכונת jp90.

מה שחשוב כאן הוא שרק הגופן השתנה; הנתונים לא השתנו בכלל.

• נקודת הקוד של 葛 היא U+845B גם ב-XP וגם ב-Windows 11
• ב-XP (גליפי JIS90) הוא מוצג בצורה שמפשטת את פנים הרדיקל העוטף ל-ヒ; מ-Vista ואילך (גליפי JIS2004) הוא מוצג בצורה שכותבת גם 人 בפנים
• לכן תמונה סרוקה של טופס שהודפס במערכת הישנה ותצוגת המסך במחשב חדש לא מסכימים על צורת התו. השוואת נתונים תואמת לגמרי

האם לרדיקל השיניו של 辻 יש נקודה אחת או שתיים, צורת רדיקל ה”אכילה” של 飴 וכדומה אותו דבר. אם לא מכירים את ההיסטוריה הזאת, החקירה נוטה ללכת בכיוון הלא נכון של “הנתונים הושחתו במיגרציה”. כשאומרים לכם שמראה של תו שונה לפני מיגרציה ואחריה, קודם משווים את נקודות הקוד, ואם הן תואמות חושדים בהבדל גליף של גופן — זה הסדר הנכון.

flowchart TB
    accTitle: אותה נקודת קוד, גליף שונה לפי הגופן
    accDescr: נקודת הקוד U+845B של 葛 נשארת זהה גם ב-XP וגם ב-Windows 11; רק הצורה המוצגת משתנה בין גופן גליפי JIS90 לגופן גליפי JIS2004, והשוואת נתונים תואמת לגמרי
    cp["נקודת קוד U+845B（葛）"] --> f90["גופן גליפי JIS90（XP）"]
    cp --> f04["גופן גליפי JIS2004（מ-Vista ואילך）"]
    f90 --> g90["הצורה שמפשטת את הפנים ל-ヒ"]
    f04 --> g04["צורת תקן הדפוס שכותבת 人 בפנים"]
    g90 -.-> same["השוואת נתונים תואמת לגמרי"]
    g04 -.-> same

איור 4: רק הגופן השתנה; נקודת הקוד U+845B נשארת זהה בכל סביבה.

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

4. בוררי וריאציה אידיאוגרפיים (IVS) — ציון גליף כנתון

IVS ‏(Ideographic Variation Sequence) הוא מנגנון שמניח נקודת קוד בלתי-נראית שנקראת “בורר וריאציה אידיאוגרפי” מיד אחרי קאנג’י, כדי לציין וריאנט גליף כנתון. הבוררים שבשימוש הם U+E0100–U+E01EF ‏(VS17–VS256).³

איזה רצף “תו בסיס + בורר” מפנה לאיזה גליף מחליט רישום שנקרא IVD ‏(Ideographic Variation Database), שמנוהל על ידי Unicode Consortium. האוספים העיקריים הם כדלקמן.⁴

התיעוד של Microsoft, למשל, נותן את הדוגמה ש-U+845B לבדו (葛) משמש בכתיב תחנת נישי-קאסאי, ו-U+845B+U+E0100 ‏(VS17) משמש בכתיב העיר קאטסוראגי, נארה. אותו 葛, אבל איזה גליף הוא אפשר להבחין כנתון.³

flowchart TB
    accTitle: דוגמה להבחנה באותו 葛 כנתון עם IVS
    accDescr: 葛 כ-U+845B לבדו משמש בכתיב תחנת נישי-קאסאי; הרצף של U+845B ואחריו VS17 משמש בכתיב העיר קאטסוראגי; איזה רצף מפנה לאיזה גליף מחליט רישום ה-IVD
    seq1["U+845B לבדו"] --> gl1["הגליף שבשימוש בכתיב תחנת נישי-קאסאי"]
    seq2["U+845B + VS17"] --> gl2["הגליף שבשימוש בכתיב העיר קאטסוראגי"]
    ivd["IVD（הרישום）"] -.-> gl1
    ivd -.-> gl2

איור 5: גם עם אותו 葛, נוכחות הבורר או היעדרו מאפשרים להבחין איזה גליף הוא כנתון.

4.1. התנהגות בסביבה שאינה תומכת

בצד הגופן, ההתאמה בין IVS לגליף ממומשת בטבלת cmap של OpenType (פורמט 14).⁵ כשגופן תומך (IPAmj Mincho וכדומה) ויישום תומך שניהם נוכחים, הגליף שצוין מופיע; כשלא, זה הולך כך.

• ההתנהגות הנכונה המוגדרת: מתעלמים מהבורר ומוצג גליף ברירת המחדל של תו הבסיס (הבורר עצמו בלתי-נראה)
• יישומים ישנים יותר וחלק ממחסניות ציור: הבורר מטופל כתו לא-ידוע עצמאי, ו-□ נוסף מוצג

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

flowchart TB
    accTitle: איך מוצגים נתונים נושאי-IVS
    accDescr: כשגופן תומך ויישום תומך שניהם נוכחים מוצג הגליף שצוין; כשלא, מתעלמים מהבורר ומוצג גליף ברירת המחדל של תו הבסיס; ביישומים ישנים יותר וחלק ממחסניות ציור הבורר מטופל כתו לא-ידוע ו-□ נוסף מוצג
    ivs["בסיס + בורר IVS"] --> env{"גופן תומך + יישום?"}
    env -->|"כן"| ok["הגליף שצוין"]
    env -->|"לא"| other{"איך מציירים?"}
    other -->|"מתעלמים"| ignore["גליף ברירת מחדל"]
    other -->|"ישן / חלק מהמחסניות"| tofu["□ נוסף"]
    ignore -.-> spec["נכון מוגדר"]

איור 6: IVS נשאר קריא כתו הבסיס גם אם הוא מתדרדר, אבל האם הגליף שצוין מופיע תלוי בסביבת המקבל.

4.2. זהירות מימוש — “תו אחד” יכול להיות עד ארבע יחידות קוד

בוררי IVS מ-U+E0100 ואילך הם נקודות קוד במישור משלים, לכן ב-UTF-16 הם תמיד זוג סורוגט (שתי יחידות קוד). אם תו הבסיס הוא קאנג’י במישור משלים (למשל 𠮟 ‏(U+20B9F), שנוסף ב-JIS2004), הבסיס לבדו כבר שתי יחידות קוד, והרצף שמשתמש מזהה כ”תו אחד” הוא עד ארבע יחידות קוד ב-UTF-16, ועד שמונה בתים ב-UTF-8.

• "葛󠄀" ‏(葛+VS17) ב-C# יש לו string.Length == 3. ‏Substring וחיתוך באורך קבוע מסכנים פיצול של תו הבסיס מהבורר
• אימות ספירת תווים וחיתוך צריכים להיעשות ביחידות גרפמה (API כמו StringInfo), לא ביחידות קוד
• לאורך עמודת DB ‏(nvarchar(n) של SQL Server הוא ביחידות קוד UTF-16), אם מקבלים IVS, מקצים פי שניים עד ארבעה ממספר התווים הנראה
• בחיפוש ובהשוואה, נוכחות הבורר או היעדרו עושים מחרוזת שונה. האם חיפוש של “葛” פוגע ב-“葛+VS17” זה משהו שצריך להחליט כדרישה ולממש

flowchart TB
    accTitle: תו אחד נושא-IVS ויחידות קוד UTF-16
    accDescr: הרצף של תו בסיס ובורר וריאציה אידיאוגרפי שמשתמש מזהה כתו אחד הוא תמיד זוג סורוגט לבורר, ואם תו הבסיס הוא קאנג'י במישור משלים עוד שתי יחידות קוד, עד ארבע יחידות קוד ב-UTF-16
    one["תו נראה אחד"] --> base["תו בסיס"]
    one --> vs["בורר וריאציה"]
    base -.-> bnote["+2 אם משלים"]
    vs -.-> vnote["תמיד 2 יחידות קוד"]
    base --> total["עד 4 יחידות UTF-16"]
    vs --> total
    total -.-> risk["פיצול בחיתוך קבוע"]

איור 7: תו נושא-IVS יכול להיות עד ארבע יחידות קוד ב-UTF-16; חיתוך לפי יחידת קוד מסוכן.

5. גאיג’י (EUDC) — תווים שמוצגים רק על אותו מחשב

גאיג’י הוא מנגנון שבו משתמש מקצה גליף משלו לנקודת קוד באזור השימוש הפרטי של Unicode ‏(PUA: U+E000–U+F8FF וכדומה). לנקודת קוד באזור שימוש פרטי אין משמעות מוסכמת עולמית; אותו U+E000 יכול לקבל תו אחר לכל מחשב ולכל ארגון.⁶

ב-Windows יוצרים את הגליף בעורך התווים הפרטיים (eudcedit.exe), והוא נשמר בקובץ גופן שנקרא eudc.tte. הקובץ הזה מותקן כגופן מוסתר ומשויך לכל גופן ברישום HKEY_CURRENT_USER\EUDC.⁷ בעידן Shift_JIS ‏(CP932) טווח הגאיג’י היה 0xF040–0xF9FC, ובהמרה ל-Unicode הוא ממופה לאזור השימוש הפרטי.

התוצאה של המנגנון הזה ברורה.

• eudc.tte שייך לאותו מחשב (לאותו משתמש) ואינו נוסע לצד השני עם הנתונים
• ברגע שהוא מועבר לדואר, ל-PDF, לרשת או למערכת אחרת הוא הופך ל-□ או נראה כמו גאיג’י אחר של הצד השני
• אם שוכחים להעביר את eudc.tte במיגרציית מערכת הפעלה או בהחלפת מחשב, קורה “תו שהוצג במחשב הישן לא יוצג”

זו הזהות של הייעוץ השני בפתיחה.

flowchart TB
    accTitle: למה גאיג'י מוצגים רק על אותו מחשב
    accDescr: גליף שנוצר בעורך התווים הפרטיים נשמר ב-eudc.tte ומשויך לגופנים ברישום של אותו מחשב, לכן אם רק קוד אזור השימוש הפרטי מועבר לדואר, ל-PDF או למערכת אחרת הוא הופך ל-□ או נראה כתו אחר
    edit["יוצרים גליף PUA"] --> tte["שומרים ב-eudc.tte"]
    edit -.-> editN["עורך תווים פרטיים"]
    tte --> reg["מיפוי גופנים ברישום"]
    reg --> local["מוצג על אותו מחשב"]
    tte -.-> stay["eudc.tte נשאר מאחור"]
    send["רק קוד ה-PUA הולך"] --> dest["דואר / PDF / מערכת אחרת"]
    dest --> broken["□ או תו שגוי"]
    local ~~~ send

איור 8: הגליף חי ב-eudc.tte; בנתונים נשאר רק מספר של אזור שימוש פרטי, לכן גאיג’י נראים שבורים ברגע שהם יוצאים מהמחשב.

5.1. תשובה מציאותית למערכת שכבר קיבלה גאיג’י

הבעיה היא כשנתונים שירשו ממערכת מדור קודם כבר יש בהם גאיג’י מעורבבים. ההליך שאנחנו ממליצים עליו בהתקשרויות מיגרציה הוא כדלקמן.

1. חוקרים: סורקים מסדי נתונים וקבצים בביטוי רגולרי לאזור השימוש הפרטי (U+E000–U+F8FF), וממנים את קודי הגאיג’י שבשימוש ואת ספירותיהם. אוספים eudc.tte ממחשבים בכל אתר ומאשרים את הגליפים
2. מזהים: לכל גאיג’י, חוקרים “אפשר לייצג כתו Unicode רגיל”, “אפשר לייצג עם IVS”, “יש תו מתאים בפלטפורמת מידע התווים (MJ)”, ובונים טבלת התאמת תווי חלופה. בפועל רוב המקרים הם פשוט שצורה ישנה נעשתה כגאיג’י של JIS
3. מחליפים: מחליפים את הנתונים מטבלת ההתאמה. רק כשבאמת אין תו מתאים, שומרים כתמונה או מצרפים הערה לרשומה הזאת
4. חותכים: במערכת החדשה, דוחים קלט של אזור השימוש הפרטי באימות, ולא יוצרים גאיג’י חדשים

flowchart TB
    accTitle: הליך מיגרציה של נתונים שמכילים גאיג'י
    accDescr: ממנים גאיג'י שבשימוש בסריקת אזור השימוש הפרטי ואיסוף eudc.tte, בונים טבלת התאמת תווי חלופה ומחליפים, ובמערכת החדשה דוחים קלט של אזור השימוש הפרטי באימות ולא יוצרים גאיג'י חדשים
    st1["חוקרים: סורקים PUA"] --> st2["מזהים: טבלת חלופה"]
    st2 --> st3["מחליפים מהטבלה"]
    st3 --> st4["חותכים: בלי גאיג'י חדשים"]
    st1 -.-> tte["אוספים eudc.tte"]
    st2 -.-> nomap["אין מיפוי: תמונה או הערה"]

איור 9: ממגרים גאיג’י בארבעה שלבים חוקרים, מזהים, מחליפים וחותכים, ולא יוצרים גאיג’י חדשים.

הכיוון זהה בצד הממשלה: נאמרה מדיניות לזהות באופן ייחודי את הגאיג’י שרשויות מקומיות יצרו בעצמן (נאמר כשני מיליון תווים ברחבי הארץ) מול התווים הסטנדרטיים לעניינים מנהליים שמתוארים בהמשך, ולהפסיק את השימוש בהם.¹⁰ “לא להגדיל גאיג’י; לזהות אותם מול ערכת תווים מתוקננת” הופך לדפוס המיגרציה המבוסס במגזר הציבורי והפרטי.

6. פלטפורמת התווים של הממשלה — מתווי קוסקי מאוחדים לתווים הסטנדרטיים לעניינים מנהליים

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

במערכות ליבה עירוניות (מערכות שתואמות לתקן), מבנה דו-שכבתי נמצא במפרט הסטנדרטי: משתמשים בתווים הסטנדרטיים לעניינים מנהליים לחילופי מידע של שמות אנשים וכדומה, ומתממשקים עם מערכות חיצוניות שאין להן כללי חילופין מאוחדים — סמארטפונים וכדומה — בהיקף JIS X 0213:2012.¹⁰ המבנה עצמו של “להחזיק ערכת תווים רחבה בפנים, ולהחליף עם החוץ בטווח שסביבה כללית יכולה להציג” הוא גם אסמכתא למערכות במגזר הפרטי.

flowchart TB
    accTitle: החילופין הדו-שכבתיים של מערכת תואמת-תקן
    accDescr: מערכת עירונית תואמת-תקן משתמשת בתווים הסטנדרטיים לעניינים מנהליים לחילופי מידע של שמות אנשים וכדומה, ומתממשקת עם מערכות חיצוניות כמו סמארטפונים שאין להן כללי חילופין מאוחדים בהיקף JIS X 0213:2012
    sys["מערכת עירונית תואמת"] --> renkei["חילופי שמות"]
    sys --> gaibu["מערכות חיצוניות"]
    renkei --> mjp["תווים מנהליים סטנדרטיים"]
    mjp -.-> mjpN["שמות אנשים וכו׳"]
    gaibu --> jis["היקף JIS X 0213:2012"]
    gaibu -.-> sumaho["בלי כללים（סמארטפון）"]
    mjp -.-> naibu["ערכת רחבה מוחזקת בפנים"]

איור 10: מבנה דו-שכבתי: חילופין ממשלתיים משתמשים בתווים הסטנדרטיים לעניינים מנהליים; חילופין חיצוניים בלי כללים משתמשים ב-JIS X 0213:2012.

כהנחיה מעשית למערכת עסקית כללית, אנחנו ממליצים על הבא.

• מחליטים על ערכת התווים המתקבלת ומציינים אותה גם במפרט וגם באימות קלט. למשל “היקף JIS X 0213:2012”, “אזור השימוש הפרטי ותווים משלבים אינם מותרים”, “IVS אינו מתקבל (או מתקבל, אבל תצוגה מובטחת רק בסביבת IPAmj Mincho)”
• לא מקבלים בלי גבול. תכנון של “זה Unicode, אז הכול הולך” יישבר איפשהו בתצוגה, בהדפסה או בחילופין
• מחליטים מראש על ההפעלה לתווים מחוץ לטווח. הכלל להחלפת ייצוג חלופי (צורה חדשה, קטקאנה) והניסוח שמסבירים לאדם הם עצמם מפרט מערכת
• כשלמערכת במורד הזרם כמו ממשלה או פיננסים יש כלל ערכת תווים, לוקחים אותו כסמכות ומיישרים איתו

flowchart TB
    accTitle: תכנון והפעלה של ערכת תווים מתקבלת
    accDescr: מחליטים על ערכת התווים המתקבלת ומציינים אותה גם במפרט וגם באימות קלט; מקבלים תווים בטווח; לתווים מחוץ לטווח, מחליטים על ההפעלה כולל כלל החלפת ייצוג חלופי והניסוח שמסבירים לאדם
    decide["מחליטים על ערכת התווים המתקבלת"] --> spec["מציינים במפרט"]
    decide --> valid["מציינים באימות קלט"]
    valid --> range{"בטווח?"}
    range -->|"כן"| ok["מקבלים"]
    range -->|"לא"| alt["מחליפים בייצוג חלופי"]
    alt -.-> word["הניסוח שמסבירים לאדם הוא גם מפרט"]

איור 11: מציינים את ערכת התווים המתקבלת גם במפרט וגם באימות קלט, ומחליטים גם על ההפעלה מחוץ לטווח.

7. בחירת גופנים והטמעתם — יישור מסך וטופס

7.1. האופי של הגופנים הרגילים

מה שחשוב בבחירה הוא פחות העדפת גופן מאשר האם הגופן הזה קיים בכל סביבה שמעורבת בתצוגה, בהדפסה ובייצור PDF. גופנים יפניים משלימים ב-Windows 10/11 (BIZ UD וכדומה) לפעמים אינם נוכחים לפי התצורה, ובתצורה שמייצרת PDF בצד השרת לנוכחות הגופן או להיעדרו בשרת יש השפעה ישירה.

flowchart TB
    accTitle: הסביבות שיש לאשר בבחירת גופן
    accDescr: בבחירת גופן, מה שחשוב הוא פחות העדפת גופן מאשר האם הגופן הזה קיים בכל סביבה שמעורבת בתצוגה, בהדפסה ובייצור PDF; תצורת גופנים משלימים ונוכחות הגופן או היעדרו בשרת משפיעות ישירות
    cand["גופן מועמד"] --> exist["בכל סביבה?"]
    exist --> scr["סביבת תצוגה"]
    exist --> more{"הדפסה או שרת PDF?"}
    more --> prn["סביבת הדפסה"]
    more --> srv["שרת ייצור PDF"]
    scr -.-> hojo["גופן משלים?"]
    hojo -.-> hojoN["עשוי להיעדר"]
    srv -.-> eikyo["הגופן בשרת חשוב"]

איור 12: בוחרים גופן פחות לפי העדפת גופן מאשר לפי נוכחותו בכל סביבת תצוגה, הדפסה וייצור PDF.

7.2. יסודות תכנון טופס — מיישרים, ומטמיעים

• מציינים את אותו גופן על המסך ועל הטופס. אם הגופנים שונים, אותם נתונים יכולים להיראות כגליף אחר, ומקבלים את התלונה מהפתיחה. תצורה כמו “Meiryo על המסך, MS Mincho על הטופס” צריכה לפחות להיבדק האם יש הבדל גליף ב-168 תווי JIS2004
• מטמיעים את הגופן ב-PDF. אם לא מטמיעים, צד הצפייה מצייר-חלופי בגופן שיש לו בהישג יד, ויכול להשתנות לא רק הגליף אלא גם הפריסה
• האם הטמעה מותרת נקבע לפי הרישיון. גופן OpenType מכריז על הרשאות הטמעה בשדה fsType ‏(Installable / Restricted / Preview & Print / Editable, איסור תת-קבוצה וכדומה), ואסור להטמיע גופן שההטמעה שלו אינה מורשית.¹¹ לגופן מסחרי, אישור החוזה נדרש
• עושים הטמעת תת-קבוצה לבסיס. אם מטמיעים רק את הגליפים של התווים שבשימוש, אין צורך לקחת על עצמכם גופן יפני שלם (כמה MB עד עשרות)
• אם יש דרישת שמירה ארוכת טווח, PDF/A. PDF/A ‏(ISO 19005) הוא תקן שמשלים בתוך הקובץ את המשאבים הנחוצים לתצוגה, והטמעת גופן נדרשת.¹² זו גם הדרך האמינה ביותר למנוע “עשר שנים אחר כך פתחתי והגליפים השתנו”

flowchart TB
    accTitle: זרימת ההחלטה להטמעת גופן
    accDescr: לפני הטמעת גופן ב-PDF, מאשרים את רישיון ההטמעה fsType; אם מורשה, עושים הטמעת תת-קבוצה לבסיס; אם יש דרישת שמירה ארוכת טווח, שוקלים PDF/A שדורש הטמעה
    emb["מטמיעים את הגופן ב-PDF"] --> lic{"ההטמעה מורשית לפי fsType?"}
    lic -->|"מורשה"| sub["הטמעת תת-קבוצה היא הבסיס"]
    lic -->|"לא מורשה"| ng["אסור להטמיע"]
    sub -.-> gly["רק הגליפים של התווים שבשימוש"]
    sub -->|"דרישת שמירה ארוכת טווח"| pdfa["שוקלים PDF/A"]
    pdfa -.-> must["הטמעת גופן נדרשת"]

איור 13: הטמעה מניחה אישור רישיון fsType; הטמעת תת-קבוצה ו-PDF/A הם הבסיס.

איך לבחור אמצעי מימוש להדפסה ולפלט PDF מכוסה לעומק ב”הדפסה ופלט PDF ביישומים עסקיים של Windows”.

8. קישור גופנים ונפילה לאחור — התופעה ש”גופן אחר מתערבב”

תו שלגופן שצוין אין לו גליף אינו מוצג ככלום; ציור-חלופי בגופן אחר הוא התנהגות ברירת המחדל של מחסניות ציור מודרניות. ב-GDI, “קישור גופנים” שמוגדר ברישום (FontLink\SystemLink) עושה זאת; ב-DirectWrite, WPF ודפדפנים, “נפילה לאחור של גופן” עושה.¹⁵

flowchart TB
    accTitle: זרימת קישור גופנים ונפילה לאחור
    accDescr: אם לגופן שצוין יש גליף הוא מוצג כמו שהוא; אם לא, הוא מצויר-חלופי בגופן קישור או נפילה לאחור; אם אין גליף בשום מקום הוא הופך ל-□, אבל הנתונים לעיתים קרובות עדיין חיים
    disp["מציגים תו"] --> has{"לגופן שצוין יש גליף?"}
    has -->|"כן"| draw["מציגים בגופן שצוין"]
    has -->|"לא"| fb{"האם ביעד קישור או נפילה לאחור?"}
    fb -->|"כן"| alt["מציירים-חלופי בגופן אחר"]
    alt -.-> mixed["הסיבה לתחושת גופן מעורב"]
    fb -->|"לא"| tofu["□（tofu）מוצג"]
    tofu -.-> alive["הנתונים לעיתים קרובות עדיין חיים"]

איור 14: □ הוא עקבות של כשל נפילה לאחור; האם ציור-חלופי מצליח הוא הפיצול בין “מעורב” ל”tofu”.

ידיעת המנגנון הזה מאפשרת להסביר את המקרים הנפוצים הבאים.

• תחושת הגופן שונה בין לטינית ליפנית: כי גופן לטיני צוין קודם, רק החלק היפני מצויר בגופן יפני מקושר או נופל-לאחור
• רק הקאנג’י במשפט יפני הופכים לגליף בסגנון סיני: יעד הנפילה לאחור נפתר לגופן סיני. קל לקרות בדף רשת או ביישום שלא מעביר מידע שפה (תכונת lang או לוקאל) נכון
• מופיע tofu ‏(□): לא לגופן שצוין ולא ליעד הנפילה לאחור יש גליף. במילים אחרות □ הוא “עקבות של כשל נפילה לאחור”, והנתונים לעיתים קרובות עדיין חיים

נפילה לאחור היא מנגנון הקלה; היא אינה תחליף לבחירת הגופן הנכון מההתחלה.¹⁵ ביישום עסקי העמדה הבריאה היא “בנתיבי התצוגה וההדפסה העיקריים, משלימים בגופנים שתוכננו לבדם; נפילה לאחור היא ביטוח לתווים לא צפויים”. לחשיבת בחירת גופן בממשק רב-לשוני, ראו גם “לוקליזציה של יישומי WinForms/WPF”.

9. רשימת בדיקה למימוש ביישומים עסקיים

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

נרמול בפרט הוא מלכודת שהיא עצמה נושא המאמר: תהליך שמיושם “בכוונות טובות” שמוחץ את ההבחנה של תווי וריאנט ושל רוחב מלא מול חצי-רוחב. המקור כמו שהוא; עיבוד על עותק הוא העיקרון. תאונות קידוד תווים בחילופי CSV מכוסות לעומק ב”CSV אינו "סתם טקסט"”.

flowchart TB
    accTitle: המקור כמו שהוא; עיבוד על עותק
    accDescr: מאחסנים את המחרוזת שהוזנה כמו שהיא כמקור; מיישמים נרמול על עותק מוגבל לשימוש כמו יצירת מפתח חיפוש; יישום NFKC על המקור מאבד את ההבחנה של תווי וריאנט ושל רוחב מלא מול חצי-רוחב
    input["המחרוזת שהוזנה"] --> orig["מקור: מאחסנים כפי שהוזן"]
    input --> copy["עותק: מנרמלים, מוגבל לשימוש"]
    copy -.-> use["יצירת מפתח חיפוש וכדומה"]
    orig -.-> ng["NFKC על המקור מוחץ הבחנות"]

איור 15: מגבילים נרמול לשימוש ומיישמים אותו על עותק; מאחסנים את המקור כפי שהוזן.

10. סיכום

• מפצלים בעיות תווים קודם ל”שכבת נתונים (קידוד תווים)” ול”שכבת מראה (גופנים)”. � הוא סימן לתאונת שכבת נתונים, □ לתאונת שכבת מראה.
• JIS X 0213:2004 שינה את הגליפים לדוגמה של 168 תווים, ול-Windows יש גליפי JIS2004 כברירת מחדל מ-Vista ואילך. 葛, 辻 ו-飴 שנראים שונים לפי סביבה הם היסטוריה של גופנים, לא השחתת נתונים.
• האמצעי הסטנדרטי לנעול גליף כנתון הוא IVS, אבל בלי גופן תומך ויישום תומך הוא נופל לגליף ברירת המחדל. אל תשכחו את השפעת המימוש שתו אחד יכול להיות עד ארבע יחידות קוד UTF-16.
• גאיג’י (EUDC) הוא נכס ספציפי לאותו מחשב ואינו יכול לנסוע עם הנתונים. התשובה המציאותית היא למנות בזמן מיגרציה, להחליף מטבלת התאמה לתווים רגילים או IVS, ולהפסיק ליצור חדשים.
• מערכת שמטפלת בשמות אנשים מחליטה על ערכת התווים המתקבלת ומציינת אותה. הממשלה מתקננת לכיוון התווים הסטנדרטיים לעניינים מנהליים על יסוד תווי קוסקי מאוחדים ופלטפורמת מידע התווים, ומערכת שמתממשקת צריכה לעקוב אחרי התנועה הזאת.
• לטפסים ול-PDF, “ליישר את הגופן עם המסך, לאשר את הרישיון, ולהטמיע” הוא הבסיס. לשמירה ארוכת טווח, שוקלים PDF/A.
• נרמול NFKC, חיתוך לפי יחידת קוד והמרת CP932 הם שלוש הנקודות ששוברות בשקט תווי וריאנט וגאיג’י. עושים אחסון המקור ועיבוד ביחידות גרפמה לעיקרון.

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

flowchart TB
    accTitle: השאלה הראשונה שמחליטה על נקודת הכניסה לחקירה
    accDescr: כשאומרים לכם שהתו שונה, קודם משווים אם נקודות הקוד זהות או שונות; אם הן זהות מתחילים את החקירה כבעיית גופן, אם הן שונות כבעיית נתונים
    said["אמרו לכם שהתו שונה"] --> cmp{"נקודות הקוד זהות?"}
    cmp -->|"זהות"| fontp["בעיית גופן"]
    cmp -->|"שונות"| datap["בעיית נתונים"]

איור 16: אם נקודות הקוד זהות, מתחילים את החקירה כבעיית גופן; אם הן שונות, כבעיית נתונים.

מאמרים קשורים

• מבוא לקידודי טקסט ב-Windows - ה-mojibake שקורה באינטגרציה עם Linux
• קידודי טקסט וסופי שורה ב-Windows - היסודות של mojibake ו-CRLF/LF
• הדפסה ופלט PDF ביישומים עסקיים של Windows — בחירה בין System.Drawing.Printing, WPF וספריות דוחות
• לוקליזציה של יישומי WinForms/WPF — resx, הרכבות לוויין והחלפת תרבות בפועל
• CSV אינו “סתם טקסט”: מדריך מעשי לטיפול ב-CSV ביישומים עסקיים ב-C# (קידוד, תאימות Excel, הגנה מפני הזרקה)
• מבוא לנגישות יישומי Windows — הכנה לאוטומציית UI ולדרישות התאמות סבירות

תחומי ייעוץ קשורים

KomuraSoft LLC מטפלת בתכנון ובחקירה סביב תווים במערכות עסקיות. מבידוד הסיבה לסימפטומים כמו “התו שונה על המסך ועל הטופס” או “אחרי המיגרציה שם אדם הפך ל-□”, דרך מינוי גאיג’י ובניית טבלת תווי חלופה במיגרציה ממערכת מדור קודם, תכנון ערכת התווים המתקבלת של מערכת שמטפלת בשמות אנשים, וסקירת תצורת הטמעת הגופנים של טפסים ו-PDF, אנחנו מכסים גם את שכבת הקוד וגם את שכבת הגופן.

• פיתוח יישומי Windows
• שימוש חוזר והעברה של נכסים קיימים
• ייעוץ טכני וסקירת תכנון
• צרו קשר

קישורים

מאמרים קשורים

מאמרים עדכניים עם אותן תגיות, להעמקה בנושאים קרובים.

נושאים קשורים

העמודים האלה ממקמים את הנושא בהקשר רחב יותר של שירותים והחלטות.

שירותים הקשורים לנושא הזה

המאמר קשור ישירות לשירותים הבאים.

שאלות נפוצות

שאלות נפוצות בפניות בנושא המאמר.

למה אותו תו 葛 נראה שונה לפי המחשב או הטופס המודפס?

סביר יותר שזה הבדל בגליפים של גופן מאשר mojibake. JIS X 0213:2004 (JIS2004) תיקן את הגליפים לדוגמה של 168 קאנג'י לצורות תקן הדפוס, וגם Windows הפך את גליפי JIS2004 לברירת המחדל ב-MS Gothic / MS Mincho ואחרים מ-Vista ואילך. 葛, 辻, 飴 וכדומה הם דוגמאות מייצגות: נקודת הקוד של Unicode (הנתונים) נשארת זהה, ורק הגליף שהגופן מחזיק (המראה) השתנה. משווים את הנתונים והם תואמים; אי-התאמת צורה בין תמונת טופס מתקופת XP למסך של מחשב חדש היא התנהגות מוגדרת. אם רוצים ליישר גם את הגליפים, משתמשים באותו גופן על המסך ועל הטופס, או מציינים את הגליף עם בורר וריאציה אידיאוגרפי.

אם משתמשים בבוררי וריאציה אידיאוגרפיים (IVS), זה פותר כל בעיית גליף של שמות אנשים?

לא. IVS הוא מנגנון שמניח בורר מ-U+E0100 ואילך מיד אחרי תו בסיס כדי לציין גליף כנתון, והגליף שצוין מוצג רק כשגופן תומך כמו IPAmj Mincho ויישום תומך שניהם נוכחים. בסביבה שאינה תומכת ההתנהגות המוגדרת היא שהבורר מתעלמים ממנו ומוצג גליף ברירת המחדל של תו הבסיס; בחלק מהסביבות הבורר יכול גם להופיע כ-□. נוסף על כך, תו נושא-IVS יכול להיות עד ארבע יחידות קוד ב-UTF-16, וזה משפיע על ספירת תווים, חיתוך ותכנון אורכי עמודות DB. אם מכניסים אותו, מאשרים את היקף התמיכה דרך תצוגה, הדפסה ומערכות במורד הזרם לפני השימוש.

האם תו שנרשם כגאיג'י (EUDC) יכול להיות מוצג על מחשב אחר או ב-PDF?

ככלל, לא. גאיג'י הוא מנגנון שבו משתמש רושם גליף לקובץ eudc.tte של אותו מחשב בנקודת קוד באזור השימוש הפרטי של Unicode (מ-U+E000 ואילך); אותה נקודת קוד אינה מוגדרת או היא גליף אחר על מחשב אחר. גורל ההעברה לדואר, ל-PDF או למערכת אחרת הוא אפוא להפוך ל-□ או להיראות כתו אחר. אם כבר ירשתם נתונים שמכילים גאיג'י, הנתיב המציאותי בזמן מיגרציה הוא למנות שימושים באזור השימוש הפרטי, לבנות טבלת התאמה לתווי Unicode רגילים או לבוררי וריאציה אידיאוגרפיים, ולהחליף. כדאי להימנע מיצירת גאיג'י חדשים במערכת חדשה.

עד כמה מערכת עסקית צריכה לקבל תווים בשמות אנשים?

הדבר הראשון הוא "להחליט על ערכת התווים המתקבלת ולציין אותה כמפרט". במרשמי משפחה יש כ-56,000 תווי קוסקי מאוחדים, ומערכות שתואמות לתקן הממשלתי נעות לכיוון שימוש בתווים הסטנדרטיים לעניינים מנהליים, הרחבה של פלטפורמת מידע התווים — אבל מערכת עסקית כללית אינה מחויבת לקבל את אותה רמה בלי גבול. תכנון מציאותי הוא להחליט על טווח כמו "עד היקף JIS X 0213" או "לא מקבלים בוררי וריאציה אידיאוגרפיים או את אזור השימוש הפרטי", לאמת בקלט, ולהפעיל מקרים מחוץ לטווח עם התראה או ייצוג חלופי. רק מערכות שמתממשקות עם מערכות ממשלתיות או רשויות מקומיות צריכות לעקוב אחרי תנועת התווים הסטנדרטיים לעניינים מנהליים ודרישות המימוש המבוססות על JIS X 0221.

איך גורמים לטופס או ל-PDF להציג את אותם תווים כמו המסך?

הבסיס הוא לציין את אותו גופן על המסך ועל הטופס, ולהטמיע את הגופן ב-PDF. אם הגופנים שונים, אותם נתונים יכולים לשנות גליף; אם למחשב הצפייה אין את הגופן, משתמשים בגופן חלופי לציור והמראה נשבר. האם הטמעה מותרת נקבע לפי רישיון הגופן (OpenType fsType), לכן מאשרים במקום להשאיר לספריית הדוחות. הטמעת תת-קבוצה, שמטמיעה רק את התווים שבשימוש, גם שומרת על גודל הקובץ. אם שמירה ארוכת טווח היא דרישה, שוקלים PDF/A, שדורש הטמעת גופן.

פרופיל הכותב

עמוד היכרות עם כותב המאמר.

Go Komura

מנהל KomuraSoft LLC

מתמחה בפיתוח תוכנה עבור Windows, ייעוץ טכני וחקירת תקלות, בעיקר בפרויקטים עם מערכות קיימות ובאגים שקשה לשחזר.