UTF8/Unicode/Ansicode Konvertierungen!

[Mavarik]

Hallo Zusammen!

Ich steh irgendwie gerade auf dem Schlauch... :stupid:

Die Routine

Delphi-Quellcode:

var
  F : Textfile;
  S : WideString;
begin
  Assignfile(F,'Foo.Dat');
  Rewrite(F);
  S := 'üöäßé•©';
  Writeln(F,S);
  Closefile(F)
end;

Schreib die Zeichen so in die Datei wie sie auf dem Bildschirm stehen...
Als "1Byte" Strings.

Textedit XY schreib die gleiche Zeichenfolge als(üöäÃYéâ_¢Â©) auf die Platte.. UTF8??

Also beim einlesen

Delphi-Quellcode:

var
  F : Textfile;
  S : WideString;
  A : String;
begin
  Assignfile(F,'Foo.dat');
  Reset(F);
  Readln(F,S);          // in S steht üöäÃYéâ_¢Â©  Length(15)=15
  A := UTF8ToString(S); // potenzieller Datenverlust 
  Closefile(F)
end

1. Wieso Datenverlust? Wie wäre es richtig?
2. Wie kann ich, nachdem ich mit A gearbeitet habe den String wieder wegschreiben sodas Editor XY den wieder lesen kann?

Mavarik

[bernau]

Schau mal hier:

http://stackoverflow.com/questions/1...nd-delphi-2009

Man kann eine Codepage als optionalen Parameter angeben.

Ansonsten nicht mehr das alte AssignFile verwenden.

Alternativ TStreamWriter.

Was ist "Textedit XY"

[Mavarik]

Zitat:

Zitat von bernau (Beitrag 1325969)

Schau mal hier:
Man kann eine Codepage als optionalen Parameter angeben.

OK

Delphi-Quellcode:

var
  F : Textfile;
  S : WideString;
begin
  Assignfile(F,'Foo.dat',cp_UTF8);
  Rewrite(F);
  S := 'üöäßé•©';
  Writeln(F,S);
  Closefile(F)
end;

Funktioniert jetzt wie "erwartet"!

aber

Delphi-Quellcode:

var
  F : Textfile;
  S : WideString;
  A : String;
begin
  Assignfile(F,'Foo.dat',cp_UTF8);
  Reset(F);
  Readln(F,S);            // S ist jetzt wie erwartet
  A := UTF8ToString(S);   // A ist jetzt A '����镩'
  Closefile(F)
end;

Doppeltgemoppelt?

Editor: Ich habe eine UTF8 HTML Seite die ich in einen Memo(Code) bearbeiten will um dann wieder html daraus zu machen...
Aber entwerder habe ich im HTML ein "?" oder ein "�"

[bernau]

Hat die HTML-Seite den BOM-Code.

mal mit einem HEX-Editor schauen.

[bernau]

Wiso eigendlich "UTF8ToString"

Wenn du das Textfile mit cp_UTF8 öffnest, dann müsste beim Lesen in der Variablen S doch schon das korrekt decodierte Zeichen stehen. (Nicht getestet. Nur so ne Idee.)

[Sir Rufo]

Wenn man das Encoding mit angibt, dann weiß Delphi, wie es die Strings vom intern verwendeten Unicode (UTF16) beim Speichern codieren soll. In der Datei befindet sich dann der Text im angegebenen Encoding.

Beim Lesen funktioniert das genau umgekehrt (vom xy Encoding nach Unicode UTF16).

Ein zusätzliches

Delphi-Quellcode:

UTF8ToString

hat dann die gleichen Auswirkungen, wie wenn man einen Text von deutsch nach englisch übersetzt und das Ergebnis versucht wieder von deutsch nach englisch zu übersetzen :stupid:

(Bei den beliebten Anglizismen müsste das sogar funktionieren :D)

[himitsu]

HTML muß kein BOM haben (hat es meistens auch nicht), denn dort wird die Kodierung über ein Meta-Tag geregelt.

[bernau]

Zitat:

Zitat von himitsu (Beitrag 1325978)

HTML muß kein BOM haben (hat es meistens auch nicht), denn dort wird die Kodierung über ein Meta-Tag geregelt.

Richtig.

[Uwe Raabe]

Zitat:

Zitat von Mavarik (Beitrag 1325965)

1. Wieso Datenverlust?

Die Warnung gibt dir eigentlich schon alle notwendigen Informationen:

Zitat:

W1058 Implizite String-Umwandlung mit potenziellem Datenverlust von 'WideString' zu 'RawByteString'

Delphi-Quellcode:

Utf8ToString

erwartet einen RawByteString (also einen Byte-String ohne CodePage-Information), bekommt aber einen WideString. Mangels besserer Information macht der Compiler dort aus dem WideString einen AnsiString mit der aktuellen CodePage und gibt diesen als RawByteString an die Funktion. Diese erwartet aber (Hint: Funktionsname) eine UTF-codierten Byte-Sequenz. Das Ergebnis sieht dann in vielen Fällen eher bescheiden aus.

[Mavarik]

Zitat:

Zitat von bernau (Beitrag 1325976)

Wiso eigendlich "UTF8ToString"

Wenn du das Textfile mit cp_UTF8 öffnest, dann müsste beim Lesen in der Variablen S doch schon das korrekt decodierte Zeichen stehen. (Nicht getestet. Nur so ne Idee.)

Klar... Das hat ja auch mit dem Zusatz dann geklappt.

Die HTML Componente kann das komischerweise nicht... Ich teste noch...

[SMO]

Zitat:

Zitat von bernau (Beitrag 1325969)

Man kann eine Codepage als optionalen Parameter angeben.

Ansonsten nicht mehr das alte AssignFile verwenden.

Es gibt auch System.GetTextCodePage und System.SetTextCodePage. Sind aber nur primitive Wrapper für einen Typecast: TTextRec(T).CodePage.

Dass man modernere Methoden für den Dateizugriff verwenden sollte, ist klar. Aber wie sieht es mit Konsolenanwendungen aus?
Da benutze ich noch immer das gute, alte Writeln.

Ein bisschen Off-topic:

Die alten Pascal-Dateifunktionen sind ja seit einiger Zeit Unicodetauglich und Codepage-aware. Das finde ich prinzipiell gut. Allerdings gefällt mir die Implementierung nicht so ganz. Ich habe mich vor einer Weile mal näher damit beschäftigt und festgestellt, dass etliche der _WriteXxx Prozeduren das TTextRec.CodePage Feld missbrauchen, um festzustellen ob die Datei bereits geöffnet wurde. Dafür müsste aber meiner Meinung nach das Feld TTextRec.Mode verwendet werden.
Man suche in System.pas nach "TryOpenForOutput", dann findet man mehrere Male sowas:

Delphi-Quellcode:

if t.CodePage = 0 then TryOpenForOutput(t);

Sollte aber

Delphi-Quellcode:

if t.Mode <> fmOutput then

sein. Man vergleiche dazu die Fundstellen von "TryOpenForInput".

Ist das im aktuellen D10 noch immer so? Falls ja, wer macht den Bugreport?

[himitsu]

Für Console gibt es entweder nette Componenten, die den Zugriff besser regeln und auch weitere Funktionen bieten, wie z.B. Farben und Cursorposition zu ändern.
Und SetFileApisToANSI oder SetFileApisToOEM.

Ansonsten kann man auch auf StdIn und StdOut mit modernen Dateifunktionen zugreifen.