[GELÖST] ISO 8859-1 in UTF-8 umwandeln

Hallo zusammen,

nach stundenlanger Forschung und einem Fortschritt von 0% wende ich mich nun hoffnungsvoll an euch.
Im generellen geht es darum, dass ich einen UTF-8 String habe, der die Sonderzeichen als ISO 8859-1 interpretiert und ich somit die Sonderzeichen nicht in NAV anzeigen lassen kann.

Nun aber noch einmal genauer.
Ich bekomme von einem WebService einen String zurück, der eine XML-Struktur besitzt und das Encoding UTF-8 besitzt.

Code:

<?xml version="1.0" encoding="utf-8"?><?xml-stylesheet type="text/xsl" href="/DocuWare/Platform/Content/standard.xslt"?><DocumentsQueryResult xmlns:s="http://dev.docuware.com/schema/public/services" TimeStamp="2017-04-06T06:04:16Z" xmlns="http://dev.docuware.com/schema/public/services/platform"><Count>1</Count><Items><Item HaveMoreTotalPages="true" Id="376" Title="Unnamed Document with id 376 from 04/05/2017 15:44:34" LastModified="2017-04-06T05:52:52Z" CreatedAt="2017-04-05T13:44:34Z" FileSize="4126" SectionCount="2"><Fields><Field FieldName="COMPANY" FieldLabel="Firma" IsNull="true" /><Field FieldName="CONTACT" FieldLabel="Kontakt"><String>12345</String></Field><Field FieldName="SUBJECT" FieldLabel="Betreff/Nr."><String>€ ä Ä ü Ü ö Ö &amp; ß é È è È ´ ` Á Ó Ú á ó ú À Ò Ù à ò ù í Í ì Ì â Â Ô ô û Û ê Ê î Î ł Ł</String></Field>


Wie ihr allerdings am Ende des Strings erkennen könnt besitzt es nicht wirklich den Encoding UTF-8.
In dem Programm, woher ich den String bekomme habe ich folgende Zeichenkette

Code:

€ ä Ä ü Ü ö Ö & ß é È è È ´ ` Á Ó Ú á ó ú À Ò Ù à ò ù í Í ì Ì â Â Ô ô û Û ê Ê î Î ł Ł


Auf Grund einer Seite (sind Fremdlinks erlaubt?) habe ich herausgefunden, dass es sich hierbei um "ISO 8859-1" handelt.

Nun stellt sich mir die Frage, wie ich diese Zeichen in UTF-8 bekomme, um sie richtig in NAV anzeigen zu können.
Ich habe es bereits versucht als Datei mit UTF-8 zu speichern und wieder ab zu rufen. Leider ohne Erfolg.

Ich hoffe, dass mir einer von euch weiter helfen kann, da dies für meine Schnittstelle zum anderen Programm sehr wichtig ist.


Viele Grüße
Kai

Zuletzt geändert von Kai R. am 11. April 2017 07:20, insgesamt 1-mal geändert.

Hallo Kai,

vielleicht hilft der der folgende Link weiter:

http://www.dynamics.is/?p=617

Gruß

Michael

Hier sind meine Konvertierungsskripte, ich habe da eben noch eins für diesen Fall ergänzt.

Hallo Kai,

vielleicht hilft der der folgende Link weiter:

http://www.dynamics.is/?p=617

Gruß

Michael

Servus Michael,

das habe ich auch schon gesehen, bringt mich persönlich aber nicht weiter. Es wird von ISO nach UTF-8 konvertiert.
Ich brauche es aber anders herum und mir fehlt leider das Know-How, wie ich das umbauen könnte.

Hier sind meine Konvertierungsskripte, ich habe da eben noch eins für diesen Fall ergänzt.

Servus Kai,

ich habe es mir einmal angeschaut und wie folgt getestet:

Code:

