Re: ANSI oder nicht ANSI?

Jens Lenge schrieb:

Verstehe ich jetzt mal so, dass die Stringfunktionen - egal ob die "alten" (Pos/Copy usw.) oder die mit "Ansi..." - nicht ohne weiteres mit dem neuen UnicodeString funktionieren werden.

Kommt drauf an, was man unter "funktionieren" versteht. An den Funktionen ändert sich eigentlich nichts, wenn sie mit exakt den Daten gefüttert werden wie zuvor.

Wenn dabei aber der String von Unicode auf Ansi gewandelt wird, damit die Funktion ablaufen kann, dann kann diese Umwandlung eine unerwartete Auswirkung haben. Wenn es schon vorher unsinnig war, Pos() auf einen MBCS-String loszulassen, dann ändert sich daran auch bei Unicode nichts.

Verstehe ich richtig?
Falls ja, gibt es bei D2009 dann entsprechende "Unicode..."-String-Funktionen?

Sicher gibt es dort solche Funktionen, nur muß man sich mit deren neuen Grenzen vertraut machen.

Auf die Gefahr hin, mich zu wiederholen:

Die Basisfunktionen (wie Pos/Copy) arbeiten mit 1 bzw. 2 Byte großen "Elementen" (AnsiChar, WideChar), ohne sich darum zu kümmern, ob diese Elemente nun Zeichen, Teile von Zeichen oder ganz andere Informationen enthalten. Das fällt bei mir unter String-Verarbeitung, wo ein String nicht mehr als ein Array Of xyzChar ist.

Wenn es aber darum geht, Texte zu analysieren, auseinanderzunehmen oder zu ändern, dann muß man die dafür vorgesehenen Funktionen verwenden, die nicht z.B. versehentlich ein Byte eines längeren Zeichens verändern, oder die zusammengehörenden Bytes eines Zeichens auseinanderhacken. Dann ist es auch nicht generell möglich, 1 Zeichen in einer Variablen vom Typ Char abzulegen, weil manche Zeichen eben länger sein können als nur ein Element vom Datentyp Char (selbst wenn in D2009 Char=WideChar ist).


Wer sicher ist, daß seine Strings nichts anderes als Ansi-Zeichen enthalten, und damit 1 Char auch genau 1 Zeichen enthält, der sollte bei den AnsiStrings und Ansi-Funktionen bleiben, dann liegt er mit seiner (übernommenen) Stringverarbeitung auf der sicheren Seite. Dann bleibt es auch ohne Folgen, wenn irgendwo im Code versteckt angenommen wird, daß 1 Char genau 1 Byte ist. Solche versteckten Fallen kann der Compiler nicht immer erkennen und anmeckern :-(

Deshalb sollte man IMO vor einer Umstellung auf D2009 die unspezifischen Datentypen String und Char erst einmal durch AnsiString und AnsiChar ersetzen. Im nächsten Schritt muß der Code von Hand durchforstet werden, und man kann wieder auf String und Char umstellen, wenn man sicher ist, daß solche Daten nur unverändert transportiert oder höchstens zusammengesetzt werden, aber nicht auseinandergenommen oder analysiert werden. In denjenigen Teilen, die auch mit Unicode klarkommen, ggf. nach entsprechenden Anpassungen, kann dann auf UnicodeString umgestellt werden. Der Typ WideChar sollte eigentlich garnirgends verwendet werden, da er (wegen UTF-16) garnicht in der Lage ist, wirklich alle Unicode Zeichen aufzunehmen. Dann kann man schon an den Datentypen erkennen, wo man bei der Weiterentwicklung mit Fußangeln rechnen muß.

DoDi
.

Relevant Pages

  • Re: CreateFile pathname
    ... >Instead of passing a char[] as parameter 1, ... Microsoft uses arrays of WCHAR to store UNICODE characters, ... or how to convert a string into the write format. ...
    (microsoft.public.windowsce.embedded.vc)
  • Re: Retrieving text from CEdit box as char *?
    ... Windows CE uses Unicode so strings coming from the OS such as window text ... If you really need a string of char, you need to convert the CString to ... Alternatively, if you don't actually need the string in ASCII format, just ...
    (microsoft.public.windowsce.embedded.vc)
  • Re: porting to 2005
    ... This little function which retrieves a string from an ini file gives all ... I think lots of your problems are caused by incorrect use of 'char' data ... and you will build a Unicode application. ... const CString & section, ...
    (microsoft.public.vc.mfc)
  • Re: Using VC6 code in VS 2005
    ... Both are char strings, no? ... LPTSTR is equivalent to TCHAR *. ... basing on the value of UNICODE and _UNICODE preprocessor macros. ... atoi wants a char* string, but CString::GetBuffer returns a TCHAR string. ...
    (microsoft.public.vc.language)
  • Konvertierung von Unicodezeichen
    ... innerhalb der Textfelder Umlaute und Sonderzeichen als Unicode dargestellt. ... Dort sind jedoch die Zeichen als normaler lesbarer Text ... Function ConvertString(sString As String) As String ... Dim xAs Byte ...
    (microsoft.public.de.access)
Loading