הבלוג של ארתיום :: icode‏‏Un

תכירו Boost.Locale

אחרי תהיות עמוקות על תמיכה בלוקליזציה ב־C++‎, הבנתי שלא ניתן יהיה ללכת איתה רחוק. לקחתי ICU והתחלתי לעטוף אותו בסביבה ידידותית לתכנות C++‎ מודרני.

אחרי הרבה עבודה הבנתי… כל מה שאני עושה יהיה שימושי הרבה מעבר ל־CppCMS ולכן החלטתי להכין ספריה נפרדת שמטפלת בלוקליזציה במטרה לשלב אותה ב־Boost. כך נולד Boost.Locale שנותנת כלים פשוטים וחזקים לעבודה עם לוקליזציה.

דוגמה פשוטה שתבהיר את החשיבותה ועוצמתה. הנה קטע קוד שמציג למשל את תאריך המאמר באתר:

out << format(translate("{1}, posted  at {2,date} on {2,time} by {3}"))
          % title % date % author;

ועכשיו המתרגם יכול לתרגם את המשפט לצורה הבאה:

"{1}, פורסם ב{2,locale=he_IL@calendar=hebrew,date} ‏(לועזי {2,date}) ב־{2,time} ע"י {3}"

מה קרה כאן? התצוגה באנגלית תהיה

‎Some article was published at 11/8/2009 on 10:30 PM by somebody

כאשר התצוגה בעברית תהיה

מאמר מסוים פורסם בכ"א בחשון התש"ע (לועזי 08/11/2009) ב־22:30 ע"י מישהו

למעשה, בלי שימוש ב־libhdate, בלי לעבוד קשה מידי, קיבלתי אפשרות להציג את התאריך העברי והלועזי לפי הלוקל העברי, רק בגלל ש־ICU תומך בלוח־השנה העברי.

למעשה, עבזרת Boost.Locale ניתן לעשות המון דברים בצורה פשוטה. למשל:

cout << as::spellout << 123 <<endl;

יידפיס בלוקל עברי

מאה עשרים ושלוש

יאפשר לחלק מילה "שָלוֹם" לארבעה תווים בהתחשב בניקוד: "שָ", "ל", "וֹ" ו־"ם" ועוד. למיין טקסט בצורה נכונה ועוד עשרות פעולות חשובות שניתנות ע"י ICU רק בצורה נוחה וטבעית ל־C++‎.

תכירו Boost.Locale:

תיעוד http://cppcms.sourceforge.net/boost_locale/docs/.
תיעוד מפורט של פונקציות ומחלקות: http://cppcms.sourceforge.net/boost_locale/docs/doxy/html/
קוד מקור (דרך svn)‏ https://cppcms.svn.sourceforge.net/svnroot/cppcms/boost_locale/trunk

תהנו, אשמח גם לתגובות.

המשך...

על תמיכה בלוקליזציה ב־C++‎ ועל תקן שבור

ככל שעובד הזמן אנחנו מתקרבים יותר ויותר לתקן C++‎ החדש שבהחלט מעשיר את השפה בהרבה כלים חיוניים – הן מבחינת ליבת השפה והן לבחינת הספריה הסטנדרטית.

אבל נשאר מקום אחד שבו C++0x כמעט ולא נגע, אפילו שהתקן שבור לחלוטין – לוקליזציה…

לצורך הדגמה בואו נכתוב תכנה טרוייואלית שמדפיסה מספר לקובץ טקסט number.txt:

#include <iostream>
#include <fstream>
#include <locale>


int main()
{
        // Set global locale to system default;
        std::locale::global(std::locale(""));

        // open file "number.txt"
        std::ofstream number("number.txt");

        // write a number to file and close it
        number<<13456<<std::endl;
}

תכנה פשוטה אפילו טריוויאלית. עכשיו בואו נעשה אותו דבר ב־C.

#include <stdio.h>
#include <locale.h>

int main()
{
        setlocale(LC_ALL,"");
        FILE *f=fopen("number.txt","w");
        fprintf(f,"%'i\n",13456);
        fclose(f);
        return 0;
}

גם פשוט ביותר.

