Strings über mehrere Dateien vereinheitlichen

[Timm Thaler]

Ich hab mal wieder ein Problem mit den Stringtypen. Das Konstrukt ist folgendes:

In einer Konfig-XML-Datei stehen Bezeichnungen, die auch Umlaute enthalten können:

Code: Alles auswählen

<?xml version="1.0" encoding="utf-8"?>
<config>
  <input name="Schlüssel" />

Geany meint dazu, Kodierung ist Utf-8 ohne BOM. Umlaute werden richtig dargestellt.

Diese Bezeichnungen werden jetzt von einem Programm (Datenlogger) in einen string[50] gelesen:

Code: Alles auswählen

txt := string(TDOMElement(Item[k]).GetAttribute('name'));

Der String ist als Shortstring definiert, weil er mit vielem anderen in einem Array steht. Macht aber keinen Unterschied, auch wenn ich die [50] weglasse und der String ein Ansistring ist.

Die Bezeichner werden jetzt mit WriteLn in eine reine Textdatei geschrieben. Geany meint, die Kodierung ist ISO8859-1, Umlaute werden richtig dargestellt. (Witzigerweise meint Geany zu einer anderen, auf gleiche Weise aber mit einem anderen Programm erstellten Datei, die Kodierung sei Utf-8, auch hier werden die Umlaute richtig dargestellt.)

Die Textdatei wird jetzt von einem zweiten Programm (Web-CGI) mit ReadLn eingelesen, ein bißchen HTML drumgebaut und als "content-type:text/html; charset=utf-8" als Webseite ausgegeben. Dabei werden allerdings die Umlaute falsch kodiert. Auch der Versuch, die Umlaute vor dem WriteLn mit StringReplace(txt, 'Ä', 'Ä', [rfReplaceAll]); zu wandeln scheitert daran, dass hier schon das 'Ä' nicht als solches erkannt wird.

Ich versuche gerade rauszufinden, wo meine Umlaute die falsche Kodierung bekommen. Sting ist ja eigentlich Ansistring, müsste also mit Utf-8 stimmen, Shortstring macht wie gesagt keinen Unterschied, auch das string() beim XML-Parsen hat keinen Einfluss, ohne bringt nur der Compiler eine Warnung, aber das Ergebnis ändert sich nicht.

Wie bekomme ich Umlaute bzw. Kodierungen über mehrere Dateien und Programme konsistent?

Die Programme laufen auf einem Raspberry unter Raspbian, FPC 3.0.0, Lazarus 1.6.2.

[Timm Thaler]

Achso, wenn ich für das erzeugte HTML-Dokument statt utf8 als charset=latin1 (was ja ISO8859-1 ist) angebe, werden die Umlaute im Browser richtig dargestellt. Aber ursprünglich waren die im XML-Dokument ja mal utf-8.

[wp_xyz]

Dein Programm, das die xml-Datei eingelesen hat, verwendete das die Units laz_xmlread und laz_dom? Das wäre falsch, die "2"-er Units laz2_xmlread und laz2_dom verwenden utf8.

[Timm Thaler]

Dein Programm, das die xml-Datei eingelesen hat, verwendete das die Units laz_xmlread und laz_dom? Das wäre falsch, die "2"-er Units laz2_xmlread und laz2_dom verwenden utf8.

Sieht so aus:

Code: Alles auswählen

uses
  Classes, SysUtils, DOM, XMLRead

Wie heissen denn die 2er-Units? DOM2 ist schonmal falsch...

[wp_xyz]

So wie's in meinem Post steht. Vielleicht wird's durch eine andere Formatierung deutlicher:

laz2_dom
laz2_xmlread

Benötigen als Anforderung das Package lazutils.

[Timm Thaler]

So wie's in meinem Post steht. Vielleicht wird's durch eine andere Formatierung deutlicher: laz2_dom laz2_xmlread Benötigen als Anforderung das Package lazutils.

Hab ich gefunden. Allerdings steht bei http://wiki.lazarus.freepascal.org/xmlread, dass XMLread auch utf-8 kann.

