This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(316.8, 38%, 40%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EMF%3C/text%3E%3C/svg%3E)
Hello,
if (component.Unit.Find("°C") != -1)
component.Unit.Replace("°C", "Grad Celsius");
I have problems with characters that I pass on via the TCP/IP interface. I think it is due to the character set. How can I solve this?
CString strNormal("Some °C Unicode string");
char ascstrNormal[32];
USES_CONVERSION;
strcpy_s(ascstrNormal, T2CA(strNormal));
CString str = _T("Some °C Unicode string");
char ascstr[32];
strcpy_s(ascstr, T2CA(str));
I cut and pasted your example code into a VS2022 MFC application. I could not reproduce the issue -- there were no incorrect characters in the converted text.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(246.4, 86%, 33%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EDL%3C/text%3E%3C/svg%3E)
If I copy/paste your code snippet into a C++ console project, I see:
Your debugger shows the character as Â, which is 0xC2 (shown as -62 decimal), I'm not sure why that's different for you. Does the CString str show the correct character for the degree symbol (0x00b0) if you view it in the debugger?
The character ° encoded into UTF-8 is 0xC2B0. If your environment takes that as ISO-8859-1 (or CP1252), that sequence prints as
That should give an idea of what is going on. (I had to include it as image, as the forum software choked on the sequence inline.)
Does the CString str show the correct character for the degree symbol (0x00b0) if you view it in the debugger?
No.
@Erland Sommarskog jogged my memory about the encoding of source code files.
CString strNormal("Some °C Unicode string");
char ascstrNormal[32];
USES_CONVERSION;
strcpy_s(ascstrNormal, T2CA(strNormal));
CString str = _T("Some °C Unicode string");
char ascstr[32];
strcpy_s(ascstr, T2CA(str));
I can reproduce the problem if the containing source code file is encoded as UTF8.
see bottom of thread.
Have you tried changing the encoding of the source file(s)?
In the IDE, with a source file open and with focus, use the File menu and Save As.
From the dialog that opens, the Save button has a dropdown list attached. Drop it and select Save with Encoding. Make note of the current encoding, then try a different one.
In my tests "Western European (Windows) - Codepage 1252" and "Unicode UTF-8 with signature ..." do NOT show the extra character. But "Unicode UTF-8 without signature ..." DOES show that extra character.
Rebuilds were done after each change to the encoding of the source file.
I'm just looking at the string. TCP/IP later.
For string is answered.
Could I also do this via code?
//Input.... ->.....Filter..->...Output
I've always taken the standard.
Which setting, depending on what? The last question.
>Which setting, depending on what?
I don't know if there is a simple rule or guide for that. You may get some insight from here:
UTF-8, UTF-16, UTF-32 & BOM
General questions, relating to UTF or Encoding Form
https://www.unicode.org/faq/utf_bom.html
Note especially:
Q: Is there a standard method to package a Unicode character so it fits an 8-Bit ASCII stream?
https://www.unicode.org/faq/utf_bom.html#gen9
Q: Which method of packing Unicode characters into an 8-bit stream is the best?
https://www.unicode.org/faq/utf_bom.html#gen10
>I have problems with characters that I pass on via the TCP/IP interface.
>I think it is due to the character set.
Which compiler and IDE are you using? Which versions?
Which version of the C RTL via the Win SDK?
FWIW when I build your example and display it using VS2017 Community Edition 15.9.58, Win SDK 10.0.17763.0, and ISO C++17 Standard (/std:c++17) I do NOT see that extra character.
Which compiler and IDE are you using? Which versions? Which version of the C RTL via the Win SDK? FWIW when I build your example and display it using VS2017 Community Edition 15.9.58, Win SDK 10.0.17763.0, and ISO C++17 Standard (/std:c++17) I do NOT see that extra character. How can I see which Std Library I am using?
Microsoft Visual Studio Professional 2017
Version 15.9.35
VisualStudio.15.Release/15.9.35+28307.1500
Microsoft .NET Framework
Version 4.8.09037
Installierte Version: Professional
Microsoft Visual Studio Tools for Applications 2017 00370-20001-29427-AYY90
Microsoft Visual Studio Tools for Applications 2017
Visual C++ 2017 00370-20001-29427-AYY90
Microsoft Visual C++ 2017
type here
What do I have to do, what can I do to make it work?
I am looking for a simple solution.
This thread is confused, because you have two questions. The first is:
I have problems with characters that I pass on via the TCP/IP interface. I think it is due to the character set. How can I solve this?
The answer so far is: We don't know anything about this problem, so we can't give you solutions.
Then you are asking (paraphrased): "Why am I seeing this  in the debugger?". This question has a quite obvious answer: your source file is in UTF-8, but the debugger has no information about the encoding of your string, and displays the information in your ANSI code page.
But whether this answer has any relevance to your TCP/IP problem, I don't know. Since I don't know what problem you have there.
This thread is confused, because you have two questions. The first is:
ok. Let's first look at the string without TCP/Socket. Later I have a string that I have to send to the server via socket. Would that have any effect?
ok. Let's first look at the string without TCP/Socket. Later I have a string that I have to send to the server via socket. Would that have any effect?
I am not sure this question is meaningful.
But since you are sending something over a TCP/IP socket you are communicating with someone/something. When you communicate with someone, you need to have an agreement on how to perform that communication. When humans meet we can sometimes make this up as we go. You and I met, and I speak Swedish and you speak German, and I realise quite quickly that you don't understand what I'm saying. Since I learnt German in school, I switch to German, but then you find my German awful, and you switch to English, and by then we have completed the negotiation.
Computers as usually less flexible. If two computers start talking to each other without any common protocol than TCP/IP (which only is a base protocol where you say "let's use mouth and ears rather than sign language), there will be no communication. Some protocols permit for negotiation, for instance on the character set.
So you need to know the protocol for your TCP/IP communication and what character set(s) it supports. If you send UTF-8, but the other end thinks that the agreement is to use ISO-8859-1, your ' will be taken as Â*. Now, hopefully, your receiver is not that antique, but is able to speak Unicode. But even then you need to know whether the encoding is supposed to be UTF-8, UTF16, UTF16-LE or something else.
But all these have very little to do what you see in the debugger. The debugger is displaying you a byte stream by using a character format. And in this context it make sense to use a legacy character set, since there is one-to-one mapping between byte and character.
Computers as usually less flexible. If two computers start talking to each other without any common protocol than TCP/IP (which only is a base protocol where you say "let's use mouth and ears rather than sign language), there will be no communication. Some protocols permit for negotiation, for instance on the character set.
https://learn.microsoft.com/en-us/answers/questions/1467973/full-duplex-communication-sample-c-mfc
OK, Please see this thread. Maybe you have a good sample project.
And in this context it make sense to use a legacy character set, since there is one-to-one mapping between byte and character.
Which coding, which setting for the file would you prefer?
OK, Please see this thread. Maybe you have a good sample project.
I've actually done TCP/IP programming, but it's soon 30 years ago. These days, I only work with SQL Server, but happened to see this thread, and jumped in since I have a special interest in character sets and the like.
Which coding, which setting for the file would you prefer?
You mean the encoding of the source-code file? Normally, that would not matter, since a communication program reads from once source (user input, a file, database etc) and does not send data hard-coded into the file. The exception may be packet-header data, stating what type of packet that is. But such codes are typically only uppercase ASCII letters.
Then again, it can be a good idea to be consistent. In our team we have settled on that files must be in UTF-8 and have a leading BOM, and we have rules in Git to enforce this.