[DUG] Help - Mime64 insanity !

Robert Martin rob at chreos.co.nz
Wed Aug 10 09:07:38 NZST 2016


Hi guys

Thanks for your suggestions.

Todd, Joylon is %100 right.  The StringList was added as a debug mechanism.

The issue is that I create an XML (Utf-8 so I can deal with foreign 
languages).    When I load back in the XML I am getting errors in my 
code (which has worked fine prior to rebuilding in Xe2).  I opened the 
xml in the Edge browser (because I like the way XML is displayed) and 
noted what looked like corruption in the Mime text of the images.  
Opening the XML in Notepad++ showed corruption (overwritten characters 
and I couldn't arrow through them).  So I assumed the issue was with the 
Mime text.

After Joylon and Peter's suggestions about the BOM preamble I had 
another look and they are right.  The only difference is the preamble.  
I knew about this but had assumed it not to be an issue as my XML has 
the preamble too and only the Mime appears corrupt. However I have just 
re tested importing the XML file and if I ignore the error message 
(changed my code to keep going) the images are loading and displaying 
correctly.

I now thing that

a) The mime is correct
b) Edge browser has trouble displaying long string text on a single line
c) There is some sort of bug in Notepad++ that causes problems on Utf-8 
BOM encoded text files with long single line files
d) the problem is with another (none Mime field in my file)

Thanks for all your help, I spent ages on this but was getting tripped 
up by false assumptions.

Cheers
Rob




