Unicode und FPC/Lazarus

[marcov]

Absolut richtig.
Alle diese "Systeme" müssen entsprechend betrachtet werden.

Systeme sind alles was man als ein Blackbox von Pascal beherrschter Kode sehen kann. Also alles außer direkte Kommunikation mit den Außenwelt. Man kann etwas vom Database an GUI übergeben, mit vielleicht noch eigenen Datastrukturen dazwischen usw.

Ein Expression wie

Code: Alles auswählen

x:=x+s;

mit s eine andere Codierung als x würde sorgt dafuer das x utf8 (oder -16) wird, weil nur Unicode ein Superset aller Codierungen ist. Früher oder Später hat man die Konvertierungen in ein etwa heterogenes System doch.

z.B. für das "Basis"-"System", das aus "pos", "copy", "delete", "s[i]" etc besteht, macht das bereits jetzt der Compiler und behandelt die Funktionen so, als wären die Formal-Parameter und die rechte Seite der Zuweisung dynamish (polymorphisch) codiert.

Über TStrings haben wir gerade diskutiert. (Ergebnis steht natürlich noch aus und ist aufgrund des "zu viel Arbeit" Arguments sowieso rein theoretisch.)

Und inkompatibel, und das Problem mit der [] operator, und und.

Ein weiteres "System" wäre die LCL. Hier scheint es mir am sinnvollsten zu sein, die Festlegung auf einen bestimmten Typ da zu machen, wo über den angebundenen externen Widget-Set entschieden wird. Der erfordert natürlich einen festen Codierungs-Typ.

Nicht unbedingt. Mann muss nur jede durchgeben nach/von extern Funktionen mit Codierung Rechnung halten, und das muss man immer (auch im D7, D2009+ und heutigen Lazarus fall). Es ist nur das in die Unicode Systeme man etwas mehr weißt von der Kodierung. (Lese eine bestimmte Unicode Version).

Für "Systeme", die die Anwender implementieren, sind sie selbst verantwortlich.

Alle Systeme sind gelinkt. Ein TStringlist in ein Anwender System macht das System RTL+Anweder Kode wird usw. Also System ist der größten Blackbox der man im Pascal Kode definieren kann. Insgesammt alles, RTL,FCL, Komponenten, anwender Kode, weil das String Kode unter Kompiler Kontrolle ist.

[Patito]

mit s eine andere Codierung als x würde sorgt dafuer das x utf8 (oder -16) wird, weil nur Unicode ein Superset aller Codierungen ist.

Hier steckt schon einer der Fehler!

Unicode ist eben kein Superset aller möglichen Codierungen. Es ist nun wirklich nicht schwer Gegenbeispiele zu finden...

Hier mal ein paar:
1) Filenamen (in Linux und Windows) - (sind nicht immer verlustfrei in Unicode konvertierbar - Filesysteme sind wohl älter als Unicode)
2) Barcodes (was ist FNC1 in Unicode?)
3) Sequenzen von Tastaturcodes (was ist F12 in Unicode?)
4) Stringbuffer - Unicode Texte, die in Blöcke fester Länge zerlegt werden, sind kein Unicode, und können nicht so einfach hin und her codiert werden.
z.B. hat so etwas wie LeftStr(text, 10) ggf. keine mit Unicode kompatible Codierung mehr.

Wer ein wenig überlegt, wird leicht mehr davon finden...

Man kann sich natürlich auf den Standpunkt stellen, dass alles was nicht ins Unicode Schema passt nicht schön genug ist um
ein String zu sein. Dann programmiert man aber leider nur bei den Anfängern im Sandkasten der Lehrsprachen.

[Mathias]

3) Sequenzen von Tastaturcodes (was ist F12 in Unicode?)

Gibt es dafür einen Unicode ?
Ich dachte, dies sei eine normale Funktions-Taste, ausser bei DOS, dort ist bei F10 fertig.

[m.fuchs]

Hm, irgendwie verstehe ich nicht so ganz was du sagen willst, könntest du das noch näher ausformulieren?

1) Filenamen (in Linux und Windows) - (sind nicht immer verlustfrei in Unicode konvertierbar - Filesysteme sind wohl älter als Unicode)

Welche Filenamen kann man denn nicht in Unicode darstellen?

2) Barcodes (was ist FNC1 in Unicode?)

Was haben Barcodes mit Strings zu tun? Das FNC1 dient meines Wissens als Trennerzeichen zwischen Code-Bestandteilen. Das muss doch der Barcode-Reader behandeln und dann mehrere Datensätze zurückliefern.

3) Sequenzen von Tastaturcodes (was ist F12 in Unicode?)

Was haben Keycodes mit Strings zu tun? OnKeyDown und OnKeyUp liefern den Keycode zum Beispiel als Word zurück.

4) Stringbuffer - Unicode Texte, die in Blöcke fester Länge zerlegt werden, sind kein Unicode, und können nicht so einfach hin und her codiert werden.
z.B. hat so etwas wie LeftStr(text, 10) ggf. keine mit Unicode kompatible Codierung mehr.

