NAV-Tools

Vielen Dank, aber warum steht in der Funktion dann:
" ANSI[84] := 245; ASCII[84] := 228; // ä " ???

Bei mir steht in der Codeunit

Code:

ANSI[67] := 228;   ASCII[67] := 132;  // ä
[...]
ANSI[84] := 245;   ASCII[84] := 228;  // õ

Nachtrag:
Ich habe mir die Objekte gerade noch einmal heruntergeladen und die Textdatei in Notepad++ geöffnet.
Dort steht tatsächlich die von dir angegebene Zeile, jedoch zeigt mir Notepad++, dass die Datei als ANSI interpretiert wurde.
NAV-Objekt-Textdateien sind jedoch als ASCII zu interpretieren.
Stelle ich in dem Texteditor die Kodierung von ANSI auf ASCII, dann zeigt mir der Texteditor sie auch richtig an.

Die Datei ist also richtig, wird von deinem Texteditor jedoch falsch interpretiert.
Importierst du die Datei in NAV, dann müsste die Codeunit bei dir genauso angezeigt werden, wie in meinem oben geschriebenen Code.

Vielen Dank, jetzt funktioniert es.

Die Base 64 Encode/Decode Funktion in Deinen Tools benutzt den DataType binary der in NAV 2009 nicht mehr unterstützt wird lt. Online-Hilfe.
Ist die Funktion für NAV 2009 nun nicht mehr verfügbar?

Da die hier zur Verfügung gestellten Objekte auf 5.00 basieren, und die Funktionen nicht aus meiner eigenen Feder stammen, kann ich zur Zeit noch nicht sagen, ob es eine alternative Variante (ohne Binary-Datentyp) geben wird, oder ob die Funktion leider nicht mehr in purem C/AL-Code angeboten werden kann.

Hi,

ich wollte gerade die Funktion "ASCII2EBCDIC" verwenden bekomme aber den Fehler, dass die CONVERT Funktion die gleiche Zeichenlänge für die Parameter benötigt. Grund ist, das die Variable "ASCII-E" das Zeichen 27 nicht gesetzt bekommt und EBCDIC bis 84 gesetzt wird.
Weiß jemand, was Zeichen 27 wäre?

Wenn das ein dezimaler Code 27 ist, dann das ist das normalerweise ESC oder 0x1b was im EBCDIC wahrscheinlich nicht vorhanden ist.

Gruß, Fiddi

Habe die Codeunits importiert.
Jedoch habe ich beim aufrufen der CU`s das Problem, dass mir immer gesagt wird ich habe keine Rechte um ausführen der CU?

Kann ich das ändern?!

Habe die Codeunits importiert.
Jedoch habe ich beim aufrufen der CU`s das Problem, dass mir immer gesagt wird ich habe keine Rechte um ausführen der CU?

Kann ich das ändern?!

Das Problem ist wahrscheinlich, dass die IDs der CUs nicht in eurer Lizenz stehen und daher die Meldung kommt.
Du hast zwei Möglichkeiten:
1. Du änderst in der Textdatei die IDs der Cus auf eure Lizenz ab oder
2. Du wendest dich an deinen Partner, der wird dir helfen.

@Timo Lässer:
viewtopic.php?f=7&t=2353&p=80786#p80786

Dieser Bugfix ermöglicht es auch dem RTC, Ordner auszuwählen.

In InitEBCDICMap hat sich noch ein kleiner Copy&Paste-Fehlerteufel eingeschlichen:

Code:

EBCDICchars[17] := 216;  ASCIIchars[17] := 81;  // Q
...
EBCDICchars[27] := 129;  ASCIIchars[17] := 97;  // a

Durch die doppelte Verwendung des 17. Zeichens sind die beiden Strings nicht gleich lang und können bei CONVERTSTR nicht verwendet werden.

