@Jolyon The memory steam could have been simply copied to a TFilestream for that.
Todd On 10 Aug 2016 8:38 a.m., "Jolyon Direnko-Smith" <[email protected]> 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 <[email protected]> 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" <[email protected]> >> 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). >>> >>> >>> 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: [email protected] >>> Admin: http://delphi.org.nz/mailman/listinfo/delphi >>> Unsubscribe: send an email to [email protected] with >>> Subject: unsubscribe >>> >>> >>> >>> >>> _______________________________________________ >>> NZ Borland Developers Group - Delphi mailing list >>> Post: [email protected] >>> Admin: http://delphi.org.nz/mailman/listinfo/delphi >>> Unsubscribe: send an email to [email protected] with >>> Subject: unsubscribe >>> >> >> _______________________________________________ >> NZ Borland Developers Group - Delphi mailing list >> Post: [email protected] >> Admin: http://delphi.org.nz/mailman/listinfo/delphi >> Unsubscribe: send an email to [email protected] with >> Subject: unsubscribe >> > > > _______________________________________________ > NZ Borland Developers Group - Delphi mailing list > Post: [email protected] > Admin: http://delphi.org.nz/mailman/listinfo/delphi > Unsubscribe: send an email to [email protected] with > Subject: unsubscribe >
_______________________________________________ NZ Borland Developers Group - Delphi mailing list Post: [email protected] Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to [email protected] with Subject: unsubscribe
