unicode

hi ich versuche mich gerade ein bischen an unicode und wollte mal wissen ob das eine software significant langsamer macht, mir ist klar das er dann immer ca. das doppelte kopieren muß, aber ich hab in ner faq mal was von 100x gelesen, könnt ihr mir da ein bischen auf die sprünge helfen, evtl. tipps was es zu beachten gibt oder nen guten link

die hab ich schon
http://www.chemie.fu-berlin.de/chemnet/use/info/libc/libc_18.html
http://www.cl.cam.ac.uk/~mgk25/unicode.html#linux

lg lolo

^^am kopieren wird nicht liegen. z.b. eine 16-bit CPU macht ja am liebsten 16-bit transfers und kann daher auch prima UTF-16 verarbeiten. langsam wirds nur, wenn zwischen verschiedenen formaten hin- und herkonvertiert werden muss. und das handling von komprimiertem unicode, wie z.b. UTF-8, das ist auch langsam.

rüdiger

Kommt darauf an, welche Unicode-Darstellung du wählst. Wenn du UTF-16/8 oä. nimmst, dann sind Operationen wie das bestimmen der Länge oder der Zugriff auf einzelne Zeichen wesentlich aufwendiger. Dafür ist der Speicherbedarf geringer. Bei UCS-4 braucht dafür jedes Zeichen 4 Byte (also 4 mal so viel, wie sonst üblich) aber dafür sollte die Laufzeit nicht wesentlich unterschiedlich sein.

also ich dachte eher an eine string klasse, wenn ich beim kopieren nicht immer auf '\0' testen muß kann ich doch auch UTF-8/16 mit register breite kopieren, also sollte das nicht so schlimm sein z.b. mit memcpy() oder so? eigentlich gibts ja eh keine alternative irgendwie muß man ja die blöden zeichen darstellen/speichern...

würdet ihr in euerer software unicode und normale strings mischen oder eher die ganze software auf unicode umstellen?

bei windows ist es doch so das per default jede software unicode ist?

noobLolo schrieb:

bei windows ist es doch so das per default jede software unicode ist?

windoof verwendet im kernel UCS-2, jedes zeichen belegt 16 bits. zu jedem string gehört eine struct, die ihn beschreibt: http://msdn.microsoft.com/en-us/library/aa380518(VS.85).aspx (es sind dann keine nullen als ende-kennung nötig). der user-mode hantiert aber auch mit null-terminierten UCS-2 strings rum (also dann 2 null-bytes als abschluss)

rüdiger

noobLolo schrieb:

also ich dachte eher an eine string klasse, wenn ich beim kopieren nicht immer auf '\0' testen muß kann ich doch auch UTF-8/16 mit register breite kopieren, also sollte das nicht so schlimm sein z.b. mit memcpy() oder so? eigentlich gibts ja eh keine alternative irgendwie muß man ja die blöden zeichen darstellen/speichern...

Das Problem bei UTF-8/16 ist ja nicht das kopieren, sondern alles was auf einzelnen Zeichen operiert (also zB Anzahl der Zeichen bestimmen oder auf das nte Zeichen zugreifen).

noobLolo schrieb:

würdet ihr in euerer software unicode und normale strings mischen oder eher die ganze software auf unicode umstellen?

Ich würde alles mit UTF-8 machen.

noobLolo schrieb:

bei windows ist es doch so das per default jede software unicode ist?

Das kann man dem Compiler mitteilen, was man gern hätte: ANSI, DBCS oder UNICODE.
Dafür gibts den Datentyp TCHAR.
http://msdn.microsoft.com/en-us/library/cc842072.aspx
Willst du z.B. Unicode, definierst du

#define UNICODE

http://blogs.msdn.com/oldnewthing/archive/2004/07/15/184076.aspx

rüdiger schrieb:

Ich würde alles mit UTF-8 machen.

keine gute idee, ausser du willst nur die zeichen 0...127 verwenden. ansonsten kriegst du's mit der kodiere/dekodiererei zu tun.

;fricky schrieb:

rüdiger schrieb:

Ich würde alles mit UTF-8 machen.

keine gute idee, ausser du willst nur die zeichen 0...127 verwenden. ansonsten kriegst du's mit der kodiere/dekodiererei zu tun.

Sehr gute Idee. :p
Ich habe es jedenfalls auch so in einem kleinen Windowsprojekt gemacht: Alles was von außen als Text reinkommt ist UTF-8. Intern wird, da wo es sein muss, mit wchar_t gearbeitet und mit der Funktion MultiByteToWideChar nach wchar_t konvertiert, das ist prinzipiell nur eine Zeile für die Umwandlung.

Big Brother schrieb:

Sehr gute Idee.
Ich habe es jedenfalls auch so in einem kleinen Windowsprojekt gemacht: Alles was von außen als Text reinkommt ist UTF-8. Intern wird, da wo es sein muss, mit wchar_t gearbeitet und mit der Funktion MultiByteToWideChar nach wchar_t konvertiert...

du musstest es konvertieren? dann war die idee, utf-8 zu verwenden, wohl doch nicht so gut. *fg*
nee, im ernst. hat man's mit utf-8 datenquellen zu tun, dann muss man sich schon damit auseinandersetzen. oder wenn man mit einem mix aus ascii, chinesischen, kyrillischen, griechischen, usw, -zeichen speicherplatzsparend umgehen will. sonst bringt utf-8 eher nicht so viel. ich würde lieber ein festes format nehmen (ucs-2 z.b.).

;fricky schrieb:

du musstest es konvertieren? dann war die idee, utf-8 zu verwenden, wohl doch nicht so gut. *fg*

Ich wollte es konvertieren, weil ich das UTF-8 Format als Eingangsformat gewählt hatte. :p
Es war ein Windows/Linux Projekt und ich wollte, dass das Programm ein möglichst weit verbreitetes Textformat entgegen nimmt.
Bei ucs-2 würde man z.B. unter Linux nicht ums Konvertieren drum rumkommen, wüßte jedenfalls nicht wie.

rüdiger

Kommt halt auf die Umgebung an. Wenn man nur für Windows entwickelt, dann ist UCS-2 vermutlich praktischer als UTF-8. Aber UCS-2 kann eben nicht alles aus Unicode! UTF-8 hat halt den Vorteil, dass man den meisten Code der char verwendet einfach weiter benutzen kann und es viel Platz spart. Bei wchar_t hat man immer Probleme sobald man für verschiedene Systeme entwickelt (Windows: wchar_t == UCS-2, Linux/OSX: wchar_t == UCS-4).