Reading and Writing Unicode Files using C/AL


We have had some partner suggestion for adding Unicode capabilities to the existing Microsoft Dynamics NAV File functions. What we recommend is to use .NET Interop to achieve this functionality.

For example, you can use an instance of the System.IO.StreamWriter class to write to an OutStream or the System.IO.StreamReader class to read from an InStream. You control the encoding by using the System.Text.Encoding class where you select between Default, Unicode or UTF8 encoding.

  • Please note that XMLports in Microsoft Dynamics NAV 2013 directly supports importing and exporting flat text files in MS-DOS, UTF-8, UTF-16 encodings by setting the new TextEncoding property.

Writing Unicode text files

Let’s start with a small example on writing some text to a file in Unicode format.

Declare the following variables:

Name DataType Subtype
outFile File  
outStream OutStream  
streamWriter DotNet System.IO.StreamWriter.’mscorlib, Version=, Culture=neutral, PublicKeyToken=b77a5c561934e089′ 
encoding DotNet System.Text.Encoding.’mscorlib, Version=, Culture=neutral, PublicKeyToken=b77a5c561934e089′ 

Then write this code, using a suitable path for the outFile:



  streamWriter := streamWriter.StreamWriter(outStream, encoding.Unicode);


  streamWriter.WriteLine(‘Hello World’);




  • You can use ‘Hello World’ as above or a text string with some more special characters as you like. I added some Danish characters..: ‘Hello ÆØÅ World’ to more easily see what’s going on.

 Run the code and verify the file is in Unicode.

  • One way to verify a file is in Unicode is to open it with Notepad and select File/Save As…, and then inspect the Encoding field.

Try change the above example to use encoding.Default and verify the file is in ANSI (codepage) format (for example using Notepad as above).

Please note that if you use C/AL to write directly to the outStream, like this:

outStream.WRITETEXT(‘Hello World’);

this is still handled using MS-DOS encoding and is compatible with previous versions of Microsoft Dynamics NAV.

  • You can open a file in MS-DOS encoding by starting Wordpad and in the Open file dialog select “Text Documents – MS-DOS Format (*.txt)”.

In Microsoft Dynamics NAV 2013, all normal text handling are done in Unicode, so the data that are entered on the pages – like customer names one on the Customer Card – can utilize the Unicode character set, the data can be stored in the database and used in C/AL code.

Let’s see how you can extend the above example with data from the Customer table:

Add the customer variable:

Name DataType Subtype
 customer Record   Customer

And write this code – you can set a filter if needed:



  streamWriter := streamWriter.StreamWriter(outStream, encoding.Unicode);





  UNTIL customer.NEXT = 0;




 If you open the Customers.txt file with a Unicode file viewer it should contain all the Unicode details you have used for your customer names.

Reading Unicode text files

Similar to the above you can read Unicode text files by using the System.IO.StreamReader class to read from an InStream as you can see in the small example below:

Declare the following variables:

Name DataType Subtype
inFile File  
inStream InStream  
streamReader DotNet System.IO.StreamReader.’mscorlib, Version=, Culture=neutral, PublicKeyToken=b77a5c561934e089′
encoding DotNet System.Text.Encoding.’mscorlib, Version=, Culture=neutral, PublicKeyToken=b77a5c561934e089′
txt Text  

Then write this code, using a suitable path for the inFile:




  streamReader := streamReader.StreamReader(inStream,encoding.Unicode);

  txt := streamReader.ReadToEnd();


Create the Infile.txt as a Unicode file and add some Unicode characters to it. You should see them in the message box when you run the C/AL code.



I hope these simple examples can get you started with Unicode file handling in C/AL. 


Thanks and best regards!

Hans Kierulff

Comments (9)

  1. Urpo Kotipalo says:

    Hello Hans, and thank you for sharing this with all of us!

    I tested this in 2009R2 (with mscorlib version 2.0, obviously), and it seems to work somewhat after I changed the declaration of outStream to something like out_Stream, oStream or something else that is not a reserved word.

    After this change I was able to write 3072 characters until the outstream dies on me and gives an error "This message is for C/AL programmers: The call to member Dispose failed: Cannot access a closed file.."

    Do you happen to know how to fix this? I also have some problems in initiating the encoding part to use a specific codepage (ISO-8859-15) instead of those predefined ones (Unicode, UTF7, UTF8, UTF32)

  2. 4BzSoftware says:

    Hello, I got solution for Navision 2013 Table Fields Unicode Caption.

    You can try it S#001 at my SkyDrive link

  3. says:

    useful :)

  4. Allan says:


    I have used this on NAV2013 but after upgrading to NAV2013R2 – this now gives an error: "This message is for C/AL programmers: The call to member Dispose failed: Cannot access a closed file."

    Have the way of Disposing changed?

  5. Sebastiaan Lubbers says:

    @Allan: The .NET 4.0 version StreamReader.Close also closes then Stream used in the constructor. Apparantly this also works for the Nav File type.

  6. Allan says:

    @Sebastian: So what to do?

  7. User says:

    I try this solution for 2009R2 but it gives the error "Unknown type ''." when I try to compile.

    I already change the reserved names like outStream.

    Any ideia?

  8. User2 says:

    When writing large files the memory footprint of the service tier is very big (hundreds of megabytes for writing a 50 mb file).

    Something I wouldn't expect when working with file streams.

    Same code in a dotnet language has very low memory footprint (less than 5mb).

    The same is with other file-stream related stuff (reading and writing, like XmlWriter and XmlReader).

    Seems like a bug with stream handling in nav runtime to me.

    Can you please check this?

    thanks & best regards

  9. RWE says:

    In 2009R2 I also get a: "Unknown type ''." error when compiling. I've tried almost any variant of the syntax and variable declaration, but without luck. Have anyone succeeded with this in 2009R2 ?