utf8 output from mysql

Q&A's, tips, howto's
Locked
denis
Posts: 20
Joined: Wed Apr 27, 2011 12:19 pm
Location: Petsamo, Murmansk, RU

utf8 output from mysql

Post by denis »

Good night everyone!

I am trying to port my website and cms from tomcat/java to dragonfly/newlisp. The site is in Russian (cyrillic), so the problem: when I retrieve data from mysql database and print it through dragonfly's view I get this: "\208\148\208\183\195\166\209\131\208\180\208\182\209\139\209\133\209\138\195\166\209\131" instead of "Дзæуджыхъæу" (as an example).

I use mysql.lsp module of newlisp. The default encoding of mysql database is utf8, encoding of page in browser is also utf8. The same result (two-byte code in numbers, but not symbols themeselves) I have got when I used postgresql database with postgres.lsp.

My question is: did I miss something very trivial, or I will have to change mysql.lsp in some way?

If you can give me some hint? Thank you in advance!

Denis

Lutz
Posts: 5289
Joined: Thu Sep 26, 2002 4:45 pm
Location: Pasadena, California
Contact:

Re: utf8 output from mysql

Post by Lutz »

Perhaps you are missing a: http-equiv="Content-Type" content="text/html; charset=utf-8" declaration in the META tag header of the HTML page you are displaying. When you print that number-string to an UTF-8 able medium you will see UTF-8 characters, e.g: when printing to an UTF-8 capable terminal:

Code: Select all

> (println "\208\148\208\183\195\166")
Дзæ
"Дзæ"
> 
... and the same happens with output to a HTML page. 'println' or 'print' will actually output UTF-8 codes, the backslash representation is only the way newLISP shows character codes > 127 in interactive mode.

I don't think that your problem has anything to do with databases.

Ps: user "itistoday" (one of the authors of the Dragonfly module) may also be able to help you; he is familiar with Cyrillic writing.

denis
Posts: 20
Joined: Wed Apr 27, 2011 12:19 pm
Location: Petsamo, Murmansk, RU

Re: utf8 output from mysql

Post by denis »

Thank you, Lutz!

I have just fixed the problem, but the resolution was not even in the page encoding. Actually, I hadn't Russian (ru_RU.UTF-8) locale being set in the operating system (Linux at VPS). First I installed the Russian locale. Then, before requests to the database I put

Code: Select all

 (set-locale "ru_RU.UTF-8") 
and it solved the problem.

Locked