wide characters

[Bill Cunningham]

I want to print out the Chinese character meaning water which is decimal
27750 I believe. Do I use wprintf to do this and just include wchar.h ? So
far I haven't gotten anything to work.

Bill

[Antoninus Twink]

Re: wide characters

On 15 Oct 2008 at 21:23, Bill Cunningham wrote:

I want to print out the Chinese character meaning water which is
decimal 27750 I believe. Do I use wprintf to do this and just include
wchar.h ? So far I haven't gotten anything to work.

To be honest, internationaliz ation in "standard" C is a complete mess,
hacked on imperfectly to the language at the last possible minute. The
wchar_t representation of a string is platform *and locale* dependent,
so bad things can happen if the run-time locale of your program is
different from the compile-time locale.

The best advice is to take advantage of an existing Unicode library:
someone else has already made the mistakes you're likely to made,
debugged them, and put the resulting code in a library for you to use,
so why reinvent the wheel?

A good option could be the ICU library (http://www.icu-project.org)
developed at IBM.

[Ben Bacarisse]

Re: wide characters

Antoninus Twink <nospam@nospam. invalidwrites:

On 15 Oct 2008 at 21:23, Bill Cunningham wrote:

>I want to print out the Chinese character meaning water which is
>decimal 27750 I believe. Do I use wprintf to do this and just include
>wchar.h ? So far I haven't gotten anything to work.

>
To be honest, internationaliz ation in "standard" C is a complete mess,
hacked on imperfectly to the language at the last possible minute. The
wchar_t representation of a string is platform *and locale* dependent,
so bad things can happen if the run-time locale of your program is
different from the compile-time locale.

I may regret this but I can't see what you mean by this. The only
meaning I can put on it applies equally to programs that use a library
like ICU.

The best advice is to take advantage of an existing Unicode library:
someone else has already made the mistakes you're likely to made,
debugged them, and put the resulting code in a library for you to use,
so why reinvent the wheel?
>
A good option could be the ICU library (http://www.icu-project.org)
developed at IBM.

Do you really think that is easier than either of the methods
illustrated here:

#include <wchar.h>
#include <locale.h>
#include <stdio.h>

int main(int argc, char **argv)
{
wchar_t water = 27750;
setlocale(LC_AL L, "");
printf("汦");
printf("%lc\n", water);
return 0;
}


Of course, there are numerous way in which this can go wrong, but that
also apply to using ICU.

--
Ben.

[Michael]

Re: wide characters

Bill Cunningham wrote:

I want to print out the Chinese character meaning water which is decimal
27750 I believe. Do I use wprintf to do this and just include wchar.h ? So
far I haven't gotten anything to work.
>
Bill
>
>

If you use UTF-8, then the original C library is already enough.

[lovecreatesbeauty@gmail.c0m]

Re: wide characters

On Oct 16, 1:00 pm, Michael <mich...@michae ldadmum.no-ip.orgwrote:

Bill Cunningham wrote:

I want to print out the Chinese character meaning water which is decimal
27750 I believe. Do I use wprintf to do this and just include wchar.h ? So
far I haven't gotten anything to work.

>
If you use UTF-8, then the original C library is already enough.

Yes. I can print the Chinese word for water as I print ascii on my
machine.

(btw, the Chinese word for water is $B?e(B.
http://www.chinese-tools.com/tools/c...l?cn=%E6%B0%B4,
http://www.chinese-tools.com/tools/s...ml?q=%E6%B0%B4 )

$ cat a.c
#include <stdlib.h>
#include <stdio.h>

int main(int argc, char *argv[])
{
if (!argv[1]) return EXIT_FAILURE;
printf("%s\n", argv[1]);
return EXIT_SUCCESS;
}

$ make && ./a.out "hello $B?e(B"
gcc -ansi -pedantic -Wall -W -c -o a.o a.c
a.c:4: warning: unused parameter 'argc'
gcc a.o -o a.out
hello $B?e(B
$

[Bill Cunningham]

Re: wide characters

Ben I am not seeing what you and Antonius are meaning by saying
"locale". I understand run-time and compile-time but I've never used the
term "locale".

Bill

[Ben Bacarisse]

Re: wide characters

"Bill Cunningham" <nospam@nspam.i nvalidwrites:

Ben I am not seeing what you and Antonius are meaning by saying
"locale". I understand run-time and compile-time but I've never used the
term "locale".

I did not use the term and I claimed that I could understand what
Antoninus Twink meant by his posting. Unless he comes back to explain
what he meant, I suggest you ignore the term (as he used it).

--
Ben.

[Antoninus Twink]

Re: wide characters

On 16 Oct 2008 at 20:40, Ben Bacarisse wrote:

"Bill Cunningham" <nospam@nspam.i nvalidwrites:

> Ben I am not seeing what you and Antonius are meaning by saying
>"locale". I understand run-time and compile-time but I've never used
>the term "locale".

>
I did not use the term and I claimed that I could understand what
Antoninus Twink meant by his posting. Unless he comes back to explain
what he meant, I suggest you ignore the term (as he used it).

I have the impression (perhaps it's just an unfounded prejudice) that
trying to work portably with wide characters in raw C is fraught with
difficulty, and relying on intelligent library routines is a safer
option.

Here's a quote from the wprintf manpage:

glibc represents wide characters using their Unicode (ISO-10646)
code point, but other platforms don’t do this. Also, the use of C99
universal character names of the form \unnnn does not solve this
problem. Therefore, in internationaliz ed programs, the format string
should consist of ASCII wide characters only, or should be
constructed at run time in an internationaliz ed way (e.g., using
gettext(3) or iconv(3), followed by mbstowcs(3)).

[Bill Cunningham]

Re: wide characters


"Antoninus Twink" <nospam@nospam. invalidwrote in message
news:slrngffbp8 .atj.nospam@nos pam.invalid...

[snip]

Here's a quote from the wprintf manpage:
>
glibc represents wide characters using their Unicode (ISO-10646)
code point, but other platforms don't do this. Also, the use of C99
universal character names of the form \unnnn does not solve this
problem. Therefore, in internationaliz ed programs, the format string
should consist of ASCII wide characters only, or should be
constructed at run time in an internationaliz ed way (e.g., using
gettext(3) or iconv(3), followed by mbstowcs(3)).

I have gettext and FSF's libiconv on my system. I will have to find out
what mbstowcs is. Ok I see what you're trying to say. Basically stay away
from C's wchar.h functions and use something better.

Bill

[Ben Bacarisse]

Re: wide characters

"Bill Cunningham" <nospam@nspam.i nvalidwrites:

"Antoninus Twink" <nospam@nospam. invalidwrote in message
news:slrngffbp8 .atj.nospam@nos pam.invalid...
>
[snip]
>

>Here's a quote from the wprintf manpage:
>>
>glibc represents wide characters using their Unicode (ISO-10646)
>code point, but other platforms don't do this. Also, the use of C99
>universal character names of the form \unnnn does not solve this
>problem. Therefore, in internationaliz ed programs, the format string
>should consist of ASCII wide characters only, or should be
>constructed at run time in an internationaliz ed way (e.g., using
>gettext(3) or iconv(3), followed by mbstowcs(3)).

>
I have gettext and FSF's libiconv on my system. I will have to find out
what mbstowcs is. Ok I see what you're trying to say. Basically stay away
from C's wchar.h functions and use something better.

That can't be what he is saying because mbstowcs is, roughly speaking,
one of "C's whcar.h functions".

I think, from the sort of programs I've seen you write, you will be
fine with standard C for a while yet.

There *is* a problem with wide character support but it is not fixed
by using other libraries. If there is going to be a miss-match
between the wide character representation used by your compiler and
that used by your run-time, then your will have trouble. The solution
is to use only run-time strings (this is what the quote is saying but
I have translated it from the system specific language of glibc,
gettext etc.). This applies to any program using any such facilities,
including the standard ones[1].

If you can assume that there is no such miss-match, then all is well.

[1] In fact it applies to all programs that use any character data, it
is just that we all assume that the execution and source character
sets are the same these days. In the old days, this problem occurred
even with printf("Hello world.\n");

--
Ben.