בואו נריץ את התכנות כאשר הלוקל הוא en_US.UTF-8… ונקבל בקובץ number.txt את המספר: 13,456, עכשיו נעשה אותו דבר, רק נגדיר לוקל נפוץ אחר ru_RU.UTF-8‏: כך LC_ALL=ru_RU.UTF-8 ./a.out ונקבל:

 ‎13<?>456

כאשר אם נריץ תכנה ב־C נקבל דווקא משהו נכון: ‎13 456

אופס… מה קרה כאן? כשאני עושה את אותו הדבר דרך C ודרך C++‎ אני מקבל תוצאה שונה, יותר מזה, הפלט של תכנה שכתובה ב־C++‎ מצביעה על טקסט UTF-8 לא תקין! (אפשר לבדוק בקלות עם iconv).

מה בעצם קראה כאן?

לפי הגדרות הלוקל הרוסי. התו שמפריד בין אלפים ומאות הוא תו U2002 – ‏ EN SPACE – סוג של רווח שונה מרווח ASCII רגיל U0020. כלומר בגלל שמדובר בתו Unicode שהוא לא בתחום ASCII הוא צריך להיות מקודד כמחרוזת ארוכה מבית 1.

אז למה ספריית C מתמודדת יפה מאוד עם בעיה זו וספריית C++‎ לא?

עכשיו בואו נסתכל בהגדרות הסביבה להצגת מספרים: המחלקה ‏std::numpunct‎ מייצגת את סימון ההפרדה thousands_sep‏ כבית בודד! לכן אין שום סיכוי לייצג תו Unicode U2002, לעומת זאת, ספריית C, מייצגת את סימון ההפרדה כמחרוזת ולא כתו בודד. מכאן, אין שום בעיה לייצר מספרים.

זאת הייתה דוגמה של בעיוה הטריוויאלית לשחזור. קיימים עוד בעיות עקרוניות רבות כאלה בתקן לוקליזציה הקיים ב־C++‎ היום. חבל שהוועדה שמטפלת ב־C++0x כלל לא התייחסת לנושא זה — אולי הגיע זמן להעלות את הנושא?

המשך...

ייסורי בינאום ולוקליזציה בשנת 2009

מה יותר פשוט מאשר להציג תאריך ושעה בהתאם למקובל באיזור? בארה"ב תכתוב ‎6/15/2008 8:30 PM ובישראל תכתוב 15/6/2008 20:30. לא מסובך, נכון? כמובן ‎strftime‎ עושה את העבודה הנאמנה בצורה טובה. אכן, יש אופציות ‎"%x"‎ ו־‎"%X"‎ להצגת תאריך ושעה בהתאם ללוקל מקומי.

עכשיו בואו נעשה את הדרך ההפוכה: יש לנו טופס HTML בו אנחנו רוצים להציג תאריך ולתת למשתמש אפשרות לערוך אותו? במילים אחרות אני רוצה אופציה של פענוח תאריך ושעה לפי התבנית המקובלת לאיזור ובשפה הספציפיים… ואכן, יש פונקציה הפוכה ל־strftime ‏— strptime. שעושה את העבודה ההפוכה.

כמובן גם ב־C++‎ יש מקבילות std::facet מסוג: std::time_put ו־std::time_get עושות את העבודה וגם מאפשרות להשתמש ביותר מ־locale אחד בתהליך, שמאפשר, למשל לייצר טקסט שונה למשתמשים שונים בחוטים שונים. ב־C ובשירותי מערכת ההפעלה הסטנדרטיים אין כלי כזה, יש רק strftime_l ו־strptime_l הלא מתועדים ולא מוגדרים לפי סטנדרט שעושים את העבודה.

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

הגדרות סטנדרט C++‎ של std::time_get מכילות באג לוגי שמקשה מאוד על יצירת כלים לפענוח תאריך ושעה בצורה נכונה וגם כשעובדים, הם עושים זאת בצורה חלקית — כי אין מקבילה של strptime המלאה של C.
גם API של C, מסתבר כלא תמיד עובד כמו שצריך.

