Re: UTF-8 encoding question regarding PhpPgAdmin development
От | Peter Eisentraut |
---|---|
Тема | Re: UTF-8 encoding question regarding PhpPgAdmin development |
Дата | |
Msg-id | Pine.LNX.4.44.0301071909100.29178-100000@localhost.localdomain обсуждение исходный текст |
Ответ на | UTF-8 encoding question regarding PhpPgAdmin development (Jean-Michel POURE <jm.poure@freesurf.fr>) |
Ответы |
Re: UTF-8 encoding question regarding PhpPgAdmin development
Re: UTF-8 encoding question regarding PhpPgAdmin |
Список | pgsql-hackers |
Jean-Michel POURE writes: > - Are some database encodings not translatable into UTF-8 using SET > CLIENT_ENCODING = 'Unicode'. It used to be the case for Latin1, but it has > been fixed now. It should be possible. If not, it's a bug. > - Some letters, like the euro sign, do not belong to Latin1. Example: let's > say we have a Latin1 database and use SET CLIENT_ENCODING = 'Unicode'. If I > input a euro sign, does it get rejected by PostgreSQL? Currently, it gives you a warning and ignores the character. Not sure that is ideal. > - More generaly, is it safe to convert an Encoding (ex: Latin1 or Chinese > multi-byte) into UTF-8 using SET CLIENT_ENCODING? Can all multi-byte > encodings be converted into/from UTF-8 safely? Some points to keep in mind: Some character sets contain characters that are not in Unicode, although you might choose to ignore that fact because it is of relatively minor importance. Round-trip conversion is not safely possible, so if your tool provides a read/edit/write tool then you will have problems. Finally, when you display East Asian characters you will have a font problem because the Chinese, Japanese, and Korean characters are mapped to the same range in Unicode but you are supposed to use country-specific glyphs. In short, I don't think what you are trying to do is easily achievable. -- Peter Eisentraut peter_e@gmx.net
В списке pgsql-hackers по дате отправления: