Autor |
Beitrag |
hRb
Beiträge: 269
Erhaltene Danke: 12
|
Verfasst: 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)
Delphi-Quelltext 1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11:
| procedure TForm1.ReadMemoClick(Sender: TObject); var Path: String; begin Memo1.ScrollBars := ssBoth; Path:= Edit1.Text; Memo1.Lines.LoadFromFile(Path); 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
Beiträge: 19285
Erhaltene Danke: 1743
W11 x64 (Chrome, Edge)
Delphi 11 Pro, Oxygene, C# (VS 2022), JS/HTML, Java (NB), PHP, Lazarus
|
Verfasst: Di 09.08.22 16:21
hRb hat folgendes geschrieben : | 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.
hRb hat folgendes geschrieben : | 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
Beiträge: 19285
Erhaltene Danke: 1743
W11 x64 (Chrome, Edge)
Delphi 11 Pro, Oxygene, C# (VS 2022), JS/HTML, Java (NB), PHP, Lazarus
|
Verfasst: 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:
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:
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:
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:
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 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
Beiträge: 269
Erhaltene Danke: 12
|
Verfasst: 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
Delphi-Quelltext 1:
| Richedit1.Text := Memo1.Text; |
Allerdings findet bei dieser Textzuweisung wieder eine Codewandlung statt, denn aus
wird
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
Beiträge: 19285
Erhaltene Danke: 1743
W11 x64 (Chrome, Edge)
Delphi 11 Pro, Oxygene, C# (VS 2022), JS/HTML, Java (NB), PHP, Lazarus
|
Verfasst: Do 11.08.22 22:27
hRb hat folgendes geschrieben : | 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.
hRb hat folgendes geschrieben : | (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.
hRb hat folgendes geschrieben : | 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.
hRb hat folgendes geschrieben : | 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
Beiträge: 269
Erhaltene Danke: 12
|
Verfasst: 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:
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!
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 Path: String; myEncoding : TEncoding; begin Path:= Edit1.Text; myEncoding := TEncoding.Default; if (Edit2.Text = 'ASCII') then myEncoding := TEncoding.ASCII; if (Edit2.Text = 'BigEndianUnicode') then myEncoding := TEncoding.BigEndianUnicode; if (Edit2.Text = 'Default') then myEncoding := TEncoding.Default; if (Edit2.Text = 'Unicode') then myEncoding := TEncoding.Unicode; if (Edit2.Text = 'UTF-8') then myEncoding := TEncoding.UTF8; 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
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
Beiträge: 19285
Erhaltene Danke: 1743
W11 x64 (Chrome, Edge)
Delphi 11 Pro, Oxygene, C# (VS 2022), JS/HTML, Java (NB), PHP, Lazarus
|
Verfasst: Mo 15.08.22 22:57
hRb hat folgendes geschrieben : | 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.
hRb hat folgendes geschrieben : | 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...
hRb hat folgendes geschrieben : | 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.
hRb hat folgendes geschrieben : | Was bedeuten true/false bzw 1 und 4 bei TEncoding? |
Jetzt verstehe ich erst, was du damit meinst.
Wenn du einfach mal auf Untersuchen klickst, bekommst du ein weiteres Fenster, in dem du siehst, in welchen Feldern diese Werte drin stehen:
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
Beiträge: 269
Erhaltene Danke: 12
|
Verfasst: Mo 15.08.22 23:23
Noch einmal nachgelegt, zum möglichen Vorschlag jaenicke
Leider ist auch Dein Vorschlag nicht "lupenrein".
1. Der Befehl
Delphi-Quelltext 1:
| Edit2.Text := DataOriginal.Encoding.EncodingName; |
liefert eigenartigerweise nicht wie beim Memo UTF-8, sondern
2. Weiterhin müsste beim Befehl
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;)
Moderiert von Th69: Delphi-Tags hinzugefügt
Einloggen, um Attachments anzusehen!
|
|
Th69
Beiträge: 4785
Erhaltene Danke: 1055
Win10
C#, C++ (VS 2017/19/22)
|
Verfasst: Di 16.08.22 11:00
Als Info noch: die Code Page Liste gibt es unter Code Page Identifiers.
|
|
jaenicke
Beiträge: 19285
Erhaltene Danke: 1743
W11 x64 (Chrome, Edge)
Delphi 11 Pro, Oxygene, C# (VS 2022), JS/HTML, Java (NB), PHP, Lazarus
|
Verfasst: Di 16.08.22 17:03
Stimmt, das BOM wird nicht erkannt. Man muss den TStringStream direkt als UTF8-Stream erstellen:
Delphi-Quelltext 1:
| DataOriginal := TStringStream.Create('', TEncoding.UTF8); |
|
|
hRb
Beiträge: 269
Erhaltene Danke: 12
|
Verfasst: 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
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
Delphi-Quelltext 1:
| Edit2.Text := DataOriginal.Encoding.EncodingXXXX; |
jedenfalls ohne PageNr
und alternativ
Delphi-Quelltext 1:
| Edit2.Text := DataOriginal.Encoding.EncodingYYYY; |
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 Th69: Delphi-Tags hinzugefügt (und dadurch das "Sonnenbrille"-Icon entfernt )
|
|
jaenicke
Beiträge: 19285
Erhaltene Danke: 1743
W11 x64 (Chrome, Edge)
Delphi 11 Pro, Oxygene, C# (VS 2022), JS/HTML, Java (NB), PHP, Lazarus
|
Verfasst: 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 Th69: URL-Titel hinzugefügt
|
|
Th69
Beiträge: 4785
Erhaltene Danke: 1055
Win10
C#, C++ (VS 2017/19/22)
|
Verfasst: 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
Beiträge: 269
Erhaltene Danke: 12
|
Verfasst: 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
|
|
|