Hi Stefano, I was not aware of the RCF line breaks specification. Thanks!
I will let you know if I encounter any other issues. Thanks a lot guys. Regards, Lukas On Thu, Dec 15, 2011 at 3:32 PM, Stefano Bagnara <[email protected]> wrote: > I guess mime4j 0.6 output was not mime compliant. > MIME requires newlines in text parts to use CRLF (\r\n) as line > separators and also says that CR and LF are not allowed in a text part > other than in the line separator sequence. > > From RFC2046: > --- > 4.1.1. Representation of Line Breaks > > The canonical form of any MIME "text" subtype MUST always represent a > line break as a CRLF sequence. Similarly, any occurrence of CRLF in > MIME "text" MUST represent a line break. Use of CR and LF outside of > line break sequences is also forbidden. > --- > > Most email clients accept LF (\n) line separators, but CRLF is the right > one. > > So in 0.7 in fixed this bug. > > 0.6 vs 0.7 differences aside, are you experiencing issues with the > CRLF used by mime4j 0.7 ? > > Stefano > > 2011/12/15 Lukáš Vlček <[email protected]>: > > Hey again, > > > > I did downgraded my code to 0.6 version to see what differences I will > get. > > > > Unfortunatelly, I was not able to prove that the below > > mentioned message.getHeader().getField("from").getBody() did decoding > > however, I was able to show that I am getting different content from > > TextBody. > > > > There are two branches in my github repo now: > > - workaboud (using mime4j 0.7.2) > > - backto06 (using mime4j 0.6) > > > > I would like to point out the following parts of my test: > > > https://github.com/lukas-vlcek/mime4j-test/blob/workaround/src/test/java/org/mime4j/test/BasicTest.java#L112 > > vs. > > > https://github.com/lukas-vlcek/mime4j-test/blob/backto06/src/test/java/org/mime4j/test/BasicTest.java#L110 > > > > The first is using 0.7.2 and I am getting "\r\n" sequence where using > 0.6 I > > am getting only "\n". > > > > I am not saying there is a bug in Mime4J but I would like to understand > > what has changed and why I am getting different results using different > > mime4j version. As you can see I did not change anything important in any > > of util classes between "workaround" and "backto06" branches: > > https://github.com/lukas-vlcek/mime4j-test/compare/workaround...backto06 > > > > The only important change (except different version of mime4j) is in > > ParseUtil class where I had to drop MessageBuilder logic: > > > https://github.com/lukas-vlcek/mime4j-test/compare/workaround...backto06#diff-2 > > > > Any idea why I am getting "\r\n" chars instead of "\n"? > > > > Regards, > > Lukas > > > > On Thu, Dec 15, 2011 at 1:19 PM, Lukáš Vlček <[email protected]> > wrote: > > > >> OK, got it. > >> (Although in 0.6 it was returning decoded content) > >> > >> Regards, > >> Lukas > >> > >> > >> On Thu, Dec 15, 2011 at 1:16 PM, Oleg Kalnichevski <[email protected] > >wrote: > >> > >>> On Thu, 2011-12-15 at 11:41 +0100, Lukáš Vlček wrote: > >>> > Hi, > >>> > > >>> > I tried it and it works. Thanks! > >>> > > >>> > However, still I am not sure if this fixed everything. > >>> > See the following commit in my test repo on github (I added a new > branch > >>> > called "workaround") > >>> > > >>> > https://github.com/lukas-vlcek/mime4j-test/commit/385c66847bec4393ad67069fb367c174f87c5656 > >>> > > >>> > As you can see the call to message.getFrom().get(0).getName() > returns > >>> > expected data, but message.getHeader().getField("from").getBody() > does > >>> not. > >>> > At least that is how I understand its JavaDoc: > >>> > > >>> > http://james.apache.org/mime4j/apidocs/org/apache/james/mime4j/stream/Field.html#getBody() > >>> > > >>> > "Gets the unparsed and possibly encoded (see RFC 2047) field body > >>> string." > >>> > > >>> > How should I understand the "encoded" in this context? > >>> > > >>> > >>> Encoded actually means, well, encoded, as specified in RFC 2047. > >>> > >>> Oleg > >>> > >>> > >>> > >> >
