[DUG] Help - Mime64 insanity !
Jolyon Direnko-Smith
jsmith at deltics.co.nz
Wed Aug 10 10:21:04 NZST 2016
@Todd
The input stream is not what needs to be saved. It is the result of
*encoding* the stream that needs to be saved, which in the code is
available as a string (since that is the final result required by the
function). Unless you are going to use file handling primitives (Assign /
ResetFile etc) you need something to provide the file handling to get that
string onto disc in UTF8 form.
You *could* use a file stream for that but you would need to separately
convert the string to a UTF8 buffer before Write()ing it to that stream,
introducing multiple opportunities to aim the trigger at your own leg
appendage. :)
You *could* use a string stream. Interestingly though, as far as I can
tell in this case you don't get a BOM in the output file and can't get one
unless you explicitly write it there first yourself (adding much more
complexity), so if you actually need/want a BOM this isn't easily adaptable
to provide that. As I understand it, the BOM wasn't actually the problem
in Robert's case, rather the assumption that there *wasn't* a BOM was the
only problem.
An encoded string stream is also a bit of a mess to get your head around.
The encoding specified in the constructor determines the encoding of the
bytes backing the storage of the "string". i.e. it isn't really a
"StringStream" at all since this (to me) means a stream(able) "string",
i.e. (in 2009+) UTF16. Before Delphi 2009 this is what it would have been,
except in that case an ANSI string.
Rather, as implemented, it's a "CharacterStream". A byte stream holding a
sequence of characters in some arbitrary encoding.
imho it would be more intuitive for a T*String*Stream to be a *stream*
containing a *String *and instead of an Encoding property (unnecessary
since it would always be UTF16 internally) have an Encoding parameter on
the I/O methods etc. Just as a T*String*List is a *list* of *String*(s)
which you Encode/Decode as necessary for any I/O.
Even if you did use a string stream it wouldn't be any/much simpler than
the string list version (and if that lack of BOM in any output file does
actually cause a problem then it's a non-starter anyway).
Which leaves... a stringlist as the simplest and most flexible option. You
might choose one of the more complex options for a more robust
implementation, but imho that would be overkill for a quick diagnostic
facility.
:)
On 10 August 2016 at 09:31, Todd Martin <todd.martin.nz at gmail.com> wrote:
> @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" <jsmith at deltics.co.nz>
> 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> 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>
>>> 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: 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
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>>>
>>>
>>> _______________________________________________
>>> 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
>>>
>>
>>
>> _______________________________________________
>> 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
>>
>
> _______________________________________________
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://listserver.123.net.nz/pipermail/delphi/attachments/20160810/7e9cb649/attachment-0001.html
More information about the Delphi
mailing list