לצורך ההשוואה, בניתי תכנה פשוטה, שמייצרת מחרוזת עם תאריך ושעה בעזרת כלֵי C,‏ C++‎ וספריית ICU. ולאחר מכן מפענחת אותה אם אותם הכלים. בדקתי את זה עבור מספר לוקלים. בטבלה למטה מוצגים: לוקל, שעה ותאריך כפי שמייוצרים ע"י כלים שונים והפענוח של אותם תאריך ושעה המוצגים בפורמט בינלאומי.

    en_US.UTF-8
    strftime        10/05/2009 11:36:38 PM to 2009-10-05 23:36:38
    std::facet      10/05/2009 11:36:38 PM to 2009-10-05 00:00:00
    icu::DateFormat Oct 5, 2009 11:36:38 PM to 2009-10-05 23:36:38
    he_IL.UTF-8
    strftime        05/10/09 23:36:38 to 2009-10-05 23:36:38
    std::facet      05/10/09 23:36:38 to 1909-10-05 23:36:38
    icu::DateFormat 23:36:38 05/10/2009 to 2009-10-05 23:36:38
    de_DE.UTF-8
    strftime        05.10.2009 23:36:38 to 2009-10-05 23:36:38
    std::facet      05.10.2009 23:36:38 to 2009-10-05 23:36:38
    icu::DateFormat 05.10.2009 23:36:38 to 2009-10-05 23:36:38
    en_GB.UTF-8
    strftime        05/10/09 23:36:38 to 2009-10-05 23:36:38
    std::facet      05/10/09 23:36:38 to 1909-10-05 23:36:38
    icu::DateFormat 5 Oct 2009 23:36:38 to 2009-10-05 23:36:38
    ja_JP.UTF-8
    strftime        2009年10月05日 23時36分38秒 to 2009-10-05 23:36:38
    std::facet      2009年10月05日 23時36分38秒 to 2009-10-05 23:36:38
    icu::DateFormat 2009/10/05 23:36:38 to 2009-10-05 23:36:38
    ar_EG.UTF-8
    strftime        05 أكت, 2009 IST 11:36:38  to 2009-10-05 00:00:00
    std::facet      05 أكت, 2009 IST 11:36:38  to 2009-10-05 11:36:38
    icu::DateFormat ٠٥/١٠/٢٠٠٩ ١١:٣٦:٣٨ م to 2009-10-05 23:36:38
    tr_TR.UTF-8
    strftime        05-10-2009 23:36:38 to 2009-10-05 23:36:38
    std::facet      05-10-2009 23:36:38 to 2009-10-05 23:36:38
    icu::DateFormat 05.Eki.2009 23:36:38 to 2009-10-05 23:36:38
    ru_RU.UTF-8
    strftime        05.10.2009 23:36:38 to 2009-10-05 23:36:38
    std::facet      05.10.2009 23:36:38 to 2009-10-05 23:36:38
    icu::DateFormat 05.10.2009 23:36:38 to 2009-10-05 23:36:38
    zh_CN.UTF-8
    strftime        2009年10月05日 23时36分38秒 to 2009-10-05 23:36:38
    std::facet      2009年10月05日 23时36分38秒 to 2009-10-05 23:36:38
    icu::DateFormat 2009-10-5 下午11:36:38 to 2009-10-05 23:36:38

כפי שניתן לראות:

std::facet לא מתמודד עם שעון של 12 שעות המכיל ציון AM/PM.‏
std::facet לא מוסוגל לשחזר שנה בעזרת שתי ספרות בלבד וזורק אותנו משנת 2009 ל־1909 ב־2 מתוך 9 דוגמאות.
strptime לא מצליח לשחזר שעה בכלל ו־std::facet וטועה ב־12 שעות בלוקל מצרי.יש לציין שזה באג בייצוג locale כי הפורמט המוגדר הוא ‎"%Z %I:%M:%S"‎ במקום ‎"%p %I:%M:%S"‎ — להציג איזור זמן במקום סימון AM/PM המתאים (م).

במילים אחרות… מימוש של std::facet גרוע, יש בעיות בייצוג locale באופן כללי.

עצוב שזה המצב בשנת 2009…

המשך...

לרגל שחרורו של gcc-4.4... חידושים ושיפורים.

