From: | Karel Zak <zakkr(at)zf(dot)jcu(dot)cz> |
---|---|
To: | Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp> |
Cc: | dfunct(at)telus(dot)net, pgsql-general(at)postgresql(dot)org |
Subject: | Re: International support |
Date: | 2001-02-23 10:05:57 |
Message-ID: | 20010223110557.A31231@ara.zf.jcu.cz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Zak McGregor | 2001-02-23 11:34:06 | Using NULL values in calculated results |
Previous Message | Renaud Tthonnart | 2001-02-23 09:40:30 | Re: Query with multiples operators BETWEEN |