Hi Pavel,
As you may know from my earlier forum post, we are receving short text files as attachments that we must parse on-the-fly and act upon. The content type for the files is "text/plain" and the are encoded as Sevenbit. When I open up one of these files as received by Outlook in a Hex Editor, I am seeing "0D 0A" (basically a LF-CR or \n\r) byte sequences that are not appearing in the Message.Attachment.FileData byte stream - they are simply omitted. These line breaks are absolutely crucial, as they separate parseable sections of data from one another - if this "delimiter" is not included in the FileData byte array, our parsing operations will not know where one section of data ends and the next begins.
Are you aware of any reasons why this two-byte sequence would consistently not be read into the FileData array? Is there anything that can be done about this?
Thanks for any help!!!
-Tim
Comments: ** Comment from web user: kasAt **
As you may know from my earlier forum post, we are receving short text files as attachments that we must parse on-the-fly and act upon. The content type for the files is "text/plain" and the are encoded as Sevenbit. When I open up one of these files as received by Outlook in a Hex Editor, I am seeing "0D 0A" (basically a LF-CR or \n\r) byte sequences that are not appearing in the Message.Attachment.FileData byte stream - they are simply omitted. These line breaks are absolutely crucial, as they separate parseable sections of data from one another - if this "delimiter" is not included in the FileData byte array, our parsing operations will not know where one section of data ends and the next begins.
Are you aware of any reasons why this two-byte sequence would consistently not be read into the FileData array? Is there anything that can be done about this?
Thanks for any help!!!
-Tim
Comments: ** Comment from web user: kasAt **
Hi,
im still facing this issue (text file is attached) im using latest code for ImapX ( ImapX 2.0.0.15, i have tested dll files from v4.0 and v4.0 client folder) but still my downloaded txt file loses \r\n