Hello everybody,
I'm really new to this forum and to the programming language C.
While working through a C beginners tutorial I stumbled over a small issue, which I can't solve (and it's annoying me ;) ).
The german Umlauts (special characters) are not correctly displayed in the windows console using the printf() command.
When I start the programm it prints other chars instead of the german Umlauts (see picture)
#include <stdio.h>
int main(void) {
printf("Österreichische Äpfel findet man überall - auch unter Fußmatten\n");
// Oesterreichische Aepfel findet man ueberall, auch unter Fussmatten
return 0;
}
The standard codepage in my Console is 850, but also changing to 1252 does not change the problem.
Can someone explain me this behavior, please.
Thank you in advance.
[Windows XP 32 Bit, SP2, same on SP3]
You will have to use Unicode strings to get the correct output.
Sorry, no example currently available, but searching the forum should get you a hit.
Thanks for your fast reply, Stefan.
Did you mean wchars and wprint?
Quote#include <stdio.h>
#include <wchar.h>
int main(void)
{
wchar_t wstr[] = L"öäüß";
wprintf(L"Umlaute: %ls\n", wstr);
return 0;
}
This code also prints the wrong umlauts.
Maybe I got you wrong and searched for the wrong attempt?
I know very well what you mean with UNICODE, but I can't assign it to the right C functions.
But never mind. It's a satisfiable information for me, if you say "It's a normal behavior for 'fprint()', don't worry"
I'm really at the beginning of the C tutorial and I hope this Unicode-stuff will be explained in one of the the following chapters.
I was simply irritated, because every compiled example of the tutorial prints broken Umlauts. And I thought: "Damn, why the author of this tutorial does not explain the broken Umlauts? He otherwise explained every little sideeffect in his examples."
btw: It's a german tutorial (openbook) - "C von A bis Z" and the author use Umlauts in his printf() functions.
Test this code:
#include <stdio.h>
int main(void)
{
char strANSI[] = "öäüß";
char strOEM[] = ",,"á";
/*
strOEM[0] = 0x94; //148
strOEM[1] = 0x84; //132
strOEM[2] = 0x81; // 129
strOEM[3] = 0xE1; // 225
*/
printf("Umlaute: OEM: [%s] ANSI: [%s]\n", strOEM, strANSI);
return 0;
}
Hi timovjl,
thanks for your examplecode.
The 'cryptic' OEM codes looks like right Umlauts in the console output (see picture).
Hmm, that means each time, I want to write a program with console outputs, I have to enter this special chars instead of Umlauts. :-\ Not very handy.
I never wrote programs for console mode. But after running your code I tried this using my favorit language (PureBasic) and was suprised.
Same problem with console prints using the Basic compiler. :o
It seems this 'problem' is not a problem. Maybe it's caused because the sourcecode editor running in Windows mode use another codemap as the console.
Okay, now this is claryfied for me.
Thanks guys.
Edit: PS: Ahhh! Now I tried it successfully with the CharToOEM() WinAPI function using PureBasic (see Umlaut3.gif).
I guess it's a similar way in C. :)
QuoteMaybe it's caused because the sourcecode editor running in Windows mode use another codemap as the console.
That is correct.
As you have found, different fonts and different code pages give different results.
Take a look at the Character Map (charmap.exe) Windows accessory. And look up "Code Pages" in MSDN.
Quote from: kurzer on October 22, 2009, 10:50:01 PM
I was simply irritated, because every compiled example of the tutorial prints broken Umlauts. And I thought: "Damn, why the author of this tutorial does not explain the broken Umlauts? He otherwise explained every little sideeffect in his examples."
btw: It's a german tutorial (openbook) - "C von A bis Z" and the author use Umlauts in his printf() functions.
There is currently a discussion about this book taking place at the Use-Net in the group
de.comp.lang.c, thread
C-Buch für Lau, which tells us that the book includes many misinformation, but it is not the worst available.
So I would work my way through this book with caution.
Quote from: kurzer on October 22, 2009, 09:44:10 PM
Hello everybody,
I'm really new to this forum and to the programming language C.
While working through a C beginners tutorial I stumbled over a small issue, which I can't solve (and it's annoying me ;) ).
If you want, you can use windows api to output your text according to the codepage. The following function do, it for you !
#include <windows.h>
#include <strsafe.h>
unsigned long int win_wprintf(LPCWSTR szFormat, ...)
{
# ifndef ARRAY_SIZE
# define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]))
# endif
wchar_t szText[1024 * 10];
va_list args;
unsigned long int dwWritten;
/* Format the text into the buffer */
va_start(args, szFormat);
StringCbVPrintfW(szText, ARRAY_SIZE(szText), szFormat, args);
va_end(args);
/* Output the buffer to the console. */
if (WriteConsoleW(GetStdHandle(STD_OUTPUT_HANDLE), szText, lstrlenW(szText), &dwWritten, NULL))
{
return dwWritten;
}
return 0;
}
int main(void) {
win_wprintf(L"Österreichische Äpfel findet man überall - auch unter Fußmatten\n");
// Oesterreichische Aepfel findet man ueberall, auch unter Fussmatten
return 0;
}you need to compile with windows extension on !You can also use the conversion function
CharToOemBuffW that convert from any string to oem
(you need to link with user32.lib)
Thank you very much for your comments, guys. *thumbsup*
@Stefan Pendl: Thank you for the link to de.comp.lang.c (C-Buch für Lau).
I have read the thread and I think that the discussed issues/failures are not to critical for me. Most of posts matters about the name and concept of datatypes (byte, char and so on). Some of them seems slightly wrong explained by the autor. But most of the definitions I know from my days on the good old Amiga, which I programmed in Assembler (16 years ago). And I do not plan to write C programms for esoteric machines using 9 or 18 Bits for a Byte. ;)
So, I will go on reading the book and keep your warnings in mind.
Quote from: kurzer on October 22, 2009, 09:44:10 PM
Hello everybody,
I'm really new to this forum and to the programming language C.
While working through a C beginners tutorial I stumbled over a small issue, which I can't solve (and it's annoying me ;) ).
The german Umlauts (special characters) are not correctly displayed in the windows console using the printf() command.
When I start the programm it prints other chars instead of the german Umlauts (see picture)
I use in this cases an add-in (I don't know from the Pelles C homepage or from John's homepage) which can convert ANSI to OEM charaters.
If I use this add-in your code will get to:
#include <stdio.h>
int main(void) {
printf("™sterreichische Žpfel findet man berall - auch unter Fuámatten\n");
// Oesterreichische Aepfel findet man ueberall, auch unter Fussmatten
return 0;
}
looks funny but gives the correct output.
PS.: Schaut lustig aus, aber das Ergebnis passt. ;)
Quote from: Stefan Pendl on October 24, 2009, 08:48:11 AM
Quote from: kurzer on October 22, 2009, 10:50:01 PM
I was simply irritated, because every compiled example of the tutorial prints broken Umlauts. And I thought: "Damn, why the author of this tutorial does not explain the broken Umlauts? He otherwise explained every little sideeffect in his examples."
btw: It's a german tutorial (openbook) - "C von A bis Z" and the author use Umlauts in his printf() functions.
There is currently a discussion about this book taking place at the Use-Net in the group de.comp.lang.c, thread C-Buch für Lau, which tells us that the book includes many misinformation, but it is not the worst available.
So I would work my way through this book with caution.
the openbook was the second book i took for starting with C , but the discussion about the sizeof(x); shouldn't irretate our shorty("kurzer"). for sure is, that the openbook got a couple of mistakes/errors wich don't make the book bad, if you wanna fix those mistakes its always a good thing to have a second book with it, where it is already displayed wright. Even Addision-Wesley's C Book got an error inside wich turns out when you pay attention to the questions and the practice part ;).