Неправильный вывод в консоль русского языка

@Arefev596 · Регистрация: 15.01.2021

Студворк — интернет-сервис помощи студентам

Пишу "Шифр Цезаря", заменяю буквы в введенном тексте с шагом 2 (например), следовательно "абаб" должно преобразоваться в "вгвг", что и находится в переменной InputText. Только в консоль выводится "туту" почему-то. Как решить проблему?

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
#include <iostream>
#include "Cesar.h"
#include <locale>
#include <Windows.h>
#include <string>
using namespace std;
 
 
int cesar()
{
    int step;
    cout << " Введите ключ для зашифровывания текста: \n ";
    cin >> step;
    char InputText[255];
    cout << " Введите текст, который хотите закодировать: " << endl;
    SetConsoleCP(1251);
    cin >> InputText;
    int len = strlen(InputText);
   
    for (int i = 0; i < len; i++)
    {
        if (step >= 0)
            InputText[i] = (InputText[i] - 'а' + step) % 32 + 'а';
        else
            InputText[i] = (InputText[i] - 'а' + 32 + step) % 32 + 'а';
    } 
    cout << InputText << endl;
    SetConsoleCP(866);
    system("pause");
  
    return 0;
}

@SmallEvil · 24.08.2021, 15:08

Сообщение от ram876

Раз все критикуют старые решения, тогда предложите, пожалуйста, решение на чистом c++, которое не будет зависеть от платформы.

Мне кажется, что единственного способа не существует.
Единственный выход использование фреймворков, или личных костылей в виде определения системы (во время компиляции) и выбор правильного способа установки локали.

Сообщение от мама Стифлера

но его ОС использует по умолчанию кодировку 866

866 по умолчанию только для консоли, и только под Windows.
А вообще тема довольно серьезная и обширная.

На правильное отображения влияют несколько факторов.
- Кодировка исходного кода программы. (в MSVC 2015 это никак не влияет, студия об этом уже позаботилась)
- установка std::locale, она обязательно (по умолчанию) влияет на текстовый ввод/вывод используя региональные (языковые) особенности.
- настройка самой консоли, в случае если locale по какой то причине этого не сделала или сделала неправильно.
- ну и наконец поддержка ОС кодировок (того же ЮНИКОДА, или utf-8).
- да, чуть не забыл, наличие шрифтов в системе для отображения символов Юникода тоже как бы нужно, наверное

Довольно недавно начал интересоваться мультиязычностью, в частности Юникодом.
И это не такая простая тема, охватывая ее в контексте кросс-платформености.

Сообщение от Замабувараев

Рекомендую использовать функции с W на конце и забыть про кодировки.

и забыть про кодировки, ну - ну ...

@мама Стифлера · 24.08.2021, 15:12

Сообщение от qppq

пишу так

Ну тогда поток вывода будет в кириллице, а поток ввода останется по дефолту(юникод вроде). Поэтому лучше использовать связку строк

Кликните здесь для просмотра всего текста

C++
1
2
3
4
5
6
7
8
9
10
11
SetConsoleCP(CP_UTF8);
SetConsoleOutputCP(CP_UTF8);
.
//или
.
SetConsoleCP(1251);
SetConsoleOutputCP(1251);
.
//или
.
.

@Замабувараев · 24.08.2021, 15:20

Сообщение от SmallEvil

и забыть про кодировки, ну - ну ...

Да, потому что есть функции ReadConsoleW и WriteConsoleW, которые сразу работают с юникодом.

@SmallEvil · 24.08.2021, 15:43

Сообщение от Замабувараев

ReadConsoleW и WriteConsoleW

Это только Windows приблуды.

Я лишь хочу сказать что избавится от работы с кодировками не получится.
Для экономии места и сетевого трафика, мультиязычный Юникод кодируется в UTF-8
(сжимается, и довольно не плохо, в зависимости от содержимого).

То-есть, перед записью/чтении в файл или получения/отправки по сети его нужно перекодировать.

И еще , есть коды, библиотеки, сохраненные базы в других кодировках, которые работают/сохранены старыми кодировками только с string, char *, которые кодировать также придется.

То есть твой простой совет про Виндовс функции с W на самом деле не избавит от работы с кодировками.
Даже внутри одной системы, не говоря о переносимости.

Добавлено через 1 минуту
И как я уже написал выше, установка локализации влияет на форматирование, чисел , дат, денежных записей, и т.д.
Не нужно об этом забывать.

Добавлено через 2 минуты
То есть, я пытаюсь донести что кодировка и локаль (локализация) не одно и то же.

