היום נדבר על מאיפה מגיעים krakozyabrs באתר ובתוכניות, אילו קידודי טקסט קיימים ובאילו יש להשתמש. בואו נסתכל מקרוב על היסטוריית הפיתוח שלהם, החל מ-ASCII בסיסי, כמו גם בגרסאות המורחבות שלו CP866, KOI8-R, Windows 1251 וכלה בקידוד קונסורציום Unicode המודרני UTF 16 ו-8. תוכן העניינים:
לחלק מהמידע הזה אולי נראה מיותר, אבל האם תדע כמה שאלות אני מקבל ספציפית לגבי ה-krakozyabrs הזוחלים (קבוצת תווים בלתי קריא). עכשיו תהיה לי הזדמנות להפנות את כולם לטקסט של מאמר זה ולמצוא את הטעויות שלי. ובכן, התכוננו לקלוט את המידע ונסו לעקוב אחר זרימת הסיפור.
ASCII - קידוד טקסט בסיסי עבור האלפבית הלטיני
הפיתוח של קידודי טקסט התרחש במקביל להיווצרות תעשיית ה-IT, ובמהלך תקופה זו הם הצליחו לעבור לא מעט שינויים. היסטורית, הכל התחיל עם EBCDIC, שהיה די דיסוננטי בהגייה הרוסית, מה שאפשר לקודד אותיות באלפבית הלטיני, ספרות ערביות וסימני פיסוק עם תווי בקרה. אבל עדיין, נקודת המוצא לפיתוח קידודי טקסט מודרניים צריכה להיחשב כ- ASCII המפורסם (קוד אמריקאי סטנדרטי להחלפת מידע, שברוסית מבוטא בדרך כלל כ"שאל"). הוא מתאר את 128 התווים הראשונים בשימוש הנפוץ ביותר על ידי משתמשים דוברי אנגלית - אותיות לטיניות, ספרות ערביות וסימני פיסוק. 128 התווים המתוארים ב-ASCII כללו גם כמה תווי שירות כגון סוגריים, סימני גיבוב, כוכביות וכו'. למעשה, אתם יכולים לראות אותם בעצמכם: אלו 128 התווים מהגרסה המקורית של ASCII שהפכו לסטנדרט, ובכל קידוד אחר בהחלט תמצאו אותם והם יופיעו בסדר הזה. אבל העובדה היא שבעזרת בית אחד של מידע אתה יכול לקודד לא 128, אלא עד 256 ערכים שונים (שניים בחזקת שמונה שווה 256), לכן, לאחר הגרסה הבסיסית של Asuka, שלם הופיעה סדרה של קידודי ASCII מורחבים , שבהן ניתן היה, בנוסף ל-128 התווים הבסיסיים ניתן לקודד גם באמצעות תווי קידוד לאומי (לדוגמה, רוסית). כאן, כנראה שכדאי לומר קצת יותר על מערכות המספרים המשמשות בתיאור. ראשית, כפי שכולכם יודעים, מחשב עובד רק עם מספרים במערכת הבינארית, כלומר עם אפסים ואחדים ("אלגברה בוליאנית", אם מישהו למד את זה במכון או בית ספר). בית אחד מורכב משמונה ביטים, שכל אחד מהם מייצג שתיים בחזקת שתיים, החל מאפס, ועד שניים עד שביעי: לא קשה להבין שכל השילובים האפשריים של אפסים ואחדים בבנייה כזו יכולים רק להיות 256. המרת מספר מהשיטה הבינארית לעשרונית היא די פשוטה. אתה רק צריך לחבר את כל הכוחות של שניים עם אחדים מעליהם. בדוגמה שלנו, זה מתברר כ-1 (2 בחזקת אפס) ועוד 8 (שתיים בחזקת 3), פלוס 32 (שתיים בחזקת חמישית), פלוס 64 (בחזקת שישית), ועוד 128 (בחזקה שביעית). סך הכל הוא 233 בסימון עשרוני. כפי שאתה יכול לראות, הכל מאוד פשוט. אבל אם תסתכל מקרוב על הטבלה עם תווי ASCII, תראה שהם מיוצגים בקידוד הקסדצימלי. לדוגמה, "כוכבית" מתאימה למספר ההקסדצימלי 2A ב-Aski. אתה בטח יודע שבמערכת המספרים ההקסדצימליים, בנוסף למספרים הערביים, משתמשים גם באותיות לטיניות מ-A (פירושו עשר) עד F (פירושו חמש עשרה). ובכן, להמיר מספר בינארי להקסדצימלילפנות לשיטה הפשוטה הבאה. כל בייט של מידע מחולק לשני חלקים של ארבעה ביטים. הָהֵן. בכל חצי בייט ניתן לקודד רק שישה עשר ערכים (שתיים בחזקת רביעית) בבינארי, שניתן לייצג בקלות כמספר הקסדצימלי. יתרה מכך, בחצי השמאלי של הבתים, יהיה צורך לספור שוב את המעלות החל מאפס, ולא כפי שמוצג בצילום המסך. כתוצאה מכך, אנו מקבלים כי המספר E9 מקודד בצילום המסך. אני מקווה שהמהלך של ההיגיון שלי והפתרון לחידה הזו היו ברורים לך. ובכן, עכשיו בואו נמשיך, למעשה, לדבר על קידוד טקסט.
גרסאות מורחבות של Asuka - קידודי CP866 ו-KOI8-R עם פסוודוגרפיה
אז, התחלנו לדבר על ASCII, שהיה, כביכול, נקודת המוצא לפיתוח כל הקידוד המודרני (Windows 1251, Unicode, UTF 8). בתחילה, הוא הכיל רק 128 תווים של האלפבית הלטיני, ספרות ערביות ועוד משהו, אך בגרסה המורחבת ניתן היה להשתמש בכל 256 הערכים שניתן לקודד בבייט אחד של מידע. הָהֵן. אפשר היה להוסיף סמלים של אותיות בשפה שלך לאסקי. כאן נצטרך לסטות שוב כדי להסביר מדוע יש צורך בכלל בקידוד טקסט ומדוע זה כל כך חשוב. התווים על מסך המחשב שלך נוצרים על בסיס שני דברים - סטים של צורות וקטוריות (ייצוגים) של תווים שונים (הם נמצאים בקבצים עם פונטים שמותקנים במחשב שלך) וקוד שמאפשר לך לשלוף בדיוק את זה מקבוצה זו של צורות וקטוריות (קובץ גופן). סמל שיהיה צורך להכניס במקום הנכון. ברור שהגופנים עצמם אחראים לצורות הווקטוריות, אבל מערכת ההפעלה והתוכנות המשמשות בה אחראיות על הקידוד. הָהֵן. כל טקסט במחשב שלך יהיה קבוצה של בתים, שכל אחד מהם מקודד תו בודד של הטקסט הזה. התוכנה שמציגה את הטקסט הזה על המסך (עורך טקסט, דפדפן וכו'), בעת ניתוח הקוד, קוראת את הקידוד של התו הבא ומחפשת את הצורה הווקטורית המתאימה בקובץ הגופן הנדרש, המחובר כדי להציג זאת. מסמך טקסט. הכל פשוט ובנאלי. משמעות הדבר היא שכדי לקודד כל תו שאנו צריכים (לדוגמה, מהאלפבית הלאומי), יש לעמוד בשני תנאים: הצורה הווקטורית של תו זה חייבת להיות בגופן המשמש, ותו זה יכול להיות מקודד בקידודי ASCII מורחבים בבייט אחד. לכן, יש חבורה שלמה של אפשרויות כאלה. רק עבור קידוד תווים בשפה הרוסית, ישנם מספר סוגים של Aska מורחבת. לדוגמה, CP866 הופיע במקור , שהיה לו את היכולת להשתמש בתווים מהאלפבית הרוסי, וזו הייתה גרסה מורחבת של ASCII. כלומר, החלק העליון שלו עלה בקנה אחד לחלוטין עם הגרסה הבסיסית של Aska (128 תווים לטיניים, מספרים ועוד שטויות), שמוצגת בצילום המסך ממש למעלה, אבל לחלק התחתון של הטבלה עם קידוד CP866 היה המראה המצוין ב- צילום מסך ממש מתחת ומותר לקודד עוד 128 תווים (אותיות רוסיות וכל מיני פסאודו-גרפיקה): אתה רואה, בעמודה הימנית המספרים מתחילים ב-8, כי מספרים מ-0 עד 7 מתייחסים לחלק הבסיסי של ASCII (ראה צילום מסך ראשון). לפיכך, האות הקירילית "M" ב-CP866 תהיה בעלת הקוד 9C (היא ממוקמת במפגש של הישר המתאים עם 9 ועמודה עם המספר C במערכת המספרים ההקסדצימליים), אותו ניתן לכתוב בבייט אחד של מידע , ואם יש גופן מתאים עם תווים רוסיים אות זו תופיע בטקסט ללא בעיות. מאיפה הגיע הסכום הזה?פסאודוגרפיה ב-CP866 ? כל העניין הוא שהקידוד הזה עבור טקסט רוסי פותח עוד בשנים הדביליות שבהן מערכות הפעלה גרפיות לא היו נפוצות כפי שהן עכשיו. וב-Dosa ובמערכות הפעלה טקסט דומות, הפסבדוגרפיה אפשרה לפחות איכשהו לגוון את עיצוב הטקסטים, ולכן CP866 וכל שאר עמיתיו מקטגוריית הגרסאות המורחבות של Asuka שופעות בו. CP866 הופץ על ידי IBM, אך בנוסף לכך פותחו מספר קידודים עבור תווים בשפה הרוסית, לדוגמה, ניתן לייחס את KOI8-R לאותו סוג (ASCII מורחב) : עקרון הפעולה שלו נשאר זהה כמו זה של CP866 שתואר קצת קודם לכן - כל תו של טקסט מקודד כבייט בודד אחד. צילום המסך מציג את המחצית השנייה של טבלת KOI8-R, כי המחצית הראשונה תואמת לחלוטין לאסוקה הבסיסית, שמוצגת בצילום המסך הראשון במאמר זה. בין המאפיינים של קידוד KOI8-R, ניתן לציין שהאותיות הקיריליות בטבלה שלו אינן בסדר אלפביתי, כפי שנעשה ב-CP866. אם תסתכל על צילום המסך הראשון (של החלק הבסיסי, הכלול בכל הקידוד המורחב), תבחין שב-KOI8-R אותיות רוסיות ממוקמות באותם תאים של הטבלה כמו האותיות המתאימות באלפבית הלטיני מהחלק הראשון של הטבלה. זה נעשה למען הנוחות של המעבר מתווים רוסיים ללטיניים על ידי ביטול רק סיביות אחת (שתיים לחזקה שביעית או 128).
Windows 1251 - הגרסה המודרנית של ASCII ולמה הסדקים יוצאים
המשך הפיתוח של קידודי טקסט נבע מהעובדה שמערכות הפעלה גרפיות צברו פופולריות והצורך להשתמש בהן בפסוודוגרפיה נעלם עם הזמן. כתוצאה מכך, קמה קבוצה שלמה שבעצם היו עדיין גרסאות מורחבות של Asuka (תו אחד של טקסט מקודד עם רק בית אחד של מידע), אך ללא שימוש בסמלים פסאודוגרפיים. הם היו שייכים למה שנקרא קידודי ANSI, שפותחו על ידי מכון התקנים האמריקאי. בשפה המקובלת, השם קירילי שימש גם עבור הגרסה עם תמיכה בשפה הרוסית. דוגמה לכך תהיה Windows 1251 . זה היה שונה לטובה מה-CP866 ו-KOI8-R ששימשו בעבר בכך שאת מקומם של סמלים פסאודוגרפיים בו תפסו הסמלים החסרים של הטיפוגרפיה הרוסית (למעט סימן ההטעמה), כמו גם סמלים ששימשו בשפות סלאביות רוסית (אוקראינית, בלארוסית וכו'). ): בגלל שפע כזה של קידודים של השפה הרוסית, ליצרני הפונטים ויצרני התוכנה היו כאבי ראש ללא הרף, ואתם ואני, קוראים יקרים, הסתבכנו לעתים קרובות עם אותם באגים ידועים לשמצה כאשר היה בלבול עם הגרסה המשמשת בטקסט. לעתים קרובות מאוד הם יצאו בעת שליחת וקבלה של הודעות בדואר אלקטרוני, מה שגרר יצירת טבלאות המרה מורכבות מאוד, שלמעשה לא יכלו לפתור בעיה זו באופן יסודי, ולעתים קרובות משתמשים השתמשו בתעתיק של אותיות לטיניות לצורך התכתבות. הימנע מהקשקוש הידוע לשמצה בעת שימוש בקידוד רוסי כמו CP866, KOI8-R או Windows 1251. למעשה, הסדקים שהופיעו במקום טקסט רוסי היו תוצאה של שימוש שגוי בקידוד של שפה נתונה, שלא תאם את זה ב שבה הודעת הטקסט הייתה מקודדת במקור. נניח שאם תנסה להציג תווים מקודדים באמצעות CP866 באמצעות טבלת הקוד של Windows 1251, אז אותו ג'יבריש (סט חסר משמעות של תווים) ייצא ויחליף לחלוטין את טקסט ההודעה. מצב דומה מתעורר לעתים קרובות מאוד בעת יצירה והגדרה של אתרים, פורומים או בלוגים, כאשר טקסט עם תווים רוסיים נשמר בטעות בקידוד שגוי שמשתמשים בו באתר כברירת מחדל, או בעורך טקסט שגוי, שמוסיף גאג בלתי נראה. לקוד בעין בלתי מזוינת. בסופו של דבר, לאנשים רבים נמאס מהמצב הזה עם הרבה קידודים ושטויות מתגנבות כל הזמן, והתנאים המוקדמים הופיעו ליצירת וריאציה אוניברסלית חדשה שתחליף את כל הקיימים ותפתור את הבעיה עם הופעת טקסטים בלתי קריאים . בנוסף, הייתה הבעיה של שפות כמו סינית, שבהן היו הרבה יותר תווי שפה מ-256.
Unicode - קידודים אוניברסליים UTF 8, 16 ו-32
לא ניתן היה לתאר את אלפי התווים הללו של קבוצת השפות בדרום מזרח אסיה בבייט אחד של מידע שהוקצה לקידוד תווים בגרסאות מורחבות של ASCII. כתוצאה מכך, קונסורציום בשם Unicode (Unicode Consortium) נוצר בשיתוף פעולה של מובילי תעשיית IT רבים (אלה שמייצרים תוכנה, המקודדים חומרה, היוצרים גופנים) שהתעניינו בהופעתו של קידוד טקסט אוניברסלי. הווריאציה הראשונה שפורסמה בחסות קונסורציום Unicode הייתה UTF 32 . המספר בשם הקידוד פירושו מספר הביטים המשמשים לקידוד תו אחד. 32 ביטים שווים ל-4 בתים של מידע שיידרשו כדי לקודד תו בודד אחד בקידוד ה-UTF האוניברסלי החדש. כתוצאה מכך, אותו קובץ עם טקסט מקודד בגרסה המורחבת של ASCII וב-UTF-32, במקרה האחרון, יהיה בגודל (משקל) גדול פי ארבעה. זה רע, אבל עכשיו יש לנו הזדמנות לקודד באמצעות UTF מספר תווים השווים לשניים בחזקת שלושים ושניים ( מיליארדי תווים שיכסו כל ערך הכרחי באמת עם מרווח אדיר). אבל מדינות רבות עם שפות של הקבוצה האירופית לא היו צריכים להשתמש במספר עצום כזה של תווים בקידוד בכלל, עם זאת, בעת שימוש ב-UTF-32, הם ללא סיבה קיבלו עלייה של פי ארבע במשקל של מסמכי טקסט, וכתוצאה מכך, עלייה בנפח התעבורה באינטרנט ובנפח הנתונים המאוחסנים. זה הרבה, ואף אחד לא יכול היה להרשות לעצמו בזבוז כזה. כתוצאה מהפיתוח של Unicode, הופיע UTF-16 , שהתברר כמוצלח כל כך עד שהוא אומץ כברירת מחדל כמרחב הבסיס לכל התווים שבהם אנו משתמשים. הוא משתמש בשני בתים כדי לקודד תו אחד. בוא נראה איך הדבר הזה נראה. במערכת ההפעלה Windows, אתה יכול לעקוב אחר הנתיב "התחל" - "תוכניות" - "אביזרים" - "כלי מערכת" - "טבלת תווים". כתוצאה מכך, תיפתח טבלה עם הצורות הווקטוריות של כל הגופנים המותקנים במערכת שלך. אם תבחר בערכת התווים Unicode ב"אפשרויות מתקדמות", תוכל לראות עבור כל גופן בנפרד את כל מגוון התווים הכלולים בו. אגב, על ידי לחיצה על כל אחת מהן, תוכל לראות את קוד שני הבייטים שלו בפורמט UTF-16 , המורכב מארבע ספרות הקסדצימליות: כמה תווים ניתן לקודד ב-UTF-16 באמצעות 16 סיביות? 65,536 (שניים בחזקת שש עשרה), וזה המספר שאומץ כמרחב הבסיס ביוניקוד. בנוסף, ישנן דרכים לקודד כשני מיליון תווים באמצעותו, אך הן הוגבלו למרחב מורחב של מיליון תווים של טקסט. אבל גם הגרסה המוצלחת הזו של קידוד Unicode לא הביאה סיפוק רב למי שכתב, נניח, תוכניות רק באנגלית, כי לאחר המעבר מהגרסה המורחבת של ASCII ל-UTF-16, משקל המסמכים הוכפל (בייט אחד לכל תו ב-Aski ושני בתים עבור אותו תו ב-YUTF-16). בדיוק כדי לספק את כולם וכולם בקונסורציום Unicode, הוחלט להמציא קידוד באורך משתנה . זה נקרא UTF-8. למרות השמונה בשם, יש לו למעשה אורך משתנה, כלומר. ניתן לקודד כל תו של טקסט לרצף של אחד עד שישה בתים באורך. בפועל, UTF-8 משתמש רק בטווח שבין אחד לארבעה בתים, כי מעבר לארבעה בתים של קוד כבר אי אפשר אפילו תיאורטית לדמיין משהו. כל התווים הלטיניים שבו מקודדים לבייט אחד, בדיוק כמו ב-ASCII הישן והטוב. מה שראוי לציין הוא שבמקרה של קידוד של האלפבית הלטיני בלבד, גם אותן תוכנות שאינן מבינות Unicode עדיין יקראו את מה שמקודד ב-YTF-8. כלומר, החלק הבסיסי של Asuka פשוט הועבר ליצירה זו של קונסורציום Unicode. תווים קיריליים ב-UTF-8 מקודדים בשני בתים, ולדוגמה, תווים גרוזיניים מקודדים בשלושה בתים. קונסורציום Unicode, לאחר יצירת UTF 16 ו-8, פתר את הבעיה העיקרית - כעת יש לנו מרחב קוד יחיד בגופנים שלנו . ועכשיו היצרנים שלהם יכולים למלא אותו רק בצורות וקטוריות של תווי טקסט בהתבסס על החוזקות והיכולות שלהם. ב"טבלת התווים" למעלה ניתן לראות שגופנים שונים תומכים במספר תווים שונים. חלק מהגופנים העשירים ב-Unicode יכולים להיות כבדים למדי. אבל עכשיו הם שונים לא בעובדה שהם נוצרו עבור קידודים שונים, אלא בעובדה שיצרן הגופנים מילא או לא מילא לחלוטין את חלל הקוד הבודד בצורות וקטוריות מסוימות.
מילים מטורפות במקום אותיות רוסיות - איך לתקן את זה
הבה נראה כעת כיצד מופיעים krakozyabrs במקום טקסט או, במילים אחרות, כיצד נבחר הקידוד הנכון עבור טקסט רוסי. למעשה, הוא מוגדר בתוכנית שבה אתה יוצר או עורך את הטקסט הזה, או הקוד באמצעות שברי טקסט. כדי לערוך וליצור קבצי טקסט, אני אישית משתמש בעורך HTML ו-PHP טוב מאוד, לדעתי, Notepad++ . עם זאת, הוא יכול להדגיש את התחביר של מאות שפות תכנות וסימון אחרות, ויש לו גם את היכולת להרחיב באמצעות תוספים. קרא סקירה מפורטת של התוכנית הנפלאה הזו בקישור המצורף. בתפריט העליון של Notepad++ ישנו פריט "קידודים", שבו תהיה לך הזדמנות להמיר אפשרות קיימת לזו שנמצאת בשימוש באתר שלך כברירת מחדל: במקרה של אתר ב-Joomla 1.5 ומעלה, כמו כמו גם במקרה של בלוג על וורדפרס, כדאי להימנע מהמראה Krakozyabrov לבחור באפשרות UTF 8 ללא BOM . מהי הקידומת BOM? העובדה היא שכאשר פיתחו את הקידוד YUTF-16, מסיבה כלשהי הם החליטו לצרף אליו דבר כמו היכולת לכתוב את קוד התווים גם ברצף ישיר (לדוגמה, 0A15) וגם בהיפוך (150A) . וכדי שתוכניות יבינו באיזה רצף לקרוא את הקודים, הומצא ה-BOM (Byte Order Mark או במילים אחרות, חתימה), שהתבטא בהוספת שלושה בתים נוספים ממש בתחילת המסמכים. בקידוד UTF-8, לא סופקו BOMs בקונסורציום Unicode, ולכן הוספת חתימה (אותם שלושה בתים נוספים הידועים לשמצה בתחילת המסמך) פשוט מונעת מתוכניות מסוימות לקרוא את הקוד. לכן, כששומרים קבצים ב-UTF, עלינו לבחור תמיד באפשרות ללא BOM (ללא חתימה). לפיכך, אתה תגן על עצמך מראש מפני זחילה החוצה של krakozyabrs . מה שראוי לציין הוא שחלק מהתוכניות ב-Windows לא יכולות לעשות זאת (הן לא יכולות לשמור טקסט ב-UTF-8 ללא BOM), למשל, אותו פנקס רשימות של Windows הידוע לשמצה. הוא שומר את המסמך ב-UTF-8, אך עדיין מוסיף את החתימה (שלושה בתים נוספים) לתחילתו. יתר על כן, בתים אלו תמיד יהיו זהים - קרא את הקוד ברצף ישיר. אבל בשרתים, בגלל הדבר הקטן הזה, יכולה להיווצר בעיה - נוכלים ייצאו. לכן, אל תשתמש בפנקס רשימות Windows רגיל בשום מקרה.כדי לערוך מסמכים באתר שלך אם אינך רוצה שיופיעו סדקים. אני מחשיב את עורך Notepad++ שכבר הוזכר כאפשרות הטובה והפשוטה ביותר, שאין לה כמעט חסרונות והיא מורכבת רק מיתרונות. ב-Notepad++, כאשר תבחרו קידוד, תהיה לכם אפשרות להמיר טקסט לקידוד UCS-2, שקרוב מאוד באופיו לתקן Unicode. גם ב-Notepad ניתן יהיה לקודד טקסט ב-ANSI, כלומר. ביחס לשפה הרוסית, זה יהיה Windows 1251, שכבר תיארנו למעלה, מאיפה המידע הזה? זה רשום ברישום של מערכת ההפעלה Windows שלך - באיזה קידוד לבחור במקרה של ANSI, איזה לבחור במקרה של OEM (לשפה הרוסית זה יהיה CP866). אם תגדיר שפת ברירת מחדל אחרת במחשב שלך, קידודים אלה יוחלפו בקידוד דומים מקטגוריית ANSI או OEM עבור אותה שפה. לאחר שתשמרו את המסמך ב-Notepad++ בקידוד שאתם צריכים או תפתחו את המסמך מהאתר לעריכה, תוכלו לראות את שמו בפינה הימנית התחתונה של העורך: כדי למנוע בלבול , בנוסף לשלבים שתוארו למעלה , יהיה שימושי לכתוב את קוד המקור בכותרת שלו בכל דפי האתר מידע על הקידוד הזה, כך שלא יהיה בלבול בשרת או במארח המקומי. באופן כללי, כל שפות סימון ההיפרטקסט למעט HTML משתמשות בהצהרת xml מיוחדת, המציינת את קידוד הטקסט.
<?xml version="1.0" encoding="windows-1251"?>
לפני ניתוח הקוד, הדפדפן יודע באיזו גרסה משתמשים ואיך בדיוק הוא צריך לפרש את קודי התווים של אותה שפה. אבל מה שראוי לציין הוא שאם שומרים את המסמך בברירת המחדל של Unicode, ניתן להשמיט את הצהרת ה-xml הזו (הקידוד ייחשב ל-UTF-8 אם אין BOM או UTF-16 אם יש BOM). במקרה של מסמך HTML, רכיב Meta משמש לציון הקידוד , אשר ממוקם בין תגיות הפתיחה והסגירה של Head:
<head>...<meta charset="utf-8">...</head>
ערך זה שונה למדי מהתקן ב-Html 4.01, אך תואם באופן מלא לתקן Html 5, והוא יובן כהלכה על ידי כל הדפדפן הנמצא בשימוש כעת. בתיאוריה, אלמנט ה-Meta המציין את הקידוד של מסמך ה-Html ימוקם בצורה הטובה ביותר גבוה ככל האפשר בכותרת המסמך , כך שעד שהטקסט יתקל בתו הראשון שלא מה-ANSI הבסיסי (שתמיד נקרא בצורה נכונה וב- כל וריאציה), לדפדפן כבר אמור להיות מידע על אופן פירוש הקודים של התווים הללו. קישור למקור המקורי: קידוד טקסט ASCII (Windows 1251, CP866, KOI8-R) ו-Unicode (UTF 8, 16, 32) - כיצד לתקן את הבעיה עם קרקרים
אלו 128 התווים מהגרסה המקורית של ASCII שהפכו לסטנדרט, ובכל קידוד אחר בהחלט תמצאו אותם והם יופיעו בסדר הזה. אבל העובדה היא שבעזרת בית אחד של מידע אתה יכול לקודד לא 128, אלא עד 256 ערכים שונים (שניים בחזקת שמונה שווה 256), לכן, לאחר הגרסה הבסיסית של Asuka, שלם הופיעה סדרה של קידודי ASCII מורחבים , שבהן ניתן היה, בנוסף ל-128 התווים הבסיסיים ניתן לקודד גם באמצעות תווי קידוד לאומי (לדוגמה, רוסית). כאן, כנראה שכדאי לומר קצת יותר על מערכות המספרים המשמשות בתיאור. ראשית, כפי שכולכם יודעים, מחשב עובד רק עם מספרים במערכת הבינארית, כלומר עם אפסים ואחדים ("אלגברה בוליאנית", אם מישהו למד את זה במכון או בית ספר). בית אחד מורכב משמונה ביטים, שכל אחד מהם מייצג שתיים בחזקת שתיים, החל מאפס, ועד שניים עד שביעי: 
לא קשה להבין שכל השילובים האפשריים של אפסים ואחדים בבנייה כזו יכולים רק להיות 256. המרת מספר מהשיטה הבינארית לעשרונית היא די פשוטה. אתה רק צריך לחבר את כל הכוחות של שניים עם אחדים מעליהם. בדוגמה שלנו, זה מתברר כ-1 (2 בחזקת אפס) ועוד 8 (שתיים בחזקת 3), פלוס 32 (שתיים בחזקת חמישית), פלוס 64 (בחזקת שישית), ועוד 128 (בחזקה שביעית). סך הכל הוא 233 בסימון עשרוני. כפי שאתה יכול לראות, הכל מאוד פשוט. אבל אם תסתכל מקרוב על הטבלה עם תווי ASCII, תראה שהם מיוצגים בקידוד הקסדצימלי. לדוגמה, "כוכבית" מתאימה למספר ההקסדצימלי 2A ב-Aski. אתה בטח יודע שבמערכת המספרים ההקסדצימליים, בנוסף למספרים הערביים, משתמשים גם באותיות לטיניות מ-A (פירושו עשר) עד F (פירושו חמש עשרה). ובכן, להמיר מספר בינארי להקסדצימלילפנות לשיטה הפשוטה הבאה. כל בייט של מידע מחולק לשני חלקים של ארבעה ביטים. הָהֵן. בכל חצי בייט ניתן לקודד רק שישה עשר ערכים (שתיים בחזקת רביעית) בבינארי, שניתן לייצג בקלות כמספר הקסדצימלי. יתרה מכך, בחצי השמאלי של הבתים, יהיה צורך לספור שוב את המעלות החל מאפס, ולא כפי שמוצג בצילום המסך. כתוצאה מכך, אנו מקבלים כי המספר E9 מקודד בצילום המסך. אני מקווה שהמהלך של ההיגיון שלי והפתרון לחידה הזו היו ברורים לך. ובכן, עכשיו בואו נמשיך, למעשה, לדבר על קידוד טקסט.
אתה רואה, בעמודה הימנית המספרים מתחילים ב-8, כי מספרים מ-0 עד 7 מתייחסים לחלק הבסיסי של ASCII (ראה צילום מסך ראשון). לפיכך, האות הקירילית "M" ב-CP866 תהיה בעלת הקוד 9C (היא ממוקמת במפגש של הישר המתאים עם 9 ועמודה עם המספר C במערכת המספרים ההקסדצימליים), אותו ניתן לכתוב בבייט אחד של מידע , ואם יש גופן מתאים עם תווים רוסיים אות זו תופיע בטקסט ללא בעיות. מאיפה הגיע הסכום הזה?פסאודוגרפיה ב-CP866 ? כל העניין הוא שהקידוד הזה עבור טקסט רוסי פותח עוד בשנים הדביליות שבהן מערכות הפעלה גרפיות לא היו נפוצות כפי שהן עכשיו. וב-Dosa ובמערכות הפעלה טקסט דומות, הפסבדוגרפיה אפשרה לפחות איכשהו לגוון את עיצוב הטקסטים, ולכן CP866 וכל שאר עמיתיו מקטגוריית הגרסאות המורחבות של Asuka שופעות בו. CP866 הופץ על ידי IBM, אך בנוסף לכך פותחו מספר קידודים עבור תווים בשפה הרוסית, לדוגמה, ניתן לייחס את KOI8-R לאותו סוג (ASCII מורחב) : 
עקרון הפעולה שלו נשאר זהה כמו זה של CP866 שתואר קצת קודם לכן - כל תו של טקסט מקודד כבייט בודד אחד. צילום המסך מציג את המחצית השנייה של טבלת KOI8-R, כי המחצית הראשונה תואמת לחלוטין לאסוקה הבסיסית, שמוצגת בצילום המסך הראשון במאמר זה. בין המאפיינים של קידוד KOI8-R, ניתן לציין שהאותיות הקיריליות בטבלה שלו אינן בסדר אלפביתי, כפי שנעשה ב-CP866. אם תסתכל על צילום המסך הראשון (של החלק הבסיסי, הכלול בכל הקידוד המורחב), תבחין שב-KOI8-R אותיות רוסיות ממוקמות באותם תאים של הטבלה כמו האותיות המתאימות באלפבית הלטיני מהחלק הראשון של הטבלה. זה נעשה למען הנוחות של המעבר מתווים רוסיים ללטיניים על ידי ביטול רק סיביות אחת (שתיים לחזקה שביעית או 128).
בגלל שפע כזה של קידודים של השפה הרוסית, ליצרני הפונטים ויצרני התוכנה היו כאבי ראש ללא הרף, ואתם ואני, קוראים יקרים, הסתבכנו לעתים קרובות עם אותם באגים ידועים לשמצה כאשר היה בלבול עם הגרסה המשמשת בטקסט. לעתים קרובות מאוד הם יצאו בעת שליחת וקבלה של הודעות בדואר אלקטרוני, מה שגרר יצירת טבלאות המרה מורכבות מאוד, שלמעשה לא יכלו לפתור בעיה זו באופן יסודי, ולעתים קרובות משתמשים השתמשו בתעתיק של אותיות לטיניות לצורך התכתבות. הימנע מהקשקוש הידוע לשמצה בעת שימוש בקידוד רוסי כמו CP866, KOI8-R או Windows 1251. למעשה, הסדקים שהופיעו במקום טקסט רוסי היו תוצאה של שימוש שגוי בקידוד של שפה נתונה, שלא תאם את זה ב שבה הודעת הטקסט הייתה מקודדת במקור. נניח שאם תנסה להציג תווים מקודדים באמצעות CP866 באמצעות טבלת הקוד של Windows 1251, אז אותו ג'יבריש (סט חסר משמעות של תווים) ייצא ויחליף לחלוטין את טקסט ההודעה. 
מצב דומה מתעורר לעתים קרובות מאוד בעת יצירה והגדרה של אתרים, פורומים או בלוגים, כאשר טקסט עם תווים רוסיים נשמר בטעות בקידוד שגוי שמשתמשים בו באתר כברירת מחדל, או בעורך טקסט שגוי, שמוסיף גאג בלתי נראה. לקוד בעין בלתי מזוינת. בסופו של דבר, לאנשים רבים נמאס מהמצב הזה עם הרבה קידודים ושטויות מתגנבות כל הזמן, והתנאים המוקדמים הופיעו ליצירת וריאציה אוניברסלית חדשה שתחליף את כל הקיימים ותפתור את הבעיה עם הופעת טקסטים בלתי קריאים . בנוסף, הייתה הבעיה של שפות כמו סינית, שבהן היו הרבה יותר תווי שפה מ-256.
כמה תווים ניתן לקודד ב-UTF-16 באמצעות 16 סיביות? 65,536 (שניים בחזקת שש עשרה), וזה המספר שאומץ כמרחב הבסיס ביוניקוד. בנוסף, ישנן דרכים לקודד כשני מיליון תווים באמצעותו, אך הן הוגבלו למרחב מורחב של מיליון תווים של טקסט. אבל גם הגרסה המוצלחת הזו של קידוד Unicode לא הביאה סיפוק רב למי שכתב, נניח, תוכניות רק באנגלית, כי לאחר המעבר מהגרסה המורחבת של ASCII ל-UTF-16, משקל המסמכים הוכפל (בייט אחד לכל תו ב-Aski ושני בתים עבור אותו תו ב-YUTF-16). בדיוק כדי לספק את כולם וכולם בקונסורציום Unicode, הוחלט להמציא קידוד באורך משתנה . זה נקרא UTF-8. למרות השמונה בשם, יש לו למעשה אורך משתנה, כלומר. ניתן לקודד כל תו של טקסט לרצף של אחד עד שישה בתים באורך. בפועל, UTF-8 משתמש רק בטווח שבין אחד לארבעה בתים, כי מעבר לארבעה בתים של קוד כבר אי אפשר אפילו תיאורטית לדמיין משהו. כל התווים הלטיניים שבו מקודדים לבייט אחד, בדיוק כמו ב-ASCII הישן והטוב. מה שראוי לציין הוא שבמקרה של קידוד של האלפבית הלטיני בלבד, גם אותן תוכנות שאינן מבינות Unicode עדיין יקראו את מה שמקודד ב-YTF-8. כלומר, החלק הבסיסי של Asuka פשוט הועבר ליצירה זו של קונסורציום Unicode. תווים קיריליים ב-UTF-8 מקודדים בשני בתים, ולדוגמה, תווים גרוזיניים מקודדים בשלושה בתים. קונסורציום Unicode, לאחר יצירת UTF 16 ו-8, פתר את הבעיה העיקרית - כעת יש לנו מרחב קוד יחיד בגופנים שלנו . ועכשיו היצרנים שלהם יכולים למלא אותו רק בצורות וקטוריות של תווי טקסט בהתבסס על החוזקות והיכולות שלהם. ב"טבלת התווים" למעלה ניתן לראות שגופנים שונים תומכים במספר תווים שונים. חלק מהגופנים העשירים ב-Unicode יכולים להיות כבדים למדי. אבל עכשיו הם שונים לא בעובדה שהם נוצרו עבור קידודים שונים, אלא בעובדה שיצרן הגופנים מילא או לא מילא לחלוטין את חלל הקוד הבודד בצורות וקטוריות מסוימות.
במקרה של אתר ב-Joomla 1.5 ומעלה, כמו כמו גם במקרה של בלוג על וורדפרס, כדאי להימנע מהמראה Krakozyabrov לבחור באפשרות UTF 8 ללא BOM . מהי הקידומת BOM? העובדה היא שכאשר פיתחו את הקידוד YUTF-16, מסיבה כלשהי הם החליטו לצרף אליו דבר כמו היכולת לכתוב את קוד התווים גם ברצף ישיר (לדוגמה, 0A15) וגם בהיפוך (150A) . וכדי שתוכניות יבינו באיזה רצף לקרוא את הקודים, הומצא ה-BOM (Byte Order Mark או במילים אחרות, חתימה), שהתבטא בהוספת שלושה בתים נוספים ממש בתחילת המסמכים. בקידוד UTF-8, לא סופקו BOMs בקונסורציום Unicode, ולכן הוספת חתימה (אותם שלושה בתים נוספים הידועים לשמצה בתחילת המסמך) פשוט מונעת מתוכניות מסוימות לקרוא את הקוד. לכן, כששומרים קבצים ב-UTF, עלינו לבחור תמיד באפשרות ללא BOM (ללא חתימה). לפיכך, אתה תגן על עצמך מראש מפני זחילה החוצה של krakozyabrs . מה שראוי לציין הוא שחלק מהתוכניות ב-Windows לא יכולות לעשות זאת (הן לא יכולות לשמור טקסט ב-UTF-8 ללא BOM), למשל, אותו פנקס רשימות של Windows הידוע לשמצה. הוא שומר את המסמך ב-UTF-8, אך עדיין מוסיף את החתימה (שלושה בתים נוספים) לתחילתו. יתר על כן, בתים אלו תמיד יהיו זהים - קרא את הקוד ברצף ישיר. אבל בשרתים, בגלל הדבר הקטן הזה, יכולה להיווצר בעיה - נוכלים ייצאו. לכן, אל תשתמש בפנקס רשימות Windows רגיל בשום מקרה.כדי לערוך מסמכים באתר שלך אם אינך רוצה שיופיעו סדקים. אני מחשיב את עורך Notepad++ שכבר הוזכר כאפשרות הטובה והפשוטה ביותר, שאין לה כמעט חסרונות והיא מורכבת רק מיתרונות. ב-Notepad++, כאשר תבחרו קידוד, תהיה לכם אפשרות להמיר טקסט לקידוד UCS-2, שקרוב מאוד באופיו לתקן Unicode. גם ב-Notepad ניתן יהיה לקודד טקסט ב-ANSI, כלומר. ביחס לשפה הרוסית, זה יהיה Windows 1251, שכבר תיארנו למעלה, מאיפה המידע הזה? זה רשום ברישום של מערכת ההפעלה Windows שלך - באיזה קידוד לבחור במקרה של ANSI, איזה לבחור במקרה של OEM (לשפה הרוסית זה יהיה CP866). אם תגדיר שפת ברירת מחדל אחרת במחשב שלך, קידודים אלה יוחלפו בקידוד דומים מקטגוריית ANSI או OEM עבור אותה שפה. לאחר שתשמרו את המסמך ב-Notepad++ בקידוד שאתם צריכים או תפתחו את המסמך מהאתר לעריכה, תוכלו לראות את שמו בפינה הימנית התחתונה של העורך: 
כדי למנוע בלבול , בנוסף לשלבים שתוארו למעלה , יהיה שימושי לכתוב את קוד המקור בכותרת שלו בכל דפי האתר מידע על הקידוד הזה, כך שלא יהיה בלבול בשרת או במארח המקומי. באופן כללי, כל שפות סימון ההיפרטקסט למעט HTML משתמשות בהצהרת xml מיוחדת, המציינת את קידוד הטקסט.
GO TO FULL VERSION