[
https://issues.apache.org/jira/browse/MIME4J-60?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12615210#action_12615210
]
Stefano Bagnara commented on MIME4J-60:
---------------------------------------
What does the "int" returned by isLineDelimiter represent?
I'm not sure it will work: let's say I want a strategy recognizing all of them
(isolated CR, isolated LF, canonical CRLF).
A. isLineDelimiter(-1,'\r') returns 1
B. isLineDelimiter(<anything>,'\r') returns 1
C. isLineDelimiter(-1,'\n') returns 1
D. isLineDelimiter(<anything>,'\n') returns 1
E. isLineDelimiter('\r','\n') returns 1
If I'm parsing "first line\r\nsecond line" wouldn't this result in B and E
rules matching and so in a doubled newline?
The problem I encountered while writing the
MIME4J-60-readLine-returns-no-newline.patch is that to correctly handle all of
them you have to keep track of CR alone because they could be part of a CRLF or
they could be considered an isolated newline depending on the next char.
> Configurable strategy for line delimiters
> -----------------------------------------
>
> Key: MIME4J-60
> URL: https://issues.apache.org/jira/browse/MIME4J-60
> Project: Mime4j
> Issue Type: Wish
> Affects Versions: 0.4
> Reporter: Stefano Bagnara
> Fix For: 0.5
>
> Attachments: MIME4J-60-readLine-returns-no-newline.patch,
> newlinestrat.patch
>
>
> There is an ongoing discussion about how we should deal with non canonical
> line endings (isolated LF and/or isolated CR).
> This issue is to track discussion results and proposed patches.
--
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]
