469,613 Members | 1,324 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,613 developers. It's quick & easy.

Unicode I/O

Hi,

The following std c++ program does not output the unicode
character.:-

%./a.out
en_US.UTF-8
Infinity:
%cat unicode.cpp
#include<iostream>
#include<string>
#include<locale>

int main()
{
std::wstring ws = L"Infinity: \u221E";
std::locale loc("");
std::cout << loc.name( ) << " " << std::endl;
std::wcout.imbue(loc);
std::wcout << ws << std::endl;
}
%locale
LANG=en_US
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=en_US.UTF-8

What am I missing? Kindly help. I am trying to understand unicode i/o
in c++ to modify an application to work for unicode input.

Thank You,
Himanshu
Jun 27 '08 #1
10 2999
hi***********@gmail.com wrote:
Hi,

The following std c++ program does not output the unicode
character.:-

%./a.out
en_US.UTF-8
Infinity:
%cat unicode.cpp
#include<iostream>
#include<string>
#include<locale>

int main()
{
std::wstring ws = L"Infinity: \u221E";
std::locale loc("");
std::cout << loc.name( ) << " " << std::endl;
std::wcout.imbue(loc);
std::wcout << ws << std::endl;
}

Unicode support is not included by current C++ standard,
In C++0x, there will be Unicode support.

I'm quite dummy about locale things,
But you can check Boost utf8_codecvt_facet, which works very well.

I'm sure there's no "\u" escape character in C++,
while Java has this.

HTH.

--
Best Regards
Barry

