> > There's no character code in EUC_TW (CNS 11643-1992) > > corresponding to Big5 0xc05c. That's why PostgreSQL complains. > > > But I've created another db using MULE_INTERNAL encoding, the same error > reported, why ?
Since Big5 representation of MULE_INTERNAL is actually "leading character"+EUC_TW. i.e. > Why don't Postgres directly support BIG5 in server side It's because of pury technical reason. Handling those encodings containing bytes < 0x80 in second (or third) byte of a word confuses our SQL parser. I think it's not impossible for the parser to handle Big5, but if we make such a change, the parser would not be able to other encodings. If you have a good idea to overcome these problems, we are wellcome. > as BIG5 is the > main encoding using for Traditional Chinese communities, i.e. HK & > Taiwan ? As EUC_TW do not have complete correspondings char in BIG5, > this will seriously prevent the Traditional Chinese communities for > using Postgresql ! Just a curious. Why do people living in those area prefer Big5 over EUC_TW? I thought EUC_TW (or CNS 11643-1992) was defined by the goverment in Taiwan. Is there any technical superiority in Big5? Or maybe "don't know why but just many peole use Big5":-) -- Tatsuo Ishii ---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
