Hallo Dimitri,
ich vermute, dass dein ActiveX-Tool diese Konvertierung vornimmt und LabVIEW damit nichts/wenig zu tun hat…
Wenn ich dein XML per ReadTextFile in LabVIEW lese, siehst man nämlich folgendes (Ausschnitt):
Code:
Anzeige in \-code display: z\00a\00\n\01o\00 (Unicode für začo)
Dein Screenshot der LabVIEW-Anzeige zeigt aber deutlich ein "normales c": diese Konvertierung zu ASCII wurde nicht von LabVIEW durchgeführt, sondern wird von der ActiveX-Komponente geliefert…
Danke für die Antwort Gerd. Dachte evtl. kennt sich jemand besonders gut aus mit der lib und es gäbe evtl. noch eine Methode, dass unicode rauskommt.
Gruß
dimitri
Nun gut, LabVIEW ist nicht wirklich Unicode fähig, alle Strings sind nur 8-bit...
Außer du stellst da gewisse Ini-Werte anders ein, aber da kenn ich mich auch nicht genau aus. Und was ich bisher so gelesen haben, zu 100% funktioniert das auch nicht.
Gruß, Jens
Hallo Jens,
ja, die nicht offizielle Unterstützung von LabVIEW ist uns bekannt und wir quälen uns trotzdem da durch. Wir haben schon vor knapp 10 Jahren Prüfstände nach China geliefert, wo man zwischen den Sprachen Deu/Eng/Chinesisch wechseln konnte. Geht so halbwegs.
In die LabVIEW Ini und auch in die Ini von den builds gehört dann ein "UseUnicode=True". Außerdem muss man mit dem Kontextmenüeintrag "Force unicode" (bei string Anzeigen zb) rumprobieren. Ist etwas hakelig ... geht aber an sich ganz ok.
Jetzt haben wir von normalen tsv-Dateien umgestellt auf xml ... lief super bis wir unicode ausprobiert haben.
Gruß
dimitri
Hast du dir einmal den NI XML Parser unterhalb der File I/O Palette angesehen? Die machen das nicht so viel anders als wie in deinem VI, jedoch bekomme ich bei Abruf von "XML" (nicht "text") auch Unicode. Das verhält sich teilweise etwas anders. Ich will da aber ohne aktuelle Not nicht unnötig viel Zeit rein stecken :-)
Hallo Martin,
die zwei VI's hier lesen unicode, ja.
[
attachment=61045]
Aber da fehlen einem sämtliche Freiheitsgrade. Fügt man etwas hinzu muss man Quellcode anpacken. Man kann nicht gezielt einzelne Elemente lesen.
Diese Palette macht es genauso falsch (Ist aber zusätzlich zur ActivX Lösung wesentlich langsamer):
[
attachment=61046]
Gruß
dimitri
Ich weiß nicht, ob es dir weiterhilft, aber im VIPM gibt es 2 unicode-Tools, von JKI und NI.
Gruß, Jens
Wusst ich nicht. Schau ich mal was die so machen. Danke.
(16.07.2020 12:55 )jg schrieb: [ -> ]Ich weiß nicht, ob es dir weiterhilft, aber im VIPM gibt es 2 unicode-Tools, von JKI und NI.
Gruß, Jens
Viele dieser VI's haben wir in der Vergangenheit so ähnlich selber programmiert - interessant. Aber helfen tun die in diesem Zusammenhang nicht.
Wir machen jetzt Folgendes (nicht wirklich toll ...): Wir konvertieren den unicode string in ein Byte-Array und speichern die Byte-Werte selbst in der XML (2 byte pro Zeichen). Nicht schön. Im normalen Editor nicht vom Menschen lesbar ... aber mittelfristig programmieren wir noch ein spezielles Editor-Programm, welches dann den Inhalt zum Anzeigen wieder in lesbare strings wandelt.
Wie gesagt, nicht schön, aber wollten xml auch nicht ganz verwerfen.
Beste Grüße