tomron87/hebrew-wikipedia-sentences-corpus huggingface dataset:
מהירות ההעברה גורמת לגרסה זו של הממשק להיות איטית מדי עבור יישומים מסוימים הדורשים מהירות העברה גבוהה.
גודל כרטיסי זיכרון בהתקן זה, מוגבל עד 2 ג'יגה-בייט.
גרסה זו יצאה לשוק באפריל 2000 והביאה שיפור משמעותי יחסית לגרסה USB 1.1 הישנה יותר.
שינוי זה התבטא בעיקר במהירות העברת נתונים של עד 480 מגהביט לשנייה (פי 40 מהגרסה הקודמת).
בנוסף לכך, גרסה זו תומכת לאחור בכל ההתקנים העובדים בממשק USB 1.1 ומשתמשת באותם מחברים, מתאמים וכבלים.
תקן USB 2.0 אף מתחרה בתקן FireWire הנפוץ במחשבי מקינטוש שמגיע לקצב של עד 800 מגהביט, אם כי חלק מהמחשבים הנמכרים כיום תומכים בשני התקנים.
כאשר יצא תקן USB 3.2, תקן USB 3.1 דור 2 קיבל גם את השם USB 3.2 Gen 2x1 (המציין שזהו דור 2 ובשימוש של אפיק מידע יחיד).
USB 3.2 Gen 2x2 עשה שימוש בקצב ההעברה של USB 3.1 דור 2 (10 ג'יגהביט לשנייה), אך בגלל השימוש באפיק מידע כפול, קצב ההעברה הכולל היה 20 ג'יגהביט לשנייה ולכן הוא ידוע יותר בשם (USB 3.2 SuperSpeed+ (20 Gbps.
USB A - יציאת ה-USB הנפוצה ביותר (מלבנית).
USB B - צורה מעט פחות נפוצה של אותו התקן (ריבוע ששתיים מפינותיו מעוגלות).
Mini USB - גרסה קטנה יותר של חיבורי A ו-B, נפוצה במכשירים קטנים יותר.
Micro USB - הגרסה הקטנה ביותר של חיבורי A ו-B, הוכרזה בשנת 2009 כתקן הבינלאומי לטעינת מכשירים סלולרים החל בשנת 2012. יצאה גרסה מיוחדת ל-Micro-B שבעצם הכפילה את כמות המחברים והיא שימשה כמחבר SuperSpeed לתקן USB 3.x לפני שיצא המחבר החדש, Type-C.
בסוף 2013 הכריזה קבוצת USB 3.0 Promoter על פיתוח מחבר ה-USB הבא.
המחבר החדש, Type-C, מתבסס על הטכנולוגיות של USB 3.1 ושל USB 2.0 ונועד לענות על הדרישה למחבר מתקדם יותר מבחינת גודל, שימושיות ומהירות.
עיצוב חדש לגמרי עם התאמה לטלפונים וטאבלטים
גודל קטן יותר מהמחברים שהיו קיימים לפניו
המחבר יכול להתחבר בכל כיוון, בניגוד למצב במחברים שלפניו בהם ניתן היה לחבר רק בכיוון אחד
תאימות לתקן טעינה 1.2 ותקן Power Delivery 2.0.
המחבר נבנה עם אפשרות להתממשקות מול מתאמים מיוחדים וזאת על מנת לשמור על תאימות למחברי ה-USB הקודמים.
ב-2014 הכריזה חברת אינטל כי היא תציג טלפונים וטאבלטים חדשים עם תאימות למחבר החדש ובהמשך גם מחשבים נייחים וכל מוצר אחר אשר עושה שימוש ב-USB יכיל את המחבר החדש.
המפרט הסופי של מחבר ה-Type-C נקבע ב-2014 והחל להיות מופץ ב-2015.
USB OTG הוא התקן ל-USB 2.0 המאפשר להתקנים שונים שבדרך כלל פועלים כ"Slave" (כשמחוברים למחשב) לפעול כ"Master" אל מול התקן "Slave" אחר.
באמצעות תקן USB OTG ניתן לדוגמה לחבר מקלדת רגילה או החסן נייד (דיסק און קי) למחשב כף יד או לטלפון חכם.
התקן המשחרר לחלוטין את הצורך בכבלים מסוג כלשהו על ידי יציאה משולבת מתאם המקיים קשר רדיו אלחוטי.
בנוסף על סוגי החיבורים הפיזיים, קיים שוני בצבע החיבור, המצביע על קצבי העברת נתונים, והקצאות חשמל שונות.
שלא כמו RS-232 וממשקים טוריים דומים שבהם פורמט הנתונים הנשלחים אינו מוגדר, USB מורכב מכמה שכבות של פרוטוקולים.
כל עסקת USB מורכבת מ:
חבילת אסימון - Token Packet (כותרת המגדירה את מה שהיא מצפה לעקוב אחריה)
חבילת נתונים אופציונלית - Optional Data Packet (המכילה את המטען)
חבילת סטטוס - Status Packet (משמשת לאשר עסקאות ולספק אמצעי לתיקון שגיאות)
USB הוא אפיק ממוקד מארח.
המארח יוזם את כל העסקאות.
החבילה הראשונה, הנקראת גם אסימון, נוצרת על ידי המארח כדי לתאר מה יש לעקוב והאם עסקת הנתונים תהיה קריאה או כתיבה ומהי כתובת המכשיר ונקודת הקצה המיועדת.
החבילה הבאה היא בדרך כלל חבילת נתונים הנושאת את המטען ואחריה חבילת לחיצת יד, המדווחת אם הנתונים או האסימון התקבלו בהצלחה, או אם נקודת הקצה נתקעה או לא זמינה לקבל נתונים.
נתונים על ה-USBus מועברים תחילה LSBit.
מנות USB מורכבות מהשדות הבאים,
כל החבילות חייבות להתחיל בשדה סנכרון.
שדה הסנכרון הוא באורך 8 סיביות במהירות נמוכה ומלאה או באורך 32 סיביות עבור מהירות גבוהה ומשמש לסנכרון השעון של המקלט עם זה של המשדר.
שתי הסיביות האחרונות מציינות היכן מתחילים שדות ה-PID.
שדה זה משמש לזיהוי סוג החבילה הנשלחת.
הטבלה הבאה מציגה את הערכים האפשריים.
ישנם 4 סיביות ל-PID, אולם כדי להבטיח שהוא מתקבל כהלכה, 4 הסיביות מושלמות וחוזרות על עצמן, מה שהופך PID של 8 סיביות בסך הכל.
שדה הכתובת מציין לאיזה מכשיר מיועדת החבילה.
אורך 7 ביטים מאפשר תמיכה ב-127 מכשירים.
כתובת 0 אינה חוקית, שכן כל מכשיר שעדיין לא הוקצתה לו כתובת חייב להגיב למנות שנשלחות לכתובת אפס.
שדה נקודת הקצה מורכב מ-4 ביטים, המאפשרים 16 נקודות קצה אפשריות.
עם זאת, להתקנים במהירות נמוכה יכולים להיות רק 2 נקודות קצה נוספות על גבי צינור ברירת המחדל.
בדיקות יתירות מחזוריות מבוצעות על הנתונים בתוך מטען החבילות.
לכל מנות האסימון יש CRC של 5 סיביות בעוד לחבילות הנתונים יש CRC של 16 סיביות.
מאותת על ידי אפס בודד (SE0) למשך כ-2 פעמים סיביות ואחריו J למשך זמן של סיביות אחת.
ל-USB יש ארבעה סוגי חבילות שונים.
חבילות אסימונים מציינות את סוג העסקה שיש לעקוב אחריה, מנות נתונים מכילות את המטען, מנות לחיצת יד משמשות לאישור נתונים או דיווח על שגיאות ומנות התחלה של מסגרת מציינות את תחילתה של מסגרת חדשה.
USA Today הוא עיתון יומי אמריקאי הראשון בתפוצתו בארצות הברית עם 1,621,091 עותקים נכון ל-2019. העיתון נוסד ב-15 בספטמבר 1982 על ידי אלן ניוהארט, ומוצא לאור בחברת גנט.
העיתון מופץ ב-50 מדינות בארצות הברית.
בעיתון ארבעה מדורים עיקריים, ולכל מדור צבע מאפיין:
כלכלה (Money) – צבע ירוק
בידור (Life) – צבע סגול
העיתון נוסד ב-1982, במטרה ליצור עיתון שיופץ בהפצה ארצית, בניגוד לרוב העיתונים בארצות הברית שהם מקומיים.
פורמט העיתון שונה אף הוא – העיתון צבעוני, גדוש בתרשימים ותמונות.
פורמט זה שונה לחלוטין מהפורמטים של שאר העיתונים הגדולים בארצות הברית, שרובם כתובים בשחור-לבן כמו הניו יורק טיימס והוול סטריט ג'ורנל.
העיתון היה בין העיתונים הראשונים שהשתמשו בלוויינים בתהליך ההפצה שלו.
הגרסאות הסופיות של העיתון נשלחות לבתי דפוס אזוריים ברחבי ארצות הברית.
חידוש זה גרם לדחיית שעת סגירת הגיליון שלו והפיכתו למעודכן יותר ביחס לשאר העיתונים.
עם תפוצה שבועית של 726,206 עותקים, בסיס מנויים דיגיטליים של 504,000 מנויים, ומספר קוראים יומי ממוצע של 2.6 מיליון, היו אס איי טודיי נחשב לעיתון הנקרא ביותר בארצות הברית.
הקהל של העיתון הוא בדרך כלל בעל דעות מרכז.
העיתון מופץ בכל 50 מדינות ארצות הברית כולל פוארטו ריקו.
הגרסה הבין-לאומית מופצת גם באסיה, קנדה, אירופה, והאיים הפסיפיים.
ב-2001 עברה מערכת העיתון למקלין שבווירג'יניה, לבניין המכסה שטח של 120,000 מטר רבוע.
במרץ 2004 נאלצו עורכי העיתון להתמודד עם סקנדל – ג'ק קליי, כתב העיתון וזוכה פרס פוליצר, הואשם שזייף סיפורים אשר פורסמו בעיתון.
עורכי ה-USA Today ערכו בדיקות קפדניות לכל כתבותיו של קליי, ולאחר שנתגלה שחלקן זויפו עזב קליי את מערכת העיתון.
העיתון פרסם התנצלות רשמית בעמוד הראשון, יום לאחר סיום הפרשה, פרשה שדמתה לפרשת ההעתקות של ג'ייסון בלייר בניו יורק טיימס, אך לוותה בפחות רעש תקשורתי.
העיתון אינו מופץ בימים ראשון ושבת, והמוטו שלו הוא "עיתון האומה – מספר 1 בארצות הברית" (The Nation's Newspaper – #1 in the USA).
מדור הדעה של היו אס איי טודיי מכיל מאמרי מערכת, טורים שנכתבים על ידי כותבים אורחים, וחברים בוועד התורמים למאמרי המערכת, מכתבים למערכת וקומיקס קצר.
מאפיין מיוחד של מאמר הדעה של העיתון הוא פרסום דעות מנוגדות.
נוסף על מאמר המערכת, מופיע גם מאמר שנכתב על ידי כתב אורח המנוגד למאמר המערכת, בדרך כלל מומחה בתחומו.
מאז הבחירות לנשיאות ארצות הברית 1984, היו אס איי טודיי באופן מסורתי שמר על מדיניות של לא לתמוך באף מועמד לנשיאות ארצות הברית או כל פקיד ממשלתי ופדרלי אחר.
URL (ראשי תיבות באנגלית: Uniform Resource Locator; בעברית: מַעַן מַשְׁאַבִּים אָחִיד), הוא רצף של תווים במבנה אחיד המשמש לייצוג המיקום של דפי אינטרנט וקבצים ברשת האינטרנט.
באופן עממי ה־URL מכונה כתובת האתר, כתובת רשת או כתובת הדף.
למעשה, URL הוא מקרה פרטי של URI, שהוא המונח הנכון, הכולל את כל הכתובות בהן נעשה שימוש, אך בשל סיבות היסטוריות, המונח URL נמצא בשימוש נרחב.
כתובת URL בנויה באופן כללי בצורה:
scheme – מציינת את אופן השימוש בכתובת: הפרוטוקול בו יעשה שימוש (למשל HTTP או HTTPS) ובכפוף אליו גם אילו פרמטרים נוספים יש להעביר.
authority – ה"רשות" אליה שייך המשאב, כלומר כתובת ה־IP של השרת עליו הוא נמצא, או כתובת מילולית שתתורגם לכתובת כזו על ידי מנגנון ה־Domain Name System, בנוסף ניתן להוסיף נקודתיים ואת פורט (port) ה־TCP בשרת.
path – ה"נתיב" בו נמצא המשאב במערכת הקבצים של השרת – אם ישנן תיקיות משנה ועד שם העמוד.
אם הנתיב ריק, סימן ששם העמוד הוא גנרי כגון index.html, default.asp וכו'.
query – שאילתה (בשיטת GET; בשיטת POST הנתונים לא עוברים ב־URL) שנועדה להעביר לאותו המשאב פרמטרים נוספים בצורת parameter=value, להפרדה בין מספר פרמטרים משמש הסימן "&".
רוב כתובות ה־URL בהן נעשה שימוש באינטרנט מיועדות לשימוש על ידי פרוטוקול HTTP ובנויות בצורה –
כאשר החלקים שבסוגריים מרובעים הם אופציונליים.
זהו ה-URL של ערך זה, ה-schema היא https, ה-server הוא שרת ויקיפדיה העברית – he.wikipedia.org, וה-path הוא הנתיב של מסמך זה בשרת – wiki/URL
זוהי למעשה הכתובת לאותו משאב (דף), בתוספת הזדהות כ־anonymous, וציון פתחת (port) ברירת המחדל – 443.
זהו ה־URL של דף העריכה של ערך זה, ה־path השתנה ל־w/index.php שהוא הדף המאפשר עריכה של עמודים בוויקיפדיה, וכמו כן נוספה שאילתה – query בת שני פרמטרים, כותרת הערך אותו יש לערוך – title=URL, וכן הפעולה אותה יש לבצע – action=submit.
במקרה זה, מדובר בביטוי המזהה נתיב למקור מידע (Resource) באופן חד חד ערכי.
ה-URI מהווה בפועל הרחבה של URL, כך שניתן לזהות כל מקור מידע בעזרתו ולא רק דפי אינטרנט.
USA 193 (ידוע גם בשמות NRO שיגור 21, NROL-21, או L-21) היה לוויין ריגול צבאי אמריקני.
הלוויין היה בבעלות ה-National Reconnaissance Office, שהיא אחת מסוכנויות הביון של ממשלת ארצות הברית.
אופן פעולתו ותפקידו של הלוויין הם בגדר סוד מדינה בארצות הברית.
שיגורו של הלוויין USA 193 היה השיגור הראשון שבוצע עבור ממשלת ארצות הברית בחוזה עם United Launch Alliance – ULA שהיא חברה העוסקת בשיגורים לחלל.
הלוויין הושמד בהצלחה על ידי טיל של מערכת SM-3, שנורה מספינת מלחמה אמריקנית ממערב להוואי ב-21 בפברואר 2008.
אתר השיגור: בסיס חיל האוויר ונדנברג, בקליפורניה.
נתוני מסלול בחלל: אף שלא התפרסמו נתונים רשמיים, על פי תצפיות חובבים המסלול היה 349 ק"מ × 365 ק"מ × 58.48°.
ניתן ללמוד מנתונים אלה כי מסלולו של הלוויין הלך ודעך לקראת חדירה לאטמוספירה
אף ששיגור הלוויין וכניסתו למסלול היו מוצלחים, הלוויין איבד קשר עם תחנת הבקרה שעות לאחר השיגור.
דיווחים בלתי רשמיים ראשונים, ממקורות בממשל האמריקני, על לוויין ריגול אשר מסלולו הולך ודועך לקראת כניסה לאטמוספירה בתוך שבועות ספורים, התפרסמו בסוף חודש ינואר 2008. דיווח זה לא הפתיע חובבי חלל העוסקים בתצפיות על לוויינים סביב כדור הארץ, אשר עקבו אחר הלוויין.
על פי דיווחי הסוכנות האמריקנית לניהול מצבי חירום הלוויין הכיל שני חומרים מסוכנים: הידרזין ובריליום.
על פי השערות שונות הלוויין הכיל אף מקור כוח גרעיני, זאת בניגוד לדיווחים רשמיים של ארצות הברית.
ב-29 בינואר 2008 פרסמה סוכנות הידיעות Associated Press כי גנרל בחיל האוויר האמריקני אמר כי נעשות תוכניות למניעת התרסקותו של הלוויין באטמוספירה עקב חשש שיפול באזור צפון אמריקה.
גיבוש תוכנית להשמדת הלוויין USA 193 בעזרת שיגור טיל לעברו החל בחודש ינואר 2008, ב-12 בפברואר 2008 נתן הנשיא בוש את אישורו לתוכנית.
גורמים רשמיים אמריקנים הכחישו כי פעולת השמדת הטיל נועדה למנוע נפילת טכנולוגיה סודית לידי ידיים זרות וכן הכחישו כי השיגור בא בתגובה לניסוי שערכה ממשלת סין בשנת 2007 בטיל נגד לוויינים.
המטרה המוצהרת העיקרית בהשמדת הלוויין הייתה לנקב את מכל הדלק של הלוויין ולרוקן כ-450 ק"ג של הידרזין בטרם יכנס לאטמוספירה.
על פי דיווח הפנטגון ב-21 בפברואר 2008, במבצע קרח שרוף, שוגר טיל מדגם SM-3 מסיירת טילים אמריקנית, אשר פגע בלוויין בגובה של כ-247 ק"מ מעל האוקיינוס השקט, במהירות של כ-36,667 קמ"ש.
USA Network הוא ערוץ טלוויזיה בכבלים המשודר בארצות הברית.
הערוץ החל לשדר בשנת 1977 ונקרא תחילה ערוץ המדיסון סקוור גארדן.
ב־1980 שינה את שמו ל־USA Network.
הערוץ נמצא בבעלות תאגיד NBC, ומשדר מגוון של תוכנית טלוויזיה מקוריות, סדרות בשידורים חוזרים המשודרות בסינדיקציה, סרטי קולנוע ומשדרי ספורט (בעיקר טורנירים של גולף וטניס).
נכון לשנת 2005 כ־89 מיליון משקי בית היו מנויים לערוץ.
החל מאוקטובר 2007 שודר הערוץ גם בגרסת HDTV.
ב־2008 זכה הערוץ לאחוזי הצפייה הגבוהים ביותר בשעות השיא מבין כל ערוצי הכבלים בארצות הברית.
ליגת ה-USBL (ראשי תיבות: United States Basketball League) היא ליגת כדורסל גברים אמריקאית המשוחקת באביב.
הליגה הוקמה בשנת 1985. הליגה הושבתה בשנת 2007, והאלופה האחרונה מליגה זו היא הקנזס קייג'רז שזכו בתואר ב-1 ביולי 2007. המוטו של הליגה הזו הוא: "ליגה של הזדמנות".
במשך השנים שיחקו רבים משחקני הליגה הזו בליגות שונות ברחבי העולם, לרבות ליגת ה-NBA, ליגות הכדורסל האירופאיות (כולל היורוליג) והליגה הישראלית.
יצחק פרי, פיני גרשון ושלמה וייספלר נסעו לראות את דארל ארמסטרונג משחק ב"אטלנטה איגלס" לפני קיץ 1993, אך גרשון העדיף שלא להחתימו בעבור מכבי ראשון לציון ובמקומו נלקח סטיב בארט ששיחק מולו במדי "ניו ג'רזי שור-קאטס" באותו המשחק.
לאחר חששות שהליגה תקרוס לאחר עונת 2007, הליגה הודיעה כי לא תפעל בעונת 2008, וכי תשקול את אפשרויותיה בעתיד.
עם זאת, הליגה לא חזרה לפעילות מאז, למרות שבאתר האינטרנט של הליגה פורסם בחודש ינואר 2010 כי מקווים לחדש את פעילות משחקי הליגה באפריל 2010.
את עונת 2007 פתחו עשר קבוצות, ששיחקו בחלוקה של שני בתים בני חמש קבוצות, ארבע קבוצות נשרו במהלך העונה ושש הקבוצות הנותרות שובצו מחדש בבית אחד.
USP הוא אקדח גרמני תוצרת חברת הקלר וקוך.
האקדח עוצב בשנים 1989–1992 והוצג לראשונה בשנת 1993. כיום האקדח נמצא בשימוש ביחידות משטרתיות רבות וגם ביחידות צבאיות רבות.
United States Medical Licensing Examination (בחינת הרישוי ברפואה של ארצות הברית; USMLE) היא בחינה בת שלושה שלבים הנדרשת לקבלת רישיון לעסוק ברפואה בארצות הברית, אשר נערכת על ידי המועצה הלאומית לרפואה (FSMB) והמועצה הלאומית לבחינות רפואיות (NBME).
הבחינה מיועדת למקומיים וזרים, בעלי תואר MD, המעוניינים לעסוק ברפואה במדינה.
הבחינה נועדה לבחון את היכולת של הנבחן ליישם ידע, מושגים ולהפגין מיומנויות טיפוליות יסודיות אשר מהוות בסיס לטיפול בטוח ויעיל בחולים.
לפני ייסוד המבחן, ב-1996, היו בארצות הברית בחינות רבות שנועדו להכשרה במדינות או מחוזות מסוימים.
לכן התעורר צורך בבחינה אחידה שתהיה תקפה בכל אזורי המדינה ותוודא שכל הרופאים עברו את אותו מסלול הכשרה ללא קשר לאוניברסיטה או למדינה בה למדו.
בחינת ה-USMLE נולדה כמענה לצורך זה.
USA-260, הידוע גם בשם GPS IIF-9, GPS SVN-71 ו- NAVSTAR 73, הוא מערכת ניווט לוויינית אמריקנית.
הוא היה ה-9 מתוך 12 לווייני IIF שהושקו.
הלווין נבנה על ידי בואינג והושק על ידי United Launch Alliance, USA-260.
השיגור התרחש ממתחם שיגור החלל 37B בנמל החלל קייפ קנוורל.
אורך חיי הלוויין הוא 15 שנה ומסתו היא .
הוא נמצא כעת בשירות לאחר הזמנתו ב-20 באפריל 2015.
USB-C (רשמית USB Type-C) מכונה גם Type-C, הוא סוג מחבר ממשפחת USB עם 24 פינים וראש סימטרי סיבובי.
מפרט USB Type-C 1.0 פורסם על ידי (USB-IF) והושלם באוגוסט 2014. הוא פותח בערך במקביל למפרט ה-USB 3.1. ביולי 2016 הוא אומץ על ידי הנציבות הבין-לאומית לאלקטרוטכניקה וניתן לו מספור התקן הרשמי "IEC 62680-1-3".
התקן עם מחבר Type-C אינו מיישם בהכרח את הגדרות USB, אספקת חשמל מסוג USB או כל מצב חלופי (Alternate Mode) כלשהו.
מחבר Type-C משותף למספר טכנולוגיות אך הוא מחייב רק מעטות מהן.
USB 3.2, שפורסם בספטמבר 2017, מחליף את התקן USB 3.1. הוא שומר על מצבי הנתונים SuperSpeed ו-"SuperSpeed+" של 3.1 ומציג שני מצבי העברה "SuperSpeed+" חדשים מעל מחבר USB-C באמצעות פעולת שני נתיבים, עם קצבי נתונים של 10 ו-20 Gbit/s.
USB4, שיצא בשנת 2019, הוא תקן פרוטוקול העברת ה-USB הראשון שזמין רק באמצעות USB-C.
תקן ה USB4 מאפשר קצבי נתונים של 20 ו-40 Gbit/s.
USS Callister (בתרגום חופשי: החללית קאליסטר) הוא הפרק הראשון בעונה הרביעית של סדרת האנתולוגיה "מראה שחורה".
תסריט הפרק נכתב על ידי יוצר הסדרה ו-ויליאם ברידג'ס.
הפרק בוים על ידי .
הפרק עלה לשירות הזרמת המדיה "נטפליקס" יחד עם שאר פרקי העונה ב-29 בדצמבר 2017.
עלילת הפרק עוקבת אחר רוברט דיילי (ג'סי פלמונס), מתכנת מוכשר אך חסר כישורים חברתיים העובד כבעלים שותף בחברה היוצרת ומנהלת משחק רשת מרובה משתתפים.
דיילי, שמרגיש מתוסכל נוכח חוסר ההערכה של שאר העובדים כלפיו, יוצר מעין "מוד" במשחק החברה ובו הוא מפקד על ספינת חלל ומשתמש בדי.אנ.איי של שאר העובדים במטרה לייצר עותקים שלהם עליהם הוא מפקד בספינת החלל.
בהיותו מפקד הספינה והמתכנת הראשי, דיילי משתמש בכישוריו כדי להתעלל בחברי הצוות ולהענישם במידה והמרו את פיו.
לאחר שדיילי מכניס את אחת העובדות החדשות למשחק, היא מחליטה להמריד את שאר חברי הספינה לנקום בדיילי ולברוח מפניו.
בניגוד להרבה פרקים אחרים בסדרה, "החללית קלאיסטר" עושה שימוש רב בקומדיה ואפקטים מיוחדים.
בהיותו מעריץ של סדרת הטלוויזיה "מסע בין כוכבים", ברידג'ס שאף להכניס כמה שיותר אלמנטים ממנה לפרק.
בנוסף להשראה זו, הפרק גם שאב השראה מהפרק "" מסדרת הטלוויזיה "אזור הדימדומים" וכן מהדמות "Playtime Fontayne" מסדרת הקומיקס "".
הפרק זכה לביקורות חיוביות ובהן כאלו ששיבחו את הדמיון לסדרה "מסע בין כוכבים", המשחק והצילום.
צופים רבים ראו בפרק זה השוואה לגברים בעמדת כוח שמנצלים את מעמדם לרעה והשוו את עלילת הפרק לפרשת התקיפות המיניות של הארווי ויינסטיין.
בשנת 2018, הפרק זכה בארבעה פרסי אמי לבידור בפריים טיים וביניהם ו.
בנוסף, הפרק היה מועמד לשלושה פרסי אמי.
פרק המשך יצא בסוף העונה השביעית של הסדרה "מראה שחורה".
על גבי ספינת החלל "קאליסטר", הקפטן רוברט דיילי (ג'סי פלמונס) וצוותו משמידים את ספינת החלל של אויבם המושבע, וואלדק (בילי מגנוסן), אך הוא בורח.
הצוות חוגג את ניצחונם ודיילי מנשק שתי נשים מצוות הספינה.
במציאות, דיילי הוא מנהל טכנולוגיות ראשי בחברה "Callister Inc".
החברה הוקמה על ידי דיילי בשיתוף עם ג'יימס וולטון (), המנכ"ל והיא אחראית לפיתוח משחק הרשת "Infinity" (בעברית: אין סוף) ובו שחקנים יכולים לפקד על ספינת חלל משלהם בעולם וירטואלי.
דיילי זוכה ליחס מחפיר מצד שאר העובדים, שנראים זהים לגמרי לחברי הצוות על ספינת החלל "קאליסטר".
מתכנתת חדשה בשם נאנט קול (כריסטין מיליאוטי) משבחת על דיילי על עבודתו על המשחק, אך וולטון, שהוא יותר אסרטיבי מדיילי, מפריע לשיחתם של השניים כדי לעשות לנאנט סיור במשרד.
כשדיילי חוזר לביתו, הוא פותח "גרסת מפתחים" של Infinity עליה הוא התקין מוד שמדמה את הסימולציה לסימולציה המזכירה את סדרת הטלוויזיה האהובה עליו "Space Fleet".
לאחר שהוא נכנס למשחק ובהיותו קפטן הספינה, דיילי מתעלל בעובדיו וחונק את וולטון שמתרפס מולו.
לאחר שעובדת בשם שאניה לורי () מזהירה את נאנט מפני דיילי, דיילי לוקח את כוס הקפה של נאנט ובעזרת הדי.אנ.איי שלה הוא יוצר העתק שלה ומכניס אותו למשחק בביתו.
נאנט מתעוררת על גבי ספינת החלל כשהיא מבולבלת לחלוטין.
הגרסה של לורי על ספינת החלל מסבירה לנאנט שהם רק העתקים דיגיטליים של עובדי החברה.
נאנט מנסה לברוח, אך משוגרת בחזרה לגשר הספינה.
נאנט מסרבת להקשיב לפקודותיו של דיילי והוא בתגובה מסיר את פניה וחונק אותה עד שהיא מסכימה לציית.
צוות החללית יוצא למתקפה נגד וואלדק, אך מחליטים לחוס על חייו.
לאחר שדיילי עוזב, נאנט מוצאת דרך לשלוח מייל ובו הזמנה למשחק לנאנט האמיתית במטרה לבקש את עזרתה.
נאנט מהעולם האמיתי שואלת את דיילי מהעולם האמיתי לפשר ההזמנה, אך הוא מסביר לה שזאת רק הודעת ספאם.
דיילי חוזר למשחק, מתחקר את הצוות אודות ההודעה והופך את לורי למפלצת לאחר שהיא מגינה על נאנט.
לאחר שדיילי עוזב את המשחק, נאנט מזהה חור תולעת רחוק המתפקד כחיבור לשרת הראשי של Infinity ובו נמצא עדכון למשחק שיכול למחוק אותם (נאנט משערת שמכיוון שהם חיים בגרסה של המשחק שעברה שינויים, המשחק יימחק אותם ביחד עם העדכון באופן אוטומטי והם ימותו).
וולטון מסרב לקחת חלק בתוכנית לאחר שדיילי יצר גרסה וירטואלית של הבן שלו, טומי ולאחר מכן הרג אותו בכדי להעניש את וולטון.
בנוסף, וולטון מסביר שמכיוון שלדיילי יש עדיין את הדי.אנ.איי שלהם, הוא יוכל פשוט ליצור אותם מחדש ולהעניש אותם יותר.
נאנט מבטיחה לוולטון שהם יצליחו לקחת מדיילי סוכריה ועליה הדי.אנ.איי של טומי.
כשדיילי חוזר למשחק, נאנט משכנעת אותו לקחת אותה למשימה על כוכב "Skillane IV" לבד.
על הכוכב, נאנט מתפשטת ונכנסת לשחות באגם.
דיילי מתפתה ונכנס לשחות ביחד איתה, בכך הוא משאיר מאחור התקן בשם "האומניקורדר" בעזרתו הוא שולט על המשחק.
צוות הספינה משגר את האומניקורדר לספינה ובעזרתו, הצוות משחזר תמונות אינטימיות של נאנט שאוחסנו בענן.
בעזרת התמונות, הצוות סוחט את נאנט האמיתית להזמין פיצה לביתו של דיילי האמיתי ולגנוב את הסוכריה כשהוא לא שם לב.
לאחר שהצליחו, הצוות משגר את נאנט הדיגיטלית בחזרה לספינה.
דיילי חוזר לספינה ומבחין בצוות מנסה לברוח.
דיילי משתלט על ספינת חלל מרוסקת במטרה לרדוף אחריהם דרך חגורת אסטרואידים.
הקלאיסטר מתנגשת באסטרואיד, אבל וולטון מסכן את חייו כדי לתקן אותה ולבסוף מת.
לאחר שהספינה עוברת בחול התולעת, השרת הראשי של המשחק מזהה את הספינה כספינה ממודלת ונועל את מנגנוני השליטה שבה, בכך דיילי נאלץ להישאר תקוע במשחק שנמחק סביבו.
בעולם האמיתי, דיילי נראה יושב על כיסא ולא מסוגל לזוז.
הצוות מתעורר ומגלה שהמשחק העביר אותם לשרת הראשי והעניק להם ספינה חדשה, ביגוד חדש ושלורי ו-וולדאק חזרו לצורתם האנושית.
לאחר שהשיגו את חירותם, הצוות מסייר ברחבי הגלקסיה בחיפוש אחר הרפתקאות חדשות ומחליטים לענות להודעה שהתקבלה ממשתמש בשם "Gamer691" (ארון פול) שמאיים עליהם שיפוצץ את ספינתם.
הם מבינים שמדובר באחד ממיליוני השחקנים אשר מחוברים למשחק והפרק מסתיים בכך שהם בוחרים לטוס משם.
למרות שהעונות הראשונה והשניה של "מראה שחורה" שודרו בערוץ 4 בבריטניה, נטפליקס רכשה את זכויות ההפצה של הסדרה עבור 12 פרקים (שפוצלו לשתי עונות כאשר בכל עונה יש שישה פרקים) בספטמבר 2015 עבור 40 מיליון דולר.
במרץ 2016, נטפליקס רכשה את זכויות ההפצה של ערוץ 4 במטרה לשדר את הסדרה בבריטניה.
ששת הפרקים בעונה הרביעית הופצו בנטפליקס ב-29 בדצמבר 2017. הפרק "USS Callister" נחשב לפרק הראשון בעונה, למרות שהסדרה היא סדרת אנתולוגיה וניתן לצפות בפרקים בכל סדר נתון.
הפרק נכתב בנובמבר 2016. הפרק נוצר על ידי צ'ארלי ברוקר, יוצר הסדרה ועל ידי ויליאם ברידג'ס, שכתב את הפרק "" מהעונה השלישית.
ברוקר ציין שהפרק מבוסס על חזון שלו ליצור "מראה שחורה בחלל", ושהרעיון לפרק התבשל בזמן הפקת הפרק "" בעונה השלישית.
ההשראות לפרק היו הפרק "It's a Good Life" מסדרת הטלוויזיה "אזור הדמדומים" המתמקד בילד עם כוחות אלוהיים שמתעלל בעיירה קטנה שכוחת אל וכן בדמות הקומיקס "Playtime Fontayne" מהקומיקס "Viz", דמות של אדם מבוגר שמאלץ אנשים אחרים להשתתף במשחקים ילדותיים.
ברוקר השווה את דיילי לדיקטטור קים ג'ונג-און ולאנשים "שנכנסים לרשת ופשוט מתלוננים על הכל".
ברוקר השווה את הפרק למעין גרסה למבוגרים של הסרט "צעצוע של סיפור" והשווה את הצעצועים בחדר שנאלצים לקפוא כשאנדי בסביבה לצוות הספינה שנאלצים לחכות שדיילי יתנתק כדי להגיד מה הם באמת חושבים עליו.
למרות שזה נעשה בצורה צנועה, הפרק משתמש בקומדיה שלא אופיינית לפרקים האחרים בסדרה, ברוקר אפילו כינה את הפרק "הפרק הכי עדכני בסדרה".
בנוסף, ברוקר השווה את הפרק לפרק "סאן ג'וניפרו" והצהיר ששני הפרקים מרחיבים את מה שהסדרה ניסתה לבנות עד כה.
כמעריץ נלהב של מסע בין כוכבים, ברידג'ס הכניס מלא אלמנטים מהסדרה לפרק.
בנוסף, ברידג'ס שאב השראה מעלילת הסרט "כיבוש הגלקסיה" במסגרתו אנשים נורמטיביים נשאבים לעלילת מדע בדיוני ממנה הם לא מסוגלים לברוח.
בראיון, ברוקר ציין שהפרק לא נועד לפגוע במעריצים של "מסע בין כוכבים", אלא רחוק מכך.
במקור, דמותו של דיילי נועדה להיות "לא אהודה" כבר מתחילת הפרק, אך פרט זה שונה מכיוון שהיוצרים האמינו שהחשיפה של טבעו האמיתי של דיילי (מיד לאחר שהוא חונק את וולטון) היא יותר מפתיעה.
ברוקר סיפר בראיון שדיילי בוודאות מת לאחר אירועי פרק ושהוא מת מרעב מכיוון שעל דלת ביתו היה שלט "נא לא להפריע".
היינס רצה לסיים את הפרק עם צילום של דיילי בביתו מאשר את הסצנה השמחה ששודרה במקור.
למרות זאת, ברוקר התעקש להשאיר את הסצנה כיוון שלטענתו "לא כל הפרקים במראה שחורה מסתיימים בצורה פסימית".
בתסריט הראשוני של הפרק, על כל דמות היה מותקן שתל שבבי אנושי (אותו שתל מהפרק "תולדות חייך") שהיה אמור לתעד את כל מה שהדמויות ראו ושמעו, מה שמסביר מדוע נאנט הופתעה כשהיא התעוררה על ספינת החלל לראשונה ושהיא חולקת את אותן הזכרונות ומחשבות עם נאנט האמיתית.
ברוקר ויתר על הפרט הזה כיוון שהאמין שהצגה של השתל ביחד עם שילוב הדי.אנ.איי של אנשי הצוות כדי ליצור את ההעתקים הדיגיטליים היה פשוט ארוך מידי ולכן עניין השתל נחתך מהפרק.
כשנאנט שואלת את שאניה איך הטכנולוגיה של דיילי עובדת, האחרונה פשוט עונה לה "זה גאדג'ט מזורגג" .
תשובה זו נועדה להמחיש לצופים כמה ההיבט הטכנולוגי מאחורי יצירת הפרק הוא לא רלוונטי.
האתר Rotten Tomatoes העניק לפרק ציון של 95% טריות על סמך 38 ביקורות.
UTF-8 (ראשי תיבות של 8-bit Unicode Transformation Format או 8-bit UCS Transformation Format) הוא קידוד תווים באורך משתנה ליוניקוד, שנוצר על ידי רוב פייק וקן תומפסון.
ניתן לקודד בו כל תו המצוי בתקן יוניקוד על ידי שימוש באחד עד ארבעה בתים, תלוי בתו.
הקידוד ב־UTF-8 מעניק את כל יתרונות השימוש בקידוד ליוניקוד ומוסיף עליהם, בין היתר, גם חיסכון בזיכרון, עמידות בפני איבוד או השחתת בתים ותאימות לאחור ל־ASCII.
ה־IETF מעדיף בבירור את UTF-8 ומחייב כל פרוטוקול אינטרנט לתמוך בו, וכן קונסורציום הדואר האלקטרוני, ה־IMC, ממליץ שכל תוכנת דואר אלקטרוני תוכל להציג וליצור דואר באמצעות UTF-8.
שיטת הקידוד המוכרת כ־UTF-8 הומצאה על ידי קן תומפסון בערב 2 בספטמבר 1992. תומפסון כתב את רעיונו על מצעית בעת ששהה במזנון מהיר בניו ג'רזי עם רוב פייק.
ביום שלאחר מכן, פייק ותומפסון מימשו את רעיונם והפכו את מערכת ההפעלה Plan9 של מעבדות בל למערכת ההפעלה הראשונה בעולם המשתמשת בקידוד.
UTF-8 הוצג רשמית לראשונה בכנס USENIX בסן דייגו שנערך ב־25–29 בינואר 1993.
מאז פורסמו מספר הגדרות ל־UTF-8, בהן:
הגדרות אלו מיושנות ואינן בשימוש יותר.
RFC 3629 / STD 63 (2003) הקובע את UTF-8 כאלמנט סטנדרטי בפרוטוקולי אינטרנט
שלוש ההגדרות מסכימות על מנגנון הקידוד, וההבדלים ביניהן נסובים בעיקר סביב נושאים כגון טווח המספרים המייצגים המותרים לשימוש ביוניקוד וכיצד יש לטפל בקלט שגוי.
פרויקט יוניקוד החל כחלק ממאמץ ליצור מערכת תווים אחידה בינלאומית .
בפשטנות גדולה ניתן לומר שיוניקוד הוא טבלה גדולה של תווים הממפה כל תו למספר המייצג אותו.
יוניקוד אינו מפרט כיצד יש לייצג מספר זה במחשב.
דרושה שיטה שבאמצעותה ניקח את המספר המייצג את התו ונשמור אותו במחשב בתור בית (או רצף של בתים).
לשיטה זו אנו קוראים "קידוד תווים".
UTF-8 הוא קידוד תווים, הוא מורה לנו כיצד יש לקחת את המספר הייצוגי ולשמור אותו במחשב (וכיצד יש לקרוא מספרים השמורים במחשב ולהמירם למספרים ייצוגיים שלאחר מכן נוכל להמיר לתווים).
אם ברשותנו טקסט ואנו מעוניינים להכניסו למחשב באמצעות קידוד יוניקוד, תחילה נחליף כל תו בטקסט למספרו הייצוגי לפי טבלת יוניקוד.
כעת ברשותנו רצף של מספרים, באמצעות UTF-8 נשמור את המספרים הללו במחשב.
UTF-8 מבוסס על יוניקוד בכך ששיטת השמירה שלו מבוססת על המספרים הייצוגיים שנקבעו ביוניקוד.
בעוד שקיים מיפוי אחד של תווים למספרים ייצוגיים בשם יוניקוד, קיימות דרכים רבות לשמור מספרים אלה במחשב, קרי, קיימים קידודי תווים רבים ליוניקוד.
בהם UCS-2 ו־UCS-4 הפשוטים המורים לשמור את המספר באמצעות 2 או 4 בתים בהתאמה (קידודים אלה אינם בשימוש, שני בתים אינם מספיקים יותר לכל תווי יוניקוד ו־UCS-4 הפך ל־UTF-32) וכן גם קידודים מתוחכמים יותר כמו UTF-8 ו־UTF-16.
הקידוד ב־UTF-8 הוא תלוי תו, או נכון יותר תלוי במספר המייצג את התו בתקן היוניקוד.
לכל תו ברפרטואר התווים של יוניקוד יש מספר המייצג אותו.
קיימים תווים שמסיבות של תאימות או סיבות אחרות חוזרים מספר פעמים ברפטואר אך לכל אחד מהם מספר שונה.
כל מספר מייצג תו אחד בלבד ולכן ניתן, ואולי אף עדיף, לדבר על התווים דרך מספריהם הייצוגיים ולא דרך שמותיהם, כדי למנוע בלבול.
נהוג לרשום את המספרים המייצגים את התווים בצורה הקסדצימלית בשל קלות ההמרה מצורה זו לצורה הבינארית שהיא הצורה בה נכתבים המספרים למחשב.
נהוג גם, כאשר מדברים על תווים או המספרים המייצגים אותם, לנקוט בסימונים מיוחדים המבהירים שמדובר ביוניקוד:
אם התו (קרי, המספר המייצג אותו) נמצא בטווח שבין 0x00000000 ל־0x0000FFFD, נאמר שהתו נמצא במשטח הרב־לשוני הבסיסי ונכתוב רק את ארבע הספרות האחרונות של המספר עם הקידומת U+.
לדוגמה, המספר המייצג את האות אל"ף ביוניקוד הוא 0x000005D0, ולכן נתייחס אליה בתור U+05D0. המשטח הרב־לשוני הבסיסי טומן בחובו את מרבית התווים בהם השתמשו ומשתמשים גם היום.
אם המספר גדול מ־0x0000FFFD, נאמר שהוא מחוץ למשטח הרב־לשוני הבסיסי ונכתוב את כל ספרות המספר המייצג עם הקידומת U-.
משטחים אלה מכילים בתוכם תווים רבים שהשימוש בהם מועט לרוב, לדוגמה: תווים מוזיקליים, סימנים מתמטיים ואותיותיהן של שפות היסטוריות.
כאשר נאמר U+05D0 נתכוון בעצם לאות אל"ף (א) כפי שהיא מוגדרת בתקן היוניקוד.
כאשר נאמר 0x05D0 נתכוון בעצם למספר מסוים (שבמקרה מייצג ביוניקוד את האות אל"ף).
משום שמדובר אך ורק במספר, נוכל לכותבו בכל צורה שנחפוץ כל עוד ערכו זהה.
נוכל לרשום למשל גם 0x000005D0, או 1488, שהוא ערכו של המספר בבסיס העשרוני – ממש כפי שאין הבדל אם נרשום 2 או 2.0 או 002 מבחינת ערך המספר.
הקידוד ב־UTF-8 פועל לפי מספר עקרונות פשוטים:
התווים U+0000 עד U+007F (שהם תווי ASCII שכזכור ערכיהם נעים בין 0 ל־127) מומרים פשוט למספרים 0x00 עד 0x7F בהתאמה ומקודדים לבית אחד.
מספרים אלו קטנים, ודי ב־7 סיביות כדי לייצגם ולכן בכל בית בו מקודד אחד מהתווים הנ"ל, תהיה הסיבית המשמעותית ביותר כבויה (ערכה 0).
משום שכל תווי ה־ASCII מקודדים ב־UTF-8 באמצעות בית אחד, אנו מקבלים שטקסט המקודד ב־ASCII, מקודד בדיוק באותה הצורה ב־UTF-8. דבר זה נותן לנו תאימות לאחור ל־ASCII.
תווים מעבר ל־U+007F יקודדו באמצעות מספר בתים (בפועל, שניים עד ארבעה בתים).
הסיבית המשמעותית ביותר בכל אחד מהבתים הללו תהיה דלוקה (ערכה יהיה 1).
הבחירה בכמה בתים להשתמש תלויה בערך המספר הייצוגי, מספרים בטווח 0x0007FF–0x000080 יקודדו באמצעות שני בתים, מספרים בטווח 0x00FFFF–0x000800 יקודדו באמצעות שלושה בתים ומספרים גדולים יותר (מספרים בטווח 0x10FFFF–0x010000) יקודדו באמצעות ארבעה בתים.
הקידוד תוך שימוש ברצף של בתים כדי לייצג תו אחד ייעשה כך:
הבית הראשון יתחיל ברצף של 1 כמספר הבתים הדרושים ואחריהם יבוא 0. לדוגמה, אם ברצוננו לקודד את המספר באמצעות שלושה בתים, הבית הראשון יחל ברצף 1110 ובכלליות יהיה מהצורה 1110xxxx (בהמשך יוסבר מהם הערכים הנוספים).
כל בית נוסף (קרי, הבית השני, השלישי והרביעי ברצף, אם קיימים) יחל ברצף 10 ובכלליות ייראה כך: 10xxxxxx.
כעת ברשותנו מספר בתים, בהם חלק מהסיביות כבר תפוסות בשל הכללים הקודמים וכן סיביות חופשיות (אותן סימנו ב־x בסעיפים הקודמים).
נמיר את המספר לייצוג בינארי עם מספר סיביות כמספר הסיביות הפנויות ונמלא אותן במספר שקיבלנו.
הטבלה הבאה מסכמת את עקרונות הקידוד:
טווח מספריםהקסדצימלי ערך המספר הייצוגיבינארי UTF-8בינארי הערות 000000–00007F 128 ערכים 0zzzzzzz 0zzzzzzz ערכים המקבילים ל־ASCII, הסיבית המשמעותית ביותר כבויה.
לשם המחשה נקודד את האות העברית אל"ף (א), סימנה ביוניקוד U+05D0, באמצעות UTF-8:
האות נמצאת בטווח האותיות שבין U+0080 ל־U+07FF ולכן תקודד על ידי שני בתים.
הבית הראשון יהיה מהצורה 110xxxxx (שני 1 משום שיש שני בתים, ואחריהם 0 כנדרש) והבית השני יהיה מהצורה 10xxxxxx (משום שהוא בית נוסף הוא מתחיל ברצף 10).
המספר המייצג את אל"ף הוא 0x05D0. אנו רואים שברשותנו 11 סיביות פנויות (נספור את סך ה־x בשני הבתים) ולכן נרשום את המספר בייצוג בינארי תוך שימוש ב־11 סיביות, נקבל: 101-1101-0000 (המקפים הם לשם בהירות הקריאה בלבד ואינם נדרשים).
נחדיר את המספר הבינארי לתוך הסיביות הפנויות.
התוצאה הסופית היא שני הבתים לעיל, אותם ניתן לבטא בנוחיות רבה בצורה ההקסדצימלית 0xD7 0x90, וכך מקודדת ב־UTF-8 האות אל"ף.
במקור, UTF-8 תמך גם בקידודו של תו באמצעות חמישה ואף שישה בתים.
קידוד באמצעות שישה בתים מעניק מרחב של 31 סיביות חופשיות וכך ניתן לכסות את כל האזור 0x7FFFFFFF–0x00000000. בפועל, הוחלט שכל המספרים הייצוגיים של יוניקוד יישארו בטווח 0x10FFFF–0x000000, הדורש רק 21 סיביות, ולכן UTF-8 הוגבל על ידי לייצוג באמצעות עד ארבעה בתים (המעניקים 21 סיביות פנויות).
הקידוד באמצעות מספר משתנה של בתים ורצפי הסיביות בתחילת כל בית, אם הוא חלק ממספר בתים המייצגים תו בודד, הופך את UTF-8 לאמין, עמיד בפני תקלות שונות וחסכוני.
חוקי הקידוד דורשים שיתקיימו התנאים הבאים:
הסיבית המשמעותית ביותר בבית המייצג תו אחד, היא תמיד 0.
הסיבית המשמעותית ביותר בבית שהוא חלק ממספר בתים המייצגים תו אחד, היא תמיד 1.
כל בית שהוא בית נוסף (לא הראשון) ברצף של בתים המייצגים תו בודד מתחיל ב־10.
כתוצאה מכך, לא ניתן להתבלבל בין בית המייצג תו ASCII (בית בודד המייצג תו בודד) לבין בית שהוא חלק ממספר בתים המייצגים יחדיו תו אחד (זאת משום שבמקרה הראשון הסיבית המשמעותית ביותר היא 0 ובמקרה השני תהיה הסיבית המשמעותית ביותר 1).
באופן כללי יותר, החוקים הנ"ל מבטיחים שלא יכול להתקיים מצב בו רצף בתים המייצג תו מסוים יוכל בתוך רצף בתים גדול יותר המייצג תו אחר.
המשמעות של העניין היא שגם אם נסתכל על חלקים מהקידוד, לעולם לא נוכל לפרש אותם כתווים אחרים פרט לתווים שהם יועדו להיות מלכתחילה.
לא ייתכן שמתוך ארבעה בתים המייצגים תו, אם נסתכל רק על שניים נוכל לחשוב בטעות שמדובר בתו אחר.
כעת ניתן להשתמש באלגוריתמי חיפוש המסתמכים על הבתים מהם מורכב הטקסט, כדי לחפש מילים או ביטויים בטקסט בצורה יעילה.
נוסף על כך, אם בית אחד הושחת או אבד בנסיבות כלשהן (למשל, במהלך העברה ברשת), רק תו אחד ייפגם, שכן ברגע שנגיע לתו הבא נבחין שמתחיל רצף חדש של בתים ולכן תו חדש.
בשיטות אחרות, איבוד בית אחד יכול להוביל להשחתה של הטקסט כולו.
מבחינה סטטיסטית, אם רצף של בתים עבר את בדיקות ה־UTF-8 והתברר כרצף שעלול לייצג תו או מספר תווים ב־UTF-8, נראה שאכן מדובר בקידוד UTF-8. תכונה זו עוזרת בכך שהיא מונעת מצב בו תוכנה תטעה לחשוב שטקסט מסוים קודד ב־UTF-8, תנסה להציגו כך ויתקבל טקסט לא קריא.
תופעה זו שכיחה מאוד בקרב קידודי ISO 8859, שכן לא ניתן להבדיל בין קידוד אחד במשפחה לשני.
גולשי אינטרנט ישראלים רבים נתקלו בתופעה של דף המציג אותיות מערב־אירופאיות במקום האותיות העבריות משום שהדפדפן טעה לחשוב שהדף מקודד ב־ISO-8859-1 במקום ISO-8859-8 (שהוא הקידוד המכיל את האותיות העבריות במשפחה).
תוספת הסיביות בתחילת כל רצף בתים המייצגים מותירה פחות סיביות לשם ייצוג המספר ולכן דורשת לעיתים בית נוסף.
128 התווים הראשונים צורכים רק בית אחד, תווים אלו הם תווי ASCII ואלו הם התווים בהם נעשה השימוש הנרחב ביותר בכל הטקסטים בעולם (כל שיטות הקידוד האחרות ליוניקוד יקודדו תווים אלה ביותר מבית אחד).
1920 התווים הבאים צורכים שני בתים לקידוד, אלה כוללים את תווי האלפבית לטיני עם הסימנים הדיאקריטיים, האלפבית היווני, האלפבית הקירילי, הקופטית, הארמנית, האלפבית העברי והאלפבית הערבי.
שאר התווים במשטח הרב־לשוני הבסיסי (65,536 התווים הראשונים) משתמשים בשלושה בתים, ושאר התווים הנתמכים ביוניקוד משתמשים בארבעה בתים לקידוד.
ככל ש־UTF-8 צורך יותר בתים לקידוד התו, אנו שמים לב שמדובר בתו ששכיחותו בטקסטים באופן כללי נמוכה יותר.
התווים שאינם במשטח הרב־לשוני הבסיסי הם תווים שכמעט ולא, או כלל לא, היו קידודים שתמכו בהם קודם לכן והשימוש בהם הוא מזערי (מדובר בתווים מוזיקליים, סימנים מתמטיים ואותיות בשפות היסטוריות).
טקסט שנכתב כולו באנגלית יתפוס את אותה כמות המקום בזיכרון כפי שהיה תופס לו קודד בשיטות הקידוד הישנות, וטקסט שנכתב בשפה שכיחה, שאינה אנגלית, יתפוס עד פי שניים מהמקום שהיה תופס לו קודד בשיטות הישנות.
טקסט המשלב בתוכו מספר שפות שכיחות יתפוס כמות מקום זהה לטקסט הכתוב רק בשפה אחת שכיחה, אך לא ניתן להשוות לכמות הזיכרון שהיה תופס לו היה נכתב בשיטות הקידוד הישנות, משום שאותן שיטות כלל לא אפשרו הצגה של מספר שפות (שאחת מהן אינה אנגלית) באותו הטקסט.
בשעת קידוד, מקודד ה־UTF-8 ממיר את התו המבוקש למספר לפי טבלת יוניקוד ואז, תלוי בערכו של אותו מספר, ממיר אותו למספר הבתים הנדרש.
מפענח UTF-8 הקורא קטע שקודד קודם לכן קורא את הבתים, על־פי הסימונים מחליט כמה בתים עליו לקרוא לשם קבלת תו בודד, מוציא מבתים אלה את המספר ואז הולך לטבלת יוניקוד ורושם את התו המתאים.
אם ברצוננו לקודד את התו U+000A שהוא תו הזנת השורה, עלינו רק ללכת לפי אלגוריתם הקידוד ומיד נגלה שכל שעלינו לעשות הוא לכתוב בבית אחד את המספר 0x000A.
אם מפענח UTF-8 יתקל בבית 0x000A, מיד ידע שמדובר בבית בודד המייצג תו בודד (הסיבית המשמעותית ביותר היא 0) ואז יבדוק מהו התו U+000A.
נשאלת השאלה מה יקרה אם מפענח ה־UTF-8 יתקל באחד מרצפי הבתים הבאים:
נבחן את האפשרות הראשונה, 0xC0 0x8A, ההמרה הבינארית היא 10001010 11000000. הסיביות המודגשות הן הסיביות המכילות את המספר בהצגתו הבינארית, המספר הוא 0x000A ומייצג את התו U+000A ביוניקוד.
הליך פיענוח דומה של שתי האפשרויות האחרות יביא לתוצאה זהה.
נראה אם כן שניתן להציג תווים מסוימים ביותר מדרך אחת.
לכאורה ניתן להציג תווים בדרך המומלצת (והחסכונית) או להציג אותם על ידי שימוש ביותר בתים.
הצגתו של תו על ידי יותר בתים ממה שצריך מכונה הצגתו ב"צורה הארוכה" (Overlong Form).
בעבר נעשה שימוש זדוני באפשרות של הצגת תווים בצורתם הארוכה לשם עקיפת מנגנוני אבטחה שונים.
תוכנות האבטחה לא פענחו את הקוד לפני הבדיקה אלא ביצעו את הבדיקה ישירות על הבתים המקודדים תוך כדי הסתמכות על אלגוריתם הקידוד המוכר ועל העובדה שכל תו מקודד בצורה הקצרה ביותר.
בשיטה זו נעקפו מנגנוני הביטחון של שרתי IIS של מיקרוסופט.
השימוש בצורה הארוכה של תווים מנע מתוכנת האבטחה למצוא אותם.
עקב כך השימוש בצורות ארוכות נאסר על ידי סטנדרט .
הסטנדרטים המגדירים את UTF-8 אינם מגדירים תגובה אחידה לאופן בו צריך מפענח UTF-8 לנהוג אם הוא נתקל בקלט לא תקין (למשל בית המצהיר על התחלה של רצף של ארבעה בתים ולאחריו בית אחד בלבד, או למשל צורה ארוכה עליה נכתב קודם לכן).
קיימות מספר אפשרויות לפיהן יכול המפענח לנהוג:
להחליף את התו המושחת בתו אחר כגון "�", "?", או תו אחר שמייצג תו לא תקין.
לפענח את הבתים לפי קידוד תווים אחר (לעיתים קרובות ISO-8859-1).
לא לשים לב ולהמשיך לפענח כאילו שמדובר בקוד תקני של UTF-8 (אפשרי בייחוד כשמדובר בצורות ארוכות).
להפסיק לפענח ולדווח על שגיאה (אולי עם אפשרות לתת למשתמש להמשיך בקידוד בכל זאת).
קיימת אפשרות גם שהמפענח ינהג בצורה שונה כאשר הוא נתקל בסוגי קלטים לא תקינים שונים.
סטנדרט דורש רק שמפענחי UTF-8 לא יפענחו "צורות ארוכות".
סטנדרט היוניקוד דורש ש"כל מפענח יוניקוד יתייחס לכל קטע קוד שגוי כשגיאה.
זה יבטיח שהוא לא יפרש או יפלוט רצף קוד שגוי".
הטיפול בקלטים לא תקינים חשוב מטעמי אבטחת מידע, כפי שראינו לגבי צורות ארוכות.
ישנן שתי אפשרויות לטפל בקלט לא תקין ולשמור על ביטחון המידע: האפשרות הראשונה היא לפענח את קידוד UTF-8 לפני שעושים בדיקות כלשהן (ואז לבצע את הבדיקות על הטקסט המפוענח).
האפשרות השנייה היא להשתמש במפענח שבמקרה של קלט לא תקין מוציא הודעת שגיאה או טקסט שהאפליקציה מחשיבה כבלתי מזיק.
אפשרות נוספת היא כלל לא לפענח את קידוד UTF-8, אך זה מחייב את התוכנה אליה מעבירים את הטקסט המקודד לטפל בעצמה בקלט לא תקין.
חשיבות נוספת לזיהוי קלטים לא תקינים ודרך הטיפול בהם היא לשם טיפול במקרים של איבוד או השחתה של בתים.
אם בית הושחת או אבד והמערכת מזהה מספר לא נכון של בתים המייצגים תו, ביכולתה למזער את הנזק לפגיעה בתו זה בלבד.
התעלמות מהבעיה והנחה שכל הבתים מופיעים ללא בדיקה שאכן כל אחד מהבתים העוקבים תואם את הדגם, עלולה במקרה של בית אחד חסר להביא לקריסת הפענוח כולו והשחתה של הטקסט (בניגוד להשחתה של תו אחד).
UTF-8 מכיל בתוכו את ASCII (קידוד האותיות הזהות נעשה בצורה דומה בשני הקידודים).
משום שכל טקסט שקודד ב־ASCII הוא גם טקסט תקני לפי UTF-8, אין צורך בשום פעולת המרה לטקסטים קיימים שכבר קודדו ב־ASCII.
ניתן להשתמש ב־UTF-8 גם בתוכנות שתוכננו עבור קידודי ASCII מורחבים מסורתיים לאחר ביצוע מספר שינויים קלים ולעיתים אף ללא שינוי כלל.
מיון מחרוזות שקודדו ב־UTF-8 על ידי אלגוריתמים המסתמכים על מיון לפי בתים, יביא אותן התוצאות כאילו מוינו המחרוזות לפי המסרים המייצגים של התווים ביוניקוד (לעובדה זו השלכות מעטות בלבד שכן לא סביר שמיון זה ייצג צורך או מיון מקובל כלשהו).
UTF-8 ו-UTF-16 הם המיונים הסטנדרטים עבור מסמכי XML.
שימוש בכל קידוד אחר מחייב ציון מיוחד על ידי אמצעי חיצוני או דרך הגדרת טקסט.
ניתן להפעיל כל אלגוריתם חיפוש המבוסס על חיפוש לפי בתים על טקסטים שקודד ב־UTF-8 (כל עוד מוודאים שהקלט תקין לפני כן).
יש לשים לב לבנייה תקינה של ביטויים רגולריים ומבנים אחרים הסופרים תווים.
ניתן לזהות בצורה יחסית פשוטה ואמינה טקסטים שקודדו ב־UTF-8. הסיכוי שתו או מחרוזת שקודדו בקידוד אחר יראו כקידוד UTF-8 תקין נמוכים מאוד וככל שהטקסט ארוך יותר הם הולכים ופוחתים אף יותר.
הבתים 0xC0, 0xC1, 0xFF-0xF5, למשל, לעולם לא יופיעו בטקסט שקודד ב־UTF-8. כדי להשיג תוצאות אמינות יותר, ניתן להשתמש בביטויים רגולריים בשביל לבדוק הימצאותם של צורות ארוכות או ערכים ממלאי מקום (surrogate values).
מפענח UTF-8 שנכתב בצורה לקויה ואינו תואם את הגרסאות העדכניות של הסטנדרטים, עלול לקבל מספר גרסאות שונות של ייצוגי תווים הנראים כמו ייצוגים חוקיים ב־UTF-8 (צורות ארוכות למשל) ולפענח אותם לתווי יוניקוד שהם כביכול מייצגים.
בצורה זו מידע יכול לדלוף מעבר להליכי בדיקה ואימות שונים שתוכננו לבדוק מידע בייצוגו בשמונה סיביות.
UTF-8 יכול לקודד כל תו יוניקוד.
ברוב המקרים, ניתן להמיר (אם כי לא לגמרי) כל טקסט שקודד בקידוד מיושן לקידוד יוניקוד ובחזרה מבלי לאבד מידע.
משום ש־UTF-8 הוא קידוד יוניקוד, הדבר תקף גם לגביו.
ניתן לזהות בקלות היכן מתחיל ומסתיים כל תו מכל מקום ברצף הבתים (בשל הסימונים המורים שבית מסוים מתחיל רצף של בתים המייצגים תו בודד, כמה בתים מעורבים ברצף זה והסימון על כל אחד מהבתים הנוספים שהוא מהווה חלק מהרצף).
כתוצאה מכך, אם נתחיל לסרוק את הטקסט המקודד מאמצע רצף בתים המייצג תו אחד, רק המידע על התו הבודד שהתחלנו את הסריקה מאמצע ייצוגו יאבד, וניתן להמשיך בפענוח תקין החל מהתו הבא.
יתרון זה בא לידי שימוש אם בית אחד או מספר בתים מושחתים או אובדים ואז רק המידע על התווים שאותם בתים הרכיבו אובד וניתן לפענח בצורה נכונה את כל שאר הטקסט.
סינכרון מחדש של קידוד מיושן שחלק מבתיו הושחתו או אבדו הוא מטלה קשה בהרבה.
לא ייתכן מצב בו רצף בתים המייצג תו בודד יוכל ברצף בתים ארוך יותר המייצג תו בודד אחר (או אותו תו בודד לצורך העניין), תופעה שכן קיימת בקידודי תווים אחרים בעלי אורך משתנה כמו Shift-JIS.
באופן פרטי, תווי ASCII המקודדים, כזכור, כבית בודד, אינם מופיעים בקידוד UTF-8 בשום צורה אחרת (כחלק מרצף תווים ארוך יותר למשל), אלא רק במקומות בהם נדרש קידוד של התו המדובר.
עובדה זו מאפשרת תאימות עם מערכות קבצים או תוכנות אחרות (למשל פונקציית ה־ של שפת C) המבצעות ניתוחים לפי ערכי ASCII השקופים לערכים אחרים.
הבית הראשון ברצף בתים המייצג תו בודד מספיק כדי לקבוע מהו אורך הרצף.
הדבר מאפשר להוציא תת-מחרוזת מן המחרוזת מבלי לבצע ניתוח מתוחכם של הטקסט.
אין הדבר נכון לרוב בקידודים מיושנים התומכים באורך משתנה.
UTF-8 אינו צורך שימוש בפעולות מתמטיות מסובכות כגון כפל או חילוק ומסתפק בפעולות על סיביות בלבד שהן פעולות מהירות בהרבה.
לרוב, הקידוד ב־UTF-8 יביא לצריכת זיכרון גדולה יותר מאשר קידוד אותו הטקסט באחד מהקידודים המיושנים, אלא אם מדובר בטקסט עם אלפבית לטיני ללא ניקוד (טקסט בו אותיות אנגליות בלבד).
בקידודים מיושנים, מרבית הכתבים מבוססי האלפבית קודדו על ידי שימוש בבית אחד לאות אחת בעוד שב־UTF-8 כל אות לוקחת לרוב שני בתים.
לוגוגרמות לרוב דרשו שני בתים לתו בקידוד מיושן אך דורשים שלושה בתים לתו בקידוד UTF-8.
קידודים מיושנים מקודדים תווים שאינם לוגוגרמות על ידי שימוש בבית אחד לתו ובכך הופכים חיתוך וחיבור של מחרוזות לפעולה פשוטה.
UTF-8 משתמש במספר קטן משמעותית של בתים לקידוד תווים שאינם תווי ASCII.
UTF-8 מקודד את התו "+" כעצמו בעוד ש־UTF-7 מקודד אותו כ"-+".
UTF-8 דורש מהמערכת להיות מערכת המבוססת על שמונה סיביות.
במקרה של דואר אלקטרוני, משמעות הדבר היא שיש צורך בקידוד נוסף בשיטת Quoted Printable או base64. שלב זה של קידוד נוסף מוביל לגידול משמעותי בתפוסת הזיכרון שדורש הקידוד.
עבור base64 מדובר בעלייה של שליש בצריכת הזיכרון.
עבור Quoted Printable הגידול תלוי במה חלקם היחסי של תווי ASCII בטקסט.
עבור טקסט שנכתב בצרפתית, תתרחש עלייה של 14% בתפוסת הזיכרון, אך טקסטים באותיות שאינן אותיות רומיות ואינם מכילים תווי ASCII יובילו לעלייה של 200% בצריכת הזיכרון.
בטקסטים רבים, הקידוד ב־UTF-7 יביס גם את הקידוד ב־UTF-8 משולב עם base64.
לא קיימים בתים שערכם 0 (תו ה־NUL ב־ASCII) אלא אם מופיע התו U+0000 שהוא תו ה־NUL ביוניקוד.
בזכות זה, פונקציות ספריית legacy של שפת C המטפלות במחרוזות (כמו strcpy() למשל) המשתמשות בתו ה־NUL כדי לציין סוף מחרוזת, לא יחתכו מחרוזות בשוגג לפני סיומן.
משום שתווי ASCII מקודדים באמצעות בית אחד, קידודם של טקסטים המורכבים בעיקר מאותיות לטיניות ללא ניקוד ב־UTF-8, יתפוס בערך חצי מהזיכרון שיתפוס קידוד אותם הטקסטים ב־UTF-16. קידודם של טקסטים רבים אחרים, שתוויהם אינם תווי ASCII, ב־UTF-8 יהיה קטן במעט מקידוד אותו הטקסט ב־UTF-16 בשל נוכחות רווחים.
רוב התוכנות הקיימות היום, ובהן גם מערכות ההפעלה, לא נכתבו תוך כדי מחשבה על יוניקוד.
שימוש ב־UTF-16 על תוכנות אלו ייצור בעיות תאימות קשות ביותר שכן UTF-16 אינו מכיל בתוכו את ASCII, כמו UTF-8. UTF-8 מאפשר לתוכנות להמשיך להתייחס לתווי ASCII בדיוק כפי שהתייחסו אליהם קודם ולשנות התנהגותם רק לגבי תווים שאינם ב־ASCII שהם ממילא תלויי מקום.
ב־UTF-8, תווים שהם מחוץ למרחב הרב־לשוני הבסיסי אינם מקרה יוצא דופן.
UTF-8 משתמש בבית כיחידה הקטנה ביותר שלו, ואילו UTF-16 משתמש במילה בגודל 16 סיביות, אשר לרוב מיוצגת כזוג בתים.
סדרם של בתים אלה בעייתי.
קיימים מספר מנגנונים היכולים לטפל בנושא זה (למשל, "סימן סדר הבתים", ה־Byte Order Mask), אך הדבר עדיין מסבך את התוכנה ועיצוב הפרוטוקול.
אם מספר אי-זוגי של בתים יורד מהתחלתו של טקסט המקודד ב־UTF-16, התוצאה תהיה טקסט שאינו תואם את תקן UTF-16 או השחתה מוחלטת של הטקסט.
לעומת זאת, ב־UTF-8 הורדה של בית יכולה במקרה הגרוע ביותר להשחית תו אחד ולכן הורדה של n בתים, במקרה הגרוע ביותר תשחית רק n תווים ושאר הטקסט יישאר תקין.
לעיתים מתייחסים בשגגה ל־UTF-16 כאל קידוד בעל אורך קבוע של שני בתים.
יחס זה מוביל לתכנות מקודדים ומפענחים הפועלים על מרבית הטקסטים אך נכשלים עבור תווים שאינם במרחב הרב־לשוני הבסיסי.
תיקון התוכנות הוא משימה קשה לרוב ולכן עדיף מראש ליישם תמיכה לכל טווח תווי יוניקוד.
UTF-8 הוא קידוד ברירת המחדל במערכות יוניקס ולינוקס.
שפת התכנות Java תומכת בקריאה וכתיבה של מחרוזות המקודדות ב־UTF-8, דרך המחלקות InputStreamReader ו-OutputStreamWriter.
מאידך, למטרות של סיריאליזציה של אובייקטים, שימוש ב־Java Native Interface ולשם הטמעת קבועים בקובצי class, משתמשת Java בגרסה קצת שונה של UTF-8 המכונה UTF-8 משופר (modified UTF-8).
ישנם שני הבדלים בין UTF-8 התקני לזה המשופר.
ההבדל השני הוא בצורת קידודם של תווים מחוץ למשטח הרב־לשוני הבסיסי.
ב־UTF-8 התקני, מקודדים תווים אלה באמצעות ארבעה בתים.
ב־UTF-8 המשופר, תווים אלה מומרים קודם כל לצורה של זוגות ממלאי מקום (surrogate pairs), כמו ב־UTF-16 ואז כל אחד מבני הזוג מקודד לבדו והקידודים נכתבים ברצף, כמו ב־CESU-8. הסיבה להבדל זה מעודנת יותר.
ב־Java, אורכו של משתנה מסוג תו הוא 16 סיביות.
מסיבה זו, חלק מתווי יוניקוד דורשים שימוש בשני משתנים מסוג תו לשם ייצוג הולם.
תכונה זו של השפה אינה תואמת את ההתקדמות ביוניקוד וההחלטה לפרוץ את גבולות המרחב הרב־לשוני הבסיסי, אך היא חיונית לשם ביצועים ולשם תאימות לאחור ולכן לא סביר שתשתנה.
השימוש ב־UTF-8 משופר מבטיח שניתן יהיה לפענח מחרוזות מקודדות על ידי פיענוח של יחידת קוד של UTF-16 אחת בכל פעם ולא על ידי פיענוח מספר ייצוגי אחד של יוניקוד בכל פעם.
השימוש ב־UTF-8 משופר גורם לכך שקידודם של תווים הדורשים ארבעה בתים כאשר משתמשים בצורה התקנית של UTF-8, דורש ב־UTF-8 המשופר שימוש בשישה בתים.
מערכת ההפעלה, Mac OS X, המיועדת למחשבי מקינטוש, מקודדת את שמות הקבצים במערכת הקבצים שלה על ידי שימוש ב־UTF-8 המותאם ליוניקוד מופרד קנונית.
לעיתים מתייחסים לגרסה זו של UTF-8 כאל UTF-8-MAC.
ביוניקוד, אם ברצוננו לייצג למשל את האות Ä (האות האנגלית הגדולה A עם שתי נקודות מעליה), נוכל להשתמש בתו היוניקוד U+00C4, שהוא בדיוק האות Ä.
לחלופין, נוכל גם להשתמש בתו U+0041 שהוא התו A (האות האנגלית הגדולה A) ומיד לאחריו לשים את התו U+0308 שהוא הסימן הדיאקריטי שתי נקודות מעל לאות.
בעיקרון תקן היוניקוד קובע חוקים לשילוב סימנים דיאקריטיים.
קיימים בתקן תווים מיוחדים הנקראים תווים משלבים (combining characters).
כתיבת אות ולאחריה תווים משלבים אמורים להוביל להצגת האות עם הניקוד.
מטעמי תאימות לאחור ומסיבות אחרות, חלק מהאותיות עם הניקוד קיימות כתו נפרד ביוניקוד.
תווים אלה נקראים תווים מורכבים מראש (precomposed characters) והתקן קובע גם לאילו תווים הם שקולים.
יוניקוד מופרד, או מפורק, קנונית הוא יוניקוד שבו נאסר השימוש בתווים מורכבים מראש ולכן חייבים להשתמש בשילוב של אותיות וסימנים דיאקריטיים בכל מקום שבו נחוץ תו עם סימן דיאקריטי.
השימוש ביוניקוד מופרד מקל רבות על הליכי מיון אך יוצר בלבול בקרב תוכנות המניחות שתווים מורכבים הם הצורה השכיחה ושילוב של תווים משלבים נעשה רק עבור צירופים מיוחדים.
(זוהי דוגמה להגוון ה־NFD לנירמול טקסט).
קיים דיון נרחב בנושא במסמך Apple Computer's Q&A 1173.
UTF-16 הוא קידוד של כל תו יוניקוד באמצעות קבוצה אחת או שתיים של 16 סיביות, כלומר 2 או 4 בתים לכל תו, בהתאם לתו.
את רוב התווים מקודדים ב־16 סיביות, ורק תווים נדירים והיסטוריים מקודדים ב־32 סיביות.
ב־1990, כאשר הוחל בתקינת תקן יוניקוד לקידוד תווים אחיד, עלה במחשבה כי אין צורך אלא בהרחבת הקידוד לכל תו מבית אחד (8 סיביות) ל־2 בתים (16 סיביות).
קידוד כזה נותן מקום ל־65,536 תווים, והמייסדים של יוניקוד סברו כי מספר זה יספיק.
תוכנן כי אותיות עם אקצנטים והברות קוריאניות יקודדו באמצעות יסודות מתחברים (combining characters), דבר שיחסוך במקומות, וכי תווים היסטוריים (כגון גותית ואוגריתית) יקודדו בתוך אזור השימוש הפרטי (private use area) של יוניקוד, במקומות U+A000 עד U+FAFF (מספרים הקסדצימליים).
כך היה המצב בגרסה 1 של תקן יוניקוד.
ברם, כעבור כמה שנים השתנו הדברים תכלית שינוי.
לצורך תאימות לאחור הוחלט על הקצאת מקומות לתווים מחוברים, כלומר במקום לקודד את האות ē כשני תווים, האות e ולאחריה קו עליון מתחבר, לקודד את כל הסימן הזה כתו אחד.
כך עלה הצורך להקצות אלפי קודים לקידוד ההברות הקוריאניות (אשר הועברו למקומות U+AC00 עד U+D7FF, ואזור השימוש הפרטי הועבר ל־U+D800 עד U+FAFF), והתחזיות לשימוש העתידי של קידוד 16 סיביות התבדו.
מתכנני יוניקוד הבינו כי 65,536 תווים אינם מספיקים לכל הצרכים, וכך נולד UTF-16, שהוא הרחבה של גרסה 1 של יוניקוד.
הקודים האלה הם U+D800 עד U+DBFF לחצי הראשון ו־U+DC00 עד U+DFFF לחצי השני.
צירוף של קוד מהחצי הראשון ולאחריו קוד מהחצי השני משמש למיעון תו יוניקוד מעבר ל־U+FFFF, כלומר מ־U+10000 עד U+10FFFF.
למשל, הצירוף D84C DFB4 ממען את התו U+233B4 (שהוא סימן סיני נדיר).
מנגנון זה נקרא מנגנון ממלאי המקום או באנגלית surrogates.
תחת קידוד זה, יוניקוד מגרסה 2 ואילך יכול להכיל 1,112,064 תווים, די והותר לכל שימוש עתידי.
בקידוד UTF-16 משתמשים מערכות Windows (החדשות יותר – NT ו־2000 ו־XP) ומצע Java.
אלה השתמשו במקור ביוניקוד המקורי של 16 סיביות ועברו ל־UTF-16 לאחר מכן.
ב־Windows ניתן לאחסן קובצי טקסט בקידוד UTF-16 או UTF-8, אך בזיכרון יימצא הטקסט תמיד כ־UTF-16. ב־Windows הבתים יופיעו בסדר little-endian, בשל השימוש של מעבדי אינטל בסדר זה, ואילו ב־Java הם יהיו בסדר big-endian.
השפעה על קידודי יוניקוד האחרים
תקן ISO 10646, שהיה תחילה נפרד מיוניקוד אך אוחד איתו אחר־כך, מכיל צורת קידוד של 32 סיביות לכל תו היכולה למען מספר זהה לזה של UTF-8. ואולם, כאשר UTF-16 פורסם, הוחלט כי תקני יוניקוד ו־ISO 10646 יגבילו את תחום התווים עד לתחום האפשרי של UTF-16, כלומר עד U+10FFFF.
כתוצאה מכך, צורות הקידוד האחרות של יוניקוד, UTF-8 (אחד עד ארבעה בתים לכל תו) ו־UTF-32 (ארבעה בתים לכל תו), מוגבלות בגרסאות הנוכחיות של יוניקוד למיעון של קצת יותר ממיליון תווים, על אף שהן יכולות באופן עקרוני למען למעלה משני מיליארד תווים.
הקידוד שומר את מספרו המייצג של התו בייצוג בינארי באורך 32 סיביות.
לדוגמה, התו A מקודד כ־0x00000041 (בהקסדצימלית), התו π כ־0x000003C0 והתו הסיני הנדיר 𣎴 שמספרו ביוניקוד U+233B4 כ־0x000233B4. יתרונו הגדול ביותר של UTF-32 הוא פשטותו, אך היא גם מקור כל חסרונותיו.
לכן, UCS-4 יכולה לקודד עד 2,147,483,648 תווים, ואילו UCS-2 יכולה לקודד רק את 65,536 התווים הראשונים, המכונים המשטח הרב־לשוני הבסיסי.
בשנת 1991 אוחד המשטח הרב־לשוני הבסיסי של ISO 10646 עם 65,536 התווים של תקן אחר למפת תווים אוניברסלית, אז יוניקוד בגרסתו הראשונה.
UCS-2, אפוא, היה זהה ליוניקוד.
תקן ISO 10646 שמר על קידוד UCS-4 באופן רשמי, אך הכול הניחו כי לא יהיה לו שימוש, משום שלא יהיה צורך ביותר מ־65,536 מקומות.
כעבור שנים התבדתה תחזית זו ותקן יוניקוד הורחב מעבר ל־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 בתים.
אין צורך בביצוע כל פעולה שהיא על הבתים או על המספרים פרט לכתיבת המספר בעת הקידוד וקריאתו בעת הפענוח.
מרבית התווים בשימוש נמצאים במשטח הרב־לשוני הבסיסי (ערכיהם ביוניקוד נעים בטווח שבין 0x0000 ל־0xFFFD) וניתן לייצגם באמצעות בית אחד או שני בתים.
UTF-32 כופה שימוש של ארבעה בתים לכל תו ולכן מגדיל את תפוסת הזיכרון בסדר גודל של פי שניים עד פי ארבעה.
UTF-32 אינה עמידה בפני איבוד בתים במהלך שליחה.
אם מסיבות אלו או אחרות אבד בית מסוים (למשל במהלך שליחה ברשת), אזי במהלך הפענוח יחולקו הבתים לרביעיות בצורה שונה והטקסט כולו יוצג בדרך לא נכונה.
אין תאימות לאחור עם ASCII.
טקסט שנכתב ב־ASCII או באחד מקידוד ISO-8859, אינו קריא באמצעות קידוד זה.
היות שקידוד UTF-32 תופס משאבים רבים (פי שניים מ־UTF-16 ברוב המקרים, ופי ארבעה מקידודים ישנים כמו ASCII ו־ISO 8859), אין הוא נמצא כמעט בשימוש.