Als ich früher solche Fragen gestellt habe, lagen die Statements von diversen Delphi-Leuten
irgendwo zwischen "So etwas sollte man nicht machen" und grobem Unverständnis.
So wie oben macht man es ja auch nicht. Hier wäre sinnvoll das was man als OSI-Modell kennt auch entsprechend auf Klassen aufzuteilen und nicht den ganzen Packetaufbau so zusammenzufassen.
Hat man entsprechende Klassen/Helperunits muss man sich um Charactercodierung nur an wenigen Stellen Quellcode Gedanken machen.
Ein Problem hier kann z.B. sein, dass Konstanten wie #$01 nich das liefern, was Du erwartest.
So etwas wird schon mal stillschweigend in andere Char-Codierungen umgewandelt.
Eigentlich nicht. $01 ist immer $01. Egal welche Codierung. Jedoch kann es sein wenn man sowas an
WinAPI-Funktionen übergibt die Strings erwarten das hier diese Sonderzeichen verstümmelt werden weil die Funktion nur Druckbare Zeichen erwartet. Hatte erst vor kurzen den Fall das ein Unicodezeichen kein richtiges Zeichen war und UTF8-Codiert eine defekte
XML-Datei produziert hatte.
Mein Tip: Mach einen Bogen um die XEs.
Mein Tipp. Ist nicht nötig. Die XEs sind sehr gut zu verwenden.
Mit etwas Geduld und Gewalt kriegt man soetwas bestimmt irgendwie hin.
Da braucht man keine Gewalt. Man muss nur verstehen wie Strings Funktionieren und schon funktioniert es in 99% aller Fälle auf Anhieb.
Aber Arbeitszeit aufzuwenden um die ganzen Absonderlichkeiten von einem Tool zu verstehen,
dessen Entwickler es für eine tolle Idee halten den Support für AnsiStrings einzuschränken
(bzw. planen ihn in Zukunft auch mal ganz zu entfernen) ist einfach nicht sinnvoll.
Wenn Du meinst. Man brauche eigentlich in 99% der Fälle keine AnsiStrings. Man muss nur Wissen wie man Daten einlist (Stichworte BOM, Konvertierungsfunktionen, ...) und wie man Sie ausgibt.
Glücklicherweise hat Emba/Delphi den Weg genommen mit Unicodestrings zu arbeiten statt hier eine Krückenlösung ala FreePascal mit UTF8 zu realisieren.
Da wo man sich Delphi XEx keine Gedanken mehr machen muss bezüglich Dateizugriff und Sonderzeichen in Dateinamen, muss man bei Freepascal noch überlegen ob man nun die Funktion mit oder ohne UTF8/native im Namen verwendet.