UTF8 und UTF8 mit BOM und dann auch noch Java

[creehawk]

Moin.Moin.

SAMPLE : Ich speichere eine Stringlist als JSON Datei so:

Delphi-Quellcode:

NewJson.SaveToFile(Path + '\info.json',Tencoding.ascii);

Ergibt UTF-8 ohne BOM.

SAMPLE : Ich speichere eine Stringlist als JSON Datei so:

Delphi-Quellcode:

NewJson.SaveToFile(Path + '\info.json',Tencoding.utf-8);

Ergibt UTF-8 mit BOM.

Ich benötige die gleiche Datei in JAVA und in Delphi.

Und jetzt: Umlaute.
UTF-8 ohne BOM liefert in Java alles wie ich es gerne hätte. Delphi (TEdit / TMemo) nicht.
UTF-8 mit BOM liefert in Java nichts, null, niente, in Delphi dann so wie ich es gerne hätte.


Was jetzt? Ich müsste doch jetzt der mit UTF-8 gespeicherten Datei vor oder beim einlesen in Delphi ein BOM verpassen? Oder wie?

creehawk

[sh17]

ASCII ist aber nicht gleich UTF-8

[creehawk]

Ok. Kann ja sein. Fakt ist aber das JAVA UTF8 mit BOM nicht liest, Delphi aber UTF8 mit BOM falsch liest. Und das JAVA Programm kann ich nicht ändern.

creehawk

[Redeemer]

Seit wann funktioniert UTF-8 ohne BOM nicht in Delphi?

Code:

LoadFromString('wuppdi.txt', TEncoding.UTF8)

ist egal, ob da ein zero width no-break space (BOM) am Anfang ist. Ohne Encoding ist das Vorhandensein der BOM hingegen verpflichtend.

[sh17]

Dann erzeuge doch in Delphi einen Stream mit BOM und lösche dann die ersten 3 Byte.

[Bernhard Geyer]

Java arbeitet an vielen Stellen mit UTF8, aber ohne BOM.
Also musst du das machen was sh17 vorschlägt.
Beim Laden umgekehrt. BOM im Stream ergänzen

[creehawk]

Tja, das habe ich zunächst mal zu Fuß gemacht (via HexEditor)und es funktioniert. Hatte ich jetzt nicht gedacht.

Ich habe bisher in Delphi allerdings nicht mit Streams gearbeitet. Wo finde ich da ein Beispiel um eben die bewustten 3 Byte vorne abzuscheiden und das wieder zu speichern?

creehawk

[sh17]

https://stackoverflow.com/questions/...ning-of-a-file

[creehawk]

Ich bin ja jetzt nicht neugierig, aber was hast du als Suchbegriff verwendet ?

creehawk

[sh17]

delphi stream byte delete

[creehawk]

Okay, danke. Ich muss mehr englisch denken......

[TiGü]

Zitat:

Ich muss mehr englisch denken

Immer! In! Englischer! Sprache! Suchen!

Gefühlt ein Großteil der (Programmier-)Probleme lassen sich durch gutes Suchen erschlagen.
Wenn die Leute aber in ihrer nicht-englischen Muttersprache suchen, wird das natürlich nix.

Ich meine, wer erwartet von euch, dass Leute mit Polnisch, Thailändisch oder Suahli passende Suchergebnisse bekommen?

[Delphi.Narium]

Suche für Delphi immer in der Form:

delphi source delphischlüsselwörter

z. B. delphi source stream byte delete

Dann ist es egal in welcher Sprache eine Fundstelle gehalten ist. Delphischlüsselwörter sind überall gleich, da einzig und alleine von Delphi abhängig.

[Uwe Raabe]

Wie Redeemer schon erwähnt hat, kann Delphi auch UTF8 ohne BOM einlesen, wenn das entsprechende Encoding beim Lesen mitgegeben wird. Interessant ist hier also nicht der Java-Code zum Erzeugen, sondern der Delphi-Code zum Lesen.

[Bbommel]

Warum so "kompliziert" mit Streams hantieren und nicht einfach die eingebauten Funktionen nutzen?

Delphi-Quellcode:

var
  strList: TStringList;
