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