יום שישי, אפריל 22, 2016

תקלות קידוד שפה בבסיס נתונים PostgreSql.

תקלות קידוד שפה בבסיס נתונים  PostgreSql .

על מנת להקל על הקורא דבר ראשון אם אתה רוצה להמנע מחיים קשים בהקשר של קידוד (ואתה לא על  SQL Server ) המנע מהתקנת השרת על וינדוס. אם אתה לא יכול לפחות המנע ממה שהוא לא SQL_ASCII והשתמש רק בשפה האנגלית.

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

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

אתם מבינים בעולם התוכנה, יש מספר יצרנים לצערי מרמת מערכת ההפעלה ועד שמירת המידע בבסיס הנתונים הנחת הבסיס היא שיש שימוש באנגלית אמריקאית  (אפילו התקן של בסיס הנתונים מתייחס ל ANSI).

מדוע אני בתור איש וינדוס אומר להמנע משימוש בוינדוס כמערכת עבור בסיס נתונים במקרה הזה ?
התמיכה בקידודים ו locale שאינם en_us לדעתי לוקה בחסר, כברירת מחדל אין תמיכה ביוניקוד (צריך להריץ chcp 65001 בשביל להפעיל תמיכה למשל ביניקוד).

כאשר אנו מעבירים מידע  בין תוכנת לקוח לשרת  -  אנו  כפופים  לסוג הקידוד של מערכת הפעלה (מה שידוע כ code page) למאפייני השפה הנוכחים (locale) אופי קידוד המידע שיועבר ממערכת ההפעלה של הלקוח , אופי קידוד המידע בצד שרת ברמת הצד המקבל, אוקי קידוד המידע ברמת מערכת ההפעלה בצד המקבל , אוקי קידוד המידע בתוך בסיס הנתונים עצמו.

בעייה קלאסית כשמתקינים בסיס נתונים היא שימוש בשפה שאינה אנגלית ו Collate ברירת מחדל.

הבעיה היא שבדר"כ יש יותר מדרך אחת להציג מידע ובחירת השפה "עברית" בצד שרת ובחירת שפה "עברית" בצד לקוח לא באמת מחייב שהמידע יעבור תקין.

סיבה קלאסית היא הסתמכות על הקידוד מערכת ההפעלה ושימוש בקידוד ברירת מחדל, כשאנו למשל מדברים על עברית זה יכול להיות : UTF16* , ISO-8859-8, UTF8, CP1255,CP 862 ,ISO646.

ממה שאני ראיתי לרוב באפליקציות מהעשור האחרון דובר על CP122 ו iso8859-8 (לא נתקלתי במצב הגיוני של UTF16 או 8 כברירת מחדל עד היום).

בעולם הוינדוס בשביל לגלות במה משתמשים נשתמש בפקודה CHCP בשביל לגלות על איזה קידוד נמצא המשתמש בחיבור הנוכחי (session).

במידה ונבחרו ברירות מחדל נאלץ לגלות מהו קידוד השרת בsession הנוכחי  (המידע בתוך בסיס הנתונים ומערכת ההפעלה בבסיס הנתונים עצמו) ולנסות לכוון את האפליקציה להשתמש באותו הקידוד (להגדיר chcp זהה) .


אם יש לנו גישה לקוד המקור נוכל להגדיר את הקידוד ברמת ה session (במקרה של ODBC) -
לדוגמה עבור PG ניתן להגדיר את הקידוד בצורה הבאה :

"SET client_encoding= 'UTF8'"

ואז לשלוח את המידע כשהוא עבר קידוד ל UTF8 (כל מחרוזת שנשלח צריכה לעבור קידוד ישירות ל UTF8 לפני ההגעה לקו)

פתרון נוסף הוא בחירת הקידוד ברמת החיבור בהנחה שהדריבר שאנו עובדים איתו תומך בunicode :

std::string url = "odbc:postgresql://url:ip/databse&client_encoding=UTF8"

חשוב לציין שאם מחרוזת החיבור נובעת מ DSN אז אפשר לבצע את ההחלפה גם בתוך ה DSN עצמו.

במידה ומשתמשים ב DSN תחת FreeTDS שם הפרמטר הוא ClientCharset והקידוד הוא לפי iconv ובגרסה הקניינית שם הפרמטר הוא Charset.
אצל אורקל שם הארגומנט הוא DatabaseCharacterSet


במידה במידה ואנו עובדים עם קידוד פנימי של שני בתים (wchar_t/UCS2)  ולא יכולים לשנות את מחרוזת החיבור הוא להחליף את הדריבר הרגיל לדוגמה psqlodbc.so ל psqlodbcw.so) ולהתבסס על המרת ברירת מחדל (בגרסאות ישנות של posgresql הפתרון היה פשוט להשתמש ב UCS2 ל UCS2 אם גם השרת וגם הלקוח הם עובדים על וינדוס).

לפעמים נתפתה פשוט תמיד להשתמש ב UTF8 תמיד ולצפות לטוב, הבעיה (אהם פרל אהם פרל) שלא כל השפות והדריברים תומכים בהמרה בין יוניקוד לשפה הנדרשת (EUC_JP לדוגמה) ואז נצטרך לבצע את ההמרה או באפליקציה שלנו או ברמת הדריבר או לבקש מבסיס הנתונים שלנו לבצע המרה.

המרה  ברמת הפעולה בבסיס הנתונים תראה בערך כך :

convert ( text , 'sourceencoding' , 'destencoding')

הממרה ברמת השפה איתה אנו משתמשים תראה בערך כך :

Perl:
$internalEncoding = decode( 'iso-8859-8', $var );
$result = encode( 'utf-8', $internalEncoding );
Java:
Charset utf8 = Charset.forName("UTF-8");
Charset iso8859_8 = Charset.forName("ISO-8859-8");
CharBuffer data = iso8859_8.decode(inputBuffer);
ByteBuffer output = utf8.encode(data);


iconv - C:

iconv_t cnv = iconv_open("UTF-8", "ISO_8859-8"); if (-1 == cnv) { return ; }
int ret = iconv(cnv, &text_in_8859_8, &length_of_text_in_8859_8, &text_in_utf8, &length_of_text_in_utf8);


אין תגובות:

הוסף רשומת תגובה