I have encoded message at receive pipeline 

byte[] msgBodyContentBytesConverted = Encoding.Convert(Encoding.Unicode, Encoding.UTF8, msgBodyContentBytes);

But when i m tried to decode text using below listed code

   1. byte[] msgBodyContentBytes = Encoding.UTF8.GetBytes(text);
           string returntext = System.Text.Encoding.UTF8.GetString(msgBodyContentBytes);
           return returntext;

There is no change in the value

The encoded value is "" but when i am trying to decode .. the output is same.

Can any one suggest me where i m missing

• Edited by Singh AK Wednesday, February 18, 2015 2:21 AM

Well, why are you even doing this?

The code you have above, in the vase majority of cases, will not change anything, even the resulting byte stream will be identical except maybe the Byte Order Mark.

Sorry, this line doesn't make sense: I tried to encode special char"" and after the encryption the value is " " .

The encoding and encryption are directly related.

Even i understand "The encoding and encryption are directly related.".

I am trying to do this is to support all UTF-8 Char set. But by seeing the result after decoding i was bit surprised.

As mentioned on the other thread, you don't need to do anything to support UTF-8.

It's still not clear what problem you're trying to solve.

It is replacing most of the character with ??????????? after been published to the message box or during instance validation at schema level. 

Who is "it"? BizTalk?

So are you saying that if you use a PassThruReceive Pipeline the characters appear correct, but as soon as you introduce Pipelines / Maps on the Receive Port your characters are replaced?? Are you absolutely sure that the problem does not originate from the source message?

Morten la Cour

Yes for routing using passthrough there is absolutely no problem. The moment i am using other pipeline few  of the character replaced to ????

But on the other hand when i am changing the code page property of schema to Western European(1252)... Whole message works fine.

But i can not go with it as it don't support all char set.

Well, that means that the SOURCE is encoded in ISO-8859-1 (1252), and that also means that your source file is saved as ANSI. You will NEVER be able to convert that to unicode/UTF-8, so if you require the support of all the worlds characters and western European is not enough, then you need to contact the people generating the source file and ask them to save the file as UTF-8!

Morten la Cour

Before going any further, you should work with the source of the flat file to determine exactly what encoding and code page they are supposed to be producing.

Keep in mind, the encoding (ANSI, UTF-8, etc) and code page (Windows-1252) are different things.  The easiest way to explain, in this context, is the code page is a specific interpretation of the ANSI character set.

And no, 1252 does not support 'all' characters, only Western European.  However, if setting WE-1252 makes everything "work fine" then they are very, very likely sending ANSI text using the 1252 Code Page.

Here's where I think this is breaking down.  The Code Page setting on a Flat File Schema is used by the disassembler to translate the platform specific WE-1252 characters to their comparable UTF-8 characters.  So, what you get out of the Flat File Disassembler is the UTF-8 translation of those characters. Xml does not support any Windows Code pages.

If the file is coming in as WE-1252 ANSI, then the source cannot send anything beyond that so, again, you don't need to worry about it, they couldn't send a high UTF-8 character even if they wanted to.

Alternatively, if they want to send full UTF-8, they can't use the WE-1252 code page with the lower 256, it just doesn't work like that.