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 >
