Autor Beitrag
hRb
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starontopic star
Beiträge: 267
Erhaltene Danke: 12



BeitragVerfasst: Mo 08.08.22 16:49 
Encoding- Decoding-Problem mit Richedit
(Vorbemerkung: ersuche schon im Vorfeld um Nachsicht. Ich raff’s einfach nicht, kleine Screen-Short-Bildchen hier einzufügen (wäre so schön). Die Hilfe sagt: vorab auf einen Server laden. Aber auf welchen? wohin? Die Seite. www.delphi-forum.de/graphics/df_search.png bringt mich auch nicht wirklich weiter. Vielleicht kann man mir privat nochmals ein Link zukommen lassen wie’s geht. Mein Fragetext ist daher nicht mehr so übersichtlich.)

Problem:
Vielleicht durch eine try-Anweisung, vielleicht auch, weil ich irgendwann beim Compiler das Häkchen gesetzt habe einen bestimmten Exception-Typ zu ignorieren, habe ich lange Zeit einen Programmfehler versteckt bzw. unterdrückt. Nun holt mich das Thema nach Installation von Delphi 10.4 wieder ein und ich würde gerne meine Open-Routine fehlerfrei sehen. Da meine Frage auszuufern droht, fange ich mit kleinen Portionen an.

Erhalte regelmäßig zur weiteren Bearbeitung eine csv-datei. Lese ich diese mit dem Code in der Delphi-Hilfe
docwiki.embarcadero....ngsEncoding_(Delphi)
in eine Memo, ist alles ok. (Anmerkung: ist gemäß Hex-Editor eigentlich eine UTF-16, wird aber vermutlich beim Lesen in ein UTF-8 gewandelt: s.unten)

ausblenden Delphi-Quelltext
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
procedure TForm1.ReadMemoClick(Sender: TObject);
var
  // You may need to change this path to suit your environment.
  Path: String;
begin
  Memo1.ScrollBars := ssBoth;
  Path:= Edit1.Text;
  Memo1.Lines.LoadFromFile(Path); // The encoding is read from the BOM and stored in the Encoding property.
  if Memo1.Lines.Encoding <> nil then
    Edit2.Text := Memo1.Lines.Encoding.EncodingName;
end;

(Diese Procedure liefert kein Error. Beim Lesen der beigestellten CSV-Datei erscheint in Edit2.Text
65001 (UTF8). Der BOM ist gemäß Hex-Editor = FF FE).

Ersetze ich jetzt das Objekt Memo gegen Richedit, dann gibt es einen EncodingError wie folgt:
Benachrichtigung über Debugger-Exception
Im Projekt4.exe ist eine Exception der Klasse EEncodingError mit der Meldung ‚Keine Zuordnung für Unicode-Zeichen in der Multibyte-Zielcodeseite vorhanden‘ aufgetreten
Anhalten, Fortsetzen, Hilfe Diesen Exception-Typ ignorieren.


Durch den Error entsteht beim Save (Decoding) ein Problem, weil die nachfolgenden Befehle nicht mehr ausgeführt werden und Edit2.Text leer bleibt. Dies führt letztlich zu ungewollter Default-Codierung (ANSI)
Soviel für heute (nur kleine Vorschau zum Delphi-Beispiel: Save funktioniert logischerweise auch bei Memo nicht, weil die if-Abfrage niemals greift)

Wer kann helfen, bzw hat eine Erklärung? Wird denn für Memo und Richedit ein anderer Load-Code aufgrufen???
Alternativ: Wer hat richtig gut funktionierende Load-Save Proceduren, die das Thema En- und Decoding beherrschen?

Ich habe die Load- und Save- Proceduren in eine Form1 gepackt als zip-Anhang beigefügt (waar vielleicht wieder größer 5 MB und ging nicht?). Leider kann ich die Original- csv-Datei aus datenschutzrechtlichen Gründen zum Test der Öffentlichkeit nicht bereitstellen und bei jeder kleinen Änderung am Original tritt der Error nicht mehr auf. Es könnte also auch an der Ausgangsdatei liegen (auf die ich keinen Einfluss habe). Aber warum tritt dann kein Fehler bei Memo auf?? Wenn möglich sich also an diesem Thema nicht aufhängen.
Freue mich auf hilfreiche Anworten.
jaenicke
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starofftopic star
Beiträge: 19272
Erhaltene Danke: 1740

