Autor |
Beitrag |
mathias
      
Beiträge: 59
Erhaltene Danke: 3
|
Verfasst: Di 19.11.13 18:33
Delphi-Quelltext 1: 2: 3: 4: 5: 6: 7: 8: 9:
| procedure TForm1.Button1Click(Sender: TObject); begin Memo1.Lines.SaveToFile('äöü.txt'); end;
procedure TForm1.Button2Click(Sender: TObject); begin Memo1.Lines.LoadFromFile('äöü.txt'); end; |
Dies Zeilen funktionieren ohne Probleme.
Im Explorer wird mir diese Datei angezeigt: "äöü.txt"
Woran liegt das ?
Mit Delphi hatte ich dieses Problem nie.
Moderiert von Narses: Code- durch Delphi-Tags ersetzt
|
|
Marc.
      
Beiträge: 1876
Erhaltene Danke: 129
Win 8.1, Xubuntu 15.10
|
Verfasst: Di 19.11.13 19:23
Probier's mal mit UTF8ToAnsi(s). 
|
|
jaenicke
      
Beiträge: 19312
Erhaltene Danke: 1747
W11 x64 (Chrome, Edge)
Delphi 11 Pro, Oxygene, C# (VS 2022), JS/HTML, Java (NB), PHP, Lazarus
|
Verfasst: Di 19.11.13 23:20
mathias hat folgendes geschrieben : | Mit Delphi hatte ich dieses Problem nie. |
Delphi ist auch sehr viel weiter entwickelt als Lazarus. Die Stringunterstützung bei Lazarus ist leider weder einheitlich noch durchdacht (UTF8 meistens, aber nicht immer, die Stringoperationen sind wegen UTF8 deutlich langsamer als bei Delphi, automatische Konvertierungen wie mit der Compiler Magic bei Delphi gibt es so nicht, ...).
Wenn man das überall manuell korrigiert, funktioniert es, aber da es nicht einheitlich ist, bleibt oft nur try & error.
|
|
mathias 
      
Beiträge: 59
Erhaltene Danke: 3
|
Verfasst: Do 21.11.13 00:02
Danke für den Hinweis mit UTF8, ich konnte mein Programm zu laufen bringen, aber so richtig durch sehe ich nicht.
Ich war immer der Meinung, das ein Zeichen in einem String 8Bit hat, das hat sich wohl unterdessen geändert.
Früher unter DOS war dies so. Unterdessen kann man sogar im Windows Notepad Chinesische Zeichen einfügen.
Ich musste auch feststellen, das TString und TListBox, Zeichenketten unterschiedlich verarbeiten.
|
|
rushifell
      
Beiträge: 306
Erhaltene Danke: 14
|
Verfasst: Do 21.11.13 00:43
Das hast Du schon richtig erkannt. Das hat mit der Unicode-Unterstützung zu tun. So werden z.B. auch chinesische Zeichen unterstützt. Ein Unicode-Zeichen wird in 16 Bit gespeichert. Beim Speichern des Memos wird der Dateiname (warum auch immer) in UTF-8 umgewandelt.
Delphi-Quelltext 1:
| ShowMessage(UTF8Encode('äöü.txt')) |
... hat den gleichen Effekt.
UTF8ToAnsi(Const S: UTF8String):String; wandelt einfach den in UTF-8 codierten String in Ansi um und umgeht so das Problem.
Viele Grüße
|
|
jaenicke
      
Beiträge: 19312
Erhaltene Danke: 1747
W11 x64 (Chrome, Edge)
Delphi 11 Pro, Oxygene, C# (VS 2022), JS/HTML, Java (NB), PHP, Lazarus
|
Verfasst: Do 21.11.13 07:08
rushifell hat folgendes geschrieben : | Ein Unicode-Zeichen wird in 16 Bit gespeichert. Beim Speichern des Memos wird der Dateiname (warum auch immer) in UTF-8 umgewandelt. |
Das stimmt eben gerade nicht. Delphi benutzt 16 Bit pro Unicodezeichen.
Lazarus hingegen benutzt UTF-8, sprich wie viel Byte ein Zeichen braucht ist nicht eindeutig festgelegt, sondern varriiert zwischen einem und vier Byte. Deshalb ist das Stringhandling dort auch komplizierter und langsamer als bei Delphi.
UTF-8 wird unter Betriebssystemen wie Linux oder Mac intern genutzt, anders als bei Windows. Das ist auch der Grund weshalb Lazarus damit arbeitet.
Deshalb wird da nichts beim Speichern in UTF-8 umgewandelt, sondern der Dateiname liegt intern als UTF-8 vor und muss aufgrund der fehlenden automatischen Konvertierung manuell konvertiert werden.
|
|
Martok
      
