Polskie znaki w C++, dziwna sprawa ;)

Odpowiedz Nowy wątek
PIKO
2008-02-25 15:34
PIKO
0

Witam.

Poszukałem w forum, ale niestety nie natkołem się na taki problem (ani na rozwiązanie) jaki mnie prześladuje. Mianowicie sprawa wygląda tak:

pisze program w mfc, pod windowsa ce 4.0 i mam dialog z edit boxe'm.

gdy wpisuje do niego tekst przez zmienną typu CEdit(zmienna.SetWindowsText("")) lub CString używając widestringa, tzn. _T("teksk") lub TEXT("text"), z polskimi znakami to wszystko wyświetla się ładnie z polskimi ogonkami i kreskami.

problem się zaczyna gdy, chcę w edit box'e wyswietlic napis z pliku. probowalem juz wiele sposobób pobrania danych z pliku, np. przez fgets, fgetws, fscanf, fwscanf. pobirajac je umieszczałem je też w różnych konstrukcjach: CString, wsting, char[], TCHAR[]. I wszystko to spełzało na niczym: w edit box'e tylko śmieci.
pomyślałem więc: coś jest nie tak z odczytem danych z pliku, więc jak to sprawdzić (debugowanie odpada, gdyż testowane przeze mnie urządzenie nie mam możliwości remote debuging:( ) wpadłem na pomysł aby dane te zapisać dalej do innego pliku. Praktycznie niezależnie od metody odczytu/przechowywania napisów polskie zanczki pięknie (i poprawnie) zapisują sie do pliku.

wtedy więc skończyły się moje pomysły (i opadły mi ręce) i postanowiłem zapytać na forum

Pozostało 580 znaków

2008-02-25 15:52

Rejestracja: 13 lat temu

Ostatnio: 1 rok temu

0

tamten plik ktory pierwotnie chciales otworzyc, zostal zapisany w innym formacie (charset, encoding, jak kto lubi angielskie okreslenia) i jak go czytasz "standardowo", zostaje jego zawartosc po prostu zle odczytana.

pliki ktore tworzysz juz przez samo urzadzenie i odczytujesz odczytujesz, sila rzeczy sa poprawnie interpretowane bo sa zapisywane w tym samym ecnodingu ktorego sie odczyt spodziewa :)

sciagnij ten plik z urzadzenia, otworz w jakims bardziej łebskim edytorze tekstowym (ew. moze tez byc hexeditor..) i podejrzyj jaki jest encoding. moze to UTF8? moze UTF16BE/LE? moze ANSI tylko z dziwna strona kodowa?

jesli ansi, tylko inna strona kodowa - sprawa w miare prosta.. ifstream.imbue() z wlasciwym locale i juz mozesz czytac wstring'i poprawnie. gorzej, jesli to UTF16 - z tym jest troche zabawy zeby strumien przygotowac, ale wykonalne.

daj znac jak poznasz encoding.


no to pojechałem z nieobecnością.. chwila przerwy i prawie rok przeleciał

Pozostało 580 znaków

PIKO
2008-02-26 08:07
PIKO
0

dzięki za odpowiedź.

plik zapisany przez urządzenie, do którego zapisywałem stringi zawierające polskie znaki, po odczytaniu pod windowsem "traci" ogonki - są po prostu zwykle litery np. ą -> a.

nie wiem jak sprawdzić enkoding (otwierałem plik hexeditem). kiedyś używałem gżegrzółki do tego ale w tym przypadku nic nie rozpoznaje. ale mogę np. przesłać ten plik.

po Twoim poście zacząłem się zastanawiać nad tymi ustawieniami lokalnymi platformy, na której uruchamiam program. niestety, urządzenie (a raczej system Windows CE4.2 w nim) nie posiada wśród ustawień lokalnych "Polski". próbowałem użyć też funkcji setlocale ale o ile SDK urządenia posiada locale.h to już nie posiada odpowiedniej biblioteki i nie linkuje się.

jeśli myślę w złym kierunku, to proszę mnie naprostować.

pozdrawiam

Pozostało 580 znaków

2008-02-26 10:10

Rejestracja: 14 lat temu

Ostatnio: 17 godzin temu

0

nie wiem jak sprawdzić enkoding (otwierałem plik hexeditem). kiedyś używałem gżegrzółki do tego ale w tym przypadku nic nie rozpoznaje. ale mogę np. przesłać ten plik.

Otwierasz plik w hex-edicie, bierzesz np. 'ż' i porównujesz kod litery z możliwymi kodami tej litery dla poszczególnych stron kodowych. Jeżeli chodzi o polski to masz m.in. CP852 (DOS), CP1250(Win) i ISO 8859-2.