Das Beispiel verstehe ich auch nicht. Man soll natürlich auch die entsprechenden Methoden verwenden. UTF8LeftStr trennt ja brav nach dem fünften Zeichen.

[mse]

Welche Filenamen kann man denn nicht in Unicode darstellen?

Unter Linux sind Dateiname kein Text sondern ein array of bytes. Es gibt also keine definierte Text-Kodierung und es kann ohne weiteres vorkommen, dass Linux Dateinamen ungültige utf-8 Sequenzen enthalten. Unter Windows sind ungültige utf-16 Sequenzen möglich.
Bekannterweise arbeitet MSEgui ausschliesslich mit utf-16. In MSEgui löse ich das Problem so, dass an der Schnittstelle zum Betriebssystem die ungültigen Bytes in einen privaten Bereich der Unicode-Codierung (konkret $f800) verschoben werden. Beim übergeben eines MSEgui Dateinamens an Linux werden die ungültigen utf-8 Sequenzen rekonstruiert. Diese Methode ist natürlich nicht Unicode da nicht genormt.
Zur Erinnerung, in MSElang gibt es die String Typen "string8" (utf-8), "string16" (utf-16), string32 (utf32/UCS4) und "bytestring" für beliebige Codierung und binäre Daten.
https://gitlab.com/mseide-msegui/mselang/wikis/home

Das Beispiel verstehe ich auch nicht. Man soll natürlich auch die entsprechenden Methoden verwenden. UTF8LeftStr trennt ja brav nach dem fünften Zeichen.

Bei der Übertragung von utf-8 wird der Text häufig in Blöcke fester Länge unterteilt. Das führt dann natürlich dazu, dass utf-8 Sequenzen aufgebrochen werden und die Teilstrings ungültige utf-8-Codierungen enthalten.

[diogenes]

Welche Filenamen kann man denn nicht in Unicode darstellen?

Unter Linux sind Dateiname kein Text sondern ein array of bytes. Es gibt also keine definierte Text-Kodierung und es kann ohne weiteres vorkommen, dass Linux Dateinamen ungültige utf-8 Sequenzen enthalten. Unter Windows sind ungültige utf-16 Sequenzen möglich.
Bekannterweise arbeitet MSEgui ausschliesslich mit utf-16. In MSEgui löse ich das Problem so, dass an der Schnittstelle zum Betriebssystem die ungültigen Bytes in einen privaten Bereich der Unicode-Codierung (konkret $f800) verschoben werden. Beim übergeben eines MSEgui Dateinamens an Linux werden die ungültigen utf-8 Sequenzen rekonstruiert. Diese Methode ist natürlich nicht Unicode da nicht genormt.
Zur Erinnerung, in MSElang gibt es die String Typen "string8" (utf-8), "string16" (utf-16), string32 (utf32/UCS4) und "bytestring" für beliebige Codierung und binäre Daten.
https://gitlab.com/mseide-msegui/mselang/wikis/home

Das Beispiel verstehe ich auch nicht. Man soll natürlich auch die entsprechenden Methoden verwenden. UTF8LeftStr trennt ja brav nach dem fünften Zeichen.

Bei der Übertragung von utf-8 wird der Text häufig in Blöcke fester Länge unterteilt. Das führt dann natürlich dazu, dass utf-8 Sequenzen aufgebrochen werden und die Teilstrings ungültige utf-8-Codierungen enthalten.

Ich mach' mir bei Dateinamen die Mühe und maskiere ungültige und "gefährliche" Zeichen, indem ich sie encodiere (präfixzeichen + hex-code), sodass ich nur noch ASCII-zeichen in den Dateinamen habe. Problem gelöst. Für mich jedenfalls.

[Michl]

1) Filenamen

Das habe ich eben unter Linux Mint probiert. Es wird Ext4 als Dateisystem verwendet. Lt. Wiki dürfen alle Bytes außer 0 und 47(das Zeichen "/") für Dateinamen verwendet werden. Das funktioniert hier problemlos. Alle Zeichen 0..255 werden im String gespeichert, die Dateien angelegt und sie werden wieder gefunden. Allerdings kann man die Dateinamen nicht darstellen (auch Dolphin kann dies nicht), da es keine zugeordneten Zeichen gibt (sind keine gültigen UTF-8 Zeichen). Allerdings werden diese Zeichen im String gehalten, daher keine Probleme. Daumen hoch für die aktuelle Stringimplementierung von FreePascal/Lazarus:

Code: Alles auswählen

procedure TForm1.Button1Click(Sender: TObject);
var
  SL: TStringList;
  aPath, s: String;
  LogFile: TextFile;
  i: Integer;