@Замабувараев · 24.08.2021, 16:25

Сообщение от SmallEvil

Это только Windows приблуды.

SetConsoleCP и SetConsoleOutputCP — тоже только «Windows приблуды». Вместо них Я рекомендую выводить строки юникодными функциями ReadConsoleW и WriteConsoleW сразу.
К тому же, манипуляции кодировками — это дурной тон. Программа должна либо получать кодировку которая сейчас установлена в консоли и перекодировать строку в неё, либо сразу выводить юникод. Иначе смена кодировки — это то же самое что перемещение значка корзины на вашем рабочем столе в другое место «потому что программе так удобно».

Сообщение от SmallEvil

То-есть, перед записью/чтении в файл или получения/отправки по сети его нужно перекодировать.
И еще , есть коды, библиотеки, сохраненные базы в других кодировках, которые работают/сохранены старыми кодировками только с string, char *, которые кодировать также придется.
То есть твой простой совет про Виндовс функции с W на самом деле не избавит от работы с кодировками.
Даже внутри одной системы, не говоря о переносимости.

Функции WinAPI работающие со строками есть только в одном варианте: юникодном UTF-16. Другие, что принимают ANSI‐строки — это лишь оболочки над W‐функциями. Настоящую работу A‐функции не делают, внутри себя они лишь гоняют байты туда‐сюда вызывая W‐функции, перекодируют строки (с потерей информации).
Если вам нужны эффективные программы, то рекомендую вам игнорировать A‐функции и сразу вызывать W‐функции.
Кроме того, некоторые функции есть только в юникодном варианте (например, CommandLineToArgvW).

@COKPOWEHEU · 24.08.2021, 16:49

Сообщение от Замабувараев

SetConsoleCP и SetConsoleOutputCP — тоже только «Windows приблуды».

...которые приходится выносить в слой совместимости, как и прочие костыли.

Сообщение от Замабувараев

Вместо них Я рекомендую выводить строки юникодными функциями ReadConsoleW и WriteConsoleW сразу.

То есть вместо человеческого, кроссплатформенного и гибкого ввода-вывода вы предлагаете очередной костыль, который мало того что непереносим, так еще и вводить ничего кроме строк не может.
Даже интересно, как вы на этом чуде подоконной техники будете реализовывать нормальный ввод-вывод.

Открыл документацию на эту функцию

https://docs.microsoft.com/ru-... eadconsole

Функция Реадконсоле

Считывает входные символы из буфера ввода консоли и удаляет его из буфера.
Синтаксис

BOOL WINAPI ReadConsole(
_In_ HANDLE hConsoleInput,
_Out_ LPVOID lpBuffer,
_In_ DWORD nNumberOfCharsToRead,
_Out_ LPDWORD lpNumberOfCharsRead,
_In_opt_ LPVOID pInputControl
);

Параметры

хконсолеинпут [ окне]
Маркер входного буфера консоли. Этот дескриптор должен иметь право доступа GENERIC_READ. Дополнительные сведения см. в статье Безопасность и права доступа для буфера консоли.

лпбуффер [ заполняет]
Указатель на буфер, который получает данные, считанные из входного буфера консоли.

ннумберофчарстореад [ окне]
...
Все режимы ввода, влияющие на поведение ReadFile , имеют тот же результат в реадконсоле. Чтобы получить и задать режимы ввода входного буфера консоли, используйте функции жетконсолемоде и сетконсолемоде .

и далее в том же духе

Алексей1153 · 24.08.2021, 16:54

COKPOWEHEU, так надо на английский переключать

@Замабувараев · 24.08.2021, 17:30

COKPOWEHEU, ваш «человеческий, кроссплатформенный и гибкий ввод‐вывод» std::wcout и std::wstring не работает, и вам приходится применять костыли с кодировками.
Во‐вторых, юникод в Windows — это UTF-16. Я не знаю, почему ваши разработчики библиотек std::wcout, std::wstring и прочих не могут этого понять чтобы сделать кроссплатформенное решение.
В‐третьих, у WinAPI богатый набор консольных функций, а не одна «вывод в файл».

@COKPOWEHEU · 25.08.2021, 09:07

Сообщение от Алексей1153

COKPOWEHEU, так надо на английский переключать

Или ждать пока в майкрософт осилят наконец юникод. Сейчас же проблема именно в этом: консоль приходится переключать в ПЯТИ местах, и то не хватает.

Сообщение от Замабувараев

COKPOWEHEU, ваш «человеческий, кроссплатформенный и гибкий ввод‐вывод» std::wcout и std::wstring не работает

