On Wed, 18 Nov 2009 14:29:53 -0600 Kenneth Marshall <k...@rice.edu> wrote:
> > Alexander > > > I thought that UTF8, UTF-16 and UTF-32 can represent all the characters. > In that case, why wouldn't you use the UTF8 equivalent? At the least it > would save space. > * UTF-16 and UTF-32 are not widely used. * Wrongly coded UTF-8 can not be 100% saved (without loss) in UTF-16. * The UTF-16 systems I know do not always display stuff in UTF-16 but show the symbol with 8-bit encodings. * I am not aware of much applications using really UTF-16 for encoding. Let alone UTF-32. Out of my mind I can't remember seen any mail application handling UTF-16/UTF-32. * UTF-16 and UTF-32 are not byte oriented and this makes thing really a big pain. It's not easy to handle that everywhere the proper way if the application sending the message is not appending the proper MIME charset (UTF-16E for (big-)endian encoding and UTF-16LE for little-endian). I think in our case we could easy stay on UTF-8. I would say that we should think global (UTF-16/UTF-32) but act local (UTF-8). I think that we could easy handle those non western languages in the UTF-8 character space. I THINK. I am not sure. We should invest more time for that issue. > Ken > -- Kind Regards from Switzerland, Stevan Bajić ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Dspam-devel mailing list Dspam-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspam-devel