begin
  aPath := GetCurrentDir + PathDelim;
 
  AssignFile(LogFile, aPath + 'log.txt');
  Rewrite(LogFile);
  s := 'test';
  WriteLn(LogFile, 'Used CodePage: ', StringCodePage(s));
 
  SL := TStringList.Create;
  CreateDir(aPath + 'temp');
  aPath := aPath + 'temp' + PathDelim;
 
  for i := 0 to 255 do
    try
      s := aPath + Char(i) + '.txt';
      SL.SaveToFile(s);
    except
      on E: Exception do
        WriteLn(LogFile, Format('Can not create File with %.3d($%.2x) %s', [i, i, s]));
    end;
 
  SL.Free;
 
  SL := FindAllFiles(aPath);
  SL.Sort;
  for i := 0 to SL.Count - 1 do
  begin
    s := ExtractFileName(SL[i]);
    WriteLn(LogFile, Format('File found: %.3d($%.2x) %s', [Byte(s[1]), Byte(s[1]), s]));
  end;
  SL.Free;
 
  CloseFile(LogFile);
end; 

[marcov]

Welche Filenamen kann man denn nicht in Unicode darstellen?

Unter Linux sind Dateiname kein Text sondern ein array of bytes. Es gibt also keine definierte Text-Kodierung und es kann ohne weiteres vorkommen, dass Linux Dateinamen ungültige utf-8 Sequenzen enthalten. Unter Windows sind ungültige utf-16 Sequenzen möglich.
Bekannterweise arbeitet MSEgui ausschliesslich mit utf-16. In MSEgui löse ich das Problem so, dass an der Schnittstelle zum Betriebssystem die ungültigen Bytes in einen privaten Bereich der Unicode-Codierung (konkret $f800) verschoben werden. Beim übergeben eines MSEgui Dateinamens an Linux werden die ungültigen utf-8 Sequenzen rekonstruiert. Diese Methode ist natürlich nicht Unicode da nicht genormt.

Gibst davon sinnige Beispiele wenn das alles nötig ist? Warum hast du die Aufwand (gegen Standarten!) gemacht?

[mschnell]

... oder Uppercase direkt arbeiten, und nicht noch ein mal konvertieren). ...

Kommentar zu Uppercase in der source:

{ UpperCase returns a copy of S where all lowercase characters ( from a to z ) have been converted to uppercase }

Funktioniert also nur für ASCII.

Kommt mir nicht besonders sinnvoll / benutzerfreundlich vor.

-Michael

[mse]

Gibst davon sinnige Beispiele wenn das alles nötig ist? Warum hast du die Aufwand (gegen Standarten!) gemacht?

Z.B. Dos Partitionen oder Samba. Den Aufwand habe ich getrieben, um den MSEide+MSEgui Anwendern das Leben zu erleichtern. Man kann damit in MSEgui problemlos Dateinamen mit ungültigen utf-8 Sequenzen in Filedialogen anzeigen, editieren und copy-pasten.

[marcov]

Gibst davon sinnige Beispiele wenn das alles nötig ist? Warum hast du die Aufwand (gegen Standarten!) gemacht?

Z.B. Dos Partitionen oder Samba. Den Aufwand habe ich getrieben, um den MSEide+MSEgui Anwendern das Leben zu erleichtern. Man kann damit in MSEgui problemlos Dateinamen mit ungültigen utf-8 Sequenzen in Filedialogen anzeigen, editieren und copy-pasten.

Danke.

[mschnell]

Welche Filenamen kann man denn nicht in Unicode darstellen?

Unter Linux sind Dateiname kein Text sondern ein array of bytes.

"Linux" selber interpretiert diese Bytes überhaupt nicht. Man kann jede Menge unterschiedliche Datei-Systeme einhängen. Das übliche "EXT" arbeitet weiterhin mit array of bytes und Interpretiert den Inhalt nicht. Man kann aber auch DOS-kompatibhle Dateisysteme verwenden (z.B. auf USB-Sticks und SD-Karten üblich), oder auch Windows NTFS, die (beim Suchen) keine klein/groß - Buchstaben - Unterscheidung machen und deshalb durchaus Code-aware sind.

-Michael

[pluto]

"Linux" selber interpretiert diese Bytes überhaupt nicht. Man kann jede Menge unterschiedliche Datei-Systeme einhängen. Das übliche "EXT" arbeitet weiterhin mit array of bytes und Interpretiert den Inhalt nicht. Man kann aber auch DOS-kompatibhle Dateisysteme verwenden (z.B. auf USB-Sticks und SD-Karten üblich), oder auch Windows NTFS, die (beim Suchen) keine klein/groß - Buchstaben - Unterscheidung machen und deshalb durchaus Code-aware sind.

Passend dazu: Ich habe bei meiner Musik Sammlung einige Dateien, die werden auf meinem PC richtig dagestellt mit Sonderzeichen und der gleichen und auf meinem banana PI werden sie nicht richtig da gestellt. Aber beim Banana PI verwende ich auch eine SD Karte, die aber EXT3 oder EXT4 sein dürfte.