Funktioniert mit laz2_DOM, laz2_XMLRead. Allerdings ist die Binary jetzt 400kB größer, ist das normal? Und benötigt TDOMElement(Item[k]).GetAttribute('name') jetzt keine Konvertierung von Widestring in String mehr?

Ahhh, diese Kodierungen machen mich noch wahnsinnig. Aber wie man im englischen Forum sehen kann nicht nur mich...

[Timm Thaler]

Ok, mit den Units laz2_DOM, laz2_XMLRead funktioniert jetzt auch das Ersetzen der Umlaute durch ä und so. Wobei das möglicherweise gar nicht mehr nötig ist, das Encoding wird ja mitgeliefert.

Dafür habe ich jetzt mit dem LazUtils Package zwei Warnungen:

Code: Alles auswählen

hcdata.lpr(34,31) Warning: "crtbegin.o" not found, this will probably cause a linking failure
hcdata.lpr(34,31) Warning: "crtend.o" not found, this will probably cause a linking failure

Scheint laut Internet nichts Ungewöhnliches zu sein, und man kann es durch Einbinden des Pfades beheben. Ich finde aber ums Verrecken den Pfad auf dem Raspi nicht, wo die Libs stehen sollen.

[photor]

Code: Alles auswählen

hcdata.lpr(34,31) Warning: "crtbegin.o" not found, this will probably cause a linking failure
hcdata.lpr(34,31) Warning: "crtend.o" not found, this will probably cause a linking failure

Scheint laut Internet nichts Ungewöhnliches zu sein, und man kann es durch Einbinden des Pfades beheben. Ich finde aber ums Verrecken den Pfad auf dem Raspi nicht, wo die Libs stehen sollen.

Tritt hier regelmäßig auf, wenn der gcc geupdated wurde.

Aus meiner Kladde dazu:

• kopier dir die fpc.cfg (versteckt) in Dein HOME-Verzeichnis (z.B. cp /etc/fpc.cfg ~/.fpc.cfg)
• finde die neue libgcc.a (z.B. gcc --print-libgcc-file-name was dann etwa /usr/......linux-gnu/6.1.1/libgcc.a[i] ergibt)
• öffne die [i]~/.fpc.cfg mit einem Editor Deiner Wahl und suche die Zeile # searchpath for libraries"
• darunter stehen wahrscheinlich schon Einträge; einfach eine Zeile mit dem oben gefundenen Pfad (ohne die libgcc.a) eintragen.
• speichern, Lazarus neu starten, keine Warnung mehr

Sieht dann so aus:

Code: Alles auswählen

# searchpath for libraries
#-Fl/usr/lib/fpc/$fpcversion/lib
#-Fl/lib;/usr/lib
-Fl/usr/lib/fpc/$fpcversion/lib/$FPCTARGET
# added by PHOTOR 2016-06-03
-Fl/usr/lib/gcc/x86_64-pc-linux-gnu/6.1.1
# added by PHOTOR 2016-09-09
-Fl/usr/lib/gcc/x86_64-pc-linux-gnu/6.2.1
# added by PHOTOR 2017-01-11
-Fl/usr/lib/gcc/x86_64-pc-linux-gnu/6.3.1
# added by PHOTOR 2017-06-05
-Fl/usr/lib/gcc/x86_64-pc-linux-gnu/7.1.1 

Du kannst es aber auch ignorieren. Mein "innerer Monk" wird aber immer ganz unruhig bei sowas.

Ciao,
Photor

PS: das stammt nicht von mir - aller höchst wahrscheinlich sogar von hier. Ich hab's nur in die Kladde geschrieben; die Ehre gebührt einem anderen

[Timm Thaler]

Ah danke, werds auch mal in meine "Kladde" übernehmen.

Zum eigentlichen Problem: Ich hab erstmal das Encoding auf iso-8859-1 umgestellt, da ich gesehen habe, dass die Webseite, die die Daten einbindet auch auf diesem Encoding basiert. Dann gehts auch mit den originalen DOM und XMLread Units.

Uuuund: Man sollte durchaus die englischen Versionen der Tuts lesen (http://wiki.lazarus.freepascal.org/XML_Tutorial), da steht das nämlich etwas ausführlicher als in den deutschen.