Export von Texten mit Sonderzeichen

Hallo,

ich habe hier die Anforderung eine Schnittstellendatei mit Daten aus NAV 2009 R2 zu befüllen.
Das Problem dabei ist allerdings, dass die Texte in NAV Sonderzeichen enthalten können. Es handelt sich dabei um Artikelübersetzungen in verschiedene Sprachen.
z.B. dieser String: "Vijak s šestrobo glavo". Es ist der Teil einer Slovenische Artikelbeschreibung. Das problematische Zeichen hier ist das š.
Die gängigen ANSI to ASCII Konverter helfen hier nicht, weder Codeunit 11501 aus dem Standard noch die TextManagement Codeunit vom Timo.

Wie bekomme ich solche Zeichen, können bei uns auch französiche oder skandinavische Zeichen sein, in eine Textdatei korrekt exportiert?
Hat das schonmal jemand gemacht?

Danke und Gruß,
Rolf

Hallo,

wenn du das nicht regelmäßig machen willst, das kannst du das mit Notepad++ machen, der ist in der Lage eine Text nach ANSI zu konvertieren.

Nav in DE gibt die Daten standardmäßig in CodePage 850 aus. Wenn du Die Daten jetzt in ANSI benötigst, dann kannst du die Datei mit NP++ öffnen, Codepage auf 850 einstellen, dann nach ANSI konvertieren.

Gruß Fiddi

Hallo,

doch das läuft regelmäßig und automatisch. Mit den Daten werden Schnittstellen zu anderen Systemen betankt.

Das Problem ist, dass schon der Standard NAV Export in ein OEM Textfile mit CodePage 850 nicht korrekt funktioniert.
Wenn ich eine solche Datei mit einem Editor wie Notepad++ oder UltraEdit nach ANSI konvertiere ist das Zeichen schon falsch.
Ich vermute mal, dass diese sprachspezifischen Sonderzeichen in Codepage 850 nicht definiert sind und damit schon falsch in der Textdatei landen, wenn man die einfach mit einem Dataport oder per "File.WRITETEXT" rausschreibt.

Gruß Rolf

ASCII zu ANSI bedeutet (in Westeuropa) Codepage 850 nach Codepage 1252 für Westeuropa (inkl. Skandinavien und Estland)
https://de.wikipedia.org/wiki/ISO_8859-1#Windows-1252
Code Page 1252 Windows Latin 1 (ANSI)
Für Central Europe (Tschechien, Polen, Ungarn etc.) ist es aber Codepage 1250, das muss dann auch in Windows umgestellt werden. Dann kann man dafür eine eigene Konvertierung schreiben (Codepage 852 nach Codepage 1252) und sieht die Zeichen auch.
Code Page 1250 Windows Latin 2 (Central Europe)
https://de.wikipedia.org/wiki/Windows-1250
Das südliche Baltikum mit Lettland und Litauen gehört hier übrigens nicht zu "Central Europe", dort Codepage 1257 (auch wenn nördlich von Vilnius in Litauen der geographische Mittelpunkt Europas liegt )
Code Page 1257 Windows Baltic Rim

ASCII zu Ansi macht dann keinen Sinn. Ich kann ja nicht immer die Codepage in Windows umstellen. Je nach dem was ich für Texte exportieren muß.
Soll ja wie gesagt automatisiert ablaufen,

Ich hab jetzt mal ein bisschen mit einem XML Port experimentiert. Wenn ich UTF-8 als encoding einstelle kommen die Daten sauber in der XML Datei an.

Code:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<Root>
   <CaptionF1>121761</CaptionF1>
   <CaptionF2>MDM d.o.o.</CaptionF2>
   <CaptionF3>093328  16</CaptionF3>
   <CaptionF4>DIN 933 A2 M 8X16</CaptionF4>
   <CaptionF5>DIN 933 A2 M 8X16</CaptionF5>
   <CaptionF6>DIN 933 A2 M 8X16</CaptionF6>
   <CaptionF7>Hexagon head screws</CaptionF7>
   <CaptionF8>Vijak s šestrobo glavo</CaptionF8>
</Root>

Jetzt habe ich nur ein Problem, ich brauche den Elementnamen (hier "CaptionF1 .... Caption F8) variabel.
Ich habe quasi eine Header-Line Konstrukt. In der Line stehen die eigentlichen Daten, im Header die Feldnamen wie sie im Output auftauchen sollen.

Ich habe mehrere Nodes angelegt, alle vom Node Typ "Element" und Source Type "Text".
Man kann zwar im XML Port den Node Names Werte zuweisen, aber beim Export scheint das leider nicht zu interessieren.
Die Node Names werden exportiert wie sie im XML Port benannt sind.

Im Code habe ich diese Zuweisungen im OnPreXMLport Trigger:

Code:

CaptionF1 := Header."Field 01 Caption";
captionf2 := Header."Field 03 Caption";
captionf3 := Header."Field 04 Caption";
captionf4 := Header."Field 05 Caption";
captionf5 := Header."Field 06 Caption";
captionf6 := Header."Field 07 Caption";
captionf7 := Header."Field 08 Caption";
captionf8 := Header."Field 09 Caption";

textf1 := Line."Field 01";
textf2 := Line."Field 02";
textf3 := Line."Field 03";
textf4 := Line."Field 04";
textf5 := Line."Field 05";
textf6 := Line."Field 06";
textf7 := Line."Field 07";
textf8 := Line."Field 08";

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

ASCII zu Ansi macht dann keinen Sinn. Ich kann ja nicht immer die Codepage in Windows umstellen.

Leider ist erst NAV 2013 bei Feldinhalten unicodefähig. In NAV 2009 kann man vieles unter einer bestimmten Lokalisierung gar nicht eingeben, weil es in der Codepage nicht enthalten ist. Mit dem š mag es noch klappen, weil das in CP 1250 zufällig noch drin und in CP 1252 sogar an der gleichen Stelle ist, es ist allerdings nicht in CP 850, sondern nur in CP 852. Wenn man noch weitere Zeichen benötigt stößt man da schnell an Grenzen, nicht zuletzt beim kyrillischen Alphabet (in CP 1251) ist dann endgültig Schluss . Wenn das erforderlich ist, kann man die Codepagecodepoints vergleichen, und anfangen Texte in separaten Feldern mit den falschen Zeichen, aber an der gleichen Stelle des Codepagegerüsts, aus dem beschränkten Zeichenvorrat parallel zu pflegen und beim Export - je nachdem wohin - dann auf die unterschiedlichen Quellen zurückgreifen. Mit den Mitteln des .NET-Frameworks bzw. mit den Skripten hier kann man in alle und von allen Codepages bzw. Unicode konvertieren.