próbowałem użyć też funkcji setlocale ale o ile SDK urządenia posiada locale.h to już nie posiada odpowiedniej biblioteki i nie linkuje się.

Spróbuj przekonwertować ansi-stringa do unikodu funkcją MultiByteToWideChar, ustawiając stronę kodową na taką w jakiej jest zapisany plik.

CP852 --> 852
CP1250 --> 1250
ISO 8859-2 --> 28592

Pozostało 580 znaków

2008-02-26 11:17

Rejestracja: 13 lat temu

Ostatnio: 1 rok temu

0

prezdewszystkim - ow encoding.. jak otworzyles plik w hexedicie, to widziales cos takiego:

FF FE [hexy]          ...A.L.A
[hexy]                .M.A.K.O
[hexy]                .T.A

ew. FE FF na poczatku, lub bez FF'ek w ogole, czy tez:

[hexy]        GŻEGŻÓŁK
[hexy]        A

czy

[hexy]        G?#EG?#$
[hexy]        !&#A

(znaczki oznaczaja 'krzaki')

pierszy, oznacza kodowanie wielobajtowe stalej dlugosci, jak UTF16 BE lub LE (zalezy ktory uklad FF'ek, a jesli ich brak - to jest 'uszkodzony'..),
drugi - oznacza kodowanie ANSI (czyli 1znak-1bajt, i jakas strona kodowa wybrana np. polska CP1250),
trzeci - kodowanie zmiennej dlugosci, np. UTF7, gdzie znaki zajmuja.. od jednego do wielu bajtow


no to pojechałem z nieobecnością.. chwila przerwy i prawie rok przeleciał

Pozostało 580 znaków

PIKO
2008-02-26 16:16
PIKO
0

witam

Otwierasz plik w hex-edicie, bierzesz np. 'ż' i porównujesz kod litery z możliwymi kodami tej litery dla poszczególnych stron kodowych. Jeżeli chodzi o polski to masz m.in. CP852 (DOS), CP1250(Win) i ISO 8859-2.

sposobem tym wychodzi, że jest to kodowanie CP1250(inaczej latin2). Ale ustaliłem to na podstawie polskich znaczków, które są przepisane z pliku stworzonego pod Windowsem i skopionwanego do urządzenia. Gdy do pliku wyjściowego zapisuje jakieś stringi zapisane z poziomu programu przez np. TEXT("Aążźć") to w pliku wychodzi z nich: "Aazzc", mimo że bezpośrednie wyświetlenie takiego stringu w urządzeniu wygląda poprawnie (są wszystkie ogonki). Nie bardzo to rozumiem. Wygląda jakby następowała jakaś konwersja podczas zapisywania stringów do pliku.

Spróbuj przekonwertować ansi-stringa do unikodu funkcją MultiByteToWideChar, ustawiając stronę kodową na taką w jakiej jest zapisany plik.

CP852 --> 852
CP1250 --> 1250
ISO 8859-2 --> 28592

Niestety dla tego Windowsa CE4.2 (tak wynika z dokumentacji) istnieje tylko CP_APC i CP_OEMCP. Używałem tej funkcji do konwersji stringów w różne strony: plik->urządzenie, urządzenie->plik, urządzenie->urządzenie i najczęściej dostawałe z "ŁÓĆŃ": " AÓ"

Już nie mam pomysłu jak do tego podejść

pozdrawiam
dzięki za odpowiedzi i wyrozumiałość

Pozostało 580 znaków

2008-02-26 16:25

Rejestracja: 14 lat temu

Ostatnio: 17 godzin temu

0

Niestety dla tego Windowsa CE4.2 (tak wynika z dokumentacji) istnieje tylko CP_APC i CP_OEMCP.

Ale próbowałeś wpisywać te kody? U mnie w PSDK też ich nie ma przy opisie MultiByteToWideChar, tylko przy WideCharToMultiByte.

Pozostało 580 znaków

PIKO
2008-02-27 13:28
PIKO
0

Ale próbowałeś wpisywać te kody? U mnie w PSDK też ich nie ma przy opisie MultiByteToWideChar, tylko przy WideCharToMultiByte.

u mnie niezaleznie od funkcji w helpi dla PSDK dla mojego konkretnego urządzenia jest:

Value Description
CP_ACP ANSI code page
CP_MACCP Not supported
CP_OEMCP OEM code page
CP_SYMBOL Not supported
CP_THREAD_ACP Not supported

... i tak na razie pozbyłem się urządzenia na jakiś czas, więc problem jest zawieszony (nie przetestuje teraz niczego w urządzeniu).
dzięki za pomoc
pozdrawiam

Pozostało 580 znaków

Odpowiedz

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