Alle Zeichensätze (ASCII, ANSI, UTF-8) sind in den ersten 7 Bit (also bis einschließlich Position 127) identisch, somit brauchen diese Zeichen nicht konvertiert werden.
(Von ISO8859-1 nach UTF-8 sind die Zeichen sogar bis Position 159 identisch.)

Wo finde ich die hier angesprochene Konvertierung von UTF-8 <> ASCII für die Zeichen ab 160? Ist das gar nicht in den Tools enthalten?

Hallo,

ich habe in NAV2013 gerade ein Problem mit Ansi2Ascii und dem großen 'Ü'.

Wenn man aus einer ANSI codierte Datei Daten mit einem 'Ü' in den Daten einliest, egal ob Textmode oder nicht, bekommt man nach dem Einlesen nicht das Zeichen mit dem Bytewert 220 sondern ein 'œ' zurück.
Gibt man das eingelesene Zeichen dann als als integer aus, erhält man 339 als Ergebnis, interessant bei einem Byte- Wert
Ansi2Ascii funktioniert aus diesem Grund auch nicht für dieses Zeichen. Diese Funktion ist so auch nicht zum laufen zu bringen, wie soll ich der Variable ANSI[59] mit einem maximalen Wert von 256 den Wert 339 zuweisen? Das funktioniert zwar, bringt aber auch nicht das gewünschte Ergebnis.

Die einzige Möglichkeit Ansi2Ascii z.Zt. brauchbar umzusetzen scheint der Weg über die CU 11501 (GenralMgt) zu sein, die direkt einen String konvertiert, das funktioniert. Der Textimport des Object- Designers scheint den Code für Ansi- Ü anscheinend richtig falsch in einen brauchbaren Konvertierungsstring umzusetzen.

Is this a bug or is this a feature?

Gruß Fiddi

NAV2013 und Ansi2Ascii?
Müsste man da nicht etwas wie Ansi2Unicode haben?

Müsste man da nicht etwas wie Ansi2Unicode haben?

Das scheint mir hier nicht das Problem.

Der Fehler passiert ja schon beim Einlesen der Daten. Schon der Quellstring enthält den falschen Code. Da muss es ein Problem bei der Zuweisung des Textstrings geben, denn es ist egal welche Routine man zum Einlesen benutzt (File oder Stream, Binär oder Textmode), es kommt immer das gleiche falsche Zeichen in der eingelesenen Variable an.

Intern arbeitet NAV anscheinend immer noch mit der Codepage 850 (zumindest in Deutschland), sonst wären die Objektexporte egal ob FOB oder TXT nicht mehr kompatibel zu älteren Versionen.

Gruß, Fiddi

Vielleicht kann ich ja hier ein wenig Licht ins Dunkel bringen. Beginnend mit Dynamics NAV 2013 arbeiten wir intern mit Unicode. Um alle Unicode-Zeichen darstellen zu können, benötigen wir nicht nur 8 Bit, sondern 16 Bit, dementsprechend auch 2 Byte. Es war also zwingend notwendig, den Char Datentyp auf 16 Bit zu verlängern.

Mit dieser Information im Kopf dran denken: Standard-File-Behandlung ist beim OPEN() (ohne zweiten Parameter Encoding wie unter 2013 R2) das Öffnen der Datei als OEM, wie bisher mit dem Nachteil der fehlerhaften Codierung in Dynamics NAV, da als Encoding OEM angenommen wird, aber tatsächlich ANSI (Latin-1) enthalten ist. Das impliziert aber auch eine Konvertierung von (vermeintlich) OEM in Unicode, ergo 16 Bit -> Char[] Datatype.

Eine Konvertierung dann auf Basis einer Text Variablen, welche aber eigentlich ein Array aus Unicode Chars ist (16 Bit), führt dabei genau zu deinem Phänomen. Bis 2009 war Byte und Char so gut wie gleichzusetzen, aber beginnend mit 2013 kann es bei gleicher Verwendung entsprechend Unterschiede geben.

