Hello,
I create Add-In and configure to use in Navision like in the blog: "Add-ins for the RoleTailored client of Dynamics NAV 2009 SP1 (part2)"
http://blogs.msdn.com/b/cabeln/archive/ ... part2.aspx
I send string from BigText, data prepared by XMLport with UTF-8. After in add-in received data going to save in a file, now that has specific chars mixed-up:
(source char ī (c4 ab) became (c2 b8)+(c2 bd) )
What should I do to get correct charset?
Thank you,
Yuri
Comments
Here is my blogpost about it:
http://devch.wordpress.com/2011/12/22/clean-workaround-for-special-characters-in-bigtext-variables/
you need 2009 R2 to get it work!
BTW - say hello to Elva guys from me:)
edited:
Ok, didn't got, you sending a string from NAV - even simplier. Get rid of bigtext - use xmldom, and send entrie xmldom variable to your .NET application. So, stream out data from xml port, load to xmldom, send to .NET.
It is good to use xmldom object. But I choose other way, because of: no time to test new solution plus minimize changes on .Net part.
So, I use HTMLdecode/encode technique. It is good that I have nonASCII chars only at one direction from Nav to DLL. Algorithm is:
1. string stored in BigText I encode
2. then in .NET dll I decode received text
3. then general XML processing left the same – that mean in c# code only one additional statement: _xml = System.Web.HttpUtility.HtmlDecode(value);
The biggest problem is on Nav side, because as it was mentioned before by ppavuk: Navision works with ANSI charset - not utf-8. So it is challenge to encode utf-8 text (need to know the structure of that unicode), hereby in attachment is code for those who are interested.
P.S. special HELLO to Peter from Raimond.
Navision developer, (3 years in NAV)
You only have a problem sending data to C#
NAV
1.
fillup Bigtext with text
2.
encode with UTF8ToHTML
3.
Send result back to webservice
C#
1.
decode to html
(Just edited the steps)
base64 obviosly do not contain any utf-8 char, and all encode\decode will be transparent, and moreover you can get rid of lots of code lines.
Let's have a look to pseudo-code below.
Say hello to Raimonds too
please read my blogpost (i already posted as 1. reply...) where i discribe how to use Dot Net StreamReader to solve the problem, it's simple & fast.
And yes, all text parsing/converting code in C/AL is extremely slow! We have to avoid this if possible.
Actually not, you already iterating to create nodes. just add base64 property to node type. That's all.
this problem does not occur in 2013
In NAV 2009 and earlier the problem only exist when sending data From NAV to ?
to whatever external application, and reading from external apps.
In R2 conversion can be done by .NET stream reader,
In earliest versions - by XmlDom (base64)
There is also third way -
Maybe there is more ways, but i think 3 is enough
All this make sense if your locale is not US or not UK (or not whatever English)
ADOStreamUTF and ADOStreamANSI are no dotNET variables but Automation variables linked to 'Microsoft ActiveX Data Objects 6.0 Library'.Stream'
And to get a working verion I also had to change the sequence of statements:
...
Everybody on-line.
...
Looking good!