Зачем вы врете?
Он не работает только в wine, а на реальной винде работает. Не говоря про другие системы.

Сообщение от Замабувараев

и вам приходится применять костыли с кодировками.

Неа, я пользуюсь wprintf и даже не подозревал что ваши std::wcout имеют какие-то проблемы.

Сообщение от Замабувараев

Во‐вторых, юникод в Windows — это UTF-16. Я не знаю, почему ваши разработчики библиотек std::wcout, std::wstring и прочих не могут этого понять чтобы сделать кроссплатформенное решение.

Лучше скажите почему в вашей виндовс до сих пор не осилили перейти на юникод? До сих пор все эти извращения с cp1251, 866 и utf-16 (который вообще ни туда ни сюда).

Сообщение от Замабувараев

В‐третьих, у WinAPI богатый набор консольных функций, а не одна «вывод в файл».

То есть предлагаете сначала программу писать нормально, а потом переписывать под ваши экзотические функции?

Алексей1153 · 25.08.2021, 09:29

Сообщение от COKPOWEHEU

Или ждать пока в майкрософт осилят наконец юникод

да я про статью на сайте - чтобы перевод кривой не читать

@COKPOWEHEU · 25.08.2021, 09:49

Алексей1153, это-то ладно, зато читать забавно.

@SmallEvil · 25.08.2021, 11:52

Ну и маленький итог для Замабувараев :
Лучше раз создать костыль для установки локали/кодировок и остальной код будет неизменен(почти полностью),
и удобен в работе.
Чем написать только для Windows (еще и нахлебаться при этом дермища с ее ~~супер~~ функциями АПИ).
Но естественно конечный продукт, рассчитанный только на Windows, можно писать и так.
И даже тут, на разные семейства ОС Windows, будешь костылять

@vlisp · 26.08.2021, 08:59

Сообщение от COKPOWEHEU

То есть вместо человеческого, кроссплатформенного и гибкого ввода-вывода

все говорят про нормальный человеческий, но никто не приводит ни одного примера

@Замабувараев · 26.08.2021, 09:18

Если какие‐то cin и cout не умеют правильно вводить и показывать строки, то очевидно, что эти библиотеки кривые и не работают. Я не знаю зачем нужно пользоваться тем что не работает, видимо, какая‐то разновидность доставить себе боль и разочарование.
Напротив, прямые вызовы операционной системы работают. Чтобы починить корявые cin и cout вы всё равно используете WinAPI, несмотря на психологический пунктик против WinAPI. А в итоге починка не удаётся.

@DrOffset · 26.08.2021, 09:42

SmallEvil, Не выводятся wchar_t символы (может быть будет полезно)

@COKPOWEHEU · 26.08.2021, 21:07

Сообщение от vlisp

все говорят про нормальный человеческий, но никто не приводит ни одного примера

Вот наиболее приближенный к человеческому вывод (ввод майкрософты как-то хитро поломали, я не нашел способа его настроить):

C
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
#include <stdio.h>
#include <wchar.h>
#include <locale.h>
#ifdef WIN32
  #include <windows.h>
  #include "fcntl.h"
  __attribute__((constructor)) void coninit(){
    SetConsoleCP(CP_UTF8); SetConsoleOutputCP(CP_UTF8);
    _setmode(_fileno(stdout), _O_U8TEXT);
    _setmode(_fileno(stdin), _O_U8TEXT);
  }
#endif
 
int main(){
#ifdef WIN32
  coninit();
#endif
  setlocale(LC_ALL, "");
  wprintf(L"x\u00B2+7x+4\n");
  return 0;
}

В отличие от варианта с std::wcout, этот работает и в wine тоже.

Сообщение от Замабувараев

Я не знаю зачем нужно пользоваться тем что не работает, видимо, какая‐то разновидность доставить себе боль и разочарование.

Правильно! Если с std::wcout проблемы, просто не пользуемся им. wprintf работает нормально.

Сообщение от Замабувараев

Напротив, прямые вызовы операционной системы работают.

Конечно. Но только в той операционной системе. Поэтому вместо ручной реализации ввода-вывода на низкоуровневых системных функциях стоит максимально использовать высокоуровневый ввод-вывод, который уже написан разработчиками.

