Re: International support
От | Karel Zak |
---|---|
Тема | Re: International support |
Дата | |
Msg-id | 20010223110557.A31231@ara.zf.jcu.cz обсуждение исходный текст |
Ответ на | Re: International support (Tatsuo Ishii <t-ishii@sra.co.jp>) |
Список | pgsql-general |
On Fri, Feb 23, 2001 at 10:02:24AM +0900, Tatsuo Ishii wrote: > > I'm currently working a project that is intended to handle Japanese > > character sets - and now I'm told ideally iMode too. :) The iMode isn't > > such an issue at the moment - but the article below has spooked me a > > little. At an early point in the project we tested if putting some input > > into a web form, which ultimately was handled by php then stored in > > postgres would return fully intact - and it did. This left me comfortable > > that PHP and Postgres don't seem to care what language they're storing in > > fields or variables. I'm 'guessing' that this is because the data, whether > > its English or Japanese is being stored in binary (or something > > else?). > I work on same things and (IMHO) is good store data in DB in MULE_INTERNAL encoding (or UNICODE in 7.1) and on-the-fly encode it to EUC_JP or Shift_JIS (for i-mode) or Latin1, because I store to same tables Latin1 English string too :-) During data input is always set correct encoding (EUC or Latin1). Sure for data searching I not use string compare ('like' or '='), but only access by 'id' integer columns - for all is used 'C' not PHP. I know it sound curious, but is better solution for multi-language and multi-encoding data storing in one DB? Our global world needs application like this.... > I believe PostgreSQL's language support is much better than MySQL's > especially for Japanese. PostgreSQL can handle both EUC/SJIS on the > fly (and even Unicode for 7.1!), and has the ability to do an ^^^^^^^^^^^^ Great work! > automatic encoding conversion between them. Moreover, PostgreSQL has > many "multibyte aware" functions including regular expression search, > which MySQL cannot do, I think. Sure, The PostgreSQL is better (and not for this only). Karel
В списке pgsql-general по дате отправления: