[
https://issues.apache.org/jira/browse/MIME4J-34?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12567423#action_12567423
]
Robert Burrell Donkin commented on MIME4J-34:
---------------------------------------------
I'm going to apply this patch.
Note that I suspect that accurate round-tripping is currently broken. I think
that MimeTokenStream uses:
int curr = 0;
int prev = 0;
while ((curr = cursor.advance()) != -1) {
if (curr == '\n' && (prev == '\n' || prev == 0)) {
/*
* [\r]\n[\r]\n or an immediate \r\n have been seen.
*/
sb.deleteCharAt(sb.length() - 1);
break;
}
sb.append((char) curr);
prev = curr == '\r' ? prev : curr;
}
which does a naive (and inefficient) cast conversion. So, to round trip I think
that the output would need to perform the reverse operation, scanning each
character in the string and casting it to a byte before pushing it into the
buffer. This option is not available ATM.
Robert
> o.a.j.m.message.Header#writeTo violates RFC 822
> -----------------------------------------------
>
> Key: MIME4J-34
> URL: https://issues.apache.org/jira/browse/MIME4J-34
> Project: Mime4j
> Issue Type: Bug
> Affects Versions: 0.3
> Reporter: Oleg Kalnichevski
> Assignee: Robert Burrell Donkin
> Attachments: mimeheader.patch
>
>
> The Header#writeTo method uses the content charset instead of US-ASCII
> required by the RFC 822. Same problem exists in the Multipart#writeTo.
--
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]