לפני כחודש שוחררה גרסה חדשה של gcc:‏ 4.4. אחד הדברים המעניינים זה התקדמות בתמיכה בתקן C++‎ החדש C++0x. הנה כמה תכונות מאוד מעניינות שכבר מזמן חיכיתי להן:

סוף־סוף, הגיע אחת התכונות הנחשקות ביותר — תמיכה ב־auto, שחוסכת המון הקלדה מיותר ומקלה בצורה משמעותית על כתיבת קוד בלתי תלוי בקונטיינרים. לדוגמה, היום כך כותבים לולאה שמדפיסה איברי הרשימה:
```
for(list<int>::contst_iterator p=numbers.begin();p!=numbers.end();++p)
{
    cout<< *p <<endl;
}
```
ואם רוצים לשנות את סוג הקונטיינר מ־list ל־vector צריך לשנות את list ל־vector בלולאה. עם טיפוס auto זה מתקצר בצורה משמעותית:
```
for(auto p=numbers.begin();p!=numbers.end();++p)
{
    cout<< *p <<endl;
}
```
ובנוסף ל"קיצור" הכתיבה, אין שום אזכור של סוג הקונטיינר בלולאת for.
טיפוסי תווים חדשים. בסטנדרט הנוכחי יש בעיה משמעותית בהגדרת תווי unicode, או ליתר דיוק העדר הגדרה ראויה שלהם. כך wchar_t למעשה יכול להיות בגודל של 32 ביטים, 16 ביטים ואפילו 8 ביטים. למעשה, בסביבת Windows, ‏wchar_t הוא בגודל של שני בתים ומייצג utf-16 (או ucs-2), כאשר בכל סביבות ה־UNIX, ‏wchar_t מייצג נקודת קידוד בודדת והוא בגודל של 32 ביט. זה יוצר לא מעט בעיות בטיפול במחרוזות unicode. כי הקידוד של std::wstring לא ברור.

התקן החדש הגדיר שני טיפוסי תווים חדשים: char16_t ו־char32_t שמונעים את האי בהירות בנושא. כך שהעבודה עם std::u16string ו־std::u32string הופכת להרבה יותר שקופה. כך, בנוסף הוגדר ייצוג חדש למחרוזות:
```
std::string normal="שלום"; // encoded as 8 bit
std::wstring wide=L"שלום"; // utf16 or utf32 depending on your OS
std::u16string utf16=u"שלום"; // utf16 encoded
std::u32string utf32=U"שלום"; // utf32 encoded
```
כמובן, לא צריך לשכוח את התמיכה ב־Variadic templates שהתווספה ב־gcc-4.3, המאפשרת לבנות פונקציות typesafe עם מספר משתנה של פרמטרים בצורה בטוחה, קצרה ומהירה. התמיכה בהן מקצרת בצורה בסדר גודל את זמן הקומפילציה של תבניות כמו std::function או std::bind.

מבחינתי, יש עוד מספר תכונות שאני מחכה להן:

תמיכה בביטויי למבדא.
תמיכה ב־delegating and inheriting constructors שמקצרת בצורה משמעותית את הכתיבה של overloaded constructors.
תמיכה ב־Concepts שייאפשר לספק פלט שגיאות הרבה יותר ידידותי.
תמיכה מלאה ב־STL החדש, כולל regular expressions.

אני מקווה שזה לא ייקח הרבה זמן…

המשך...

האם אתה מוכן לבינאום ולוקליזציה?

הכנתי שאלון קצת שמאפשר לכם לבדוק… האם אתם מוכנים לכתיבת תכנה שתהיה מוכנה להתאמה לתרבויות שונות?

אני רוצה לייצג מחרוזת, כ־char *some_text. מהו המידע שחסר לי?
יש לי מחרוזת wchar_t *text או String text ב־Java, אני רוצה לקחת את התו הראשון שלה:
```
 wchar_t c=text[0]; // C
 Char c=text.charAt(0); // Java
```
האם זהו קוד נכון?

אני כותב את הקוד הבא:

 if n==1:
     print translate("You have one aplle")
 else:
     print translate("You have %d apples") % n

מה לא בסדר בקוד הזה?

מה לא בסדר בקוד הבא:

 #include <stdio.h>
 #include <time.h>