W11 x64 (Chrome, Edge)
Delphi 11 Pro, Oxygene, C# (VS 2022), JS/HTML, Java (NB), PHP, Lazarus
BeitragVerfasst: Di 09.08.22 16:21 
user profile iconhRb hat folgendes geschrieben Zum zitierten Posting springen:
Ich raff’s einfach nicht, kleine Screen-Short-Bildchen hier einzufügen (wäre so schön). Die Hilfe sagt: vorab auf einen Server laden.
Du klickst einfach rechts unter dem Feld, in den du den Text für deinen Post schreibst, auf Dateianhang hinzufügen, wählst die gewünschte Datei aus und wenn du das Bild einbetten möchtest klickst du bei Lesbare ID auf "Aus Dateiname erzeugen" oder gibst selbst eine ein. Danach noch ein Klick auf Dateianhang hinzufügen, das war es. Nun kannst du an der Stelle das Bild auch in deinen Beitrag einfügen. Ansonsten hängt es nur als Anhang dran.

user profile iconhRb hat folgendes geschrieben Zum zitierten Posting springen:
Keine Zuordnung für Unicode-Zeichen in der Multibyte-Zielcodeseite vorhanden
Das passiert bei der Umwandlung eines Unicode-Strings in einen AnsiString, wenn es für ein Zeichen kein Ansi-Zeichen gibt. Du kannst aber beim LoadFromFile als zweiten Parameter einfach mal versuchen TEncoding.Unicode anzugeben. Es wäre aber denkbar, dass die Umwandlung nach dem Laden aus der Datei beim Laden in das RichEdit passiert, das weiß ich nicht. Dann würde der Parameter nichts bringen.

Falls möglich kannst du eine Beispiel-Datei auch per PN schicken. Dann kann ich kurz schauen, ob ich direkt etwas sehe. Viel Zeit habe ich nicht, aber das sollte eigentlich nicht lange dauern.
jaenicke
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starofftopic star
Beiträge: 19272
Erhaltene Danke: 1740

W11 x64 (Chrome, Edge)
Delphi 11 Pro, Oxygene, C# (VS 2022), JS/HTML, Java (NB), PHP, Lazarus
BeitragVerfasst: Mi 10.08.22 01:02 
Ich habe die Originaldatei per PN bekommen und konnte den Fehler reproduzieren. Das ist krank...

Ich erkläre mal was passiert. Die Datei ist UTF-8 kodiert inklusive Byte-Order-Mark:

2022-08-10

Wenn diese eingelesen wird, wird das auch korrekt erkannt. Nun wird der Inhalt der Datei aber nicht in einem Rutsch eingelesen, sondern in Teilen. Bei einem davon kommt dann der genannte Fehler beim Versuch von UTF-8 in Unicode umzuwandeln:

2022-08-10_2

Ich habe dann geschaut, bei welchem Teil das Problem auftritt und hatte da schon eine Ahnung woran es liegen könnte. Deshalb habe ich das schnell gesehen:

2022-08-10_1

Heißt:
Ein UTF-8 kodierter Buchstabe wird beim stückchenweisen Einlesen in der Mitte zerteilt. Das ist dann natürlich kein gültiger UTF-8 kodierter Buchstabe mehr...

Eine mögliche Lösung wäre, die Umwandlung in Unicode vorher selbst zu machen:
ausblenden Delphi-Quelltext
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
24:
procedure TForm1.ReadRicheditClick(Sender: TObject);
var
  // You may need to change this path to suit your environment.
  Path: String;
  DataOriginal, DataUnicode: TStringStream;
  myEncoding : TEncoding;
begin
  Richedit1.ScrollBars := ssBoth;
  Path:= Edit1.Text;
  DataOriginal := TStringStream.Create;
  try
    DataOriginal.LoadFromFile(Path);
    if DataOriginal.Encoding <> nil then
      Edit2.Text := DataOriginal.Encoding.EncodingName;
    DataUnicode := TStringStream.Create(DataOriginal.DataString, TEncoding.Unicode, False);
    try
      Richedit1.Lines.LoadFromStream(DataUnicode, TEncoding.Unicode);
    finally
      DataUnicode.Free;
    end;
  finally
    DataOriginal.Free;
  end;
end;

