Ist ICU die richtig Wahl für mich



  • Hallo zusammen,

    erst mal möchte ich eine kurze Zusammenfassung meines Problems geben.

    Mein größtest Problem ist wahrscheinlich das ich mich noch nie mit C++ beschäftigt habe sondern immer nur mit C# gearbeitet habe. Leider muss das jetzt mal spontan klappen da ich von Oben nicht wirklich die Zeit bekomme mich richtig mit der Sprache auseinander zu setzen. Deswegen wäre es total toll wenn ihr Erklärungen für Dummys machen könntet. 🙂

    Nun zur Konkreten Problematik.
    Ich habe ein steinaltes Programm hier in dem immer nur mit ANSI Codierung gearbeitet wurde. Nun möchte aber ein Kunde gerne Polnische Artikelnamen speichern.

    Das heißt ich glaube das ich zum einen alle Werte fürs Frontend von UTF-8 in ANSI umwandeln muss und dann zum anderen auch auf dem Rückweg alles was ich vom Frontend bekomme wieder in UFT-8 zurück schreiben muss.

    Warum ich das glaube:
    Die DB ist eine GT.M diese erwartet wenn man sie umstellt, das alles im UTF-8 Format ankommt. Eben auch die fest im c++ Code hinterlegten Datenbankstatements.
    Was ich jetzt im Quellcode sehen kann ist das mir von der DB auch Trennzeichen wie § mit zurück gegeben werden welche im Weiteren Codeverlauf wieder für irgendwas anderes gut sind. Diese kommen für mich bei Debugen als  oder der gleichen an und das Frontend fliegt auf die Nase.

    Was ich bisher rausgefunden habe.
    Eine Convertierung mit MultiBayteToWideChar klappt zwar ganz gut für das was vom Server kommt, aber nur so lange keine Polnischen Zeichen ins spiel kommen.
    Die Libary ICU klingt ganz gut da scheitert es aber wieder am fehlenden C++ können. Und da kann ich auf Grund des Programms alters nur die Version 3.6 einbinden.
    Lib utf-8 schmeißt nur Fehler und kann nicht ins Projekt eingebunden werden.

    Zudem habe ich noch gefunden das ich vielleicht auch Probleme mit meinen Textboxen bekommen könnte, soweit bin ich aber noch nicht vorgedrungen ob dem wirklich so ist.

    Es tut mir leid das das jetzt so ewig lang geworden ist, aber ich verzweifel langsam.

    Es wäre so super nett wenn von euch jemand mir helfen könnte Ordnung in mein Gadankenchaos zu bringen, den hier habe ich leider niemanden mit dem ich drüber sprechen kann geschweige den der mir helfen könnte.

    Viele Grüße
    Franziska



  • Da fällt mir spontan ein Zitat von Andrei Alexandrescu ein: call your head hunter!

    Wenn die DB nur UTF-8 kann, das "Frontend" aber UTF-16 benutzt, scheint MultiByteToWideChar/WideCharToMultiByte doch der logische Weg zu sein. Das funktioniert ganz sicher auch mit polnischen UTF-8 Zeichen.



  • Jetzt muss ich ganz doof fragen wie kann ich mir den Sicher sein das mein Frontend uft16 nutzt bisher fielen hier immer nur die Worte "bisher wird alles in ANSI genutzt".

    Ob meinen Head Hunter schon wieder anrufen soll... Hmm ich weiß ja nicht 🙂 erst mal will ich es etwas länger als 4 Tage versuchen auch wenn's grade echt frustrierend ist.



  • Windows GUIs verwenden UTF-16.
    Wenn dein Frontend ne Windows GUI ist, dann kommt vom OS erstmal alles als UTF-16. Bzw. wenn das Programm ein ANSI Programm ist, dann kommt es als "ANSI", wobei "ANSI" dann heisst: die System-Codepage.

    Du kannst aber in jedem Windows GUI Progamm die Strings auch direkt von den Fenstern/Buttons/... abfragen bzw. setzen - und dabei kannst du immer UTF-16 verwenden wenn du willst.

    Falls dein Programm kein Windows GUI Programm sein sollte... woher sollen wir dann wissen welches Character Encoding es verwendet?



  • Valyse schrieb:

    Jetzt muss ich ganz doof fragen wie kann ich mir den Sicher sein das mein Frontend uft16 nutzt

    Wenn jetzt schon MultiByteToWideChar benutzt wird (das hatte ich aus deinem Post so rausgelesen), dann ist es UTF-16.

    Valyse schrieb:

    bisher fielen hier immer nur die Worte "bisher wird alles in ANSI genutzt".

    Dann wären wohl alle Meldungen und Beschriftungen Latin 1. Polnisch ist Latin 2. Dass beides parallel geht bezweifle ich.



  • Ich hatte im WWW eine Funktion genommen die das MultiByteToWideChar nutzt und habe die eingebaut. Funktioniert aber eben nur so lala.

    Genau das was du sagst das alle Beschriftungen und werte bisher immer in ANSI also Latin 1 gewesen sind ist der Fall, nun muss aber auch mehr möglich sein. Und da wird vorgegeben das dafür jetzt nicht die ganze Solution neu geschrieben werden darf sondern eben nur die Texte umgewandelt werden sollen.

    Langsam bekomme ich aber das ungute Gefühl das, das nicht mal mit, gar nicht so einfach getan ist.
    Ich verstehe einfach je mehr ich google und lese immer weniger. Und Chef macht immer mehr Druck hat aber selbst auch null Plan von dem ganzen.



  • Valyse schrieb:

    Ich hatte im WWW eine Funktion genommen die das MultiByteToWideChar nutzt und habe die eingebaut. Funktioniert aber eben nur so lala.

    Was auch immer lala heißt, folgt daraus:
    1. du kannst UTF-16 anzeigen
    2. wenn die Funktion mit den richtigen Flags und UTF-8 gefüttert wird, kannst du alle Sprachen der Welt verwenden



  • @Valyse
    Ohne Code zu sehen kann ich nicht sagen was das Problem sein könnte. Man kann das auf so viele verschiedene Arten falsch machen dass raten einfach uninteressant ist.

    Das was dein Chef will, also dass nicht alles umgeschrieben werden muss, ist grundsätzlich möglich. Man muss ein Projekt nicht gleich von MBCS auf UNICODE umstellen um darin Unicode verwenden zu können. Je nachdem wo jetzt überall weitere Sprachen unterstützt werden müssen und wie das Programm aufgebaut ist kann das sehr wenig oder auch richtig viel Aufwand werden.

    Was "MultiByteToWideChar funktioniert nur so lala" angeht: wir haben hier quasi nichts an Information von dir, nur dass du diese Funktion irgendwo irgendwie für irgendwas verwendest, und das Ergebnis nicht passt.

    Was ich dir dazu nur sagen kann: An der Funktion MultiByteToWideChar liegt es schonmal nicht, denn die funktioniert wunderbar. Und was du bei der Anwendung falsch machst kann man unmöglich beurteilen wenn man den Code nicht sieht.



  • CString CBRUNIEApp::DecodeFromUTF8(CString szResult)
    {
    	TCHAR* m = new TCHAR[strlen(szResult) + 1];
    	WCHAR* w = new WCHAR[strlen(szResult) + 1];
    	strcpy(m, szResult);
    	MultiByteToWideChar(CP_UTF8, 0, m, -1, w, strlen(szResult));
    	WideCharToMultiByte(CP_ACP, 0, w, -1, m, strlen(szResult), 0, 0);
    	CString AnsiText = m;
    	delete[] m; delete[] w;
    	return AnsiText;
    }
    

    Das die Funktion die ich gefunden habe. Die bisher am ehesten tut was mir vorschwebt. Nur bei dieser Verwendung werden eben wieder zu viele raus nimmt. Wenn ich den quelltext richtig verstehe liegt es daran das alles von utf-8 wieder in ansi umgebrochen wird.



  • Ok, du drehst als eine Schleife über UTF-16, um UTF-8 in ANSI zu verwandeln.

    Statt CP_ACP müsstest du dann wohl 1250 für polnisch verwenden. Ob du es dann aber noch anzeigen kannst?


Log in to reply