Name   DataType   Subtype   Length
textfile   Text      
IOFile   DotNet   System.IO.File.'mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'   
Textencode   DotNet   System.Text.Encoding.'mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'   


Code:
textfile := ValueText;
IOFile.WriteAllText('C:\temp\Druck\test.txt',textfile,Textencode.GetEncoding(65001));


Da ich den Text schon habe und nicht aus einer Datei holen muss, habe ich deine "ANSI1252 (ISO 8859-1) nach UTF-8"-Funktion stark gekürzt und schreibe mir lediglich diese eine Datei.
Allerdings erhalte ich die gleichen komischen Zeichen, wie sie in meiner Variablen stehen.
Habe ich hier etwas übersehen?

Gruß
Kai

Hallo,

Grundsätzlich solltest du dich mit der Codeunit 6224 bzw. den darin verwendeten DOTNet- Komponenten auseinandersetzen. Außerdem kann der Blick auf die DotNet- Komponenten System.Convert und System.Text.Encoding nicht schaden.

Gruß Fiddi

In dem Programm, woher ich den String bekomme habe ich folgende Zeichenkette

Code:

€ ä Ä ü Ü ö Ö & ß é È è È ´ ` Á Ó Ú á ó ú À Ò Ù à ò ù í Í ì Ì â Â Ô ô û Û ê Ê î Î ł Ł


Auf Grund einer Seite (sind Fremdlinks erlaubt?) habe ich herausgefunden, dass es sich hierbei um "ISO 8859-1" handelt.

Nicht ganz, die letzten beiden (ł Ł) gehören zum polnischen Alphabet, die gehören z.B. nicht zur Codepage 1252, sind in Code Page 1250 Windows Latin 2 (Central Europe) bzw. ISO 8859-2 enthalten.

Fremdlinks sind erlaubt, solange es keine Werbung ist.

Code:

<?xml version="1.0" encoding="utf-8"?><?xml-stylesheet type="text/xsl" href="/DocuWare/Platform/Content/standard.xslt"?><DocumentsQueryResult xmlns:s="http://dev.docuware.com/schema/public/services" TimeStamp="2017-04-06T06:04:16Z" xmlns="http://dev.docuware.com/schema/public/services/platform"><Count>1</Count><Items><Item HaveMoreTotalPages="true" Id="376" Title="Unnamed Document with id 376 from 04/05/2017 15:44:34" LastModified="2017-04-06T05:52:52Z" CreatedAt="2017-04-05T13:44:34Z" FileSize="4126" SectionCount="2"><Fields><Field FieldName="COMPANY" FieldLabel="Firma" IsNull="true" /><Field FieldName="CONTACT" FieldLabel="Kontakt"><String>12345</String></Field><Field FieldName="SUBJECT" FieldLabel="Betreff/Nr."><String>€ ä Ä ü Ü ö Ö &amp; ß é È è È ´ ` Á Ó Ú á ó ú À Ò Ù à ò ù í Í ì Ì â Â Ô ô û Û ê Ê î Î ł Ł</String></Field>


Eigentlich sagt auch der XMl-String nichts aus, solange nicht geklärt ist, mit welchem Editor und in welcher Kodierung er sich das ganze angeschaut hat.

Gruß Fiddi

Hallo zusammen,

Jetzt wo du es sagst Kai, hast du Recht mit der CodePage. Ich hatte lediglich die gängigen wie "ä,ö,ü" geprüft.
Das mit dem ł / Ł macht es mir nicht einfacher. Jetzt bin ich noch verwirrter.

@ Fiddi:
Die DotNets habe ich mir bereits angeschaut, aber alles was ich bis jetzt versucht habe den Text um zu wandeln war erfolglos.
Auf deine Frage mit welchem Editor und welcher Kodierung ich mir das anschaue:
Ich bekomme diesen String vom Drittprogramm wieder und lass es mir als MESSAGE ausgeben. Schon in der MESSAGE sind die Werte dementsprechend zu sehen. Das heißt ich benutze keinen Editor und die NAV-Kodierung bzw. die die aus dem Drittprogramm kommt, welche laut XML-Struktur UTF-8 sein soll.

