1. קידוד PHP שונים כותבים סקריפטים טירון לא אכפת דבר כזה קידוד. לכן, באתרים אתה יכול לפעמים למצוא בלגן...
2. x64 (aka andi)

קידוד PHP שונים

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

במגזר הרוסי לעתים קרובות אתה יכול למצוא את מה שנקרא Windows קידוד. קוראים לזה אחרת: Windows-1251, cp1251 או אפילו ansi. הבא הוא utf-8. אתה יכול גם למצוא את השם Unicode, אבל זה לא לגמרי נכון, שכן Unicode הוא השם הכללי של הקבוצה כולה (utf-8, utf-16, utf-32). ו נדיר מאוד פופולרי הוא koi8-r או פשוט koi-8 - קידוד לינוקס פופולרי פעם. כמובן, אפשר לפגוש משהו אחר במגזר הרוסי, אבל זה די "פינוק" על ידי המחבר.

ההבדל העיקרי בין utf-8 לבין אחרים (בעיקר Windows-1251 ו- koi8-r) הוא האחד האחרון, ומספר התווים המרבי שניתן לייצג באמצעות קידודים אלה מוגבל ל -256. למותר לציין כי להצגה מלאה של טקסט זה לא יכול להיות מספיק. ו עבור HTML התגלה פתרון - השימוש שנקרא mnemonics. לדוגמה:

© - & copy;

מלבד העובדה שכל דמות כזו מתוארת על ידי קבוצת תווים, הקוד הופך לקריא והיצירה עם הטקסט הופכת מורכבת יותר. זה המקום שבו multibyte utf-8 מגיע להצלה. זה מאוד נוח להשתמש באותיות שונות של אלפבית וסמלים שונים בטקסט אחד.

לכן, להגדיר הנוחים ביותר של תנאים ראשוניים הוא כדלקמן: קידוד של מסד הנתונים, סקריפטים PHP ו- HTML דפי / סקריפטים JS צריך להיות זהה. כמובן, אתה יכול להשתמש אלה שונים, אבל במקרה זה יש סיכון להתבלבל. זה לא משנה איזה דף קוד משמש. אם האתר הוא רק עבור קהל דוברי רוסית, Windows-1251 יהיה מספיק. אחרת, utf-8 תהיה הבחירה ההגיונית. האפשרות הראשונה ברורה פחות או יותר. קידוד multibyte ידרוש כמה מחוות.

בעת עבודה עם utf-8, פנקס רשימות רגיל לא יעבוד ! העובדה היא כי עורך זה, בעת שמירת קובץ קידוד זה, מוסיף חתימה על ההתחלה - 3 תווים, מה שנקרא bom (סימן הזמנה בייט), אשר ניתן להשתמש בהם כדי לקבוע את הקידוד בעת פתיחת קובץ. עדיף לבחור עורך אחר: לא או Notepad + + . בהגדרות עליך לבחור לשמור ללא חתימה.

השלב החשוב הבא הוא עבודה עם מסד הנתונים. רצוי מאוד שהקידוד של בסיס / טבלה / שדה טקסט תואם את קידוד התסריט (זה יכול להיות cp1251 או utf-8, או משהו אחר). אם הנתונים ממסד הנתונים מתקבלים בצורה של "zyuk", סביר להניח שהקידוד של הקשר שונה מהנתונים המאוחסנים במאגר. השאילתה הבאה תסייע להתגבר על המצב (לבצע מיד לאחר התחברות למסד הנתונים):

אם האתר משתמש ב- Windows-1251, עליך לציין אותו - cp1251.

באופן כללי, אין שום דבר קשה. רק, את הפונקציות תקן PHP לא נועדו לעבוד עם מחרוזות multibyte. אבל יש ספריות סטנדרטיות שיסייעו לתקן את המצב: סמל ו mbstring . עבור ביטויים רגולריים, יש גם מתג הכרחי שמופעל עם התכונה u .

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

header ('Content-Type: text / html; charset = utf-8');

אם נעשה שימוש בקידוד בודד, הערך עבור התווים יהיה שונה - Windows-1251 . לאחר מכן, בעיות לא צריך להישאר.

כמה דוגמאות פשוטות ביותר לעבודה עם utf-8 ב- PHP:

דוגמה 1: iconv, מספר התווים בשורה

$ s = 'string'; # מחרוזת ב- utf-8 $ cnt1 = strlen ($ s); # יכיל את הערך 12 $ cnt2 = iconv_strlen ($ s, 'UTF-8'); # ערך נכון, 6

דוגמא 2: mbstring, מספר התווים במחרוזת

$ s = 'string'; # מחרוזת ב- utf-8 $ cnt1 = strlen ($ s); # יכיל את הערך 12 $ cnt2 = mb_strlen ($ s, 'UTF-8'); # ערך נכון, 6

דוגמה 3: ביטויים רגולריים, חיפוש והחלפה

$ s = 'מחרוזות'; # line ב- utf-8 $ s = preg_replace ('/ p / i', 'd', $ s); # תחליף לא יקרה $ s = preg_replace ('/ p / iu', 'd', $ s); # תוצאה עגן מילה

את i משנה קובע את מקרה חסר רגישות החיפוש, ואת u משנה אומר מנוע ביטוי רגיל לעבוד עם utf-8 מחרוזות.

אם מישהו אומר כי PHP לא יכול לעבוד עם utf-8, זה יהיה בסדר. כבר כמה שנים אני עושה את כל הפרויקטים שלי בקידוד הזה ולא היו שום בעיות בכלל. מנועי החיפוש עצמם השתמשו זה זמן רב קידוד נפלא זה.

מוציא לאור

לא מחובר 11 שעות

x64 (aka andi)

הערות: 2846 פרסומים: 395 רישום: 02-04-2009