begin
  [...]
  strList.writeBOM:=false;
  strList.SaveToFile('myfile.txt',TEncoding.UTF8);
  [...]
end;

Oder gibt es die Eigenschaft "WriteBOM" bei Delphi 10.2 noch nicht? Falls es sie gibt, wäre das wohl die einfachste Lösung. :-)

[sh17]

Einfach will hier keiner :lol:

[Bernhard Geyer]

Zitat:

Zitat von Bbommel (Beitrag 1486336)

Oder gibt es die Eigenschaft "WriteBOM" bei Delphi 10.2 noch nicht? Falls es sie gibt, wäre das wohl die einfachste Lösung. :-)

Da gibts was "out of the box" :shock:

Müsste man schauen ob es auch für die JSON-Klassen gibt.

[Bbommel]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1486339)

Müsste man schauen ob es auch für die JSON-Klassen gibt.

Ich hatte jetzt gar nicht groß weiter auf das JSON geachtet, weil der OP von Stringlisten geschrieben hatte. Daher ging ich jetzt einfach von der TStringList aus und nicht vom JSONWriter oder ähnlichem.

Ich hab übrigens selbst erst vor einigen Monaten hier in der DP gesehen, dass es das "WriteBOM" mittlerweile gibt und das auch jahrelang anders gelöst. :-)

[Redeemer]

Ich hatte mich schon gewundert, woher die BOM kommt, weil TEncoding keine BOM hinzufügt, da das auch für Textfetzen nutzbar ist. :-D Macht also TStringList.

[creehawk]

Tolle Wurst.

Ich rödel jetzt geschlagene Stunden in Streams und Kodierungen rum, hadere mit dem Schicksal und bereite innerlich meinen Rückzug ins Kloster vor, und da kommt einer und sagt schlicht :

Delphi-Quellcode:

    StringList.WriteBom := False;

Fertig. Problem gelöst. Einfach so. Ohne Rücksicht auf mein inneres Gleichgewicht.

Ich gehe jetzt erstmal Holz hacken. Oder die Wiese hinter HAus umgraben. Oder doch ins Kloster?

creehawk

[Redeemer]

Nicht schlimm. WriteBOM ist nicht so offensichtlich, da es an einer Stelle definiert ist, an der man es nicht erwartet. Man würde eher die Existenz von TEncodingUTF8NoBOM erwarten, aber TEncoding-Erben können keine „Header“ erstellen (da sie für den Einsatz mit – in sich jedoch gültigen – Teilstrings gedacht sind), oder einen zusätzlichen Parameter bei SaveToFile/SaveToStream. Es fehlt auch z.B. bei TStringStream.

[TiGü]

Zitat:

Zitat von creehawk (Beitrag 1486352)

Ich gehe jetzt erstmal Holz hacken. Oder die Wiese hinter HAus umgraben. Oder doch ins Kloster?

Warum nicht alles drei? :-D

[philipp.hofmann]

Du musst deinen Arbeitsansatz ändern:
- Frage im Forum stellen
- Holzhacken gehen
- Antwort im Forum lesen
- kurz den Kopf schütteln
- weiter programmieren

Dann hast du eine Lösung für dein Problem und einen Hof voll gehacktem Holz und bist ausgeglichener.

[haentschman]

Zitat:

Ich gehe jetzt erstmal Holz hacken.

Ihttps://www.youtube.com/watch?v=MsggONi5frI :stupid::lol:

[Uwe Raabe]

Wenn ich mich recht erinnere, waren Adriano's Gründe aber andere.

[AndyDF]

Habe gerade aktuell ein sehr ähnliches Thema. Ich erzeuge eine Textdatei per

Delphi-Quellcode:

StringList.SaveToFile(Filename,TEncoding.UTF8);

In diesem Fall darf aber kein BOM enthalten sein. Habe auch gleich das WriteBOM gefunden und gesetzt.
Das geht auch wunderbar unter Windows aber leider nicht unter Android.
Da wird der Textdatei immer der BOM angestellt. Es geht sogar soweit, dass bei WriteBOM := true bei Android gleich zwei BOM´s angehängt sind.

Hat hier jemand eine Idee dazu?

[Incocnito]

Zitat:

Zitat von AndyDF (Beitrag 1486393)

