[Gelöst] Welchen Zeichensatz verwendet NAV? UTF-8?

Hallo miteinander,

wir haben einige Importe/Exporte erstellt, um Daten mit einem Partner-Unternehmen auszutauschen.
Nun wurde die Frage gestellt, mit welchem Zeichensatz NAV 2013 standardmäßig arbeitet.

Irgendwo meine ich "UTF-8" gelesen zu haben - ist das korrekt? Und sollte diese Angabe auch ausreichend sein?

Ich kenn mich damit leider überhaupt nicht aus - und hoffe ihr könnt mir das beantworten.

Gruß
Ralf

Zuletzt geändert von neckit am 12. Oktober 2015 09:58, insgesamt 1-mal geändert.

Irgendwo meine ich "UTF-8" gelesen zu haben - ist das korrekt?

Nein, für den Datenaustausch standardmäßig seit Urzeiten OEM (von IBM) Codepage 850 (in Westeuropa), auch bekannt als MS-DOS, da die Codepage 1987 mit MS-DOS 3.3 eingeführt wurde.

Für XMLports kann man das ab NAV 2013 optional auf UTF-8 o.a. einstellen, wenn die statt XML CSV-Dateien oder feste Feldlängen verarbeiten.
TextEncoding Property

Intern werden die Feldwerte ab dieser Version in Unicode gespeichert. Dadurch ist im Gegensatz zu den älteren Versionen hier jedes Zeichen darstellbar (Text Encoding). Das ist auch kein UTF (Unicode Transformation Format), welches ein Abbildungsverfahren von Unicode für (aus NAV Sicht externe) Dateiformate ist.

Ab NAV 2013 R2 kann man den Parameter TextEncoding auch beim Import und Export von Dateien optional zusätzlich verwenden.
Mögliche Werte hier: MsDos, UTF8, UTF16, Windows. Der Vorgabewert ohne diesen Parameter ist wie bisher OEM850 (= MsDos). Mit "Windows" ist hier die ANSI Codepage 1252 (in Westeuropa) des Betriebssystems für Nicht-Unicode-Dateien gemeint:
Lesen: OPEN Function (File)
Schreiben: CREATE Function (File)

Alternativ: Umwandlung mit .NET
Reading and Writing Unicode Files using C/AL
Reading and Writing textfile with Encoding

Dateikonverterfunktionen für PowerShell

Achtung: Der optionale Parameter ASCII bei PowerShell-Cmdlets wie z.B. Out-File bedeutet Codepage 437 (sozusagen der amerikanische "Urvater" (als 8-Bit-Codepage von 1981), diese wiederum aufbauend auf dem "Uropa" US-ASCII (7-Bit-Codepage von 1963 mit nur 128 Zeichen) und damit nicht das gleiche wie "MsDos" in NAV. In dieser fehlen neben diversen anderen Abweichungen u.a. viele Sonderzeichen in Großbuchstaben, denen man in den westeuropäischen Sprachen so begegnet . Dafür kann Codepage 437 mehr Grafiksymbole, die unter DOS zur Erstellung von einfachen Grafiken genutzt werden können. Im Artikel zu Codepage 850 sind die Abweichungen farblich markiert bzw. einzeln verglichen. In den Funktionen habe ich natürlich u.a. deswegen auf Out-File verzichtet, aber auch weil man nur über DotNet-Methoden die volle Flexibilität für alle existierenden Codepages erhält. Ansonsten ist der richtige Parameter in der PowerShell für Codepage 850 bei üblichen Systemeinstellungen für Westeuropa OEM.

Ich kenn mich damit leider überhaupt nicht aus

In solchen Fällen:
The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!)
A tutorial on character code issues
Unicode Transformation Format
UCS vs UTF-8 as Internal String Encoding
Unicode, UTF8 & Character Sets: The Ultimate Guide
https://en.wikipedia.org/wiki/Mojibake
Grundlagen Zeichenkodierung
Zeichenkodierung Begriffe
UTF-8 Encoding Debugging Chart
https://csharpindepth.com/Articles/Unicode
http://unicode.scarfboy.com
https://wiki.selfhtml.org/wiki/Zeichencodierung
Ü auf Umwegen (Linux-Magazin, Juli 2007)