Lediglich, um euch den String hierher zu kopieren war der String kurze Zeit in Notepad.


Gruß
Kai

Lediglich, um euch den String hierher zu kopieren war der String kurze Zeit in Notepad.

Schreib den XML-String mal binär in eine Datei. (kein "cut an paste", keine Textdatei, den Text direkt im Programm in eine Datei speichern)
Dann schau dir diese Datei mal mit dem Notepad++ an, und teste mit dem Menüpunkt Kodierung so lange bis dein Text passt, dann hast du die richtige Codepage raus gefunden.

Den Text in der Codepage musst du dann mit Convert in UTF8 umwandeln.

Gruß Fiddi

Da der Text Sonderzeichen enthält (mit Codepagemix?), müsste die UTF-8-Datei auch die korrekte Byte Order Mark (BOM) haben, das würde ich auch mal prüfen wie hier beschrieben.

"ANSI1252 (ISO 8859-1) nach UTF-8"-Funktion

Das sind jetzt zwei Funktionen, weil diese zwar sehr ähnlich, aber doch verschieden sind (bei ANSI1252 im Bereich 128 - 159 Druckzeichen statt Steuerzeichen bei ISO 8859-1).

Guten morgen zusammen,

@Fiddi:
Leider hatte dies kein Erfolg. Ich habe alle möglichen Kodierungen ausprobiert, die mir Notepad++ zur Verfügung stellt.
Allerdings wurde mir bei keiner die richtigen Sonderzeichen angezeigt.

@Kowa:
Jetzt wurden bei mir auch zwei verschiedene Funktionen angezeigt. Gestern war dies noch in einer zusammen gefasst.
Ich habe allerdings keine Datei, die ich zum lesen benutze, sondern nur diesen String. Das heißt ich müsste mir erst eine Datei im ISO-Format erstellen, diese Datei in UTF-8 umwandeln und letztendlich die zweite Datei zum bearbeiten verwenden? Das klingt für mich nach zu vielen Umwegen, als dass es so gewollt sein kann?

Die Datei, die ich daraus erstellt habe hatte auch die richtige BOM.



Ich glaube so langsam mir bleibt nichts anderes übrig als bei dem Hersteller nach der Kodierung und der Codepage zu fragen, welche beim Webservice benutzt wird.
Eine Information noch:
Um von NAV mit dem Drittpgramm kommunizieren zu können bzw. Umlaute senden zu können, habe ich die Funktion von Timo benutzt http://www.msdynamics.de/viewtopic.php?f=20&t=4001 "Text2HTMLdec".
Anders herum funktioniert dies ja, aber leider nicht.

Gruß
Kai

Hallo,

kannst du die abgespeicherte XML-Datei mal hochladen, oder sind da vertrauliche Daten drin?

Zu Timo's Tools, da solltest du etwas vorsichtig sein, es könnte sein,das die mit dem neuen Textformat UTF8 in NAV Probleme haben, und nicht immer wirklich vollständig funktionieren, da Sie teilweise noch aus Zeiten vor NAV 2009 stammen.

Wenn's nicht so ist kann Timo ja noch mal eine Info geben.

Gruß Fiddi

Hallo Fiddi:

Ich hatte das gleiche Problem mit den Sonderzeichen, wenn ich zum Drittprogramm etwas übergeben habe. Daraufhin habe ich einfach mal die Funktionen von Timo getestet und eine hat funktioniert :)
Ich hoffe, ich habe die Datei richtig hochgeladen. In der .rar ist der komplette Antwortstring einmal als .txt und einmal als .xml.

Gruß
Kai

Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.

