encoding of exported navision objects (.txt files)

dayscott

does anyone know which encoding an ordinary .txt file has (an exported nav object) ?

it doesn't seem to be unicode .

DenSter

ANSI

dayscott

thx, but:

'ANSI' is not one single encoding. It can mean a variety of different encodings - usually 8 bit extensions to ASCII -


so which one is CAL text export.

DenSter

The "encoding" property of any object text file when I open it in notepad says "ANSI". I don't know what else to say about that.

DenSter

Maybe this helps? http://codeftw.blogspot.com/2009/07/how ... -text.html

dayscott

firefox says: http://uploadz.eu/images/7anvv8hok4bdt2ewylt1.jpg

java compiler says: Cp1252

interesting huh

DenSter

It's all ANSI to me

Now how do we tell which one is not correct? Maybe neither one is correct?

fitol

dayscott wrote:

does anyone know which encoding an ordinary .txt file has (an exported nav object) ?
it doesn't seem to be unicode .

I just saw this post.

It's ASCII.
NAV CC uses the codepage you have set up in Control Panel, Regional and Language Options, Advanved tab, Language for non-Unicode programs.

vaprog

fitol wrote:

It's ASCII.

ASCII defines only the low 7-bit of each byte, so, your statement is not true.

fitol wrote:

NAV CC uses the codepage you have set up in Control Panel, Regional and Language Options, Advanved tab, Language for non-Unicode programs.

Well, I could not find that setting since I use a localized windows, but the setting that seems to come closest is in German Gebietsschema ändern with part of it's description: Laguage for non-Unicode compatible programs. This lets me select a language with sublanguage e.g. Portugese (Brasil). This however is no codepage but a language.

I don't think NAV uses any standard codepage. On my western europe machine with OEM=cp850 and ANSI=cp1252 NAV's codeset is made up of cp850 with line drawing characters replaced by characters from cp1252 starting with codepoint 0128, accending, leaving out any that are present in cp850 also.

The code editor on my machine is not able to display all glyphs the same way controls or messages do. For instance, the Euro sign € is displayed properly in the application, but not in the code editor. the Euro sign, besides, is one of those glyphs that are not part of cp850 but filled in at codepoint 176, having cp1252 codepoint 0128.

fitol

You are apparently only talking about US-ASCII, but for the rest of the world ASCII has been extended to include various national characters since the very early DOS days.
If you are old enough to have used DOS you will remember that you had to specify the correct codepage in CONFIG.SYS and AUTOEXEC.BAT in order to use some national characters which is located above $7F.
Navision uses the same character values.
This is why you have to manually code conversion from ANSI to ASCII in a dataport if you want to import a textfile containing these characters created with a "normal" Windows application.
Similarly, if you use a dataport to export text fields and then try to import the text file in for example Excel using the Text import Wizard you have to specify which codepage to use in order for these national characters to display correctly. Or manually convert from ASCII to ANSI in the dataport.
As you are from germany this problem is something I would expect you to be aware of since you tend to use characters such as ä, ö and ü.

I just found nice blog here which discusses this Unicode / ASCII (or OEM) issue:
http://blogs.msdn.com/b/freddyk/archive ... icode.aspx
Especially note this part:
•The development environment and the classic client is not Unicode. When you write strings in AL code they are in OEM.
•The import/export formats are OEM format.

deV.ch

It's Codepage 437 (US-OEM)

I used it in a .net program in combination with a StreamReader and all strings with special chars (ä,ö,é,è) are now correct.

StreamReader reader = new StreamReader(NavTxtStream, Encoding.GetEncoding(437));

Bastian_Selonke

deV.ch wrote:

It's Codepage 437 (US-OEM)

I used it in a .net program in combination with a StreamReader and all strings with special chars (ä,ö,é,è) are now correct.

StreamReader reader = new StreamReader(NavTxtStream, Encoding.GetEncoding(437));

I unfortunately have to disagree. Every OEM Codepage uses the same special character glyph numbers, so you could use 850, 852 etc. for this with nearly the same result for öäüé etc.

However, if you take a look at the € sign, which has been implemented later on in CP 858, it does not fit. To test it: Create a NAV object, insert € and ü in a caption, export it as .txt and open that file. You will see the ü displayed properly, but the €. If you import back this .txt file to NAV, the € is still there. This means that NAV is using either some weird magic inside or a Codepage we do not know about

deV.ch

I can confirm that, Euro Sign is not working...

I guess they used the 437 but had a problem as soon as the euro sign came in... if you use this codepage the "Ligth Shade" is used as euro ( ░
2591) i guess because it's the least important character there... but that's just a guess...

Edit: I Did som additional testing: exported a Object with Euro Sign in Caption of TextConst. Imported in my tool, exported again with Page 437. and everything looks fine, in Notepad. It's the same. So i realy think this is a nav thing: they needed to use Page 437 for compatibility or something like that. so they took the least usable sign and used it as the euro sign. If anyone from MS can confirm this, that would be nice, so i can add this logic to my tool too. to Display the correct string.

Edit2:

private static string ConvertNAVOEMToUnicode(string Input)
        {
            return Input.Replace('░', '€');
        }

This obviously solves the issue, but it's kind of a hack...
(To write the file back, i do the oposite of this)

Bastian_Selonke

Yepp, it is a hack and I wanted to avoid that. I have created a Microsoft Premier Support ticket for this and will post the solution as soon as I have one..

deV.ch

:thumbsup:

deV.ch

Any news on this?

Bastian_Selonke

Unfortunately, no... Microsoft forwarded my request to the developers based in the United States and told me that it will take a while to supply me with an answer #-o

deV.ch

Hello there, quite a time passed since your last post, are there any news on this topic? Have your recieved an answer on your request?

chrclausen

Any update from MS on this?