[
https://issues.apache.org/jira/browse/MIME4J-161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12796030#action_12796030
]
Stefano Bagnara commented on MIME4J-161:
----------------------------------------
testDecodeEndOfStream3 currently checks that decoding "012345\n" results in
"012345\n". So, most time QuotedPrintableInputStreams translated lonely LF to
CRLF but not if this is the last byte of the stream. Sounds like a bug.
QuotedPrintableTextEncode.testLetterEncoding checks that a simple byte decoding
result in the same byte excluding CR, SP, HTAB. IMO also LF should be included
here once the previous bug is fixed (if we always treat LF as CRLF then
decoding a lone LF should result in CRLF).
> QuotedPrintableInputStream may be lenient with newlines but should be
> consistent in decoded data.
> -------------------------------------------------------------------------------------------------
>
> Key: MIME4J-161
> URL: https://issues.apache.org/jira/browse/MIME4J-161
> Project: JAMES Mime4j
> Issue Type: Task
> Affects Versions: 0.6
> Reporter: Stefano Bagnara
> Assignee: Stefano Bagnara
> Priority: Minor
> Fix For: 0.8
>
>
> Currently quotedprintableinputstreams treat the CRLF or LF as a full CRLF,
> translating single LF to CRLF while decoding, but not consistently.
> In fact if a qpstream ends with "somethingLF" the decoded result ends with
> "somethingLF" while if it ends with "somethingCRLF" the decoded result is
> "something" (no CRLF). This is inconsistent and I consider this a bug. IF LF
> is considered the same as CRLF it should be the same also if it is at the end
> of a stream.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
