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/ALReading and Writing textfile with EncodingDateikonverterfunktionen 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.