UTF-32

UTF-32 (32-bit Unicode Transformation Format או 32-bit UCS Transformation Format) הוא קידוד תווים באורך קבוע של יוניקוד, המשתמש ב־4 בתים (32 סיביות) לכל תו. הקידוד שומר את מספרו המייצג של התו בייצוג בינארי באורך 32 סיביות. לדוגמה, התו A מקודד כ־0x00000041 (בהקסדצימלית), התו π כ־0x000003C0 והתו הסיני הנדיר 𣎴 שמספרו ביוניקוד U+233B4 כ־0x000233B4. יתרונו הגדול ביותר של UTF-32 הוא פשטותו, אך היא גם מקור כל חסרונותיו. בשנת 1990, כאשר תוכנן תקן מפת התווים האוניברסלית (באנגלית UCS, ראשי תיבות של Universal Character Set) של ארגון התקינה הבין-לאומי (בר"ת: ISO), תחת מספר התקן ISO 10646, נקבע כי התקן יכיל שתי צורות קידוד: UCS-2 ו־UCS-4. שתי צורות הקידוד פועלות בצורה דומה, קידוד התו מתבצע על ידי שמירת מספרו המייצג כמספר בינארי שגודלו 16 סיביות (2 בתים) ב־UCS-2 או 32 סיביות (4 בתים) ב־UCS-4. מספר התווים שיכול כל קידוד לייצג הוא כמספר המספרים אותם ניתן לייצג בצורה בינארית על ידי מספר הסיביות בהן הוא משתמש. לכן, UCS-4 יכולה לקודד עד 2,147,483,648 תווים, ואילו UCS-2 יכולה לקודד רק את 65,536 התווים הראשונים, המכונים המשטח הרב־לשוני הבסיסי. בשנת 1991 אוחד המשטח הרב־לשוני הבסיסי של ISO 10646 עם 65,536 התווים של תקן אחר למפת תווים אוניברסלית, אז יוניקוד בגרסתו הראשונה. UCS-2, אפוא, היה זהה ליוניקוד. תקן ISO 10646 שמר על קידוד UCS-4 באופן רשמי, אך הכול הניחו כי לא יהיה לו שימוש, משום שלא יהיה צורך ביותר מ־65,536 מקומות. כעבור שנים התבדתה תחזית זו (ראו במאמר על UTF-16) ותקן יוניקוד הורחב מעבר ל־65,536 תווים והכיל כעת למעלה ממיליון תווים. נוצר הצורך להכניס לתקן צורת קידוד של 32 סיביות לכל תו, שתוכל לייצג את התווים הרבים. UCS-4 הפך לחלק מיוניקוד, אך הוגבל לייצוג של מיליון וקצת תווים בלבד (במקום שני מיליארד במקור) כדי שיתאים ל־UTF-16 שאינו מסוגל למען יותר מכך. לציון זאת שונה שמו ל־UTF-32. UTF-32 זהה ל־UCS-4 פרט לעובדה ש־UTF-32 מוגבל באופן שרירותי לייצוג 1,114,112 קודים בלבד, שהם התווים בתחום 0x10FFFF-0x000000, וכן שבניגוד ל־UCS-4, מכיל סטנדרט ה־UTF-32 מספר סמנטיקות של יוניקוד עליהן חובה לשמור. קידוד באמצעות UTF-32 נחשב לקידוד הפשוט ביותר. בניגוד לשאר הקידודים הקיימים, לקידוד זה אורך קבוע, כל תו מיוצג על ידי מספר קבוע של 4 בתים. שיטת הקידוד פשוטה: מספרו הייצוגי של התו מומר לצורה בינארית בגודל 32 סיביות (שהם 4 בתים) וכך הוא נכתב. עם הגדרתו הוגבל UTF-32 ל־21 סיביות, שהם מיליון וקצת תווים, ולכן בעצם ניתן לייצג עמו את כל הערכים בטווח שבין 0x000000 ל־0x10FFFF. תקן היוניקוד קובע שמספרו המייצג של תו לעולם לא יחרוג מערכים אלו ולכן מובטח שבעזרת UTF-32 ניתן לייצג כל תו אפשרי ביוניקוד. שיטת הקידוד פשוטה ביותר, פשוט כותבים את המספר בייצוג בינארי של 4 בתים. אין צורך בביצוע כל פעולה שהיא על הבתים או על המספרים פרט לכתיבת המספר בעת הקידוד וקריאתו בעת הפענוח. UTF-32 אינה חסכונית במקום. מרבית התווים בשימוש נמצאים במשטח הרב־לשוני הבסיסי (ערכיהם ביוניקוד נעים בטווח שבין 0x0000 ל־0xFFFD) וניתן לייצגם באמצעות בית אחד או שני בתים. UTF-32 כופה שימוש של ארבעה בתים לכל תו ולכן מגדיל את תפוסת הזיכרון בסדר גודל של פי שניים עד פי ארבעה. UTF-32 אינה עמידה בפני איבוד בתים במהלך שליחה. אם מסיבות אלו או אחרות אבד בית מסוים (למשל במהלך שליחה ברשת), אזי במהלך הפענוח יחולקו הבתים לרביעיות בצורה שונה והטקסט כולו יוצג בדרך לא נכונה. אין תאימות לאחור עם ASCII. טקסט שנכתב ב־ASCII או באחד מקידוד ISO-8859, אינו קריא באמצעות קידוד זה. היות שקידוד UTF-32 תופס משאבים רבים (פי שניים מ־UTF-16 ברוב המקרים, ופי ארבעה מקידודים ישנים כמו ASCII ו־ISO 8859), אין הוא נמצא כמעט בשימוש. השימוש היחיד הנעשה בו הוא כפורמט פנימי, בתוך הזיכרון, על ידי מערכות הפעלה, משום שהעבודה עמו פשוטה יותר מאשר עם קידודים בעלי אורך משתנה (כמו UTF-8 ו־UTF-16). כפי שצוין קודם, אין צורך בשום פעולה פרט לקריאת הנתונים לשם הבנת טקסט שקודד ב־UTF-32, וזאת בניגוד לקידודים אחרים הדורשים פענוח מורכב יותר. משום שמדובר בטיפול פנימי אין סכנה של איבוד מידע ומשום שהמידע מפוענח מקידוד אחר, אין צורך בתאימות ל-ASCII. השימוש ב־UTF-32 מביא לחסכון בזמן על חשבון בזבוז קל של זיכרון. מערכות יוניקס רבות, כולל הגרסאות החדשות ביותר של לינוקס, משתמשות ב־UTF-32 בשיטה זו. בלינוקס, למשל, קובצי יוניקוד מאוחסנים ב־UTF-8 אך מערכת ההפעלה ממירה אותם ל־UTF-32 בעת הטיפול בהם ברמה הפנימית. מערכת ההפעלה Windows אינה עושה שימוש ב־UTF-32 כלל – לא בשימוש פנימי (Windows משתמשת ב־UTF-16) ולא באחסון קובצי טקסט (אין אפשרות לשמור קובץ טקסט ב־UTF-32).