Wie funktioniert RawByteString? (ab FPC 3.x)

[mschnell]

Wenn ich vor 4 Jahren ein Delphi Projekt hatte und bei Delphi geblieben bin, musste es von 8 Bit ANSI Strings auf 16 Bit Strings umgestellt werden.

Wenn ich weiter bei Delphi bleibe, muss ich es demnächst auf 0-Basierten immutable Strings umstellen.

Wenn ich jetzt dieses Delphi XE Projekt habe und jetzt auf Lazarus umsteige, muss ich es von 16 Bit Strings auf 8 Bit UTF-8 Strings umstellen.

Wenn ich dann das Lazarus Projekt habe, muss ich es demnächst auf die neuen dynamisch codierten Strings (egal welche Codierung) umstellen.

Später dann darf ich vielleicht trotzdem auf die die 0-Basierten immutable Strings (jetzt zwingend 16 Bit codiert) umsteigen.

Wenn ich außer Strings mit sichtbaren Zeichen noch Strings für Byte-Folge verwende, habe ich noch besonders viel Spaß, um die entweder auf irgendwelche codierten Strings, auf RawByteStrings, oder auf Byte Arrays, jeweils mit unterschiedlichen Auswirkungen umzustellen.

Alles höchst erfreulich !

Hätte ich das Projekt doch gleich in Java programmiert !!!!

-Michael

[theo]

Alles höchst erfreulich !
Hätte ich das Projekt doch gleich in Java programmiert !!!!

Ich dachte du programmierst gar nicht mehr sondern motzt nur noch rum?

In den meisten Fällen spielt das doch gar keine Rolle oder ist mit ein paar Handgriffen angepasst.
Ich finde das Thema überbewertet. Mich, und wahrsch. die meisten User, hat dieses String Durcheinander noch nie von einem Projekt abgehalten.

[Socke]

Wenn die Kodierung unbekannt ist, werden die Daten als ASCII (Single-Byte, ein Codepoint ist maximal 1 Byte groß) geladen und mit Heuristiken entschieden, wie sie weiterverarbeitet werden.

Heuristik braucht man nicht: der Codierungstpy und die Länge der einzelnen Codes (1, 2 oder 4 Byte) steht (neben Referenz-Zähler, Länge und Pointer auf den String-Inhalt) im Verwaltungs-Record des Strings.

Ein Heuristik-Problem gibt es nur bei String-Konstanten, wo der Compiler raten muss was der User mit seiner #1234 Notation meint

Die Heuristik ist notwendig. Wenn du meinen Beitrag noch einmal durchliest, wirst du merken, dass die Metadaten im "Verwaltungs-Record des Strings" unter Umständen (Datei, Netzwerk, Registry, Pipes/Prozesse, Datenbank etc.) gar nicht vorhanden sind.

Für Stringkonstanten sollte die Quelltextcodierung ausschlaggebend sein. Leider wird der dafür existierende Compiler-Schalter nicht dafür vorgesehen (er wird als unbaruchbar angesehen).

[Patito]

Um die Compiler-Magig vom FPC2.7.x & D2009+ etwas aufzuklären
String(GetACP) := AnsiString(GET_ACP, AnsiDaten)+UTFString(CP_UTF8, UTF8-Daten) sollte vollgendes durchführen:
String_Daten := AnsiDaten + WideToAnsiMove(UTF8ToWideMove(UTF8Daten)); somit ist Data-Loss möglich

Das sieht nicht sonderlich gut aus. Wird da allen Ernstes reines ASCII erst in WideString gewandelt und dann wieder zurück?

Wie sonst sollte der Compiler die 2Byte Chars auf Single-Byte umstellen können? Oder Ansi Codierungen auf UTF8 automatisch umstellen?

Err... geht das nicht einfacher ohne Umweg?!

[mschnell]

Ich dachte du programmierst gar nicht mehr sondern motzt nur noch rum?

Re: Pascal: Stímmt. Im Moment mache ich jeden Tag 8 Stunden am Tag nur C. Da gibt's keine Strings

In den meisten Fällen spielt das doch gar keine Rolle oder ist mit ein paar Handgriffen angepasst.

Da haben mir meine Kollegen, die ca. 1 Mio Zeilen Delphi betreuen, aber was anderes erzählt ...
Ich würde sie liebend gerne von Lazarus überzeugen, damit wir das System endlich auf Linux umstellen können, weil Windows mit jeder neuen Version mehr nervt. Aber die trauen sich nicht.

-Michael

[EgonHugeist]

Das sieht nicht sonderlich gut aus. Wird da allen Ernstes reines ASCII erst in WideString gewandelt und dann wieder zurück?

