This is a place holder bug to make Eudora import utility work for multi-byte msg data import for Japanese. Japanese specific charse handling needs to be implemented for the import utility to work. Here are the areas which need to be covered: 1. MIME charset needs to be in ISO-2022-JP in the imported data. 2. If the target data are in different encoding than the Eudora's data, then proper conversion, most likey from Shift_JIS to ISO-2022-JP need to be done. 3. Attachment data need to be restored without specific charset in the headers unless such info was preserved by Eudora. 4. Eudora Address Book entries need to be imported with proper conversion to the one required by Mozilla. 5. Proper matching of Address Book fields need to be preserved in case Japanese data follow different order.

QA contact to myself.

Need to coordinate with Rich to make sure I pass the right data to nsMsgComposeAndSend. Kat, can you test the address book stuff, it should be working now for multi-byte stuff

Rich, What format is the character data for the body passed to CreateAndSendMessage supposed to be in? The body pointer passed in is a const char *, is it expected to be in UTF-8 or is it already supposed to be encoded to match the expected charset?

The data should be already converted to the define charset. - rhp

Hmmm... So I have 8-bit data supposedly in the current system charset. How do I convert that to match the encoding specified in the email. For example, on a Japanese system how do I convert data from Shift-JIS to ISO-2022-JP? Anyone out there know the answer or where to look for an example of this?

There should be such a mapping service available already. For example, when we save a received message into a .text file format, we need to save it in the system encoding. This would be exactly the reverse of that process. Naoki?

No single conversion available to convert Shift_JIS to ISO-2022-JP. Need to convert twice through unicode. You can call two functions nsMsgI18NConvertToUnicode to convert to unicode then nsMsgI18NConvertFromUnicode to convert from unicode.

Anyone want to review this? The code now converts the Eudora data from the system charset to Unicode, then from Unicode to the charset specified in the message headers - if there is no charset in the message headers it calls nsMsgI18NGetDefaultMailCharset to get the default charset. Please note that I believe that nsMsgI18NGetDefaultMailCharset is incomplete and does not always return the correct thing for Japanese charsets. cvs diff nsEudoraCompose.cpp (in directory O:\mozilla\mailnews\import\eudora\src\) Index: nsEudoraCompose.cpp =================================================================== RCS file: /cvsroot/mozilla/mailnews/import/eudora/src/nsEudoraCompose.cpp,v retrieving revision 1.12 diff -r1.12 nsEudoraCompose.cpp 39a40 > #include "nsMsgI18N.h" 617c618,657 < rv = m_pSendProxy->CreateAndSendMessage( nsnull, // no editor shell --- > > /* > l10n - I have the body of the message in the system charset, > I need to "encode" it to be the charset for the message > *UNLESS* of course, I don't know what the charset of the message > should be? How do I determine what the charset should > be if it doesn't exist? > > */ > > nsString uniBody; > ConvertSysToUnicode( m_pBody, uniBody); > // now do we have a charset? > if (!charSet.Length()) { > if (!m_defCharset.Length()) { > char *pSet = nsMsgI18NGetDefaultMailCharset(); > m_defCharset.AssignWithConversion( pSet); > nsCRT::free( pSet); > } > charSet = m_defCharset; > } > nsCString body; > nsCString theCharset; > theCharset.AssignWithConversion( charSet); > > rv = nsMsgI18NConvertFromUnicode( theCharset, uniBody, body); > if (NS_FAILED( rv)) { > // in this case, if we did not use the default compose > // charset, then try that. > if (!charSet.Equals( m_defCharset)) { > theCharset.AssignWithConversion( m_defCharset); > body.Truncate(); > rv = nsMsgI18NConvertFromUnicode( theCharset, uniBody, body); > } > } > uniBody.Truncate(); > > if (NS_FAILED( rv)) { > > rv = m_pSendProxy->CreateAndSendMessage( nsnull, // no editor shell 632c672,690 < --- > } > else { > rv = m_pSendProxy->CreateAndSendMessage( nsnull, // no editor shell > m_pIdentity, // dummy identity > m_pMsgFields, // message fields > PR_FALSE, // digest = NO > PR_TRUE, // dont_deliver = YES, make a file > nsIMsgSend::nsMsgDeliverNow, // mode > nsnull, // no message to replace > pMimeType, // body type > body, // body pointer > body.Length(), // body length > nsnull, // remote attachment data > pAttach, // local attachments > nsnull, // related part > nsnull, 0); // listener array > > } > *****CVS exited normally with code 1*****

Looks good to me. - rhp

Fix checked in (at least fixed as best as I know how!).

Pass this on to ji. You can use Eudora-J on my Win95-J machine to create some messages. Or better yet, just use the existing Eudora messages. If the setup is too much, you can leave this one for me to verify before RTM, which is doable.

Checked with 2000091909 win32 build and Eudora 4.3J installed in my win95J. Everything looks fine except that the attachment file name in Japanese is displayed as raw utf7 string on seamonkey. If the mail is sent from seamonkey with the same attachment, I don't see this problem. Not sure about Kat's spec. I'd like to leave this to Kat with the check point done here.

Marked it as verified, since this is the original place holder bug. Problems found in the import utility from Eudora for Japanese mails are reported in bug 58897 and bug 64119.