Dein Zeichen 'œ' (16 Bit, Unicode) findet sich in der Unicode Tabelle (http://unicode-table.com/de/#basic-latin) bei 0x0153 (= 339 Dezimal). Ursprung ist die falsche Annahme, es handele sich um eine OEM-Datei und nicht um ANSI.

Beginnend mit 2013 R2 ist dann so etwas möglich:

Code:

f.OPEN(Filename, TEXTENCODING::Windows);

Lösung wäre dementsprechend, die Umsetzung der Zeichen auf Basis der 16 Bit Werte durchzuführen.

Hallo Carsten,

danke für deine Ausführungen. Deine Erklärung wäre logisch, hat aber einen kleinen Haken:
Der Code für das Große 'Ü' ist \0xDC im Ansi- Zeichensatz, die OEM (CP850) hat an der Stelle ein '▄' das wäre in Unicode \0x2584 und nicht \0x0152. Also ist hier schon mal die Übersetzung falsch, wenn deine Unicode- Vermutung richtig wäre.
Das kleine 'ü' dessen Übersetzung immer noch funktioniert, hat in Ansi den Code \0xFC das ist in OEM ein '³' dies nach Unicode übersetzt müsste ein \0x00b3 ergeben, tut es aber nicht, sondern wird in NAV ganz korrekt als kleines 'ü' dargestellt.

Also irgendwo stimmt da was nicht.

Ich habe meinen Test nochmal in NAV 2009- Classic gefahren, das liefert den gleichen Einlesestring auch mit 'œ' für das Ansi- 'Ü', in soweit wären dann 2009 und 2013 kompatibel. Ich frage mich nur woher NAV 2009 das Zeichen nimmt, das ist in keinem europäischen OEM- Zeichensatz enthalten.
Und hier scheint auch das Problem zu liegen. NAV 2013 mapt die Zeichen beim Einlesen wieder auf die gleichen Zeichen, wie es auch im CC der Fall war, nur dass das in NAV 2013 keinen 8-Bit Code für das 'œ' gibt, und damit auf den Unicode ausgewichen wird.

Gruß, Fiddi

Ich gebe zu, das ich dazu auch keine passende Erklärung habe. Mir reicht aber aus, dass ich bei richtiger Codierung auch das für mich korrekte Ergebnis bekomme

Unten jeweils Byte- und Char-Werte nach dem Einlesen:

Code:

READ (OEM -> Default): Dies ist ein Test: äöüÄÖÜß
Byte: 68 - 105 - 101 - 115 - 32 - 105 - 115 - 116 - 32 - 101 - 105 - 110 - 32 - 84 - 101 - 115 - 116 - 58 - 32 - 132 - 148 - 129 - 142 - 153 - 154 - 225 -
Char: 68 - 105 - 101 - 115 - 32 - 105 - 115 - 116 - 32 - 101 - 105 - 110 - 32 - 84 - 101 - 115 - 116 - 58 - 32 - 228 - 246 - 252 - 196 - 214 - 220 - 223 -

READ (ANSI -> Default): Dies ist ein Test: õ÷³Íœ
Byte: 68 - 105 - 101 - 115 - 32 - 105 - 115 - 116 - 32 - 101 - 105 - 110 - 32 - 84 - 101 - 115 - 116 - 58 - 32 - 228 - 246 - 252 - 196 - 214 - 220 - 223 -
Char: 68 - 105 - 101 - 115 - 32 - 105 - 115 - 116 - 32 - 101 - 105 - 110 - 32 - 84 - 101 - 115 - 116 - 58 - 32 - 245 - 247 - 179 - 143 - 205 - 339 - 157 -

READ (OEM -> Windows (ANSI)): Dies ist ein Test: „”Ž™šá
Byte: 68 - 105 - 101 - 115 - 32 - 105 - 115 - 116 - 32 - 101 - 105 - 110 - 32 - 84 - 101 - 115 - 116 - 58 - 32 - 179 - 203 - 177 - 195 - 217 - 218 - 160 -
Char: 68 - 105 - 101 - 115 - 32 - 105 - 115 - 116 - 32 - 101 - 105 - 110 - 32 - 84 - 101 - 115 - 116 - 58 - 32 - 8222 - 8221 - 129 - 381 - 8482 - 353 - 225 -

READ (ANSI -> Windows (ANSI)): Dies ist ein Test: äöüÄÖÜß
Byte: 68 - 105 - 101 - 115 - 32 - 105 - 115 - 116 - 32 - 101 - 105 - 110 - 32 - 84 - 101 - 115 - 116 - 58 - 32 - 132 - 148 - 129 - 142 - 153 - 154 - 225 -
Char: 68 - 105 - 101 - 115 - 32 - 105 - 115 - 116 - 32 - 101 - 105 - 110 - 32 - 84 - 101 - 115 - 116 - 58 - 32 - 228 - 246 - 252 - 196 - 214 - 220 - 223 -

Hallo,

eigentlich hat Timo schon Recht. Man benötigt eigentlich Ansi2Unicode. Was mich nur gewundert hat, warum Ansi2Ascii immer noch (zumindest teilweise) funktioniert.
Es scheint so zu sein, das die Umlaute bei der ganzen Umsetzerei gerade so verschoben werden, dass Ansi2Ascii nach der Konvertierung noch das korrekte Ergebnis auch in Unicode liefert. Allerdings nur für 'öäüÖÄ', 'ß' funktioniert schon wieder nicht mehr.

Gruß, Fiddi

Hier sind Codebeispiele im MSDN-Blog mit dem Einsatz von DotNet-Datatypes (System.IO.StreamWriter,System.IO.StreamReader,System.Text.Encoding) ab NAV 2013.
Reading and Writing Unicode Files using C/AL
Allgemeine Hinweise (ab NAV 2013 R2)
Text Encoding

Zu der Entwicklung von ASCII über Codepages zu den verschiedenen Verfahren bei Unicode ist hier ein interessanter Artikel
http://www.joelonsoftware.com/articles/Unicode.html

Hello Timo,

I want to use Base64EncodeStream Function from your CodeUnit in NAV 2013 R2,
but I took an Error like this "This prefix operator cannot be used on char";

Hello Furkan,

as you can see, this could was taken from mibuso.com in 2006 (NAV4.00).

Code:

Documentation()
[...]
 | Date       Version No. Description                       |
 +----------------------------------------------------------+
 | 14.03.2006 TL4.01  00  Encrypt/Decrypt Management        |
 |                        - MD5-Encoding                    |
 |                        - Base64EncodeStream              |
 |                        - Base64DecodeStream              |

Code:

Base64EncodeStream(VAR InStr : InStream;VAR OutStr : OutStream)
// +---------------------------------------------------------+
// | Credits goes to 'fb' on mibuso for this topic:          |
// | http://www.mibuso.com/forum/viewtopic.php?p=20166#20166 |
// +---------------------------------------------------------+

It could be that this procedure is not compatible with later versions.

Hello Furkan,

as you can see, this could was taken from mibuso.com in 2006 (NAV4.00).

Code:

Documentation()
[...]
 | Date       Version No. Description                       |
 +----------------------------------------------------------+
 | 14.03.2006 TL4.01  00  Encrypt/Decrypt Management        |
 |                        - MD5-Encoding                    |
 |                        - Base64EncodeStream              |
 |                        - Base64DecodeStream              |

Code:

Base64EncodeStream(VAR InStr : InStream;VAR OutStr : OutStream)
// +---------------------------------------------------------+
// | Credits goes to 'fb' on mibuso for this topic:          |
// | http://www.mibuso.com/forum/viewtopic.php?p=20166#20166 |
// +---------------------------------------------------------+

It could be that this procedure is not compatible with later versions.

Thanks for your reply tough it is a very old post :)

I have a physical .zip file and i want to convert this file Base64. What's your offers about that problem ? How can we do this ?

Thanks for your support.