NAV-Speziell
https://blogs.msdn.microsoft.com/freddyk/2008/11/10/nav-2009-and-unicode/
https://community.dynamics.com/business/b/navteam/posts/unicode-and-microsoft-dynamics-nav-2013

Windows
Microsoft-Windows-International-Core

Danke Kai!

Ab NAV 2013 R2 kann man den Parameter TextEncoding beim Import und Export von Dateien optional zusätzlich verwenden.
Mögliche Werte hier: MsDos, UTF8, UTF16, Windows.

Achtung, es ist nicht nur eine neue Option, es ist sogar unerlässlich, beim Import (also File.OPEN) den Encoding-Parameter entsprechend dem erwarteten Zeichensatz zu setzen.
Wie Kai schon sagte: setzt man den Encoding-Parameter NICHT, nimmt NAV MsDos an. Dieses liefert aber nur dann den richtigen Inhalt, wenn die einzulesende Datei im Format MsDos erzeugt worden war. Stammt die Datei aus einem anderen System als NAV (oder ist dort in ein anderes Format wie z.B. ANSI konviertiert worden), ist der Ärger quasi schon vorprogrammiert.

Weiterhin gibt es zu beachten, dass wenn man eine Datei mit Encoding=UTF8 öffnet, diese zuvor aber im Format MsDos oder Windows erstellt worden war, der Client zumindest unter NAV 2016 CU6 abstürzt.
Klar ist das eine Kombination, die man in der Praxis NICHT wählen sollte. Die übrigen Encoding-Kombinationen beim Export und Import aber funktionieren ohne Absturz, liefern halt nur Buchstabensalat.
Ich wollte das Microsoft melden, aber deren Ticketsystem ist gerade ausgefallen. Habe es jetzt Microsoft gemeldet.

Edit: Crash korrgiert mit CU9 für NAV 2016.

Achtung, es ist nicht nur eine neue Option, es ist sogar unerlässlich, beim Import (also File.OPEN) den Encoding-Parameter entsprechend dem erwarteten Zeichensatz zu setzen.
Wie Kai schon sagte: setzt man den Encoding-Parameter NICHT, nimmt NAV MsDos an. Dieses liefert aber nur dann den richtigen Inhalt, wenn die einzulesende Datei im Format MsDos erzeugt worden war. Stammt die Datei aus einem anderen System als NAV (oder ist dort in ein anderes Format wie z.B. ANSI konviertiert worden), ist der Ärger quasi schon vorprogrammiert.

Und prompt ein schönes Beispiel aus dem NAV-Standard: Cumulative Update 7 für NAV 2016

Weiterhin gibt es zu beachten, dass wenn man eine Datei mit Encoding=UTF8 öffnet, diese zuvor aber im Format MsDos oder Windows erstellt worden war, der Client zumindest unter NAV 2016 CU6 abstürzt.

Nun habe ich einen weiteren Bug bei UTF-8, der den NAV 2016 Windows Client abstürzen lässt ("Cannot access a closed file." in der Ereignisanzeige). Meldung an Microsoft geht raus.

Letter ist eine Variable vom Typ Text mit der Länge 1.

Code:

// Read files with InStream
TestFile.OPEN('C:\Temp\File1.txt',TEXTENCODING::UTF8);
TestFile.CREATEINSTREAM(NAVInStream);
NAVInStream.READ(Letter);
TestFile.CLOSE;

TestFile.OPEN('C:\Temp\File2.txt',TEXTENCODING::UTF8);
TestFile.CREATEINSTREAM(NAVInStream);
// in case of UTF-8, NAVInStream still is pointing to closed File1, it seems
NAVInStream.READ(Letter); // ==> CRASH in case of UTF-8: "Cannot access a closed file."
TestFile.CLOSE;

Workaround:

Code:

[...]
TestFile.CLOSE;
CLEAR(NAVInStream); // <--- Neue Zeile

TestFile.OPEN('C:\Temp\File2.txt',TEXTENCODING::UTF8);
[...]


Edit: Crash korrgiert mit CU9 für NAV 2016.