<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Hi guys<br>
<br>
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.<br>
<br>
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.<br>
<br>
Cheers<br>
Rob<br>
<br>
On 10/08/2016 10:21 AM, Jolyon Direnko-Smith wrote:<br>
</div>
<blockquote
cite="mid:CALXexOrnZu+9vPof_-5ZacFTB5H0U4_Q5vW+DJ9Ug7cdndF4cA@mail.gmail.com"
type="cite">
<div dir="ltr">@Todd<br>
<br>
The input stream is not what needs to be saved. It is the
result of <b>encoding</b> 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.<br>
<br>
You <i>could</i> 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. :)<br>
<br>
You <i>could</i> 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 <b>wasn't</b> a BOM was
the only problem.<br>
<br>
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.<br>
<br>
Rather, as implemented, it's a "CharacterStream". A byte stream
holding a sequence of characters in some arbitrary encoding.<br>
<br>
imho it would be more intuitive for a T<i>String</i>Stream to be
a <b>stream</b> containing a <b>String </b>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<i>String</i>List is a <b>list</b> of <b>String</b>(s)
which you Encode/Decode as necessary for any I/O.<br>
<br>
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).<br>
<br>
<br>
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.<br>
<br>
:)<br>
<br>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On 10 August 2016 at 09:31, Todd Martin
<span dir="ltr"><<a moz-do-not-send="true"
href="mailto:todd.martin.nz@gmail.com" target="_blank">todd.martin.nz@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<p dir="ltr">@Jolyon<br>
The memory steam could have been simply copied to a
TFilestream for that.</p>
<span class="HOEnZb"><font color="#888888">
<p dir="ltr">Todd</p>
</font></span>
<div class="HOEnZb">
<div class="h5">
<div class="gmail_extra"><br>
<div class="gmail_quote">On 10 Aug 2016 8:38 a.m.,
"Jolyon Direnko-Smith" <<a moz-do-not-send="true"
href="mailto:jsmith@deltics.co.nz" target="_blank">jsmith@deltics.co.nz</a>>
wrote:<br type="attribution">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">@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).<br>
<br>
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. :)<br>
<br>
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.<br>
<br>
:)</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On 9 August 2016 at
18:35, Todd Martin <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:todd.martin.nz@gmail.com"
target="_blank">todd.martin.nz@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote"
style="margin:0 0 0 .8ex;border-left:1px
#ccc solid;padding-left:1ex">
<p dir="ltr">Why are you using a TStringlist
at all?</p>
<p dir="ltr">If you're encoding to Base64,
encoding to UTF8 is meaningless.</p>
<span><font color="#888888">
<p dir="ltr">Todd</p>
</font></span>
<div>
<div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On 9 Aug 2016
5:54 p.m., "Peter Ingham" <<a
moz-do-not-send="true"
href="mailto:ping_delphilist@3days.co.nz"
target="_blank">ping_delphilist@3days.co.nz</a>>
wrote:<br type="attribution">
<blockquote class="gmail_quote"
style="margin:0 0 0
.8ex;border-left:1px #ccc
solid;padding-left:1ex">
<div bgcolor="#FFFFFF"
text="#000000">
<p>If you look at the output
file in a hex editor, what do
you see?</p>
<p>If the first 3 bytes are <code>0xEF,0xBB,0xBF,
then that is a "Byte Order
Mark".</code></p>
<p><code>UTF-8 is a method for
encoding UNICODE characters
using 8-Bit Bytes.</code></p>
<p><code>A file containing 7-Bit
ASCII (high-order bit of
every character zero), when
converted to UTF-8 is likely
to look</code><code></code>
very similar. For anything
else, all bets are off.
Treating them as universally
equivalent is asking for
trouble.<br>
</p>
<p>Many text editors will look
for Byte Order marks (of
varying types) and use them
without displaying them (e.g:
see <a moz-do-not-send="true"
href="https://en.wikipedia.org/wiki/Byte_order_mark#UTF-8"
target="_blank">https://en.wikipedia.org/wiki/<wbr>Byte_order_mark#UTF-8</a>).</p>
<p><br>
</p>
<p>Regards<br>
</p>
<div>On 9/08/2016 5:01 p.m.,
Robert Martin wrote:<br>
</div>
<blockquote type="cite">
<pre>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.SaveToSt<wbr>ream(MemoryStream);
ReportImage.ImageMime :=
Base64.Encode_New(MemoryStream<wbr>);
.....
Function shown below...
function TMime64.Encode_New(aSourceStre<wbr>am: TMemoryStream): String;
var
IdEncoderMIME : TIdEncoderMIME;
Sl : TStringList;
begin
Result := '';
try
IdEncoderMIME := TIdEncoderMIME.Create(nil);
sl := TStringList.Create;
try
aSourceStream.Position := 0;
Result := IdEncoderMIME.EncodeStream(aSo<wbr>urceStream);
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
______________________________<wbr>_________________
NZ Borland Developers Group - Delphi mailing list
Post: <a moz-do-not-send="true" href="mailto:delphi@listserver.123.net.nz" target="_blank">delphi@listserver.123.net.nz</a>
Admin: <a moz-do-not-send="true" href="http://delphi.org.nz/mailman/listinfo/delphi" target="_blank">http://delphi.org.nz/mailman/l<wbr>istinfo/delphi</a>
Unsubscribe: send an email to <a moz-do-not-send="true" href="mailto:delphi-request@listserver.123.net.nz" target="_blank">delphi-request@listserver.123.<wbr>net.nz</a> with Subject: unsubscribe
</pre>
</blockquote>
</div>
______________________________<wbr>_________________
NZ Borland Developers Group - Delphi mailing list
Post: <a moz-do-not-send="true" href="mailto:delphi@listserver.123.net.nz" target="_blank">delphi@listserver.123.net.nz</a>
Admin: <a moz-do-not-send="true" href="http://delphi.org.nz/mailman/listinfo/delphi" rel="noreferrer" target="_blank">http://delphi.org.nz/mailman/l<wbr>istinfo/delphi</a>
Unsubscribe: send an email to <a moz-do-not-send="true" href="mailto:delphi-request@listserver.123.net.nz" target="_blank">delphi-request@listserver.123.<wbr>net.nz</a> with Subject: unsubscribe
</blockquote></div></div>
</div></div>
______________________________<wbr>_________________
NZ Borland Developers Group - Delphi mailing list
Post: <a moz-do-not-send="true" href="mailto:delphi@listserver.123.net.nz" target="_blank">delphi@listserver.123.net.nz</a>
Admin: <a moz-do-not-send="true" href="http://delphi.org.nz/mailman/listinfo/delphi" rel="noreferrer" target="_blank">http://delphi.org.nz/mailman/l<wbr>istinfo/delphi</a>
Unsubscribe: send an email to <a moz-do-not-send="true" href="mailto:delphi-request@listserver.123.net.nz" target="_blank">delphi-request@listserver.123.<wbr>net.nz</a> with Subject: unsubscribe
</blockquote></div>
</div>
______________________________<wbr>_________________
NZ Borland Developers Group - Delphi mailing list
Post: <a moz-do-not-send="true" href="mailto:delphi@listserver.123.net.nz" target="_blank">delphi@listserver.123.net.nz</a>
Admin: <a moz-do-not-send="true" href="http://delphi.org.nz/mailman/listinfo/delphi" rel="noreferrer" target="_blank">http://delphi.org.nz/mailman/l<wbr>istinfo/delphi</a>
Unsubscribe: send an email to <a moz-do-not-send="true" href="mailto:delphi-request@listserver.123.net.nz" target="_blank">delphi-request@listserver.123.<wbr>net.nz</a> with Subject: unsubscribe
</blockquote></div></div>
</div></div>
______________________________<wbr>_________________
NZ Borland Developers Group - Delphi mailing list
Post: <a moz-do-not-send="true" href="mailto:delphi@listserver.123.net.nz">delphi@listserver.123.net.nz</a>
Admin: <a moz-do-not-send="true" href="http://delphi.org.nz/mailman/listinfo/delphi" rel="noreferrer" target="_blank">http://delphi.org.nz/mailman/<wbr>listinfo/delphi</a>
Unsubscribe: send an email to <a moz-do-not-send="true" href="mailto:delphi-request@listserver.123.net.nz">delphi-request@listserver.123.<wbr>net.nz</a> with Subject: unsubscribe
</blockquote></div>
</div>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre wrap="">_______________________________________________
NZ Borland Developers Group - Delphi mailing list
Post: <a class="moz-txt-link-abbreviated" href="mailto:delphi@listserver.123.net.nz">delphi@listserver.123.net.nz</a>
Admin: <a class="moz-txt-link-freetext" href="http://delphi.org.nz/mailman/listinfo/delphi">http://delphi.org.nz/mailman/listinfo/delphi</a>
Unsubscribe: send an email to <a class="moz-txt-link-abbreviated" href="mailto:delphi-request@listserver.123.net.nz">delphi-request@listserver.123.net.nz</a> with Subject: unsubscribe</pre>
<fieldset class="mimeAttachmentHeader"></fieldset>
<p class="" avgcert""="" color="#000000" align="left">No virus found in this message.
Checked by AVG - <a moz-do-not-send="true" href="http://www.avg.com">www.avg.com</a>
Version: 2016.0.7690 / Virus Database: 4633/12782 - Release Date: 08/09/16</p>
</blockquote><p>
</p></body></html>