Nun.. Ja. Ich bin mir ziehmlich sicher, daß es so funzt. Problem hierbei ist (meiner Meinung nach), daß Funtionen oder Out/Var Parameter NICHT mit zusätzlichen Ergebnis-CodePages, wie ASCII7, existieren und deren Typsierung über den Parameter/Result klar sind: AnsiString/UTF8String/RawByteString/UnicodeString/WideString.

Err... geht das nicht einfacher ohne Umweg?!

Doch! Ein Vögelchen hat mir gezwitschert, daß beim FPC2.7 ein eigenes LibIConv geplant und gebastelt wird. JEDOCH:

Stelle die eine laaaaaange Tabelle vor von #0..High(Word) (Unicode/Wide) oder High(Longword) UCS4 und danach vieeeeeele Spalten von CodePages 0..x mit den äquivalenten Byte-Sequencen, welches je nach CP den "Char" zurück gibt. Somit wäre man in der Lage direkt von CP_x zu CP_y zu kodieren. Anderer seits bringt das Unmengen an Code mit. AFAIK nutzt Delphi+OSX auch iconv für die Umwandlungen.

Nun woher soll den der Compiler wissen, dass in dem String(What Ever) nur ASCII7 Bytes enthalten sind?. Du bist doch der Entwickler und solltest hier für Optimierung sorgen ----> nutze eigen RawByteString Converter!

Die Portierung der Apps ist das kleinere Problem. Zugriffe auf externes muß man jedoch überall anpassen. Siehe Unicode vs. SingleByte-RDBM's.

Zahn der Zeit. Globaliesierung.. Dolle Wurst! LOL

[Scotty]

Das sieht nicht sonderlich gut aus. Wird da allen Ernstes reines ASCII erst in WideString gewandelt und dann wieder zurück?

Nun.. Ja. Ich bin mir ziehmlich sicher, daß es so funzt.

Wie schaut es mit der Geschwindigkeit aus? Ich trau mich schon gar nicht, auf 2.7 zu aktualisieren.
http://forum.lazarus.freepascal.org/ind ... 521.0.html

[Patito]

Nun.. Ja. Ich bin mir ziehmlich sicher, daß es so funzt. Problem hierbei ist (meiner Meinung nach), daß Funtionen oder Out/Var Parameter NICHT mit zusätzlichen Ergebnis-CodePages, wie ASCII7, existieren und deren Typsierung über den Parameter/Result klar sind: AnsiString/UTF8String/RawByteString/UnicodeString/WideString.

Nun ja. Ein Komponentenset, das mit UTF8 arbeitet, sollte in der Tat als Parameter einen UTF8-StringTyp verwenden und keinen allgemeinen String-Container.
Dann kann man sich auch intern einen Haufen unnötiger Encoding-Vergleiche sparen.

Stelle die eine laaaaaange Tabelle vor von #0..High(Word) (Unicode/Wide) oder High(Longword) UCS4 und danach vieeeeeele Spalten von CodePages 0..x mit den äquivalenten Byte-Sequencen, welches je nach CP den "Char" zurück gibt. Somit wäre man in der Lage direkt von CP_x zu CP_y zu kodieren. Anderer seits bringt das Unmengen an Code mit. AFAIK nutzt Delphi+OSX auch iconv für die Umwandlungen.
Nun woher soll den der Compiler wissen, dass in dem String(What Ever) nur ASCII7 Bytes enthalten sind?. Du bist doch der Entwickler und solltest hier für Optimierung sorgen ----> nutze eigen RawByteString Converter!

Wenn ich mich mal so umsehe, ist eigentlich alles an Daten was ich sehe entweder ANSI (alles was jemals über ein Keyboard eingetippt wurde, ...) oder UTF8 (Web, Datenbank-Unicode, ...). Und die Texte bestehen auch noch alle zu 98% aus ASCII. So eine Konvertierung sollte im Normalfall fast nur aus NOPs bestehen.
Wenn man die Konvertierungen wenigstens irgendwo individuell ausprogrammieren kann bestehen vielleicht noch eine Chance das ganze gerade zu biegen.

Ansonsten muss wenn wohl vorerst auf RawByteString setzen und den ganzen Automatismus so gut es geht aushebeln.
Womit man wieder beim Thema "Wie funktioniert RawByteString" wäre...

Wie macht man es jetzt bei RawByteString mit den String-Konstanten? Irgendwelche Heuristiken um das Encoding der Konstanten zu raten funktionieren da ja nicht.
Wie typisiert man jetzt seine Konstanten korrekt?