On 10/08/2016 8:37 AM, Jolyon Direnko-Smith wrote:
> @Todd - looking at the code I suspect that the stringlist is in there 
> as a temporary facility to dump the encoded data to a file for 
> inspection/diagnostics (the function returns the encoded string as 
> it's result as well as writing it out to a file using a string list 
> for convenience).
>
> I think in this case, the BOM behaviour of a string list has caused a 
> bit of Heisenbergnostics - the thing observing the thing has changed 
> the thing.  :)
>
> Using a file/string stream to output the resulting string might have 
> avoided introducing the BOM complication, but if this is a temporary 
> diagnostic facility, and if it is the BOM which is the problem, then 
> just turning off the BOM facility on the string list does the job just 
> as nicely.
>
> :)
>
> On 9 August 2016 at 18:35, Todd Martin <todd.martin.nz at gmail.com 
> <mailto:todd.martin.nz at gmail.com>> wrote:
>
>     Why are you using a TStringlist at all?
>
>     If you're encoding to Base64, encoding to UTF8 is meaningless.
>
>     Todd
>
>
>     On 9 Aug 2016 5:54 p.m., "Peter Ingham"
>     <ping_delphilist at 3days.co.nz <mailto:ping_delphilist at 3days.co.nz>>
>     wrote:
>
>         If you look at the output file in a hex editor, what do you see?
>
>         If the first 3 bytes are |0xEF,0xBB,0xBF, then that is a "Byte
>         Order Mark".|
>
>         |UTF-8 is a method for encoding UNICODE characters using 8-Bit
>         Bytes.|
>
>         |A file containing 7-Bit ASCII (high-order bit of every
>         character zero), when converted to UTF-8 is likely to look|||
>         very similar.  For anything else, all bets are off.   Treating
>         them as universally equivalent is asking for trouble.
>
>         Many text editors will look for Byte Order marks (of varying
>         types) and use them without displaying them (e.g: see
>         https://en.wikipedia.org/wiki/Byte_order_mark#UTF-8
>         <https://en.wikipedia.org/wiki/Byte_order_mark#UTF-8>).
>
>
>         Regards
>
>         On 9/08/2016 5:01 p.m., Robert Martin wrote:
>>         Hi guys
>>
>>
>>         I have been struggling to get some basic Mime encoding working, I have
>>         the following code which I use to Mime64 Encode a picture contained in a
>>         TImage component....
>>
>>                       Base64 := TMime64.create;
>>                       try
>>                               MemoryStream := TMemoryStream.Create;
>>                               MemoryStream.Position := 0;
>>         Image.Picture.Graphic.SaveToStream(MemoryStream);
>>
>>                               ReportImage.ImageMime   :=
>>         Base64.Encode_New(MemoryStream);
>>                       .....
>>
>>         Function shown below...
>>
>>
>>
>>         function TMime64.Encode_New(aSourceStream: TMemoryStream): String;
>>         var
>>               IdEncoderMIME       : TIdEncoderMIME;
>>               Sl                  : TStringList;
>>         begin
>>               Result := '';
>>               try
>>
>>                   IdEncoderMIME := TIdEncoderMIME.Create(nil);
>>                   sl := TStringList.Create;
>>                   try
>>                       aSourceStream.Position := 0;
>>                       Result := IdEncoderMIME.EncodeStream(aSourceStream);
>>
>>                       sl.Text := Result;
>>                       sl.SaveToFile('d:\d\a.txt', TEncoding.UTF8);
>>                   finally
>>                       IdEncoderMIME.Free;
>>                       sl.Free;
>>                   end;
>>               except
>>                   on E : Exception do begin
>>                       raise EMimeError.Create(E.Message);
>>                   end;
>>               end;
>>         end;
>>
>>         The issue is that when I try to save the results in a UTF8 formatted
>>         file (the destination is to be a UTF-8 formatted XML file), there are
>>         'bad' characters in the file which are invisible in Notepad++ but are
>>         present.
>>
>>         If I save without specifying the file encoding (
>>         sl.SaveToFile('d:\d\a.txt') instead of sl.SaveToFile('d:\d\a.txt',
>>         TEncoding.UTF8)   ) I have what appears to be a clean ASCII file. My
>>         understanding is that ASCII characters have the same byte value (0-127)
>>         in an ASCII formatted file or a UTF-8 formatted file so I don't
>>         understand why the values would change.
>>
>>         Any suggestions.
>>
>>
>>         p.s. I have to be able to save the file as UTF-8 because that is what
>>         the destination XML is encoded in.  Currently it is 'corrupt' because of
>>         the 'bad' characters.
>>
>>         p.p.s TIdEncoderMIME.EncodeStream returns a String.  I am using Delphi Xe2.
>>
>>         p.p.p.s I know it is something stupid I am doing !
>>
>>
>>
>>
>>         Thanks
>>         Rob
>>
>>
>>         _______________________________________________
>>         NZ Borland Developers Group - Delphi mailing list
>>         Post:delphi at listserver.123.net.nz
>>         <mailto:delphi at listserver.123.net.nz>
>>         Admin:http://delphi.org.nz/mailman/listinfo/delphi
>>         <http://delphi.org.nz/mailman/listinfo/delphi>
>>         Unsubscribe: send an email todelphi-request at listserver.123.net.nz
>>         <mailto:delphi-request at listserver.123.net.nz>  with Subject: unsubscribe
>>
>         _______________________________________________ NZ Borland
>         Developers Group - Delphi mailing list Post:
>         delphi at listserver.123.net.nz
>         <mailto:delphi at listserver.123.net.nz> Admin:
>         http://delphi.org.nz/mailman/listinfo/delphi
>         <http://delphi.org.nz/mailman/listinfo/delphi> Unsubscribe:
>         send an email to delphi-request at listserver.123.net.nz
>         <mailto:delphi-request at listserver.123.net.nz> with Subject:
>         unsubscribe 
>
>     _______________________________________________ NZ Borland
>     Developers Group - Delphi mailing list Post:
>     delphi at listserver.123.net.nz <mailto:delphi at listserver.123.net.nz>
>     Admin: http://delphi.org.nz/mailman/listinfo/delphi
>     <http://delphi.org.nz/mailman/listinfo/delphi> Unsubscribe: send
>     an email to delphi-request at listserver.123.net.nz
>     <mailto:delphi-request at listserver.123.net.nz> with Subject:
>     unsubscribe 
>
> _______________________________________________
> NZ Borland Developers Group - Delphi mailing list
> Post: delphi at listserver.123.net.nz
> Admin: http://delphi.org.nz/mailman/listinfo/delphi
> Unsubscribe: send an email to delphi-request at listserver.123.net.nz with Subject: unsubscribe
>
> No virus found in this message. Checked by AVG - www.avg.com 
> <http://www.avg.com> Version: 2016.0.7690 / Virus Database: 4633/12780 
> - Release Date: 08/09/16
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://listserver.123.net.nz/pipermail/delphi/attachments/20160810/19ba22b6/attachment-0001.html 


More information about the Delphi mailing list