Ich kenne TRichEdit zu wenig, um zu sagen, ob es eine bessere Lösung gibt.
Einloggen, um Attachments anzusehen!

Für diesen Beitrag haben gedankt: icho2099
hRb Threadstarter
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starontopic star
Beiträge: 267
Erhaltene Danke: 12



BeitragVerfasst: Do 11.08.22 20:42 
Hallo jaenicke,
zunächst bin ich super dankbar für die Analyse. Hätte dies selbst nie gefunden.
Wenn ich's jedoch recht verstehe, ist dies ein Fehler bei Embarcadero, mit dem man zunächst weiter leben muss, in der Hoffnnung, dass ein Entwickler mitliest und in einer weiteren Release das Problem behoben wird. (wäre ja auch zu einfach gewesen die Einlese-Routinen von Memo (wo es funktioniert) auch bei Richedit zu verwenden; haben ja die zuweisungsgleichen Variablen Lines und Text).

Habe auch ein wenig "getrickst" und einen Umweg gefunden (allerdings mit "kleinen" Nachteilen):
Lade zunächst csv in Memo1 (fehlerfrei) und weise dann den Text Richedit zu

ausblenden Delphi-Quelltext
1:
Richedit1.Text := Memo1.Text;					

Allerdings findet bei dieser Textzuweisung wieder eine Codewandlung statt, denn aus
Image1
wird
Image2
Das ist bei der jänicke-Lösung nicht der Fall. Also danke!

Möchte das Thema jedoch gerne zu Ende entwickeln, denn das Encoding ist die eine Seite, das Decoding funktioniert in der Delphi-Hilfe auch nicht (Oh, wollte doch das Beispielprogramm (zip) beifügen; war im Debug-Mode zu groß. Vielleicht klappts dieses mal).

Hier wird zunächst wieder Edit2.Text abgefragt. Allerdings steht dort nicht - wie im Delphi-Codebeispiel unterstellt nicht nur Text (ASII, ANSI, etc) , sondern auch die verwendete Codetabelle. D.h. die if-Abfrage wird nie erfüllt und bleibt auf Default. D.h. der Code bleibt erhalten, aber eine Wandlung klappt nicht. Vielleicht könnte man die If-Abfrage anpassen (obwohl: Codetabellen gibt es Hunderte), doch das große ABER kommt jetzt: TEncoding.xxxx liefert nicht viele, sondern nur 2 Varianten.
Im Debugger sieht man:
TEncoding.Default zeigt (true, 1)
TEncoding.ASCII zeigt (true, 1)
TEncoding.Unicode zeigt (false, 4)
TEncoding.BigEndianUnicode zeigt (false, 4)
TEncoding.UTF8 zeigt (false, 4)
Wie soll hier korrekt das Decoding funktionieren? Hätte für 5 Zuweisungen auch 5 unterschiedliche Varianten erwartet. Stehe also ein weiteres mal nur mit Fragen da. Vielleicht gibt es aber auch hier eine Lösung. Wäre super!!!
Danke für alle Beiträge
hRb
Einloggen, um Attachments anzusehen!
jaenicke
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starofftopic star
Beiträge: 19272
Erhaltene Danke: 1740

W11 x64 (Chrome, Edge)
Delphi 11 Pro, Oxygene, C# (VS 2022), JS/HTML, Java (NB), PHP, Lazarus
BeitragVerfasst: Do 11.08.22 22:27 
user profile iconhRb hat folgendes geschrieben Zum zitierten Posting springen:
Wenn ich's jedoch recht verstehe, ist dies ein Fehler bei Embarcadero, mit dem man zunächst weiter leben muss, in der Hoffnnung, dass ein Entwickler mitliest und in einer weiteren Release das Problem behoben wird.
Wenn du kein entsprechendes Ticket bei Embarcadero eröffnest, wird das auch nicht behoben werden.

user profile iconhRb hat folgendes geschrieben Zum zitierten Posting springen:
(wäre ja auch zu einfach gewesen die Einlese-Routinen von Memo (wo es funktioniert) auch bei Richedit zu verwenden; haben ja die zuweisungsgleichen Variablen Lines und Text).
Das ist nicht das Problem:
Das Einlesen funktioniert ja. Nur muss beim Richedit der Inhalt danach an das Windows-Control gefüttert werden. Und dabei passiert der Fehler.

