> 1. How can I copy(or backup) mule-internal encoded data. Mule-Internal
> is for just back-end. If there is a table that have rows in many
> different kind of language. I think, I could not back it up. Am I wrong?
Just do it. You can use copy, pg_dump etc as ordinary encodings. The
result would be a mule_internal text file. Even you could view it
using the famous multilingual editor, mule.
> 2. I think Unicode is better then mule-internal. So, I will use unicode
> encoding as soon as postgresql support automatic unicode translation. At
> that time, should I translate mule-internal encoded table to unicode. (
> I know there is positive side in mule-internal. One is It store string
> with it's char set code. So I can distinguish the original char set of
> character string. Another is postgresql use UTF-8 to store Unicode data.
> It has a lot of over head when you encode CJK char. string.)
Yes, once we translate CJK encoding to Unicode, we could not translate
it back to the original encoding unless we have separate
information. That's the big problem with Unicode.
> 3. I don't know how postgresql sort mule-internal encoded data. Mule-
> internal is not another char set. It just store 2 byte char with it's
> char set code. I mean it store 1 character(2bytes) in 3 bytes. I just
> guess, postgresql may sort data by it's char set, first.
Your guess is almost correct. Each mule_internal letter has a "leading
character" (1 byte) first, then actual charset data (variable length
bytes, 1 to 4 depending on its charset) follows. So sorting would
tend to take charsets having smaller leading charcters first. The
order could be roughly:
ASCII ISO8859 Chinese Japanese Korean...
See src/include/mb/pg_wchar.h for more details.
--
Tatstuo Ishii