В 10-й Винде консоль якобы стала лучше. Я не заметил. По крайней мере она как UTF-8 не поддерживала, так и не поддерживает нормально.
Можно сказать ей `chcp 65001`, и тогда можно будет нормально выводить текст в UTF-8. Но ввести его при помощи, например, fgets как раньше нельзя было, так нельзя и сейчас.
Что характерно, если взять Cygwin или MinGW, и воспользоваться их `cat.exe`, то умная кошка знает, что имеет дело с долбанутой виндовской консолью, и всё поправляет как надо. Т.е. если запустить `cat | моя_программа.exe`, то в `stdin` уже пойдут строчки вполне себе в UTF-8.
Не знаю, м.б. это и не консоль, а стандартная библиотека в исполнении M$ в составе Visual C++. Пофиг. Всё равно разочарован. Когда они наконец это поправят?.. А если я чего-то не понял, то чего именно?..
Цоперайт © 2010-2016 @stiletto.
Никогда они это не поправят, там всё растёт из совместимости с предыдущими системами, а не от продуманной идеи текстового интерфейса программ.
Консоль — это терминал (его эмулятор), оболочка, системный API, утилиты. В десятой версии подтянули терминал, добавив украшательства, сочетания клавиш, работу с буфером, изменение размера на лету и прочее, что давно считается нормой в нормальных ОС (и уже было в альтернативных консольках под винду). Интерпретатор умнее не стал: нет смысла придумывать свой bash, которым никто не будет пользоваться. По той же причине удивительно ожидать, что стандартные утилиты вдруг перепишут, убрав жёсткую привязку к досовской кодировке. Заметим, что у нас операционная система насквозь юникодная (по крайней мере, API), системная локаль соответствует кодовой странице ANSI, а консоль работает в OEM-кодировке, и приложению надо все три варианта иметь в виду при вводе-выводе. "chcp 65001" официально не рекомендован (поскольку UTF-8 в винде не родной формат ни для чего, а это, видимо, хак для представления его в качестве одного из MBCS) и приведёт к глюкам и молчаливым падениям случайных программ (особенно кросплатформенных). Я когда-то давно поковырял это всё и пришёл к выводу, что однозначно рабочего решения не существует: если в юниксовых программах и библиотеках на C можно добиться, чтобы массивы однобайтных символов в качестве базового формата передавались без изменений, а потом объявить эру .utf-8 и заново проверить, что никто не считает, что длина строки в символах равна количеству байт в ней, то тут и программа должна внутренние форматы приводить к wchar_t, а потом ещё консоль как-то будет символы конвертировать, в зависимости от кодировки, шрифта (!) (! даже без вывода на экран, при перенаправлении в файл/из файла (!)).
Можно всё переписать заново, пользуясь только низкоуровневыми функциями, но взаимодействие с другими консольными программами вернёт пробелму на место. Можно использовать POMERSHELL (там ввод-вывод программ насильно превращается в объекты .NET) или другой язык с GUI'шной консолькой и надеяться, что их авторы насчёт кодировок всё предусмотрели. Можно, как cygwin, брать полноценный putty и подключаться к полноценной оболочке в воссозданном полноценном окружении.
@romme Два замечания:
— Я бы посмотрел на человека, сознательно пользующегося ANSI-обёрткой к API в 2015 году.
— Конвертировать внутри приложения можно сколько угодно, это автоматизируется, и это всё равно придётся делать, потому что utf-8 винда не понимает.
— Проблема в том, что весь этот правильный юникод в правильных вызовах API нормально отображаться и вводиться не хочет из-за отсутствия родной поддержки в оболочке, библиотеках, фреймворках и прочем: https://alfps.wordpress.com/2011/12/08/unicode-part-2-utf-8-stream-mode/