int main()
{
        time_t now_t=time(NULL);
        struct tm *now=localtime(&now_t);
        char str_time[32];
        strftime(str_time,sizeof(str_time),"%d/%m/%y",now);
        printf("Today is %s\n",str_time);
        return 0;
}

מהו גודל הזכרון הנדרש לשמירת תו unicode בודד?
מהו גודל של wchar_t? (למתכנתי C++/C)‏?
מהי גודל של תו unicode בשפת התכנות שאתה אוהב?
מהו קידוד של מחרוזת (unicode) בשפת התכנות/toolkit שאתה אוהב?
מה הבדל בין utf-8,‏ utf-16, ‏utf-32?‏
מהו אורך התו הארוך ביותר ב־utf8?‏

בניתי ספרייה עם שתי פונקציות בלבד. מה לא בסדר בקוד הבא (שתי בעיות לפחות)?

extern Char32 to_upper_char(Char32);
void to_upper(String str)
{
        for(int i=0;i<str.size();i++)
                str[i]=to_upper(str[i]);
}

מה לא בסדר בקוד הבא:

def print_error_message(message):
    print translate("Error occured: ")+"“"+translate(message)+"”"

מה לא בסדר בקוד הזה:

<?php $rtl_langs=array("he","ar","pa"); ?>
...
<div <?php if(in_array($lang,$rtl_langs) echo 'dir="rtl"'; ?> >
...
</div>

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

// Cut nice pice of text
wstring cut_nicely(wstring const &orig,int n)
{
   if(orig.size()<=n) return orig;
   return orig.substr(orig.find_first_of(L" \r\n\t\f",n));
}

המשך...

Unicode ב־C++‎ תיקון טעות.

עדכון קטן על תמיכה ב־Unicode ב־C++‎. למעשה, כשאמרתי בכתבה קודמת שאין כל תמיכה ב־Unicode, טעיתי. דווקא יש תמיכה אם כי היא לא מתקרבת למה ש־ICU נותן.

std::locale נותן מספר ממשקים בפרט: std::ctype<>‎ שמאפשר המרה של case והמרת קידוד בין קידוד מקומי כמו utf-8 או cp1255 למחרוזות של wchar_t. הוא מצליח להמודד עם מקרים יחסית פשוטים כמו המרת "Артём" (השם הפרטי שלי ברוסית) לאותיות גדולות וקטנות בצורה נכונה: АРТЁМ. דבר שכל הכלים, אפילו פחות מוצלחים כמו Python ו־qt3 מצליחים לבצע ללא בעיה.

אבל תמיכה מובנית עדיין לא מצליחה להתמודד עם מקרים מסובכים יותר כמו ß הגרמנית ו־Σ היוונית.

כך שלצרכים הבסיסיים, ניתן להסתפק ב־API של C++‎ כפישהו, אבל כמובן זאת לא תמיכה מלאה (כמו גם בשפות אחרות, משל Python).

לדוגמה toupper‏:

// Set global locale
locale::global(locale("en_US.UTF-8"));

// Now we can use locale for various purposes
wchar_t str[]=L"Артём";
use_facet<ctype<wchar_t> >(locale()).toupper(str,str+5);

המשך...

ייסורי Unicode ב־2009, או תמיכה ב־unicode בסביבות שונות.

אחד הדברים החסרים ביותר ב־C++‎, מבחינתי, זה העדר תמיכה טובה ב־Unicode. למרות ש־std::wstring ו־std::locale קיימים הם לא נותנים מענה על כל דרישות העבודה עם Unicode.

יש שפות תכנות כמו Python ו־Java בהן התמיכה הזו נחשבת ל"טבעית". אז החלטתי לעשות בדיקה ולבדוק מספר דברים חיוניים בעיבוד טקסט טבעי: החלפה בין אותיות גדולות וקטנות וכן מציאת גבולות המילים. דברים שנראים טריוויאליים עבור אנגלית למעשה הופכים לכלל לא טריויאליים כאשר מדובר בשפות אחרות:

שינוי אות קטנה לגדולה: ß גרמנית צריכה להפוך ל־SS (שתי אותיות).
שינוי אות גדולה לקטנה: Σ היוונית הופכת ל־σ במרכז המילה ול־ς בסופה.
הפרדת מילים לצורך חיתוך הטקסט: 中文 אלה שתי מילים ולא מילה אחת.

בדקתי 6 כלים: ספריית ICU עם API במספר שפות, ספריית glib יחד עם pango עבור C, ספריות Qt3 ו־Qt4 עבור C++‎, וגם כלים טבעיים של Java, ‏C++‎ ושל Python.

אקדים ואומר, המקרים הפשוטים כמו המרת: "Артём" (השם הפרטי שלי ברוסית) ל"АРТЁМ" עבדו בכל הכלים ושפות, אבל במקרים יותר מורכבים התוצאות היו כלל לא מעודדות:

כלי	לאותיות גדולות	לאותיות קטנות	גבולות המילים
C++‎	נכשל	נכשל	אין תמיכה
C++/ICU‎	הצליח	הצליח	הצליח
C++/Qt4‎	הצליח	נכשל	הצליח
C++/Qt3‎	נכשל	נכשל	אין תמיכה
C/glib+pango	הצליח	הצליח	נכשל
Java/JDK	הצליח	הצליח	נכשל
Java/ICU4j	הצליח	הצליח	הצליח
Python	נכשל	נכשל	אין תמיכה
Python/PyICU‎	הצליח	הצליח	הצליח

עכשיו פרטים

המשך...

מתיאוריה למציאות, או עד כמה UTF-16 באמת בעייתי

בהמשך לפוסט הקודם, החלטתי לעשות סקירה קצרה: "האם באמת תכנות שכתובות עם utf-16 לא עובדות כמו שצריך עם קידודים כפולים ומה קורה עם תכנות שמשתמשות בייצוג פנימי ב־utf-8/utf-32?"

לקחתי תו "𠂊" או U+2008A וניסיתי להציג אותו ביישומים שונים מבוססים על toolkitים שונים. התו הזה מתייחס ל־CJK Unified Ideographs Extension B‏ ולא לא יכול להיות מיוצג ב־utf-16 בעזרת איבר אחד (שני בתים) אלא דורש צירוף של שני איברים (ארבעה בתים). אם אתם לא רואים את התו הזה, או רואים אותו כריבוע בדפדפן שלכם, אפשר להתקין גופן חופשי: AR PL ShanHeiSun Uni, בעלי דביאן יכולים להתקין חבילה ttf-arphic-uming.‏ חייב לציין, אין מי מושג מה התו או המילה האלה אומרים, כך שמתנצל מראש.

קודם כל: היישומים שעובדים עם utf-16 שהתמודדו אתו בצורה יפה ונכונה (או פשוט לא מצאתי באגים ב־2 דקות ששיחקתי איתם) הם:

OpenOffice שעובד עם icu (אם כי, אני לא בטוח שהוא משתמש בו בייצוג פנימי)
Microsoft Word עבד ללא בעיות ועובד עם Windows API המבוסס על utf16‏.
FreeMind שכתוב ב־Java הצליח להציג את התו ולערוך טקסט בצורה מסודרת. (Java משתמשת ב־utf-16 במחרוזות שלה).

אבל פה פחות או יותר נגמרו היישומים שעובדים עם utf-16 וגם מסתדרים עם התו הבעייתי. נתחיל:

המשך...

UTF-8, UTF-16, Unicode וכל מה שביניהם.

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

האנשים האלה חשבו וחישבו ששני בתים יספיקו לכסות את כל השפות אפשריות. כך נולד קידוד של Unicode בשני בתים. בתחילת ה־90, יצרתי UNIX הגדולים גם חשבו ובנו UTF-8 שכדי להבטיח תאימות לאחור עם כל התכנה הקיימת — כך נולד קידוד בעל אורך משתנה.

עבר הזמן, יצרני תכנה שונים הולכו בשני כיוונים: אחד להציג כל תו בשני בתים והשני להמשיך להשתמש ב־ANSI C String ולעבוד עם תווים בעלי ייצוג באורך שונה. אבל, באמצע שנות ה־90 כבר היה ברור ששני בתים לא יספיקו כדי לכסות את כל השפות האפשריות. ולכן התקן הורחב כך שהוא כלל ערכים מ־0 ועד ל־0x10FFFF.

המשך...