Re: International support

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

In response to

Browse pgsql-general by date

  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