[
https://issues.apache.org/jira/browse/MIME4J-69?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12617164#action_12617164
]
Stefano Bagnara commented on MIME4J-69:
---------------------------------------
It seems ATM encoded words in the textual part of addresses are parsed but then
we only use the raw string when we output it.
Before I start analyzing this stuff, I'd like to hear other's opinions about
how to handle lazy parsing of this stuff and how to deal with writeTo (use the
raw part vs use the "generated" part).
Given that the field is immutable ATM we could always use the raw part but I
would like mime4j to "fix" malformations when outputting from the DOM: should
we dial with this by recognizing malformations during parsing (lazily or by
options) and "generating" output from scratch when the raw part has been
recognized as malformed ?
> Decoding/encoding is not coherent between headers and body
> ----------------------------------------------------------
>
> Key: MIME4J-69
> URL: https://issues.apache.org/jira/browse/MIME4J-69
> Project: Mime4j
> Issue Type: Bug
> Affects Versions: 0.4
> Reporter: Stefano Bagnara
> Fix For: 0.4
>
>
> It seems that we automatically decode quoted-printable and base64 encoded
> bodies, but we ignore encoding when the =?encoding?data? encoding is used in
> headers.
> We have procedures to deal with this kind of structures but we don't do that:
> DecoderUtil.decodeEncodedWords
> Should an header field automatically be decoded?
> Related: AFAIK most MUA also deal with 8bit headers (not compliant with MIME)
> treating them as if they were in the same charset of the body (recently this
> behavious has been added to Thunderbird too).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
