Großes C++ Projekt auf UTF-16 portieren
-
Artchi schrieb:
Das Thema STL und Unicode hatten wir hier schon mal: Die STL ist nicht für Unicode vorbereitet.
Hm... Der C++ Standard ist ja auch schon nicht mehr der neuste - trotzdem IMHO
ganz schön heftig. Und das ganze Projekt umzustellen auf CStrings würde bedeuten
sich noch mehr auf die MFC zu versteifen - eigentlich wollten wir von der
wegkommen.
-
Erstmal werde dir bewusst, dass Win9X dann gestorben ist (in meinen Augen kein Problem). Die MFC, das WinAPI sind voll Unicode-fähig. Die API-Funktionen haben alle eine A- und eine W- Version. Je nach Compilerswitch ruft MessageBox() MessageBoxA() oder MessageBoxW(). Die W will dann natürlich ein wchar_t.
Die STL-Strings sind in der Praxis kein großes Problem. Bei der MFC benutzt sie eh nicht und außerdem machen die nur evtl. Ärger, wenn du random access betreibst (und auch das dürfte höchstens bei asiatischen Zeichen auftreten). Nen String einfach ausgeben, also irgendwie sequentiell lesen ist kein großes Problem. Du musst dir nur immer bewusst sein, dass das n-te wchar_t nicht zwangsläufig das n-te Zeichen ist.
-
Das macht mir ja schonmal Mut
Wie sieht denn das aus bei Dingen, wie:
wstring foo = "abc"; if(foo == "abc") bar();Muss ich dass dann auch alles mit _T bzw. L versehen? Oder merkt er das alleine?
-
Das macht mir ja schonmal Mut
Win9x ist kein Problem - alle unsere Kunden haben, wie wir aus den Bestellungs-
daten sehen können Win XP/2000. Die Software ist auch eher für IT Professionals.
-
L musst du natürlich davor schreiben, sonst ist es kein wchar_t*.
-
Oha... sind die Posts doch noch angekommen *g
Bin den ganzen Tag an der Portierung gewesen. Nach einem simplen Replace von
string durch wstring und dem setzen des Compiler-Flags gab es natürlich
1000ende Fehler, weil alle möglichen Strings zu wchars gemacht werden mussten.
Das ganze wird wohl noch ein paar Tage in Anspruch nehmen - besonders er-
schwerend ist, dass wir noch eine Menge Bibliotheken (z.B. zum Datenbank-
zugriff) nutzen, die noch nie was von Unicode gehört haben...Aber das Ergebnis wird es hoffentlich wieder gut machen
Freu mich schon
auf unsere Werbe-Screenshots mit chinesischen Zeichen
-
Hi
und nicht vergessen die Datenbank auf Unicode umstellen, sonst kommt da noch ne böse überaschung und ihr wundert euch wieso da nur ? oder so komische kästchen stehen.
und noch viel spass beim portieren.
Gruss Termite
ps. Grichisch sieht auch schon ganz lustig aus
Aber ich möcht nicht wissen wie ein chinesisches XP aussieht. Das kann man dan sicher nur noch im blindflug bedienen. Dänisch und Spanisch war bei mir ja schon grauenhaft.
-
Optimizer schrieb:
Du musst dir nur immer bewusst sein, dass das n-te wchar_t nicht zwangsläufig das n-te Zeichen ist.
Hallo,
bei einem aktuellen Projekt wollen wir die Hauptfunktionalitäten in C++ und die GUI in Java machen. C++ soll jedoch von Unicode nichts wissen und nur ASCII verarbeiten. Es ist jedoch so, dass C++ in ein Buffer in der Java-Schicht ASCII reinschreibt, die dann in Java in Unicode konvertiert werden. Der Buffer dient als Model für ein TextArea. Die "Offsets" der Zeichen müssen jedoch beibehalten werden, da z.B. die C++ Schicht dem Buffer sagen kann, dass das n-te Zeichen gelöscht werden soll.
Kann ich sicher sein, dass das n-te java-char im Buffer auch das n-te ASCII-Zeichen ist?danke!
Gruß mathik
-
Ich bin jetzt nicht wirklich sicher, wie das zu verstehen ist. Hast du aus Java-Sicht ein char[] oder ein byte[]? Sagt das C++ Programm, dass der Java-Teil etwas konvertiert in den Buffer schreiben soll, oder schreibt der C++ Teil selber direkt ASCII-Text rein? Vielleicht kannst du das nochmal genauer erklären.
Kann ich sicher sein, dass das n-te java-char im Buffer auch das n-te ASCII-Zeichen ist?
Also ist es ein char[]? Ein Unicode-Zeichen kann in Java auch aus 2 chars bestehen, wie bei UTF-16 üblich. Deshalb hat ein Java-String Methoden, um das n-te Zeichen zu suchen. Wenn du also ein char[] hast, hast du wieder keinen problemlosen random access, es empfiehlt sich daher einen String zu benutzen. Wahrscheinlich ist die beste Vorgehensweise die:
- byte[] von C++ Programmteil geben lassen
- String daraus konstruieren
-
Optimizer schrieb:
Ich bin jetzt nicht wirklich sicher, wie das zu verstehen ist. Hast du aus Java-Sicht ein char[] oder ein byte[]? Sagt das C++ Programm, dass der Java-Teil etwas konvertiert in den Buffer schreiben soll, oder schreibt der C++ Teil selber direkt ASCII-Text rein? Vielleicht kannst du das nochmal genauer erklären.
Kann ich sicher sein, dass das n-te java-char im Buffer auch das n-te ASCII-Zeichen ist?
Also ist es ein char[]? Ein Unicode-Zeichen kann in Java auch aus 2 chars bestehen, wie bei UTF-16 üblich. Deshalb hat ein Java-String Methoden, um das n-te Zeichen zu suchen. Wenn du also ein char[] hast, hast du wieder keinen problemlosen random access, es empfiehlt sich daher einen String zu benutzen. Wahrscheinlich ist die beste Vorgehensweise die:
- byte[] von C++ Programmteil geben lassen
- String daraus konstruierenin JNI wird folgendes gemacht:
char* ascii = "Nur ASCII zeichen hier";
jstring str = (*env)->NewStringUTF(env, ascii);
str an eine Java-Fkt übergeben.ist jetzt immer garantiert, dass str die gleiche Länge hat wie ascii und dass der Offset der Zeichen übereinstimmt?
Gruß mathik
-
Die Länge in Zeichen müssten sowieso gleich sein, sonst wäre es kein gleichwertiger String. Die indizes der Zeichen ... müssten eigentlich auch gleich sein, da es sich ja um ASCII-Zeichen handelt und ich deshalb nicht annehme, dass ein Zeichen mit 2 chars kodiert wird. Ich sehe jetzt kein Problem.
Die binäre 0 am Ende des C-Strings wirst du ja kaum mitzählen.
-
Optimizer schrieb:
Die Länge in Zeichen müssten sowieso gleich sein, sonst wäre es kein gleichwertiger String. Die indizes der Zeichen ... müssten eigentlich auch gleich sein, da es sich ja um ASCII-Zeichen handelt und ich deshalb nicht annehme, dass ein Zeichen mit 2 chars kodiert wird. Ich sehe jetzt kein Problem.
Die binäre 0 am Ende des C-Strings wirst du ja kaum mitzählen.ok, danke!
Gruß mathik