Printf problem with special characters like: æ Æ Ø ø å Â

If you have MS Internet Explorer 6, right-click on this page, then click 'Encoding' in the pop-up menu, then try choosing some different encodings.
You will see that the characters displayed change with different encodings; that's nothing to do with Keil, nothing to do with their compiler, nothing to do with the 'C' programming language, and nothing to do with printf.

As I said originally, codes >127 are not defined by ASCII - so if you want a specific interpretation, you are going to have to specify that interpretation as well as sending the codes.
How you do this will depend on your output device; eg, you may need to send an escape sequence to select the required symbol set.

First of all, I thank everyone for there reactions concerning my problem.

Andy, You are right about the thing that it had nothing to do with printf and the C-programming language. And the story about >127 is clear to me.

I did more research on it and found out that when I type a special character in uVision by pressing for example:

[Alt-145] (0x91) gives me the character: æ.

When I store my file example.c and watch it with a Hex-edittor I see character: µ which is my case [Alt-230] (0xE6) in stead of æ.

So, with other words uVision stores 'keyboard-pressed' [Alt-145] to 'file viewing' [Alt-230].

Maby it was already clear to you, but if not, this is what is happening.

When I store my file example.c and watch it with a Hex-edittor I see character: µ which is my case [Alt-230] (0xE6) in stead of .

If it's a hex-editor you're looking in, then you shouldn't be seeing 'µ' at all --- you should be seeing 0xe6 itself. What character that display as depends on the non-ASCII encoding your hex-editor is configured to use.

So, with other words uVision stores 'keyboard-pressed' [Alt-145] to 'file viewing' [Alt-230].

No, it doesn't. You still don't get it, it seems. You still believe that the key on your keyboard labelled 'æ' must always generate the character code 145 (0x91). But that belief is wrong. Pressing that key will generate whatever code æ has in the encoding Windows is using as you type that. In the case at hand, that happens to be 230 (0xe6).

I.e. the keyboard-pressed code was 230 (0xe6) already.

This has nothing in particular to do with Keil tools. You'll almost certainly have the same behaviour if you edit your source file in any other Windows editor.

To make matters worse, Windows can use independent, and *different* non-ASCII character encodings for DOS and native Windows programs, and particularly the DOS encodings (called "code pages") are compatible to nothing else but DOS itself.

Try looking at the same file with non-ASCII characters, both in Windows' "notepad.exe" and DOS "edit.com", to see the differences.

"So, with other words uVision stores 'keyboard-pressed' [Alt-145] to 'file viewing' [Alt-230].

No, it doesn't. You still don't get it, it seems. You still believe that the key on your keyboard labelled 'æ' must always generate the character code 145 (0x91). But that belief is wrong."

No, that is *not* what he is saying. He is saying, quite correctly, that if he holds down the ALT key in uvision then presses the keys '1' followed by '4' followed by '5' on his numeric keypad he sees the character 'æ'. If he than saves the file and views it in a hex editor he sees that the value 0xE6 (230) has been stored rather than the value 0x91 (145).

Stefan

You still believe that the key on your keyboard labelled 'æ' must always generate the character code 145 (0x91).

I do not have a key labeled 'æ'on my keyboard. I generate this character by pressing [Alt-145]. So Yes I expect that it is stored as code 145, but obvious it is not.

I try your experment and yes, you are right.
When I press [Alt-145] in "notepad.exe", store it and look it in with "edit.com". It gives code 230 (0xE6).

So your conclusion "It has nothing to do with Keil" is correct.

This leads me to the question "Is there a way to make DOS and Windows codetables the same?".