Is UTF-16 and PR_Store_Support_Mask/UNICODE?

[asno...@gmail.com]

I am trying to generate MIME file out of MAPI message, without using
CDO. I am using C++ and have doubts about the code-page of the data
returned by PR_BODY. Please clarify.

1) This is about the code-page of the PR_BODY. I obtained IStream from
PR_BODY and passed it to IMultiLanguage2::DetectCodepageInIStream(),
and the returned code-page as "Windows-1252". How this could be
possible given PR_STORE_SUPPORT_MASK is UNICODE? and I was expecting
the return code to be Utf-16. .

MAPI message being used for this experiment has Japanese characters,
and I also have the MIME version of the this same particular MAPI
message, captured using EX-Journalling service, and the "charset" on
that Journal-MIME message is "Iso-Jp-2022".

Irrespective of language(English or otherwise), I expected
IMultiLanguage2::DetectCodepageInIStream() to return "Utf-16" because
is PR_STORE_SUPPORT_MASK. Also PR_INTERNET_CPID, for this message
pointed to "Iso-Jp-2022"

2) This question is about the "charset" that I could use while
stuffing PR_BODY into MIME bodypart. I know preferred method is to
convert to UTF-8 and then stuff in to MIME bodypart. Given
PR_STORE_SUPPORT_MASK, Is there anything wrong is doing this?
----content-type: text/plain
charset: "UTF-16"
content-transfer-encoding: "base64"

(PR_Body after converting to "base64')

I am thinking of just converting PR_BODY to Utf-8 before stuffing it
to MIME Bodypart. My application is going to run against Ex2003 and
above, and those store's must have PR_STORE_SUPPORT_MASK set.

Please clarify above doubts.
Ramesh

[Dmitry Streblechenko]

How are you compiling your code? Do you end up using PR_BODY_A or PR_BODY_W
property?
It is up to you what codepage you are using as logn as you can preserve teh
data correctly.

--
Dmitry Streblechenko (MVP)
http://www.dimastr.com/
OutlookSpy - Outlook, CDO
and MAPI Developer Tool
-
<asno...@gmail.com> wrote in message
news:f46ae06e-27e7-4de2...@f10g2000vbl.googlegroups.com...