You are viewing a plain text version of this content. The canonical link for it is here.
Posted to mime4j-dev@james.apache.org by Florent Georges <li...@fgeorges.org> on 2009/12/24 16:51:21 UTC

Shouldn't Reader convert \r\n to \n?

  Hi,

  I am using a MimeTokenStream to parse a multipart message.  For
bodies with textual content (for instance text/plain), I get a
Reader object from MimeTokenStream.getReader().  Unfortunately,
it seems to not convert \r\n (correct end of line in messages on
the wire) to \n (correct end of line in Java strings).

  Is this a bug or did I miss something?

  Regards,

-- 
Florent Georges
http://www.fgeorges.org/





















      


Re: Shouldn't Reader convert \r\n to \n?

Posted by Florent Georges <li...@fgeorges.org>.
Stefano Bagnara wrote:

  Hi,

> >  I am using a MimeTokenStream to parse a multipart message.
> > For bodies with textual content (for instance text/plain), I
> > get a Reader object from MimeTokenStream.getReader().
> > Unfortunately, it seems to not convert \r\n (correct end of
> > line in messages on the wire) to \n (correct end of line in
> > Java strings).

> Why do you think \n is the correct end of line in Java
> strings ?  This is platform dependant and there is no such
> thing as the "correct end of line in java strings".

  Mmh...  It seems you are right.  I've always thought that one
of the differences between byte and character streams was the
en-/de-coding of the platform dependent end of line to the
canonical form '\n'.  It seems I was wrong, and ends of line
seems to be never decoded by a Reader (except by BufferedReader
but that's not really the same thing).

  I guess this is a legacy of my C and C++ experiences :-/

> Hope you got it,

  Yup.  I've even learned something today :-)  Thanks for the
explanation, and sorry for the noise, regards,

-- 
Florent Georges
http://www.fgeorges.org/





















      


Re: Shouldn't Reader convert \r\n to \n?

Posted by Stefano Bagnara <ap...@bago.org>.
2009/12/24 Florent Georges <li...@fgeorges.org>:
>  Hi,
>
>  I am using a MimeTokenStream to parse a multipart message.  For
> bodies with textual content (for instance text/plain), I get a
> Reader object from MimeTokenStream.getReader().  Unfortunately,
> it seems to not convert \r\n (correct end of line in messages on
> the wire) to \n (correct end of line in Java strings).

Why do you think \n is the correct end of line in Java strings ? This
is platform dependant and there is no such thing as the "correct end
of line in java strings". System.getProperty( "line.separator" ) is a
method to know your system line separator.

BTW the mime4j behaviour is not related to what the line separator for
your system is.

"\r\n" (CRLF) is the correct (canonical, in rfc terms) end of line in
mime specification. So, whenever mime4j creates a mime stream from
scratch it will try to use CRLF. However, in order to be permissive
with most mime streams out there mime4j will also treat a single "\n"
(LF) as a line termination when reading a message and, for performance
purposes, it won't translate this "\n" (LF) to "\r\n" (CRLF).

>  Is this a bug or did I miss something?

Hope you got it,

Stefano