NAV 2013 R2: how to use Ansi2SystemEncoding function

Reedberg

Hello experts,
I am working with NAV 2013 R2. Recently I had to create a procedure to import text file encoded in ANSI format into NAV. I used the solution similar to the one described by the following link: https://community.dynamics.com/nav/b/navteam/archive/2012/12/05/unicode-and-microsoft-dynamics-nav-2013. It worked fine for me. However, I found that there is a built-in function Ansi2SystemEncoding in "File Management" codeunit (ID 419), which probably can be used for such purposes.
Unfortnuately, I didn't understand how to use it. The function receives two parameters with OutStream and InStream type.

1. It is not clear for me what is the purpose of such function? If I want to import text file, I only need InStream type, I don't see the why this function takes OutStream type as a second parameter? Does the function takes text from one text file and copy it into another text file?
2. Can I use this function to import text file encoded in ANSI into NAV? If yes, then how?

Thank you all in advance!

marvinas

Ansi2SystemEncoding(Destination : OutStream;Source : InStream);

Source parameter (InStream) is your input in ANSI, Destination OutStream is your result, encoded in system encoding. So you open your text file, you read the file using an InStream, and pass that InStream to the encoding function, receiving output in the OutStream parameter. Read help about CreateInStream (File) function on more details how to do it.

Reedberg

marvinas,
Thank your for your reply, but unfortunately it is not very helpful. I understand that OutStream is the result, my question is how can I use this result?
The goal is very straightforward - take a text file an import it into NAV table. As I understand I can not write data from OutStream object into NAV table.

So, the question is how can I use this function to import text file encoded in ANSI into NAV table? Could you please provide some code sample, so I can get the idea. Thank you very much for your time, it is really appreciated.

kine

Do not forget that the File.Open has now new parameter TEXTENCODING you can use to set the correct encoding when working with the file. Even on xmlport you can set the textencoding through code...

Reedberg

kine,
Thank you for tour reply. Unfortunately, TEXTENCODING parameter contains only the following list of options: MsDos, UTF8, UTF16, or Windows. There is no option to open a file using ANSI format.

kine

And what codepage you mean by ANSI? ANSI is just institute creating the standards...

vaprog

kine wrote: »

And what codepage you mean by ANSI? ANSI is just institute creating the standards...

The ANSI codepage in windows is the default character encoding used by non-unicode applications in Windows. It is not a fixed encoding, but depends on your Windows' configuration. For most western languages, the default ANSI codepage is cp1252

The OEM codepage is the default character encoding used be non-unicode console applications. Just as with the ANSI codepage, this is dependend on you Windows' configuration. In the US it is normaly IBM437, in many western European countries it defaults to cp850.


So, Microsoft left out the still most frequently used text encoding in it's list of TEXTENCODINGs .

References:
https://en.wikipedia.org/wiki/Text_file#.TXT
https://msdn.microsoft.com/en-us/library/windows/desktop/dd317752(v=vs.85).aspx

Kowa

vaprog wrote: »

So, Microsoft left out the still most frequently used text encoding in it's list of TEXTENCODINGs .

No, 'Windows' here is just the short term for 'Windows ANSI code page setting'. 'Windows ANSI' would have been clearer.
It is explained here:
Text Encoding

marvinas

You have to connect your outstream to a file or BLOB field, and you will have the converted file there, ready for further manipulations. Or, depending on what file that is, you could connect it to some XML parser, for example, and take it from there.

kine

As @Kowa already answered, Windows encoding means ANSI codepage, MS-Dos means OEM codepage. It means, just use the correct option when opening the file and you are done. The conversion functions are not working there because data in NAV 2013/2015 are already UNICODE inside the text variables... and it means already messed up when you read them incorrectly.

Reedberg

Kowa,
Thank your for your reply. I am aware of the 'Windows' option, but I am not sure that this option will be a good solution. Quote from the link you provided: If you set the text encoding to Windows, you can import and export text files that are based on the Windows codepage on the user’s computer
So, suppose that I have a text file with Russian characters encoded in ANSI format. And I have a client connecting to NAV from Germany. The uesr computer has German settings and does no know anything about Russian Characters (default ANSI codepage is not cp1252) . What will be the result? Unfortunately, I cannot test it, but my guess is that Russian characters won't be imported correctly. Please provide some feedback about my suggestion - does it look reasonable?

marvinas,
Thank you for your reply too. I understand the option regarding connecting outstream to a file or BLOB, I don't really understand the option about some XML parser, could you please provide some code sample? Just how can I use it?

kine

Than you can just use the DotNet interop and the standard Stream functionality, where you can set any encoding you want... ;-)

Reedberg

Kine,
That is exactly what I had used - Stream Reader But then I found that there is a standard Ansi2SystemEncoding function in standard NAV, so I started to ask myself - did I write the code in the best possible way? Shouldn't I have use this standard function?

Your comment confirmed for me that using DotNet interop in this kind of situation is probably the best choice, so thank you.

Kowa

An alternative are these PowerShell functions I have written which you can adapt to all existing codepages (just exchange the OEM 850 for your code page, a unicode file will be generated).
www.msdynamics.de/viewtopic.php?f=17&t=25726
If you are not using the DotNet on-the-fly conversion, an import of russian characters on a German OS system will only work if the file is converted to unicode first (like UTF8) and the NAV client import is likewise set to UTF8.
For all conversion processes also keep in mind that any OEM or ANSI page converts to unicode, but not necessarily vice versa. All required characters have to be included in a code page for this to work.

Recommended reading on this subject:
joelonsoftware.com/articles/Unicode.html

Reedberg

Kowa,
Thank you so much for the provided link, it is very useful!