Wenn dein Problem oder deine Frage geklärt worden ist, markiere den Beitrag als "Lösung",
indem du auf den "Lösung" Button rechts unter dem entsprechenden Beitrag klickst. Vielen Dank!
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…
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
Wer die erhabene Weisheit der Mathematik tadelt, nährt sich von Verwirrung. (Leonardo da Vinci)
!! BITTE !! stellt mir keine Fragen über PM, dafür ist das Forum da - andere haben vielleicht auch Interesse an der Antwort!
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
„Sag nicht alles, was du weißt, aber wisse immer, was du sagst.“ (Matthias Claudius)
16.07.2020, 10:13 (Dieser Beitrag wurde zuletzt bearbeitet: 16.07.2020 10:13 von Martin.Henz.)
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 :-)
die zwei VI's hier lesen unicode, ja.
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):
Gruß
dimitri
„Sag nicht alles, was du weißt, aber wisse immer, was du sagst.“ (Matthias Claudius)
(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
„Sag nicht alles, was du weißt, aber wisse immer, was du sagst.“ (Matthias Claudius)
/
unicode in XML Datei wird als ANSI eingelesen