user profile iconhRb hat folgendes geschrieben Zum zitierten Posting springen:
Habe auch ein wenig "getrickst" und einen Umweg gefunden (allerdings mit "kleinen" Nachteilen):
Lade zunächst csv in Memo1 (fehlerfrei) und weise dann den Text Richedit zu
Das kommt auf das gleiche heraus und war auch mein erster Test, aber das Problem daran ist, dass dann der Dateiinhalt zuerst auf die Zeilen aufgesplittet, dann wieder zu einem Text zusammengesetzt und dann im Richedit wieder in Zeilen aufgeteilt wird. Das ist daher sehr ineffizient.

Das Umkodieren in Unicode lässt sich natürlich nicht umgehen, aber bei der Stream-Lösung passiert das in einem Rutsch direkt auf dem Gesamttext.

user profile iconhRb hat folgendes geschrieben Zum zitierten Posting springen:
Hier wird zunächst wieder Edit2.Text abgefragt. Allerdings steht dort nicht - wie im Delphi-Codebeispiel unterstellt nicht nur Text (ASII, ANSI, etc) , sondern auch die verwendete Codetabelle. D.h. die if-Abfrage wird nie erfüllt und bleibt auf Default. D.h. der Code bleibt erhalten, aber eine Wandlung klappt nicht.
Eine sichere Erkennung des Encodings ist nur mit einem passenden Byte-Order-Mark möglich. Ansonsten lassen sich verschiedene Encodings nicht eindeutig erkennen. Man kann auch z.B. verschiedene Codepages nicht erkennen, da man ja nur die Bytewerte der Zeichen in der Datei hat, aber keine Metainformationen dazu. In einem Land kommt mit dem passenden Encoding dann ein Text heraus, in einem anderen Land sieht es nach Kauderwelsch aus. Das kann der Computer aber nicht gut erkennen, außer man versucht eine sprachliche Analyse.

Einige Texteditoren versuchen UTF-8 z.B. an passenden Bytesequenzen zu erkennen. Wenn aber z.B. nur einfache lateinische Buchstaben in einer Datei stehen, gibt es zwischen UTF-8 und Ansi keinen Unterschied.

Ich würde dir raten, die Dateien einmal in einem Hexeditor anzuschauen und die Ergebnisse der Speicherung mit verschiedenen Encodings zu vergleichen.
hRb Threadstarter
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starontopic star
Beiträge: 267
Erhaltene Danke: 12



BeitragVerfasst: Mo 15.08.22 20:12 
Zitat:
Wenn du kein entsprechendes Ticket bei Embarcadero eröffnest, wird das auch nicht behoben werden.

Ich habe vor 2 Wochen eine Anregung oder einen Verbesserungsvorschlag zum Compiler derart eingereicht, zu prüfen, ob beim jeweiligen Umschalten von einer Unit.pas zur nächsten, das Suchfenster nicht erhalten bleiben kann und folgende Antwort erhalten:
Zitat:
Hello ,
The Delphi Community Edition product is supported differently from the other Embarcadero products. Since these products are not eligible for update subscription the Support for these products is only available in the Community Forums, Embarcadero online documentation and the product Frequently Asked Questions (FAQ).Here are links to the Community Forums and online resources for the Community Edition products

Ich mache mir also keine Hoffnung. Außerdem kann ich als Hobbyprogrammierer ein solch schwieriges Thema Embarcadero nicht darlegen. Aber wie jaenicke schreibt:
Zitat:
das ist krank ...
Wie kann es sein, dass nach so vielen Jahren internationaler Codeanwendung ein solcher Fehler in der Libery noch besteht und nicht entdeckt wurde???
Will jetzt aber nicht ablenken. Wäre zu schade. Denn wie oben dargelegt, funktioniert ja das Delphi-Beispiel auch beim Speichern nicht (if-Abfrage immer false, also bleibt TEncoding.Default). Endlich Beispiele vom Entwickler und dann diese Enttäuschung!
ausblenden Delphi-Quelltext
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
procedure TForm1.SaveMemoClick(Sender: TObject);
var
  // You may need to change this path to suit your environment.
  Path: String;
  myEncoding : TEncoding;