Das heißt ich müsste mir erst eine Datei im ISO-Format erstellen, diese Datei in UTF-8 umwandeln und letztendlich die zweite Datei zum bearbeiten verwenden?

Man kann auch den Inhalt der Quelldatei austauschen, wie hier beschrieben. Wenn allerdings gar keine Datei vorhanden ist, müsste man die Skripte natürlich noch weiter anpassen.

Hallo
Nach dem Hexdump zu urteilen ist das tatsächlich Schrott, bzw. nicht das von dem du sagst das es das sein soll:
Das gilt aber nur dann, wenn du den XML String so wie er gekommen ist, binär in eine Datei geschrieben hast. Wenn da noch die Textkonvertierung von NAV dran war hast du leider verloren.

Hier ein Link dazu.

Gruß Fiddi

Hallo Fiddi,

ist die Textkonvertierung von NAV auch schon dran, wenn der Text rein in der Programmierung verwendet wird, oder erst, wenn es in ein Feld geschrieben und angezeigt wird?
Da ich den WebService in der Programmierung anspreche und daher auch dorthin die Antwort bekomme, habe ich also keine Chance ohne NAV die Antwort zu bearbeiten.

Gruß
Kai

Evtl schon, wenn du diesen Text unmittelbar nachdem du Ihn von der Leitung gelesen hast benutzt, als nix XML-Port oder so.

Gruß Fiddi

Hallo Fiddi,

zum verarbeiten der Daten, die ich hier als XML-String benutze verwende ich keine Datei, XMLPort oder ähnliches.
Ich baue die XML-Struktur per Programmierung auseinander und hole mir so die benötigten Informationen.
Der String, den ich gestern um 11:31Uhr geschrieben habe stammt direkt vom Webservice.

Gruß
Kai

Du nutzt nicht DotNet "System.Xml" ?

Gruß Fiddi

Ich würde den String byteweise lesen wie hier im letzten Beitrag beschrieben:
http://forum.mibuso.com/discussion/45344/xmlport-and-webservice-performance-encoding-problems

Da sind sogar Steuerzeichen drin, da ist nichts mehr zu konvertieren.

TestCP1.png

Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.

Hallo zusammen,

ich benutze keine DotNet-Variablen, um den String aus einander zu bauen.
Dies hat den Grund, dass die Schnittstelle in verschiedenen NAV-Versionen eingesetzt werden soll und kann.
ich denke aber, dass die Aufbereitung per System.XML nichts an der Kodierung/Umlauten ändern würde, oder täusche ich mich da?


Das byteweise Lesen habe ich ausprobiert, da ich das noch nicht getestet hatte.
Leider hat auch dies nicht zum gewünschten Erfolg geführt.


Gruß
Kai

ich benutze keine DotNet-Variablen, um den String aus einander zu bauen.
Dies hat den Grund, dass die Schnittstelle in verschiedenen NAV-Versionen eingesetzt werden soll und kann.

Welche sollen das denn werden? Das wird in älteren ohnehin so nicht funktionieren, alle unicodefähigen NAV-Systeme können auch DotNet, NAV 2009 R2 (technisch reicht) kann auch schon etwas DotNet, aber als Nicht-Unicodesystem den String nach Konvertierung ohnehin nur teilweise mit dem Zeichenvorrat von Codepage 1252 bzw. intern 850 verarbeiten.

ich benutze keine DotNet-Variablen, um den String aus einander zu bauen.
Dies hat den Grund, dass die Schnittstelle in verschiedenen NAV-Versionen eingesetzt werden soll und kann.

Codeunit 6224 gibt es auch schon in NAV2009.

Gruß Fiddi

Hallo zusammen,

die Schnittstelle soll in NAV 2013 folgende eingesetzt werden können.
Ihr mögt recht haben, dass ich mir mit den DotNets einiges an Arbeit erspart hätte, aber an der Kodierung der Texte sollte dies nichts ändern, oder?


Gruß
Kai