Yes. The legacy system handles encoding. That is provided as another parameter.
It is an existing, working integration. I am just porting the old system in my end. And I'd rather use mime4j than porting the kitchen sink mail parser đ€ą It looks like getting the byte offset for the attachment body is the only missing feature. fre. d. 2. okt. 2020 03.54 skrev Tellier Benoit <[email protected]>: > Hi, > > First, be aware that by just getting the offset, the attachment will > still be encoded. Is it something your legacy system can tolerate? > > > Le 01/10/2020 Ă 20:42, Lasse LindgĂ„rd a Ă©crit : > > Hi mime4j experts, > > > > I got a requirement to deliver emails to a legacy system that needs to > read > > the attachments. > > > > For each part in a multipart email I need to provide the byte offset for > > where the attachment starts in the email, so the legacy system doesn't > need > > to know how to parse emails. > > > > Performance and memory usage is an issue, so the solution can't load the > > entire email into memory, so I use the MimeTokenStream > > > > My intuition tells me that if mime4j can return an InputStream for the > > current attachment body. Getting the byte offset should be easy. But byte > > offsets are not tracked. The library seems to be aware of line numbers > > internally, but they are not exposed and I suspect they are "off" because > > the streams are buffered. > I miss knowledge to answer here. > > > > Now I am thinking that maybe I am going about this the wrong way. So I > > would very much appreciate any ideas of how to solve this in a simple > > matter. > > > > NB: I also posted a more open version of this question on SO: > > > https://stackoverflow.com/questions/64155766/find-byte-offsets-for-e-mail-attachments > > >
