Re: [Draft] Writing i18n apps with glibc 2.2
Hi Roger,
On Mon, Oct 16, 2000 at 04:10:07PM +1100, Roger So wrote:
> >
> > No, please don't. You should continue to use isprint to test whether a byte
> > is printable.
>
> I thought so too, but isprint(0xA7) didn't work, however iswprint(0xA7)
> worked ...? Now I'm confused ...
This is indeed correct. Byte 0xA7 is not a legal character in zh lcoales,
so isprint(0xA7) should return 0. While widechar 0xA7 = U000000A7 = 0xA1EC
(gb2312) = 0xA1B1 (big5), is a printable character, so iswprint(0xA7) returns 1.
Also glibc retains more information for widechar (used by iswprint) than for
multibyte (used by isprint). Internally the binary locale file keep two separate
sets of information: multibyte and widechar. All the chars presented in locale
def file will be put in widechar part, while only those also exist in charmap
file, i.e. legal chars, will be recorded in multibyte part. For example, U00A6
exist in zh_HK def files, although it's not a legal character in Big5HKSCS
charmap, iswprint(0xA6) will return 1. The same call in zh_CN and zh_TW lcoales
will result a 0, because U00A6 is not exist in zh_CN and zh_TW def files.
> Heh, I have a lot of problems with mutt 1.2.5 and glibc 2.2 ... I was meant
> to check out mutt 1.3 CVS, but with exams looming ...
With the enable-locale-fix mutt 1.2.5 should work fine even with glibc 2.2,
right? Though I understand debian mutt maintainer's hesitation of making this
default. That will make those iso8859-* people complain. Mutt 1.3.9 use
iswprint and works great for me.
> > Just a small thing. A new LC_CTYPE class "hanzi" was added in glibc 2.2
> > locale (both zh_CN and zh_TW have it, zh_HK doesn't though).
>
> Hmm ... that's a bug ...
Well, not really a bug. I added this hanzi class in zh_CN. zh_TW's CTYPE simply
copy zh_CN, while zh_HK copy "i18n".
Regards,
rigel
Reply to: