Windows-Kompatibilität von Strings erhalten

[QuickAndDirty]

Hallo!

Ich Schreibe eine Anwendung für Android und IOs und Windwos Desktop. Die App soll auf Desktops laufen um leicht präsentierbar zu sein. Und auch auf Windows Tabletts zuhause sein.

Jetzt wo ich die Kommunikation der App angehe stoße ich auf ein Problem.

Die AnsiStrings.

Ich habe mir das angesehen wenn ich die in 0-basierte ByteArrays umwandle geht das alles...nicht mehr auf dem Desktop,
denn da verhalten sich "String" Variablen 1-basiert.

Gibts ne Möglichkeit die Stringvariablen auf dem Windows Desktop auch 0-basiert zu machen?

Ich würde gerne weitgehend einen einzigen Code für alle Zielplattformen Entwickeln.

[mkinzler]

Verwende den record helper für den Stringtyp.

[QuickAndDirty]

Zitat von mkinzler:

Verwende den record helper für den Stringtyp.

Das gedachte ich zu tun, wenn du den TStringHelper meintest.
Ich muss also alle Copy, Replacestring, Delete &c aufrufe durch passende aus tStringhelper ersetzen.

Also werde ich um zwei konvertierungsmethoden für ByteArrays nicht rum kommen, je nach dem ob es 0-based strings oder 1-bases strings sind.

Dann fehlen noch all die lieb gewonnenen String-Manipulations Methoden für Bytearrays....
Wo kann ich da protestieren?

[mkinzler]

Der Helper sollte die Unterschiede zwischen den Plattformen berücksichtigen und unabhängig von ihnen immer das selbe Ergebnis liefern.

[QuickAndDirty]

Wenn ich in TIDContext.IOHandler.DefStringEncoding
Beides mal ASCIIencoding habe. Was lese ich dann in der Mobile-App mit dem TIDContext.IOHandler.Readln Befehl aus?

Ist das Ergebnis ein String mit mit 2 Byte für jedes Byte im Ascii-String der von Windows gesendet wurde?
Oder ist da Ergebnis ein Unicode String der jeweils zwei Original Ascii Zeichen in ein Unicodezeichen codiert?
Wenn es ersteres ist, was ist dann mit Zeichen die garnicht Teil des Ascii codes sind,
wie "ÖÄÜ" die sind ja durch codepage 1252 Kodiert, aber diese angaben kann ich bei Indy nicht machen, oder?

[himitsu]

Low(string) = 0 oder 1 oder man könnte das "komische" neue Verhalten einfach abschalten {$ZEROBASEDSTRINGS ON/OFF}

[Bambini]

Zitat von QuickAndDirty:

Wenn ich in TIDContext.IOHandler.DefStringEncoding
Beides mal ASCIIencoding habe. Was lese ich dann in der Mobile-App mit dem TIDContext.IOHandler.Readln Befehl aus?

Ist das Ergebnis ein String mit mit 2 Byte für jedes Byte im Ascii-String der von Windows gesendet wurde?
Oder ist da Ergebnis ein Unicode String der jeweils zwei Original Ascii Zeichen in ein Unicodezeichen codiert?
Wenn es ersteres ist, was ist dann mit Zeichen die garnicht Teil des Ascii codes sind,
wie "ÖÄÜ" die sind ja durch codepage 1252 Kodiert, aber diese angaben kann ich bei Indy nicht machen, oder?

Wenn es Cross-Encoding gehen soll, würde ich die Strings immer im UTF8 Encoding versenden.

[QuickAndDirty]

Danke, euch allen.
Ich habe die String-Behandlung jetzt komplett auf den TStringhelper umgestellt.
Und einige coole Abkürzungen bietet der auch noch.(Split & Joyn Hallelulja, EndsWith, Startwith, Trim(['"']) usw.)
MeinString.Chars[0] liefert ja auf allen Plattformen das erste Zeichen usw.

Indy war kein so großes Problem wie angenommen. Auf das Encoding des Servers habe ich keinen Einfluss, aber wenn man es als AsciiEncoding empfängt liefert Readln im Client dennoch einen brauchbaren Unicodestring.