..."Warum nicht nur
Unicode."...
Weil bis Delphi2007 die
VCL NonUniCode war und
UniCode mit TEncoding.XXX insbesondere UTF8 eigentlich erst seit XE5 wo erstmals richtig IOS&Android Mobile funktionieren und die NextGen Compiler brauchbar liefen. Da war dann auch die gemeinsame Delphi
RTL soweit, dass man entschieden AnsiString unter FMX auf MobileDevices komplett zu entfernen so das ed dort nurnoch
UniCode gibt.
Will man also aktuell portable Quelltexte schreiben, muss man für Delphi kleiner gleich D2007 rein NonUnicode mit AnsiStrings für
RTL&
VCL arbeiten.
Will man mit D2009..XE4 arbeiten, hat man zwar
UniCode RTL&
VCL in UTF16
UniCode, aber die anderen Varianten wie UTF8 hakeln dort OutOfThe Box.
Ab XE5 muss man dann bei den NextGen Compilern bei DelphiStrings auch noch beachten, das diese unter Mobile "0" nun basiert sind, also man portabel bei Strings immer schön in Schleifen mit Low(stringX) bis High(stringX) arbeitet. Und immer schön Length(stringX) verwendet, statt der früher noch möglichen Variante per [0]Index.
Da es mittlerweile also praktisch 4 Varianten von "default" DelphiStrings gibt erklärt sich dir eventuell, warum einige wenigsten das alte NonUnicode als AnsiOnly getrennt als eigene Version weiter führen.
1. Wenn du erst jetzt mit XE10.2 "einsteigst" bleibt nur der Rat: Realisiere und akzeptiere das deine gesammte Software per Default als UTF16 läuft.
2. Kümmere dich also nicht um
UniCode ja/nein, sondern kümmere dich da wo es sein muss bei Kontakt zur
WinApi (spziell also bei IniFiles) um eine EIGENE sichere Erkennung und Behandlung und nutze im Programm ausschließlich das per
RTL/
VCL gepufferte "TMemIniFile".
3. Verlasse dich nicht auf aktuell "zufällig" gerade noch funktionierende Vereinfachung per Cast oder direkter Zuweisung unter Nutzung impliziter Konvertierung durch den Delphikompiler... das wurde seit D2009 bis aktuell XE10.2.1 speziell bei UTF8 und
ANSI schon ein paar mal intern angepasst(wie wenn du genau hier mitgelesen hast erkennst, schreiben ja einige das sie bei TEncoding mal keine
Exception bekommen, wo du mit XE10.2 jetzt eine bekommst)
4. auch wenn es schwer fällt, lerne aus der Vergangenheit und nimm jetzt nicht den vermeintlich leichtesten Weg... "früher" (vor D2009) war Delphi mal wegen der "CompilerMagic" die Sprache der Wahl, wenn es um einfaches String handlig ging... jetzt kurz vor dem Sprung auf NextGen Kompiler auch für den Desktop tue dir den Gefallen und denke in UTF16 und behandle alles andere SELBST und kapsele die Konvertierungen in eigene kleine Toolfunktionen... so fällt es dir zukünftig leich nur dort mit ein paar IFDEFs deinen Quelltext mit alten und dann neuen Delphi Versionen zu übersetzen