Новые блоги и статьи Все статьи Все блоги /
Часы электронные Uhbif79 12.08.2026 Выкладываю программу часов. Программа позволяет: 1. Использовать системное время и дату, 2. Есть возможность вводить время и дату вручную. 3. Реализованы 2 будильника: начало и конец рабочего дня. . . .	Часы с будильником на основе класса QLCDNumber Uhbif79 12.08.2026 Всем добрый день, выкладываю программу часов с будильником на основе класса QLCDNumber. Здесь я пробовал самостоятельно создавал классы, впервые столкнулся с видимостью переменной одного класса из. . .	Установка MinGW GCC 16.2 и CMake 8Observer8 10.08.2026 VK Видео: https:/ / vkvideo. ru/ video-240781534_456239017 YouTube: eY5-5PyI9NM Текстовая версия	Неделя из жизни имитационной модели склада: мои кривые руки растут, откуда надо anaschu 10.08.2026 Неделя из жизни имитационной модели склада: как я почти написал неправильную логику и что с этим делать Работаю сейчас над учебно-рабочим проектом: строю в AnyLogic имитационную модель процессов. . .
Калькулятор для расчета родства russiannick 07.08.2026 1. Задача: Создать калькулятор для расчета родства. Родственных связей существует 8 ступеней, такие как: p - отец P - мать q - муж Q - жена b - брат B - сестра s - сын S - дочь	Мир по моей воле kumehtar 07.08.2026 Когда-то кажется, что всё просто. Ты весь такой светлый. Причиняешь добро. Борешься за справедливость в этом тёмном мире. Потом начинаешь замечать одну неприятную вещь. Почти каждый хороший. . .	Кредитный калькулятор Maks 05.08.2026 Решение задачи по прикладной информатике средствами 1С. Задача: Напишите приложение-калькулятор, которое помогает рассчитывать параметры кредита для аннуитетного и дифференцированного видов. . .	У нас сейчас поговорку "Опять 25" нужно переделать на "Опять +35". kumehtar 04.08.2026 С ностальгией вспоминаю времена моего детства, когда у нас и правда +25 - была максимальная температура летом. Раньше +25 °C реально казались вершиной жары, когда можно было весь день пропадать на. . .

Алексей1153 фрилансер 6500 / 5731 / 1133 Регистрация: 11.10.2019 Сообщений: 15,332
	24.08.2021, 16:54
	COKPOWEHEU, так надо на английский переключать 0

@Замабувараев COM‐пропагандист 936 / 785 / 149 Регистрация: 18.12.2014 Сообщений: 2,256 Записей в блоге: 4
	24.08.2021, 17:30
	COKPOWEHEU, ваш «человеческий, кроссплатформенный и гибкий ввод‐вывод» std::wcout и std::wstring не работает, и вам приходится применять костыли с кодировками. Во‐вторых, юникод в Windows — это UTF-16. Я не знаю, почему ваши разработчики библиотек std::wcout, std::wstring и прочих не могут этого понять чтобы сделать кроссплатформенное решение. В‐третьих, у WinAPI богатый набор консольных функций, а не одна «вывод в файл». 0

@COKPOWEHEU 4148 / 2726 / 433 Регистрация: 09.09.2017 Сообщений: 12,077
	25.08.2021, 09:49
	Алексей1153, это-то ладно, зато читать забавно. 0

@SmallEvil 4086 / 2975 / 813 Регистрация: 29.06.2020 Сообщений: 11,000
	25.08.2021, 11:52
	Ну и маленький итог для Замабувараев : Лучше раз создать костыль для установки локали/кодировок и остальной код будет неизменен(почти полностью), и удобен в работе. Чем написать только для Windows (еще и нахлебаться при этом дермища с ее ~~супер~~ функциями АПИ). Но естественно конечный продукт, рассчитанный только на Windows, можно писать и так. И даже тут, на разные семейства ОС Windows, будешь костылять 0

@Замабувараев COM‐пропагандист 936 / 785 / 149 Регистрация: 18.12.2014 Сообщений: 2,256 Записей в блоге: 4
	26.08.2021, 09:18
	Если какие‐то cin и cout не умеют правильно вводить и показывать строки, то очевидно, что эти библиотеки кривые и не работают. Я не знаю зачем нужно пользоваться тем что не работает, видимо, какая‐то разновидность доставить себе боль и разочарование. Напротив, прямые вызовы операционной системы работают. Чтобы починить корявые cin и cout вы всё равно используете WinAPI, несмотря на психологический пунктик против WinAPI. А в итоге починка не удаётся. 0

@DrOffset 19505 / 10108 / 2463 Регистрация: 30.01.2014 Сообщений: 17,828
	26.08.2021, 09:42
	SmallEvil, Не выводятся wchar_t символы (может быть будет полезно) 0