Habe gerade aktuell ein sehr ähnliches Thema. Ich erzeuge eine Textdatei per

Delphi-Quellcode:

TStringList.SaveToFile(Data,TEncoding.UTF8);

In diesem Fall darf aber kein BOM enthalten sein. Habe auch gleich das WriteBOM gefunden und gesetzt.
Das geht auch wunderbar unter Windows aber leider nicht unter Android.
Da wird der Textdatei immer der BOM angestellt. Es geht sogar soweit, dass bei WriteBOM := true bei Android gleich zwei BOM´s angehängt sind.

Hat hier jemand eine Idee dazu?

Ist jetzt aber nicht so, dass "Data" bereits schon ein BOM enthält, oder? 🙈

LG Incocnito

[AndyDF]

Zitat:

Zitat von Incocnito (Beitrag 1486396)

Ist jetzt aber nicht so, dass "Data" bereits schon ein BOM enthält, oder? 🙈
LG Incocnito

Nein - natürlich nicht. Habs in meinem Post richtig gestellt. :-)

[Redeemer]

Nimm StringStream, der kennt AFAIK keine BOM.

[Bbommel]

Merkwürdig ist das aber schon, wenn man sich das SaveToFile von der StringList anschaut, dann läuft das letztlich über SaveToStream und das sieht so aus:

Delphi-Quellcode:

procedure TStrings.SaveToStream(Stream: TStream; Encoding: TEncoding);
var
  Buffer, Preamble: TBytes;
begin
  if Encoding = nil then
    Encoding := FDefaultEncoding;
  Buffer := Encoding.GetBytes(GetTextStr);
  if WriteBOM then
  begin
    Preamble := Encoding.GetPreamble;
    if Length(Preamble) > 0 then
      Stream.WriteBuffer(Preamble, Length(Preamble));
  end;
  Stream.WriteBuffer(Buffer, Length(Buffer));
end;

Da gibt es ja nicht ansatzweise eine andere Behandlung für Android und vor allem auch nichts, weshalb da plötzlich der BOM doppelt drinsteht.

Müsste man vielleicht mal mit dem Debugger durchsteppen, um zu schauen, wo denn das BOM im Buffer/Ergebnis plötzlich auftaucht oder ob es nicht doch schon vorher irgendwie dort reinkommt.

[AndyDF]

Ja, merkwürdig ist das auf alle Fälle. Hatte mir auch das TStrings.SaveToStream() angesehen.
Zumal das WriteBOM auch bei Android in meinem Fall schon zieht. Ist es gesetzt, wird der BOM zwei mal angehangen. Ohne nur einmal.

Debugger geht leider mit der Android App nicht so zuverlässig bei mir.

[Delphi.Narium]

Was liefert denn

Delphi-Quellcode:

Buffer := Encoding.GetBytes(GetTextStr);

? Ist da unter Android schon ein BOM mit drinne, bei Windows aber nicht?

Das müsste doch 'ne Methode von TStrings sein, gibt es da Unterschiede?

[Bbommel]

Ich war jetzt mal neugierig und habe mich da mal etwas durchgehangelt. Am Ende landet man in der Funktion "LocaleCharsFromUnicode" in der Unit "System", welche die eigentliche Arbeit des Konvertierens macht. Und diese Arbeit macht sie wiederum nicht selber, sondern lässt sie vom Betriebssystem machen. Unter Windows wird dazu die Funktion "WideCharToMultiByte" aufgerufen, unter Posix-Systemen entweder mit dem Aufruf von u_strToUTF8WithSub oder von iconv, jenachdem ob die ICU-Bliothek installiert ist.

Uff. ;-) Ich nehme an, dass sich da ein Aufruf tatsächlich anders verhalten kann. Vielleicht wird ja unter Android u_strToUTF8WithSub benutzt und liefert immer ein BOM mit? Das müsste man dann wirklich debuggen oder weiter recherchieren, aber ich hab hier für die Android-Entwicklung nichts eingerichtet. Wenn es so wäre, dass da immer ein BOM rauspurzelt, dann wäre das ja ein Bug, vor allem, wenn zwei BOMs rauskommen. Da könnte man dann einen Eintrag im QP aufmachen.