[DUG] Help - Mime64 insanity !
Robert Martin
rob at chreos.co.nz
Wed Aug 10 10:34:15 NZST 2016
Hi guys
For what it's worth I did also test it using TFileStream. I have now
found and fixed the bug in the import code (not dealing with a NULL
value in the XML file correctly) and it is working like a charm.
I also agree with Joylon with regards to TStringStream, it should work
like 'String' i.e. always UTF-16 all the time and coverted (if reqd)
when reading or writing.
Cheers
Rob
On 10/08/2016 10:21 AM, Jolyon Direnko-Smith wrote:
> @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
> <mailto: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 <mailto: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 <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
> <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/12782
> - Release Date: 08/09/16
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://listserver.123.net.nz/pipermail/delphi/attachments/20160810/99eee9a9/attachment-0001.html
More information about the Delphi
mailing list