Terry IT wrote:
Quote:
hi,
i've some C and C++ code written. I'll speak about the C code here.
All of the text user interface is with printfs and scanf. They are
all ascii characters. They are working well on english . Now i have to
change these
printf("Select 1 for choosing option billing \n") ; to japanese ,
chinese etc.
>
One option would be to use GNU gettext but there are issue with GPL
code.
>
My idea is to store for each language a prefix code and the string in
seperate file
>
like for japanese , str_ja
1 "japanse string for choosing optino billing"
2 " japenase optin for chooseing the payment mode"
>
str_cn similar.
>
>
Will replacing the char str[1000] with wchar str[1000] and printf with
wprintf and reading string with wscanf work or is there something
else along with wscanf , wprintf to be done ? .
|
Keep in mind that it is perfectly legal for an implementation to
provide no support for any locales other than "C" and "". wchar_t and
char can both be 8-bit types with the same character encoding, one
that doesn't accommodate (for instance) Japanese characters.
On implementations with support for a Japanese locale, you'll need to
call setlocale(), and the name of the locale you'll need to pass to
setlocale() depends upon your implementation.
If you use wprintf() to write text and wscanf() to read it, using the
same implementation of C, they should work together properly. However,
keep in mind that the character encoding used by those functions is
implementation-defined. You can't guarantee that files created by
wprintf() calls in a program created using one implementation of C
can be read correctly using wscanf() calls by a program created with
a different implementation of C. You'll need to study the two
implementations' documentation to verify whether they can be
configured to use compatible encodings. In principle, this is also
true for printf() and scanf(), but the opportunities for a mis-match
are much greater with wchar_t.
Quote:
|
I fail to understand the relevance of wcstombs_s, _wcstombs_s_l . Why
|
Those are so-called "secure" versions of wctombs() that have been
proposed by Microsoft as additions to a future version of the C
standard. It's debatable whether they actually enable significant
improvements in security.
You won't need wcstombs() if you keep everything in wchar_t. However,
keep in mind that a few C standard library functions require char*
arguments, and have no equivalent function that takes a wchar_t*
argument. The most notable of these is fopen(). If you're reading in a
file name with wscanf() and passing it to fopen(), you might need to
call wcstombs().
Quote:
What do you guys use or recommend in such situations or how to design
such tasks ?
|
I've never coded an application which required the ability to read or
write data in any encoding other than US ASCII, so there's lots of
people better equipped to answer your question than I am. I've only
addressed the issues you've raised that I am familiar with.
