Sonderzeichen ß Ansi2Ascii

Hallo wieder einmal,

in Nav 2013 konnte ich einen String der ein 'ß' enthält exportieren mittels GeneralManagement (CU 11501) Ansi2Ascii Funktion. Ab Nav 2015 und 2016 bringt er mir ein falsches Zeichen für das 'ß' raus.

Soweit so gut (schlecht). Habe ich natürlich die Funktion aus meinem 2013er geschnitten und mittels Txt File ins 2016er importiert. Darauf geachtet, dass Notepad++ die Ansi Kodierung verwendet. Ergebnis: keine Verbesserung.

Jemand von euch eine Idee oder eigene Erfahrungen?

Mit freundlichen Grüßen vom winterlichen Bodensee im April
Daniel

€dit: Die Ironie der Sache das Exportfile:
1: als Ansi Codierung in Notepad++

Code:

 õ³÷ß░;

2: als OEM 850 Codierung in Notepad++

Code:

äüöá°

3: Zeichensatz war

Code:

äüö߀

Mein gefundener Workaround: weglassen der Ansi2Ascii Funktion und benutzen des Files mit Textencoding::Windows.

exportieren mittels GeneralManagement (CU 11501) Ansi2Ascii Funktion

Die ist üblicherweise für den Import, für den Export dann Ascii2Ansi.

Soweit so gut (schlecht). Habe ich natürlich die Funktion aus meinem 2013er geschnitten und mittels Txt File ins 2016er importiert.

Direkt geht das nicht. Wenn der Code aus NAV 2015 oder älter dort eingebracht wird, ist das nicht kompilierbar.
Die NAV 2016 Codeeditor hat seine Probleme mit diesen Zeichen
’ LEFT SINGLE QUOTATION MARK Unicode Hexadecimal: 0x2018
‘ RIGHT SINGLE QUOTATION MARK Unicode Hexadecimal: 0x2018
ASCII and Unicode quotation marks
die dort enthalten sind, und interpretiert die beim Text als einfache Anführungszeichen (Aposthroph) ' 0x27.

Unabhängig davon gibt es mit dem ß offensichtlich arge Probleme. Im aktuellen Build 45480 kommt das falsche Zeichen î, in Build 44365 aus CU3 nur eine Leerstelle bei Ausgabe in eine Textdatei. Die Funktion in NAV 2016 ist bei den Zeichen stark verändert, funktioniert aber auch nicht.

Danke für die Antwort. Wird Zeit, dass wir in DACH die Sonderzeichen abschaffen.

Die Funktion in NAV 2016 ist bei den Zeichen stark verändert, funktioniert aber auch nicht.

Beide Funktionen (Ansi2Ascii und Ascii2Ansi) wurden in Cumulative Update 7 komplett aus Codeunit 11501 entfernt.
Die Handhabung von ANSI-Dateien wurde in den betroffenen Objekten auf TextEncoding::Windows umgearbeitet.

Kann ich mich ein wenig Stolz fühlen, dass Sie meinen Workaround ins CU eingebaut haben

Kann ich mich ein wenig Stolz fühlen, dass Sie meinen Workaround ins CU eingebaut haben

Das funktioniert aber leider nur solange man nur Versionen >= NAV 2013 R2 zu versorgen hat. Wenn man Code nach NAV 2013 oder älter downgraden muss, hat man nun erheblichen Zusatzaufwand, weil es für das Dateihandling überhaupt keinen gemeinsamen Nenner mehr gibt. Ein Umbau der Funktionen unter Nutzung des Konvertierungsmöglichkeiten des .NET-Frameworks hätte diese Nachteile nicht, da muss dann beim Downgrade nur der Inhalt der Funktion angepasst werden.

Hallo,

ich hatte hier schon mal einen Vorschlag für eine Lösung für die alte Version gemacht.

Gruß Fiddi

Wenn man Code nach NAV 2013 oder älter downgraden muss, hat man nun erheblichen Zusatzaufwand, weil es für das Dateihandling überhaupt keinen gemeinsamen Nenner mehr gibt.

Ausprobiert habe ich es noch nicht, aber diese Lösung mittels .NET wäre so schon ab NAV 2013 (und höher) einsetzbar und ermöglicht auch noch weitere Codepages:
http://larswestman.se/bye-bye-ansi2ascii-and-welcome-unicode/