begin
  Path:= {vStammDir +} Edit1.Text;
  myEncoding := TEncoding.Default;             // (true, 1)
  if (Edit2.Text = 'ASCII'then
    myEncoding := TEncoding.ASCII;             // (true, 1)
  if (Edit2.Text = 'BigEndianUnicode'then
    myEncoding := TEncoding.BigEndianUnicode;  // (false, 4)
  if (Edit2.Text = 'Default'then
    myEncoding := TEncoding.Default;           // (false, 1)
  if (Edit2.Text = 'Unicode'then
    myEncoding := TEncoding.Unicode;           // (false, 4)
// Do not use UTF7 for this.  It does not have a BOM, and so the encoding cannot be detected on a load.
//  if (Edit2.Text = 'UTF7') then myEncoding := TEncoding.UTF7;
  if (Edit2.Text = 'UTF-8'then    //'65001 (UTF-8)') then
    myEncoding := TEncoding.UTF8;              // (false, 4)
  Memo1.Lines.SaveToFile(Path, myEncoding);
end;

Deshalb nochmals zur Frage zurück:
1. Bin ich der Einzige der sich mit Codewandlung herumschlägt? Niemand etwas Fertiges? Und wenn nein, dann vielleicht für mich zum Weiterknobeln:
2. der Befehl Edit2.Text := Richedit1.Lines.Encoding.EncodingName; liefert als Ergebnis
Image1
Hätte unter EncodingName nur 'ASCII', 'UTF-8', usw. erwartet. Wo kommt die CodepageNr her? Durch die EinzelByte-Auswertung des Streams? Bzw. gibt es weitere Parameter, unter der CodePageNr und Codierung (BOM-Text) getrennt abgefragt werden kann?
3. Wo finde ich noch mehr Infos zu dem einzelnen Parametern des Typ TEncoding? Werde auch bei Microsoft nicht so richtig fündig (obwohl ich mich bemühe). Daher auch lange Rückantwortzeiten. Was bedeuten true/false bzw 1 und 4 bei TEncoding?
Zitat:
Eine sichere Erkennung des Encodings ist nur mit einem passenden Byte-Order-Mark möglich. Ansonsten lassen sich verschiedene Encodings nicht eindeutig erkennen.

Klar, ich lese schon heute in meinem Original-Programm zunächst nur die ersten 5 Bytes einer Datei, untersuche und prüfe auf BOM (es könnte ja auch eine Datei .rft sein die als reiner Text angezeigt werden soll). In den Encoding-Routinen läuft also mehr.
Wäre schön, wenn ich hier noch ein Stückchen weiter käme. Dennoch Dank für alle bisherige "Single-Hilfe".
Einloggen, um Attachments anzusehen!
jaenicke
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starofftopic star
Beiträge: 19272
Erhaltene Danke: 1740

W11 x64 (Chrome, Edge)
Delphi 11 Pro, Oxygene, C# (VS 2022), JS/HTML, Java (NB), PHP, Lazarus
BeitragVerfasst: Mo 15.08.22 22:57 
user profile iconhRb hat folgendes geschrieben Zum zitierten Posting springen:
Ich habe vor 2 Wochen eine Anregung oder einen Verbesserungsvorschlag zum Compiler derart eingereicht, zu prüfen, ob beim jeweiligen Umschalten von einer Unit.pas zur nächsten, das Suchfenster nicht erhalten bleiben kann und folgende Antwort erhalten:
Das betrifft dann nicht den Compiler, sondern die IDE. Das Suchfenster bleibt zwar nicht offen, aber du kannst ganz normal F3 drücken, nachdem du zu einer anderen Unit gewechselt hast, dann suchst du dort nach dem gleichen Suchtext weiter.
Außerdem kannst du auch einfach in allen Dateien suchen (Strg + Shift + F bzw. Suchen --> In Dateien suchen). Da kannst du dann festlegen, in welchen Dateien gesucht werden soll.

user profile iconhRb hat folgendes geschrieben Zum zitierten Posting springen:
Wie kann es sein, dass nach so vielen Jahren internationaler Codeanwendung ein solcher Fehler in der Libery noch besteht und nicht entdeckt wurde???
Sehr große einfache Textdateien werden vermutlich relativ selten als Textdatei (statt als RTF) in ein RichEdit geladen und dann müssen sie ja noch UTF-8 kodiert sein und passende Zeichen enthalten... ;-)

user profile iconhRb hat folgendes geschrieben Zum zitierten Posting springen:
2. der Befehl Edit2.Text := Richedit1.Lines.Encoding.EncodingName; liefert als Ergebnis
[Bild: Image1]
Hätte unter EncodingName nur 'ASCII', 'UTF-8', usw. erwartet. Wo kommt die CodepageNr her?
65001 ist in Windows die Codepage-Nummer für UTF-8.

user profile iconhRb hat folgendes geschrieben Zum zitierten Posting springen:
Was bedeuten true/false bzw 1 und 4 bei TEncoding?
Jetzt verstehe ich erst, was du damit meinst. :idea:

Wenn du einfach mal auf Untersuchen klickst, bekommst du ein weiteres Fenster, in dem du siehst, in welchen Feldern diese Werte drin stehen:
Screenshot_2022-08-15_225118
Nur weil diese beiden Werte gleich sind, heißt das nicht, dass z.B. TEncoding.Unicode und TEncoding.UTF8 identisch sind. Wenn du Dateien damit abspeicherst und byteweise vergleichst, wirst du sehen, dass diese vollkommen unterschiedlich gespeichert wurden.

Es hat einen Grund, weshalb in vielen Editoren, z.B. im Standard Windows-Editor oder auch Notepad++ oder Excel die Möglichkeit besteht, das Encoding selbst anzugeben. Eben weil man es nicht unbedingt korrekt ermitteln kann. Und dann muss der User entscheiden.
Einloggen, um Attachments anzusehen!
hRb Threadstarter
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starontopic star
Beiträge: 267
Erhaltene Danke: 12



BeitragVerfasst: Mo 15.08.22 23:23 
Noch einmal nachgelegt, zum möglichen Vorschlag jaenicke
Leider ist auch Dein Vorschlag nicht "lupenrein".
1. Der Befehl
ausblenden Delphi-Quelltext
1:
Edit2.Text := DataOriginal.Encoding.EncodingName;					

liefert eigenartigerweise nicht wie beim Memo UTF-8, sondern
Image3
2. Weiterhin müsste beim Befehl
ausblenden Delphi-Quelltext
1:
Richedit1.Lines.LoadFromStream(DataUnicode, TEncoding.Unicode);					

vorab noch eine Korrektur erfolgen, denn hier werden beim Load auch der Offset (drei BOM-Byte) mit eingefügt (vor ID;)
Image4

Moderiert von user profile iconTh69: Delphi-Tags hinzugefügt
Einloggen, um Attachments anzusehen!
Th69
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starontopic star
Moderator
Beiträge: 4764
Erhaltene Danke: 1052

Win10
C#, C++ (VS 2017/19/22)
BeitragVerfasst: Di 16.08.22 11:00 
Als Info noch: die Code Page Liste gibt es unter Code Page Identifiers.
jaenicke
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starofftopic star
Beiträge: 19272
Erhaltene Danke: 1740

W11 x64 (Chrome, Edge)
Delphi 11 Pro, Oxygene, C# (VS 2022), JS/HTML, Java (NB), PHP, Lazarus
BeitragVerfasst: Di 16.08.22 17:03 
Stimmt, das BOM wird nicht erkannt. Man muss den TStringStream direkt als UTF8-Stream erstellen:
ausblenden Delphi-Quelltext
1:
  DataOriginal := TStringStream.Create('', TEncoding.UTF8);					
hRb Threadstarter
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starontopic star
Beiträge: 267
Erhaltene Danke: 12



BeitragVerfasst: Di 16.08.22 17:17 
Zitat:
Als Info noch: die Code Page Liste gibt es unter Code Page Identifiers.

Da wurd ich möglicherweise missverstanden. Ich meinte nicht die zahlreichen Identifiers, sondern beim Decoding schreibt man ja nur .NNNN
ausblenden Delphi-Quelltext
1:
2:
myEncoding := TEncoding.UTF8;
Memo1.Lines.SaveToFile(Path, myEncoding);

Wenn aber Edit2.text beim Load einen string liefert aus Page-Identifiers + Codierung = '65001 (UTF-8)' , dann muss ich wieder selbst den string auswerten, um zu wissen, dass es UTF8 ist. Dachte es gibt vielleicht einen Befehl wie
ausblenden Delphi-Quelltext
1:
Edit2.Text := DataOriginal.Encoding.EncodingXXXX; // der nur 'ASCII', oder 'UTF8' oder ...  liefert					

jedenfalls ohne PageNr
und alternativ
ausblenden Delphi-Quelltext
1:
Edit2.Text := DataOriginal.Encoding.EncodingYYYY; //der nur '66001', oder '1200' liefert					

also den Code Page Identifiers
Wollte beim Decoding den bequemen Weg über eine Combobox gehen. Sollte dazu aber qualifiert die Quellcodierung wissen.
(lasst Euch durch den freundlichen Herrn mit Sonnenbrille nicht stören. Das schreibe nicht ich, sondern das entsteht automatisch auf der Seite der Entwicklerecke wenn ich UTF-8 in Klammern setze.)
Ich merke, der Weg ist mal wieder steiniger als gedacht. Vielleicht kommt ja noch was. Danke.

Moderiert von user profile iconTh69: Delphi-Tags hinzugefügt (und dadurch das "Sonnenbrille"-Icon entfernt 8))
jaenicke
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starofftopic star
Beiträge: 19272
Erhaltene Danke: 1740

W11 x64 (Chrome, Edge)
Delphi 11 Pro, Oxygene, C# (VS 2022), JS/HTML, Java (NB), PHP, Lazarus
BeitragVerfasst: Di 16.08.22 17:53 
Vielleicht hilft dir ja dieses Tool: Charset detector

Und hier noch ein Hinweis wie es Microsoft in Notepad gelöst hat: The Notepad encoding detection issues keep coming up

Moderiert von user profile iconTh69: URL-Titel hinzugefügt
Th69
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starontopic star
Moderator
Beiträge: 4764
Erhaltene Danke: 1052

Win10
C#, C++ (VS 2017/19/22)
BeitragVerfasst: Di 16.08.22 18:36 
hRb: Statt des Namens solltest du die TEncoding.Codepage benutzen.
Und mittels der statischen Methode TEncoding.GetEncoding kannst du dann eine TEncoding-Instanz daraus erzeugen.

In der ComboBox kannst du ja trotzdem den Namen dazu anzeigen, merkst dir aber dazu jeweils die CodePage.
hRb Threadstarter
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starontopic star
Beiträge: 267
Erhaltene Danke: 12



BeitragVerfasst: Mo 21.11.22 17:41 
Ich stelle gerade fest, dass ich eine gestellte Frage nicht abgeschlossen habe (sorry). Problem war ja, dass es beim Einlesen einer UTF-8-Datei in ein Richedit zu einem Error kommt.
Analysen von Jänicke aber auch weiterführende Prüfungen ergaben, dass der Fehler nicht nur bei großen Dateien auftritt, sondern grundsätzlich.
Ich habe den Fehler wie empfohlen an Embarcadore gemeldet und die erwartete Antwort erhalten:
Zitat:
Hello ,
Please note that Starter Edition products are supported differently from the other Embarcadero products. Support for these free licenses is limited to the Community Forum and Embarcadero online documentation, including Frequently Asked Questions (FAQ).
Here are links to the Community Forums and online resources for the Starter Edition products

FAQ:
www.embarcadero.com/...s/delphi/starter-faq

Embarcadero Community Forum:
community.idera.com/...loper-tools/p/forums

Embarcadero Documentation Wiki:
docwiki.embarcadero.com/

Sincerely,
Erdie Sabenorio
Technical Support Engineer

To log a support request online please go to
www.embarcadero.com/support
ref:_00D30HwR._5005a2DyPh6:ref

Den Weg kann ich als Free-User also vorläufig vergessen.

Nun gab es ja noch eine Reihe anderer Vorschläge, die Datei vorab zu untersuchen (BOM Lesen, in Stream laden, etc.). Da ich ja nicht nur UTF-8 Dateien, sondern alle Arten der Textcodierung erwarten muss, kommt man um eine umfassende Vorabuntersuchung nicht herum, damit das korrekte encoding beim Einlesen gesetzt werden kann. Im Hinblick auf den eigenen Aufwand habe ich nun das Problem so umgangen, dass ich die Datei zunächst in eine Memo einlese (diese Routine funktioniert) und dann den Text dem Richedit zuweise. Das führt zwar zu doppelter Konvertierung (in Richedit steht schlussendlich eine ANSI-Codierung), aber auch die eigenen Auswertungen kosten Zeit und erfordern entsprechenden Programmieraufwand.
Also keine elegante Lösung, aber eine Lösung.
Dank dennoch für alle Hilfe. hRb