james-mime4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Markus Wiederkehr <markus.wiederk...@gmail.com>
Subject Re: [jira] Updated: (MIME4J-118) MIME stream parser handles non-ASCII fields incorrectly
Date Fri, 20 Feb 2009 12:06:06 GMT
On Thu, Feb 19, 2009 at 6:06 PM, Oleg Kalnichevski (JIRA)
<mime4j-dev@james.apache.org> wrote:
>     [ https://issues.apache.org/jira/browse/MIME4J-118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
> Oleg Kalnichevski updated MIME4J-118:
> -------------------------------------
>    Attachment: mime4j-118-field.patch
> Markus,
> Let's try a different approach to the problem. The new patch changes representation of
a MIME field in the API by replacing name/value/raw tuple with Field interface. If you like
this patch better, I'll look into changing the representation of raw field content from String
to ByteArrayBuffer or similar immutable class. As a next step I would look into resolving

Hi Oleg,

sorry for the late response, I was a bit busy the last few days..

The Field interface patch looks good to me, feel free to commit. Your
idea of providing an immutable type that can internally be cast to
something else for performance optimization sounds good as well.

One small thing: the Javadoc of Field describes the body as "unfolded
unparsed field body string". I'm not sure if this is correct. Do you
mean the field has already been unfolded by the parser at this point?


> Oleg
>> 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, mime4j-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.

Always remember you're unique. Just like everyone else.

View raw message