Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > wide characters

Reply
Thread Tools

wide characters

 
 
Bill Cunningham
Guest
Posts: n/a
 
      10-15-2008
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


 
Reply With Quote
 
 
 
 
Antoninus Twink
Guest
Posts: n/a
 
      10-15-2008
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, internationalization 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.

 
Reply With Quote
 
 
 
 
Ben Bacarisse
Guest
Posts: n/a
 
      10-16-2008
Antoninus Twink <(E-Mail Removed)> writes:

> 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, internationalization 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_ALL, "");
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.
 
Reply With Quote
 
Michael
Guest
Posts: n/a
 
      10-16-2008
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.
 
Reply With Quote
 
lovecreatesbeauty@gmail.c0m
Guest
Posts: n/a
 
      10-16-2008
On Oct 16, 1:00 pm, Michael <(E-Mail Removed)-ip.org> wrote:
> 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
$
 
Reply With Quote
 
Bill Cunningham
Guest
Posts: n/a
 
      10-16-2008
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


 
Reply With Quote
 
Ben Bacarisse
Guest
Posts: n/a
 
      10-16-2008
"Bill Cunningham" <(E-Mail Removed)> writes:

> 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.
 
Reply With Quote
 
Antoninus Twink
Guest
Posts: n/a
 
      10-16-2008
On 16 Oct 2008 at 20:40, Ben Bacarisse wrote:
> "Bill Cunningham" <(E-Mail Removed)> writes:
>> 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 internationalized programs, the format string
should consist of ASCII wide characters only, or should be
constructed at run time in an internationalized way (e.g., using
gettext(3) or iconv(3), followed by mbstowcs(3)).

 
Reply With Quote
 
Bill Cunningham
Guest
Posts: n/a
 
      10-16-2008

"Antoninus Twink" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...

[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 internationalized programs, the format string
> should consist of ASCII wide characters only, or should be
> constructed at run time in an internationalized 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


 
Reply With Quote
 
Ben Bacarisse
Guest
Posts: n/a
 
      10-16-2008
"Bill Cunningham" <(E-Mail Removed)> writes:

> "Antoninus Twink" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>
> [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 internationalized programs, the format string
>> should consist of ASCII wide characters only, or should be
>> constructed at run time in an internationalized 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.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
80 character wide <pre> block appears only 60 character wide onWindows Disc Magnet HTML 2 05-15-2010 06:53 AM
Re: DSLR lenses not good wide open at wide angle? Dauphin de Viennois Digital Photography 2 07-16-2008 12:29 PM
Wide Screen not wide enough? michelebargeman@yahoo.com DVD Video 31 04-27-2006 08:50 PM
Not many "wide-angle" compacts but, heck, many are wide-angle anyway! JeffOYB@hotmail.com Digital Photography 10 01-09-2006 08:30 AM
char 8bit wide or 7bit wide in c++? Web Developer C++ 2 07-31-2003 08:09 AM



Advertisments