Hallo Zusammen!

Ich steh irgendwie gerade auf dem Schlauch...

Die Routine

markieren

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

zusammenfalten · markieren

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

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"

Zitat von bernau:

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

OK

markieren

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

zusammenfalten · markieren

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 "�"

Hat die HTML-Seite den BOM-Code.

mal mit einem HEX-Editor schauen.

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.)

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 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

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

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

Zitat von himitsu:

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

Richtig.

Zitat von Mavarik:

1. Wieso Datenverlust?

Die Warnung gibt dir eigentlich schon alle notwendigen Informationen:

Zitat:

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

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.

Zitat von 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.)

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

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