Re: International support

I just want to say thanks to all those who responded. I'm starting to
understand things well enough now.

My only big question left unanswered is how the client's browser decides
which encoding to use. I'm guessing that their browser determines this by
something in the document's header or a META tag - assuming they set it to
Auto detect. If they force it to SJIS, for example, could they potentially
cause problems?

So I believe the following solution will work:

- Use Unicode support in postgres for storing data.
- Use the php functions: pg_set_client_encoding to resolve the issue of
converting unicode to JIS or SJIS in the case of email and iMode.
- request that all clients browsers use Unicode and not SJIS to prevent
the problem with postgres parser (can someone explain how this is done?)
- do all my string manipulation within postgres with stored procedures to
avoid requiring multi-byte string functions within PHP

I want to avoid switching to php3-i18n because I've already done a lot of
the project in PHP4 and make extensive use of its sessions. I can meet the
project's needs by using stored procedures and LIKE for what little string
parsing needs to be done.

Not using php-i18n would only have to be the case until a version for php4
comes out (hopefully it will happen). At which point we migrate to it and
enjoy the greater flexibility of being able to handle multi-byte string
parsing and encoding/decoding in PHP instead of just the database.

Unicode seems a better option since ideally we want to support other
languages also - although our immediate needs are strictly to make Japanese
character sets work.