How to display Russian letters in the console in C++?

Question

C++ / C#

Hello, there was a problem when displaying Russian letters in the console
SetConsoleCP(1251);
SetConsoleOutputCP(1251);
setlocale(LC_ALL, "English");
setlocale(0, "");
I registered utf-8, in the command line settings, in the configuration properties, the character set was checked as a multibyte encoding as well as a Unicode character set.
All this is checked, too, for some reason it does not work





Help solve the problem.
Thanks in advance

Answer 1

The eternal problem :-)
Every novice Windows C++ programmer should go through this!
1. The default Windows command line is cp866 (yes, not cp1251). I do not recommend outputting in UTF8, because cmd still clumsily works with this encoding.
2. cmd and powershell console are different consoles
3. Compiler and standard library (cin/cout) don't convert encodings on input/output in any way.
(Perhaps the conversion can be set somehow, but this is not done by default.)
4. The compiler does not convert your text strings in the program during assembly, i.e. in which encoding you wrote the string constant, the same encoding will be printed to the console. Thus - it matters in what encoding you have the source code!
5. The encoding in the console can be changed from the console itself with the chcp command. They often do so. In Russian Windows 2, the widely used console encodings are cp866 and cp1251. You should not hope that the program will always run with only one encoding.
Based on the above:
1. We always write source codes in UTF8
2. Before output, we always convert UTF8 to the console encoding. After entering - the same. There are corresponding functions in WinAPI.
3. We never change the console encoding forcibly - this is not convenient for the users of the program.
For the simplest option - you can write the sources in cp866 and by default in cmd everything will be fine with encodings.
Good luck!

Answer 2

I didn't use the latest Visual Studios, but until 2010 inclusive, the Microsoft compiler didn't blow UTF without BOM at point-blank range. I do not rule out that this paramount problem has not yet been overcome.