Jun 27 '08 #2
On 13 avr, 10:58, Barry <dhb2...@gmail.comwrote:
himanshu.g...@gmail.com wrote:
The following std c++ program does not output the unicode
character.:-
%./a.out
en_US.UTF-8
Infinity:
%cat unicode.cpp
#include<iostream>
#include<string>
#include<locale>
int main()
{
std::wstring ws = L"Infinity: \u221E";
std::locale loc("");
std::cout << loc.name( ) << " " << std::endl;
std::wcout.imbue(loc);
std::wcout << ws << std::endl;
}
Unicode support is not included by current C++ standard,
Full Unicode support isn't there, but there are a few things.
L"\u221E", for example, is guaranteed to be the infinity sign in
an implementation defined default wide character encoding,
supposing it exists. And Posix (not C++) guarantees that the
locale "en_US.UTF-8" uses UTF-8 encoding. So at the very least,
from a quality of implementation point of view, if nothing else,
he should either get a warning from the compiler (that the
character requested character isn't available), throw
std::runtime_error to indicate that the requested locale isn't
supported, or the character he wants, correctly encoded in
UTF-8. (Technically, the behavior of locale("") is
implementation defined, and I don't think it's allowed to raise
an exception. But in this case, an implementation under a
system using the Posix locale naming conventions shouldn't
return "en_US.UTF-8" as the name, but rather something like
"C".)

What I would do in his case, for starters, is do a hex dump of
the wstring's buffer, to see exactly how L"\u221E" is encoded.
Beyond that: if it's encoded as some default character indicated
a non-supported character, then he should file an error report
with the compiler, requesting a warning, otherwise, he should
file an error report for the library, indicating that locales
aren't working as specified.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Jun 27 '08 #3
On 13 Apr., 08:49, himanshu.g...@gmail.com wrote:
Hi,

* * The following std c++ program does not output the unicode
character.:-

%./a.out
en_US.UTF-8
Infinity:

%cat unicode.cpp
#include<iostream>
#include<string>
#include<locale>

int main()
{
* *std::wstring ws = L"Infinity: \u221E";
* *std::locale loc("");
* *std::cout << loc.name( ) << " " << std::endl;
* *std::wcout.imbue(loc);
* *std::wcout << ws << std::endl;

}
[snip]
>
What am I missing? Kindly help. I am trying to understand unicode i/o
in c++ to modify an application to work for unicode input.
I don't know the solution to your problem, but first of all, I'd write
to a file first, and not to the console. Examine the file - preferably
with a hex editor - and verify if it is in the proper format. If it
is, the C++ part might be okay, and you should look for a solution
somewhere else.

/Peter
Jun 27 '08 #4
On Apr 13, 5:59*pm, James Kanze <james.ka...@gmail.comwrote:
On 13 avr, 10:58, Barry <dhb2...@gmail.comwrote:
himanshu.g...@gmail.com wrote:
The following std c++ program does not output the unicode
character.:-
%./a.out
en_US.UTF-8
Infinity:
%cat unicode.cpp
#include<iostream>
#include<string>
#include<locale>
int main()
{
* *std::wstring ws = L"Infinity: \u221E";
* *std::locale loc("");
* *std::cout << loc.name( ) << " " << std::endl;
* *std::wcout.imbue(loc);
* *std::wcout << ws << std::endl;
}
Unicode support is not included by current C++ standard,

Full Unicode support isn't there, but there are a few things.
L"\u221E", for example, is guaranteed to be the infinity sign in
an implementation defined default wide character encoding,
supposing it exists. *And Posix (not C++) guarantees that the
locale "en_US.UTF-8" uses UTF-8 encoding. *So at the very least,
from a quality of implementation point of view, if nothing else,
he should either get a warning from the compiler (that the
character requested character isn't available), throw
std::runtime_error to indicate that the requested locale isn't
supported, or the character he wants, correctly encoded in
UTF-8. *(Technically, the behavior of locale("") is
implementation defined, and I don't think it's allowed to raise
an exception. *But in this case, an implementation under a
system using the Posix locale naming conventions shouldn't
return "en_US.UTF-8" as the name, but rather something like
"C".)

What I would do in his case, for starters, is do a hex dump of
the wstring's buffer, to see exactly how L"\u221E" is encoded.
Beyond that: if it's encoded as some default character indicated
a non-supported character, then he should file an error report
with the compiler, requesting a warning, otherwise, he should
file an error report for the library, indicating that locales
aren't working as specified.
James, thanks for correcting me.

I review the standard about \u and \U.
Now I'm *sure* that my assertion about the "\u" was wrong.

I run the code, realize that (Platform : Windows XP, VC8)

dumping L"\u4e00" become "0x4e 0xA1" which is exactly UTF-16,
the default Unicode transformation on Windows.

dumping "\u4e00" become "0xB6 0xA1" which is GBK encoding (mbcs),
my default encoding setting.

Is it this conversion done directly by the compiler?

Jun 27 '08 #5
On Apr 13, 8:36*pm, Barry <dhb2...@gmail.comwrote:
On Apr 13, 5:59*pm, James Kanze <james.ka...@gmail.comwrote:
On 13 avr, 10:58, Barry <dhb2...@gmail.comwrote:
himanshu.g...@gmail.com wrote:
The following std c++ program does not output the unicode
character.:-
%./a.out
en_US.UTF-8
Infinity:
%cat unicode.cpp
#include<iostream>
#include<string>
#include<locale>
int main()
{
* *std::wstring ws = L"Infinity: \u221E";
* *std::locale loc("");
* *std::cout << loc.name( ) << " " << std::endl;
* *std::wcout.imbue(loc);
* *std::wcout << ws << std::endl;
}
Unicode support is not included by current C++ standard,
Full Unicode support isn't there, but there are a few things.
L"\u221E", for example, is guaranteed to be the infinity sign in
an implementation defined default wide character encoding,
supposing it exists. *And Posix (not C++) guarantees that the
locale "en_US.UTF-8" uses UTF-8 encoding. *So at the very least,
from a quality of implementation point of view, if nothing else,
he should either get a warning from the compiler (that the
character requested character isn't available), throw
std::runtime_error to indicate that the requested locale isn't
supported, or the character he wants, correctly encoded in
UTF-8. *(Technically, the behavior of locale("") is
implementation defined, and I don't think it's allowed to raise
an exception. *But in this case, an implementation under a
system using the Posix locale naming conventions shouldn't
return "en_US.UTF-8" as the name, but rather something like
"C".)
What I would do in his case, for starters, is do a hex dump of
the wstring's buffer, to see exactly how L"\u221E" is encoded.
Beyond that: if it's encoded as some default character indicated
a non-supported character, then he should file an error report
with the compiler, requesting a warning, otherwise, he should
file an error report for the library, indicating that locales
aren't working as specified.

James, thanks for correcting me.

I review the standard about \u and \U.
Now I'm *sure* that my assertion about the "\u" was wrong.

I run the code, realize that (Platform : Windows XP, VC8)

dumping L"\u4e00" become "0x4e 0xA1" which is exactly UTF-16,
sorry 0x00

Jun 27 '08 #6
On 13 avr, 14:36, Barry <dhb2...@gmail.comwrote:
On Apr 13, 5:59 pm, James Kanze <james.ka...@gmail.comwrote:
On 13 avr, 10:58, Barry <dhb2...@gmail.comwrote:
himanshu.g...@gmail.com wrote:
The following std c++ program does not output the unicode
character.:-
%./a.out
en_US.UTF-8
Infinity:
%cat unicode.cpp
#include<iostream>
#include<string>
#include<locale>
int main()
{
std::wstring ws = L"Infinity: \u221E";
std::locale loc("");
std::cout << loc.name( ) << " " << std::endl;
std::wcout.imbue(loc);
std::wcout << ws << std::endl;
}
[...]
What I would do in his case, for starters, is do a hex dump of
the wstring's buffer, to see exactly how L"\u221E" is encoded.
Beyond that: if it's encoded as some default character indicated
a non-supported character, then he should file an error report
with the compiler, requesting a warning, otherwise, he should
file an error report for the library, indicating that locales
aren't working as specified.
I review the standard about \u and \U.
Now I'm *sure* that my assertion about the "\u" was wrong.
I run the code, realize that (Platform : Windows XP, VC8)
dumping L"\u4e00" become "0x4e 0xA1" which is exactly UTF-16,
the default Unicode transformation on Windows.
Here, you meant 0x4E 0x00, of course. Although for Windows, I'd
expect rather 0x00 0x4E---PC's are little endian (or are you
dumping wchar_t's, converted to int, rather than char's?).
dumping "\u4e00" become "0xB6 0xA1" which is GBK encoding (mbcs),
my default encoding setting.
Is it this conversion done directly by the compiler?
Yes. The standard guarantees that in L"\uxxxx", the "xxxx" is
Unicode, regardless of your platform. The compiler decides what
it will be on your platform. In a very implementation defined
manner. It then inserts the bytes into the final string,
according to what it thinks is the equivalent of the character
in what it thinks the desired encoding should be.

As you'll note, there's a lot of "what it thinks" in there.
You're very much at the compiler's mercy.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Jun 27 '08 #7
On Sat, 12 Apr 2008 23:49:15 -0700, himanshu.garg wrote:
Hi,

The following std c++ program does not output the unicode
character.:-

%./a.out
en_US.UTF-8
Infinity:
%cat unicode.cpp
#include<iostream>
#include<string>
#include<locale>

int main()
{
std::wstring ws = L"Infinity: \u221E"; std::locale loc("");
std::cout << loc.name( ) << " " << std::endl; std::wcout.imbue(loc);
std::wcout << ws << std::endl;
}

Have you tried using std::cout instead of std::wcout?
The above code won't print correctly for me either unless I
use std::cout and std::string.

#include<iostream>
#include<string>
#include<locale>

int main()
{
std::string ws = "Infinity: \u221E";
std::locale loc("");
std::cout << loc.name( ) << " " << std::endl;
std::cout.imbue(loc);
std::cout << ws << std::endl;
}

:~$ ./a.out
en_US.UTF-8
Infinity: ∞

--
OU

Jun 27 '08 #8
On Sun, 13 Apr 2008 07:46:17 -0700, James Kanze wrote:
On 13 avr, 14:36, Barry <dhb2...@gmail.comwrote:
>On Apr 13, 5:59 pm, James Kanze <james.ka...@gmail.comwrote:
On 13 avr, 10:58, Barry <dhb2...@gmail.comwrote:
himanshu.g...@gmail.com wrote:
The following std c++ program does not output the unicode
character.:-
%./a.out
en_US.UTF-8
Infinity:
%cat unicode.cpp
#include<iostream>
#include<string>
#include<locale>
int main()
{
std::wstring ws = L"Infinity: \u221E"; std::locale loc("");
std::cout << loc.name( ) << " " << std::endl;
std::wcout.imbue(loc);
std::wcout << ws << std::endl;
}

[...]
What I would do in his case, for starters, is do a hex dump of the
wstring's buffer, to see exactly how L"\u221E" is encoded. Beyond
that: if it's encoded as some default character indicated a
non-supported character, then he should file an error report with the
compiler, requesting a warning, otherwise, he should file an error
report for the library, indicating that locales aren't working as
specified.
>I review the standard about \u and \U. Now I'm *sure* that my assertion
about the "\u" was wrong.
>I run the code, realize that (Platform : Windows XP, VC8)
>dumping L"\u4e00" become "0x4e 0xA1" which is exactly UTF-16, the
default Unicode transformation on Windows.

Here, you meant 0x4E 0x00, of course. Although for Windows, I'd expect
rather 0x00 0x4E---PC's are little endian (or are you dumping wchar_t's,
converted to int, rather than char's?).
>dumping "\u4e00" become "0xB6 0xA1" which is GBK encoding (mbcs), my
default encoding setting.
>Is it this conversion done directly by the compiler?

Yes. The standard guarantees that in L"\uxxxx", the "xxxx" is Unicode,
regardless of your platform.
Does it?

"A character literal that begins with the letter L, such as L'x', is
a wide-character literal. A wide-character literal has type wchar_t.
The value of a wide-character literal containing a single c-char has
value equal to the numerical value of the encoding of the c-char in
the execution wide-character set. The value of the wide-character
literal containing multiple c-chars is implementation-defined."

It's implementation defined. No unicode guarantees.

Maybe it has recently been changed?

--
OU

Jun 27 '08 #9
On Apr 13, 7:29 pm, Obnoxious User <O...@127.0.0.1wrote:
On Sat, 12 Apr 2008 23:49:15 -0700,himanshu.gargwrote:
Hi,
The following std c++ program does not output theunicode
character.:-
%./a.out
en_US.UTF-8
Infinity:
%catunicode.cpp
#include<iostream>
#include<string>
#include<locale>
int main()
{
std::wstring ws = L"Infinity: \u221E"; std::locale loc("");
std::cout << loc.name( ) << " " << std::endl; std::wcout.imbue(loc);
std::wcout << ws << std::endl;
}

Have you tried using std::cout instead of std::wcout?
The above code won't print correctly for me either unless I
use std::cout and std::string.

#include<iostream>
#include<string>
#include<locale>

int main()
{
std::string ws = "Infinity: \u221E";
std::locale loc("");
std::cout << loc.name( ) << " " << std::endl;
std::cout.imbue(loc);
std::cout << ws << std::endl;

}

:~$ ./a.out
en_US.UTF-8
Infinity: $B!g(B
Hi,
Thanks for your time! I tried this one and got only second byte of
infinity codepoint in the output :-

%cat unicode.cpp
#include<iostream>
#include<string>
#include<locale>

int main()
{
std::string ws = "\u221E";
std::locale loc("");
// std::cout << loc.name() << " " << std::endl;
std::cout.imbue(loc);
std::cout << ws << std::endl;
}

%g++ unicode.cpp
<a warning about the wide character literal>

%g++ -v
[snipped]
gcc version 3.3.1 (Mandrake Linux 9.2 3.3.1-2mdk)

% ./a.out | hexdump
0000000 0a1e
0000002

I think I'll try workarounds instead of making the application
unicode aware :(

Thank You,
Himanshu
Jun 27 '08 #10
On Apr 13, 4:42 pm, Obnoxious User <O...@127.0.0.1wrote:
On Sun, 13 Apr 2008 07:46:17 -0700, James Kanze wrote:
Is it this conversion done directly by the compiler?
Yes. The standard guarantees that in L"\uxxxx", the "xxxx"
is Unicode, regardless of your platform.
Does it?
"A character literal that begins with the letter L, such as L'x', is
a wide-character literal. A wide-character literal has type wchar_t.
The value of a wide-character literal containing a single c-char has
value equal to the numerical value of the encoding of the c-char in
the execution wide-character set. The value of the wide-character
literal containing multiple c-chars is implementation-defined."
It's implementation defined. No unicode guarantees.
That paragraph doesn't say anything about universal character
names, and how they are interpreted. It's the paragraph I was
referring to earlier, when I said that the encoding in a wchar_t
was implementation defined. The 'xxxx' is required to be
Unicode, regardless of your platform: L"\u221E" must be an
infinity sign, everywhere. (See §2.2/2.) The encoding used in
wchar_t is implementation defined, universal character names are
not. So L"\u221E" might not result in a wchar_t which contains
the value 0x221E, but it should result in a wchar_t which, when
output in the environment the compiler considers "default"
appears as an infinity sign, supposing such exists in the
default wide character encoding of the implementation. And
although the standard doesn't require it, from a quality of
implementation point of view, I would expect a warning if the
character didn't exist in the default wide character encoding.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Jun 27 '08 #11

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

3 posts views Thread by Michael Weir | last post: by
8 posts views Thread by Bill Eldridge | last post: by
8 posts views Thread by Francis Girard | last post: by
4 posts views Thread by webdev | last post: by
2 posts views Thread by Neil Schemenauer | last post: by
10 posts views Thread by Nikolay Petrov | last post: by
6 posts views Thread by Jeff | last post: by
13 posts views Thread by Tomás | last post: by
24 posts views Thread by ChaosKCW | last post: by
reply views Thread by devrayhaan | last post: by
reply views Thread by gheharukoh7 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.