tag:blogger.com,1999:blog-273593670040001243.post1635576312072334772..comments2008-06-08T12:37:17.597-07:00Comments on Useless Factor: A second introduction to UnicodeDaniel Ehrenberghttp://www.blogger.com/profile/00902922561603041049noreply@blogger.comBlogger5125tag:blogger.com,1999:blog-273593670040001243.post-67952858409778559632008-06-08T12:37:00.000-07:002008-06-08T12:37:00.000-07:00Tom,I completely disagree with using wchar_t, sinc...Tom,<BR/><BR/>I completely disagree with using wchar_t, since it's usually 16 bits but at least 21 bits are needed. People end up treating UTF-16 strings (made of wchar_t) as an array of code points, but then there are those surrogate pairs that come up only rarely (but should still be supported). So Joel's post was outdated even when he wrote it, but it's still a good explanation of the history, justification and aims of Unicode.<BR/><BR/>On the other hand, UTF-8 is awkward to read characters from directly compared to indexing an array. I don't see any big need to compress stuff in memory using UTF-8 (which isn't all that good a compression algorithm).<BR/><BR/>I think a fixed-width encoding is easiest to use internally, so it's what I'll use for my own coding (in Factor).Daniel Ehrenberghttp://www.blogger.com/profile/00902922561603041049noreply@blogger.comtag:blogger.com,1999:blog-273593670040001243.post-82210627439153688392008-06-08T12:30:00.000-07:002008-06-08T12:30:00.000-07:00rsamuel,Factor's representation uses 3 bytes per c...rsamuel,<BR/><BR/>Factor's representation uses 3 bytes per code point, put in two arrays, with one that's 8 of the bits and one that's 16 of the bits.Daniel Ehrenberghttp://www.blogger.com/profile/00902922561603041049noreply@blogger.comtag:blogger.com,1999:blog-273593670040001243.post-63984846948939438342008-06-08T10:46:00.000-07:002008-06-08T10:46:00.000-07:00"If you're using C or C++, wchar_t rather than cha..."If you're using C or C++, wchar_t rather than char for strings works for most cases."<BR/><BR/>I'm curious as to what these "most cases" are.<BR/><BR/>First, wchar_t isn't well-defined; on many machines it's 16-bit but certainly not all.<BR/><BR/>That aside, wchar_t is completely incompatible with the standard C library and your standard C/C++ string constants. <BR/><BR/>It's absolutely not a matter of dropping in new code; contemplate that in an ASCII constant, every other byte is 0 so if your code ever relies on "byte 0 means end of string" you're lost.<BR/><BR/>Finally, wchar_t doesn't actually let you represent every Unicode "character" (or codepoint), though this is pretty academic because the missing ones are highly obscure.<BR/><BR/>Why not use UTF-8?Tomhttp://www.blogger.com/profile/07009479916609344352noreply@blogger.comtag:blogger.com,1999:blog-273593670040001243.post-86889677982467986292008-06-08T09:12:00.000-07:002008-06-08T09:12:00.000-07:00I'm curious to what other developers are using for...I'm curious to what other developers are using for their in-memory encoding. Are you using UCS-4 and taking the 4 byte per-codepoint hit? Are you using UTF-8/-16 and writing your code to deal with variable-width codepoints?<BR/><BR/>Has anyone written their code to use 3 bytes per-codepoint to get a fixed with encoding with a minimal loss?R Samuelhttp://www.blogger.com/profile/08148728494680800460noreply@blogger.comtag:blogger.com,1999:blog-273593670040001243.post-89941964853768013992008-06-08T01:19:00.000-07:002008-06-08T01:19:00.000-07:00"as well as a few weird cases like the character ß..."as well as a few weird cases like the character ß going to SS in upper case"<BR/><BR/>It might be worth mentioning that that is true even in Unicode 5.1, which introduced captai sz.Anonymousnoreply@blogger.com