| From: | David Wheeler <david(at)kineticode(dot)com> | 
|---|---|
| To: | Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp> | 
| Cc: | rees(at)ddcom(dot)co(dot)jp, pgsql-general(at)postgresql(dot)org | 
| Subject: | Re: UTF-8 and LIKE vs = | 
| Date: | 2004-08-26 16:39:23 | 
| Message-ID: | 7C851F6A-F77E-11D8-BD80-000393D9369E@kineticode.com | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-general | 
On Aug 24, 2004, at 7:21 PM, Tatsuo Ishii wrote:
> I don't know exactly what kind of encodings you wish to use, but I
> think MULE_INTERNAL might help you. It's actually mixture of various
> encodings with encoding-prefix added to each letter.  For example if
> you can mix KS5601 (Korean) and Japanese Kanji (JIS X0208) in a *same*
> column. So if you don't have problem with sorting KS5601/JIS X0208
> with C locale, you should not have problem with MULE_INTERNAL too in
> theory.
MULE_INTERNAL? Is that a locale?
> Remaining problem is how to display the Korean-Japanese mixed string
> in your client, but this is not PostgreSQL's problem, of
> course. However you could write your own conversion function
> MULE_INTERNAL <--> UTF-8, and might be able to solve the problem.
Well, the strings aren't usually mixed, but there can be different 
languages in different rows. For example, I have a customer with a 
single Bricolage instance in which they manage content in all of the 
following languages:
   Burmese
   Cantonese
   English
   Korean
   Khmer
   Lao
   Mandarin
   Tibetan
   Uyghur
   Vietnamese
And they might do a search that returns results in more than one of 
these languages.
Regards,
David
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David Wheeler | 2004-08-26 16:41:07 | Re: UTF-8 and LIKE vs = | 
| Previous Message | David Wheeler | 2004-08-26 16:36:20 | Re: UTF-8 and LIKE vs = |