Beiträge: 3661
Erhaltene Danke: 604
Win 8.1, Win 10 x64
Pascal: Lazarus Snapshot, Delphi 7,2007; PHP, JS: WebStorm
|
Verfasst: Do 21.11.13 08:10
jaenicke hat folgendes geschrieben : | Deshalb wird da nichts beim Speichern in UTF-8 umgewandelt, sondern der Dateiname liegt intern als UTF-8 vor und muss aufgrund der fehlenden automatischen Konvertierung manuell konvertiert werden. |
Wobei das an der Stelle ein Bug ist, das sollte nicht so sein.
TFileStream ruft ganz am Ende CreateFile(PChar(string),...) auf, was dann vermutlich CreateFileA ist, dem dann direkt der UTF8-String reingeworfen wird. Kann so nicht gehen.
Wer macht den Bugtracker-Eintrag auf?
Vorher wäre allerdings mal noch zu prüfen, ob String-Literale denn nun eigentlich als UTF8 eincompiliert werden sollten oder nicht.
_________________ "The phoenix's price isn't inevitable. It's not part of some deep balance built into the universe. It's just the parts of the game where you haven't figured out yet how to cheat."
|
|
rushifell
      
Beiträge: 306
Erhaltene Danke: 14
|
Verfasst: Do 21.11.13 10:18
jaenicke hat folgendes geschrieben: | UTF-8 wird unter Betriebssystemen wie Linux oder Mac intern genutzt, anders als bei Windows. Das ist auch der Grund weshalb Lazarus damit arbeitet. |
Ach so, ich dachte, Lazarus würde Widestrings mit 16 Bit-Unicode Zeichen nutzen.
Wobei man unbedingt dazusagen muss, dass UTF8ToAnsi nur eine Notlösung ist und mit Unicodezeichen, die nicht im Ansi-Zeichensatz vorkommen, logischerweise nicht funktionieren wird. Mit Umlauten ist das kein Problem, da diese im Ansi-Zeichensatz enthalten sind.
|
|
mathias 
      
Beiträge: 59
Erhaltene Danke: 3
|
Verfasst: Do 21.11.13 19:05
Habe ich das jetzt richtig verstanden ?
Ein ANSI-String besteht auch 8 Bit, ein UTF8-String kann 8,16,24 oder 32 bestehen.
In meinem Programm war der Fehler in FindFirst, mit FindFirstUTF8 hat es geklappt.
Bei jpeg.SaveToFile, musst ich das UTF8toANSI entfernen.
Bei den Memo1.Lines.SaveToFile('äöü.txt') im obersten Beitrag braucht es das UTF8toANSI.
Momentan sehe ich da nicht mehr durch.
|
|
jaenicke
      
Beiträge: 19312
Erhaltene Danke: 1747
W11 x64 (Chrome, Edge)
Delphi 11 Pro, Oxygene, C# (VS 2022), JS/HTML, Java (NB), PHP, Lazarus
|
Verfasst: Do 21.11.13 21:25
mathias hat folgendes geschrieben : | Momentan sehe ich da nicht mehr durch. |
Das geht nicht nur dir so...
Meine Strategie ist an der Stelle auch Trial&Error bei Lazarus, wenn ich mal damit etwas machen muss. Nach Logik suchen kostet nur Zeit. 
|
|
mathias 
      
Beiträge: 59
Erhaltene Danke: 3
|
Verfasst: Fr 22.11.13 19:52
|
|