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
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