[
https://issues.apache.org/jira/browse/MIME4J-118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12676087#action_12676087
]
Markus Wiederkehr commented on MIME4J-118:
------------------------------------------
As I have outlined before I would prefer a solution where Field exposes the
original data as a sequence of bytes instead of as a String. This way
MessageWriter could simply use that data as is.
Also it seems that the lenient parsing is not done correctly in
DefaultBodyDescriptor because it only uses the Content-Type charset to decode
header fields that come after Content-Type. Header field parsing would have to
be deferred until Content-Type is encountered for this to work as expected.
Btw I'm with Stefano on this one; I think we don't have to implement something
like that until someone asks for it. Also deferred header field parsing can
always be done in a custom ContentHandler implementation (in endHeader()).
> MIME stream parser handles non-ASCII fields incorrectly
> -------------------------------------------------------
>
> Key: MIME4J-118
> URL: https://issues.apache.org/jira/browse/MIME4J-118
> Project: JAMES Mime4j
> Issue Type: Bug
> Reporter: Oleg Kalnichevski
> Assignee: Oleg Kalnichevski
> Fix For: 0.6
>
> Attachments: mime4j-118-field.patch, mimej4-118.patch
>
>
> Presently MIME stream parser handles non-ASCII fields incorrectly. Binary
> field content gets converted to its textual representation too early in the
> parsing process using simple byte to char cast. The decision about
> appropriate char encoding should be left up to individual ContentHandler
> implementations.
> Oleg
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
