"Umlaute" Problems with UTF-8

[lavendelbonbon]

I am using blat with success for many years now (Thx for the Software)

Today I tried to resolve an problem I have with german "Umlaute" in textfiles, but I wasn't successful.
I am not sure if I am doing something completely wrong.
I am using Thunderbird 15 as my mail client.

I have UTF-8 encoded textfiles I want to use as Mailbodies.
When I send them with no special options the default charset 8859-1 is used
and the Umlaut " ö " and the " ß "in Größe is not shown correctly (as expected).

When I now switch to UTF-8 in the view menu of thunderbird everything is shown correctly.

So for the next step I used the option -charset UTF-8 when sending the textfile
expecting that then everything would be shown correctly.

But the "Größe" now is still not shown correctly in spite of the UTF-8 entry in the header.

Therefore I compared the mail source code of the two mails using the sourcecode viewing option in thunderbird
and surprisingly the word "Größe" shows up different.

in the original File as:

Gr=C3=B6=C3=9Fe

In the file send with the -charset UTF-8 option as:

Größe


As a further step I saved the original mail
after recieving it in thunderbird as a eml file
and just edited the Charset header entry
from ISO 8859-1 to UTF-8
without changing anything else.

And voila the mailbody is now shown correctly in thunderbird
when opening the file.

My conclusion is that the -charset switch
is not only changing the header entry (as I expected)
But is doing something else too which it obviously shouldn't.

But as I have no experience with that kind of problems
I might have gotten something completely wrong ?

[Christoph Leser]

Post by lavendelbonbon
When I now switch to UTF-8 in the view menu of thunderbird everything is shown correctly.

This shows, I think, that the mail body is correctly coded in utf-8, but the header does not indicate this, so thunderbird is not aware of this.

I believe that this has been a problem with older versions. I'm on version 3.05 where these problems have been fixed.

Regards

Von: ***@yahoogroups.com [mailto:***@yahoogroups.com] Im Auftrag von lavendelbonbon
Gesendet: Donnerstag, 13. September 2012 17:30
An: ***@yahoogroups.com
Betreff: [blat] "Umlaute" Problems with UTF-8



I am using blat with success for many years now (Thx for the Software)

Today I tried to resolve an problem I have with german "Umlaute" in textfiles, but I wasn't successful.
I am not sure if I am doing something completely wrong.
I am using Thunderbird 15 as my mail client.

I have UTF-8 encoded textfiles I want to use as Mailbodies.
When I send them with no special options the default charset 8859-1 is used
and the Umlaut " ö " and the " ß "in Größe is not shown correctly (as expected).

When I now switch to UTF-8 in the view menu of thunderbird everything is shown correctly.

So for the next step I used the option -charset UTF-8 when sending the textfile
expecting that then everything would be shown correctly.

But the "Größe" now is still not shown correctly in spite of the UTF-8 entry in the header.

Therefore I compared the mail source code of the two mails using the sourcecode viewing option in thunderbird
and surprisingly the word "Größe" shows up different.

in the original File as:

Gr=C3=B6=C3=9Fe

In the file send with the -charset UTF-8 option as:

Größe

As a further step I saved the original mail
after recieving it in thunderbird as a eml file
and just edited the Charset header entry
from ISO 8859-1 to UTF-8
without changing anything else.

And voila the mailbody is now shown correctly in thunderbird
when opening the file.

My conclusion is that the -charset switch
is not only changing the header entry (as I expected)
But is doing something else too which it obviously shouldn't.

But as I have no experience with that kind of problems
I might have gotten something completely wrong ?



[Non-text portions of this message have been removed]

[Moore, Bruce]

Von

What version of BLAT are you running? If it's an older version, you might try installing and testing with a more current version

Bruce


Von: ***@yahoogroups.com<mailto:blat%40yahoogroups.com> [mailto:***@yahoogroups.com<mailto:blat%40yahoogroups.com>] Im Auftrag von lavendelbonbon
Gesendet: Donnerstag, 13. September 2012 17:30
An: ***@yahoogroups.com<mailto:blat%40yahoogroups.com>
Betreff: [blat] "Umlaute" Problems with UTF-8

I am using blat with success for many years now (Thx for the Software)

Today I tried to resolve an problem I have with german "Umlaute" in textfiles, but I wasn't successful.
I am not sure if I am doing something completely wrong.
I am using Thunderbird 15 as my mail client.

I have UTF-8 encoded textfiles I want to use as Mailbodies.
When I send them with no special options the default charset 8859-1 is used
and the Umlaut " ö " and the " ß "in Größe is not shown correctly (as expected).

When I now switch to UTF-8 in the view menu of thunderbird everything is shown correctly.

So for the next step I used the option -charset UTF-8 when sending the textfile
expecting that then everything would be shown correctly.

But the "Größe" now is still not shown correctly in spite of the UTF-8 entry in the header.

Therefore I compared the mail source code of the two mails using the sourcecode viewing option in thunderbird
and surprisingly the word "Größe" shows up different.

in the original File as:

Gr=C3=B6=C3=9Fe

In the file send with the -charset UTF-8 option as:

GröÃ&#159;e

As a further step I saved the original mail
after recieving it in thunderbird as a eml file
and just edited the Charset header entry
from ISO 8859-1 to UTF-8
without changing anything else.

And voila the mailbody is now shown correctly in thunderbird
when opening the file.

My conclusion is that the -charset switch
is not only changing the header entry (as I expected)
But is doing something else too which it obviously shouldn't.

But as I have no experience with that kind of problems
I might have gotten something completely wrong ?

[Non-text portions of this message have been removed]




[Non-text portions of this message have been removed]

[lavendelbonbon]

hi Bruce,
I actually upgraded tested blat 3.07 before posting
Lavendel

Post by Moore, Bruce
Von
What version of BLAT are you running? If it's an older version, you might try installing and testing with a more current version
Bruce
Gesendet: Donnerstag, 13. September 2012 17:30
Betreff: [blat] "Umlaute" Problems with UTF-8
I am using blat with success for many years now (Thx for the Software)
Today I tried to resolve an problem I have with german "Umlaute" in textfiles, but I wasn't successful.
I am not sure if I am doing something completely wrong.
I am using Thunderbird 15 as my mail client.
I have UTF-8 encoded textfiles I want to use as Mailbodies.
When I send them with no special options the default charset 8859-1 is used
and the Umlaut " ö " and the " ß "in Größe is not shown correctly (as expected).
When I now switch to UTF-8 in the view menu of thunderbird everything is shown correctly.
So for the next step I used the option -charset UTF-8 when sending the textfile
expecting that then everything would be shown correctly.
But the "Größe" now is still not shown correctly in spite of the UTF-8 entry in the header.
Therefore I compared the mail source code of the two mails using the sourcecode viewing option in thunderbird
and surprisingly the word "Größe" shows up different.
Gr=C3=B6=C3=9Fe
GröÃ&#159;e
As a further step I saved the original mail
after recieving it in thunderbird as a eml file
and just edited the Charset header entry
from ISO 8859-1 to UTF-8
without changing anything else.
And voila the mailbody is now shown correctly in thunderbird
when opening the file.
My conclusion is that the -charset switch
is not only changing the header entry (as I expected)
But is doing something else too which it obviously shouldn't.
But as I have no experience with that kind of problems
I might have gotten something completely wrong ?
[Non-text portions of this message have been removed]
[Non-text portions of this message have been removed]

[Moore, Bruce]

I see Chris has already addressed this - Guess I'm just too slow....among other things

________________________________
From: ***@yahoogroups.com [mailto:***@yahoogroups.com] On Behalf Of Christoph Leser
Sent: Thursday, September 13, 2012 1:49 PM
To: ***@yahoogroups.com
Subject: AW: [blat] "Umlaute" Problems with UTF-8

Post by lavendelbonbon
When I now switch to UTF-8 in the view menu of thunderbird everything is shown correctly.

This shows, I think, that the mail body is correctly coded in utf-8, but the header does not indicate this, so thunderbird is not aware of this.

I believe that this has been a problem with older versions. I'm on version 3.05 where these problems have been fixed.

Regards

Von: ***@yahoogroups.com<mailto:blat%40yahoogroups.com> [mailto:***@yahoogroups.com<mailto:blat%40yahoogroups.com>] Im Auftrag von lavendelbonbon
Gesendet: Donnerstag, 13. September 2012 17:30
An: ***@yahoogroups.com<mailto:blat%40yahoogroups.com>
Betreff: [blat] "Umlaute" Problems with UTF-8

I am using blat with success for many years now (Thx for the Software)

Today I tried to resolve an problem I have with german "Umlaute" in textfiles, but I wasn't successful.
I am not sure if I am doing something completely wrong.
I am using Thunderbird 15 as my mail client.

I have UTF-8 encoded textfiles I want to use as Mailbodies.
When I send them with no special options the default charset 8859-1 is used
and the Umlaut " ö " and the " ß "in Größe is not shown correctly (as expected).

When I now switch to UTF-8 in the view menu of thunderbird everything is shown correctly.

So for the next step I used the option -charset UTF-8 when sending the textfile
expecting that then everything would be shown correctly.

But the "Größe" now is still not shown correctly in spite of the UTF-8 entry in the header.

Therefore I compared the mail source code of the two mails using the sourcecode viewing option in thunderbird
and surprisingly the word "Größe" shows up different.

in the original File as:

Gr=C3=B6=C3=9Fe

In the file send with the -charset UTF-8 option as:

GröÃ&#159;e

As a further step I saved the original mail
after recieving it in thunderbird as a eml file
and just edited the Charset header entry
from ISO 8859-1 to UTF-8
without changing anything else.

And voila the mailbody is now shown correctly in thunderbird
when opening the file.

My conclusion is that the -charset switch
is not only changing the header entry (as I expected)
But is doing something else too which it obviously shouldn't.

But as I have no experience with that kind of problems
I might have gotten something completely wrong ?

[Non-text portions of this message have been removed]





[Non-text portions of this message have been removed]

[lavendelbonbon]

Yes obviously it is coded correctly
but it is no longer the case when i set the "-charset UTF-8"
switch (btw I upgraded to blat 3.07 before I posted in the forum)

Post by Christoph Leser

Post by lavendelbonbon
When I now switch to UTF-8 in the view menu of thunderbird everything is shown correctly.

This shows, I think, that the mail body is correctly coded in utf-8, but the header does not indicate this, so thunderbird is not aware of this.
I believe that this has been a problem with older versions. I'm on version 3.05 where these problems have been fixed.
Regards
Gesendet: Donnerstag, 13. September 2012 17:30
Betreff: [blat] "Umlaute" Problems with UTF-8
I am using blat with success for many years now (Thx for the Software)
Today I tried to resolve an problem I have with german "Umlaute" in textfiles, but I wasn't successful.
I am not sure if I am doing something completely wrong.
I am using Thunderbird 15 as my mail client.
I have UTF-8 encoded textfiles I want to use as Mailbodies.
When I send them with no special options the default charset 8859-1 is used
and the Umlaut " ö " and the " ß "in Größe is not shown correctly (as expected).
When I now switch to UTF-8 in the view menu of thunderbird everything is shown correctly.
So for the next step I used the option -charset UTF-8 when sending the textfile
expecting that then everything would be shown correctly.
But the "Größe" now is still not shown correctly in spite of the UTF-8 entry in the header.
Therefore I compared the mail source code of the two mails using the sourcecode viewing option in thunderbird
and surprisingly the word "Größe" shows up different.
Gr=C3=B6=C3=9Fe
GröÃ&#159;e
As a further step I saved the original mail
after recieving it in thunderbird as a eml file
and just edited the Charset header entry
from ISO 8859-1 to UTF-8
without changing anything else.
And voila the mailbody is now shown correctly in thunderbird
when opening the file.
My conclusion is that the -charset switch
is not only changing the header entry (as I expected)
But is doing something else too which it obviously shouldn't.
But as I have no experience with that kind of problems
I might have gotten something completely wrong ?
[Non-text portions of this message have been removed]

[ykai]

/snip/

like others before me I suspect a problem with the version of blat
you are using.
I do this, because I use a similar setup to yours for some info
mails with the current version 3.0.7:
My body files are UTF-8 and when I use "-charset utf-8" the following
appears in the header of the mail:
Content-Type: text/plain;
charset="UTF-8"
So the client software will know about the encoding and everything is fine.

Well, actually I don't do that typically, because I send that mails
via a batch file, which get the subject (-s) and recipient file (-bf)
from the command line as parameters.
Now you are not able to enter UTF-8 on the command line (well, you can
after "chcp 650001", but in that mode the cmd will not start
any batch file :-/ [this is a known fact, but I would like to see that
documented by MS somewhere. So, if anyone has a link... much appreciated!]).
So instead I use "-charset iso-8859-1" for blat, change my console codepage
to iso-8859-1 also ("chcp 28591") and send my mails via my batch file,
including subject entered on the command line with umlauts
(... -s "Trainigstermine im MÀrz" ...).
Blat will happily convert my UTF-8 body text from the file to iso-8859-1
for the mail!

[Christoph Leser]

Ykai wrote:


Ø Blat will happily convert my UTF-8 body text from the file to iso-8859-1
for the mail!

How does blat know that your body text is UTF-8? When the charset parameter sets the charset in which the data is sent, I would like to have an additional parameter to specify the charset of the text file? The charset of the subject etc, entered on the command line is of course that which has been set with chcp.


Von: ***@yahoogroups.com [mailto:***@yahoogroups.com] Im Auftrag von ykai
Gesendet: Donnerstag, 13. September 2012 22:57
An: ***@yahoogroups.com
Cc: ***@yahoogroups.com; ***@yahoogroups.com
Betreff: Re: [blat] "Umlaute" Problems with UTF-8

/snip/

like others before me I suspect a problem with the version of blat
you are using.
I do this, because I use a similar setup to yours for some info
mails with the current version 3.0.7:
My body files are UTF-8 and when I use "-charset utf-8" the following
appears in the header of the mail:
Content-Type: text/plain;
charset="UTF-8"
So the client software will know about the encoding and everything is fine.

Well, actually I don't do that typically, because I send that mails
via a batch file, which get the subject (-s) and recipient file (-bf)
from the command line as parameters.
Now you are not able to enter UTF-8 on the command line (well, you can
after "chcp 650001", but in that mode the cmd will not start
any batch file :-/ [this is a known fact, but I would like to see that
documented by MS somewhere. So, if anyone has a link... much appreciated!]).
So instead I use "-charset iso-8859-1" for blat, change my console codepage
to iso-8859-1 also ("chcp 28591") and send my mails via my batch file,
including subject entered on the command line with umlauts
(... -s "Trainigstermine im MÀrz" ...).
Blat will happily convert my UTF-8 body text from the file to iso-8859-1
for the mail!

[lavendelbonbon]

Hi Kai,
I actually upgraded to and tested it with blat 3.07 before posting.
As you write correctly the header shows -charset UTF-8 when using
the switch but the mailbody has changes too and is no mismatched.
PS: actually the header shows
Content Transfer encoding: quoted/printable
when setting the UTF-8 switch
(but that should't cause any problems AFAIK)

(Im want to use blat that way,
because another program files its reports as UTF-8)

Lavendel

Post by ykai

/snip/

like others before me I suspect a problem with the version of blat
you are using.
I do this, because I use a similar setup to yours for some info
My body files are UTF-8 and when I use "-charset utf-8" the following
Content-Type: text/plain;
charset="UTF-8"
So the client software will know about the encoding and everything is fine.
Well, actually I don't do that typically, because I send that mails
via a batch file, which get the subject (-s) and recipient file (-bf)
from the command line as parameters.
Now you are not able to enter UTF-8 on the command line (well, you can
after "chcp 650001", but in that mode the cmd will not start
any batch file :-/ [this is a known fact, but I would like to see that
documented by MS somewhere. So, if anyone has a link... much appreciated!]).
So instead I use "-charset iso-8859-1" for blat, change my console codepage
to iso-8859-1 also ("chcp 28591") and send my mails via my batch file,
including subject entered on the command line with umlauts
(... -s "Trainigstermine im MÀrz" ...).
Blat will happily convert my UTF-8 body text from the file to iso-8859-1
for the mail!
--
Kai

[ykai]

Post by Christoph Leser
How does blat know that your body text is UTF-8?

[+] Add more intelligence for checking UTF-8 byte sequences when the UTF-8 Byte
Order Marker (BOM) is not present. This helps reduce the likelihood of
incorrectly marking the charset as "UTF-8" or not.

Well, I my case it's even simpler, because my text file have a UTF8-BOM
at the start.

Historically, it had been observed earlier (~2004) that people were
sending UTF-8 files as body without being aware that these are not
normal text files for blat (for some definition of "normal").

I suggest checking for BOMs in 2004 on this list (message #5482),
that blat should be aware of a BOM and act accordingly.
Later Chip got onto this (see "opinion poll", message #6582 and replies to it).

[lavendelbonbon]

PROBLEM Solved or at least Workarounded

Hi all thx for all your advice.

I must admit that I might have not be clear enough
describing problem.
And it actually still exists in the software or at
least in its decription.

Therefore I will try being clearer and post my workaround:

First: I am using blat 3.07

And the situation is:

I am sending a textfile as a mailbody.
This textfile is a an output of another program
so I don't really know how it is coded.

But when I am sendig it with no further options
the Umlaute are mismatched, when viewing the mail in
Thunderbird 15.

The header of the mail shows the following lines:

Content-Transfer-Encoding: 8BIT
Content-Type: text/plain;
charset="ISO-8859-1"

in the menu of TBird you can see that TBird is using
the ISO-8859-1 coding for showing the message.

When I switch the coding in the menu to UTF-8 manually,
everything is shown correctly!

Therefore I thought it would be a good Idea to use
the -charset UTF-8 switch, but oviously it isn't so.
This switch obviously does not only change the charset
header but does other things too which I don't understand.
(and isn't described)

The header lines now show as:

MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset="UTF-8"

TBird now uses UTF-8 from the start but now
the mailbody has changed so the Umlaute ar mismatched again
and I even can't find any coding in TBird manually
that shows tha mail correctly.

Then I tried something desperate
I used the Option -charset FLOPP
assuming the using an nonexistent charset
blat would only change the headerline and nothing
else would be changed.
In that I was right.

And now as Tbird doesn't get any useful
information and especially not a wrong one
about the charset of the mail
it obiously guesses the charset by its own:

And Tbird does it right!

So the problem is solved for my usage of blat by
now by using a nonexistent charset option.

But i think this is not a good tongterm solution
therefore I am posting this.

Lavendel

Post by lavendelbonbon
I am using blat with success for many years now (Thx for the Software)
Today I tried to resolve an problem I have with german "Umlaute" in textfiles, but I wasn't successful.
I am not sure if I am doing something completely wrong.
I am using Thunderbird 15 as my mail client.
I have UTF-8 encoded textfiles I want to use as Mailbodies.
When I send them with no special options the default charset 8859-1 is used
and the Umlaut " ö " and the " ß "in Größe is not shown correctly (as expected).
When I now switch to UTF-8 in the view menu of thunderbird everything is shown correctly.
So for the next step I used the option -charset UTF-8 when sending the textfile
expecting that then everything would be shown correctly.
But the "Größe" now is still not shown correctly in spite of the UTF-8 entry in the header.
Therefore I compared the mail source code of the two mails using the sourcecode viewing option in thunderbird
and surprisingly the word "Größe" shows up different.
Gr=C3=B6=C3=9Fe
GröÃ&#159;e
As a further step I saved the original mail
after recieving it in thunderbird as a eml file
and just edited the Charset header entry
from ISO 8859-1 to UTF-8
without changing anything else.
And voila the mailbody is now shown correctly in thunderbird
when opening the file.
My conclusion is that the -charset switch
is not only changing the header entry (as I expected)
But is doing something else too which it obviously shouldn't.
But as I have no experience with that kind of problems
I might have gotten something completely wrong ?

[Chip]

<snipped>

I am sending a textfile as a mailbody. This textfile is a an output of
another program so I don't really know how it is coded.

<snipped>

There is the whole problem, that you do not know the encoding that comes
from the other program. Are you able to get the output from that other
program saved to a file, so you / I can view it later with a hex viewer?
When we know how that other program outputs its text, then we can try to
figure out if there is a bug in Blat.

[Christoph Leser]

From what lavendelbobon describes it seem quite clear that his utf-8 encoded.

Here is what I guess happens:

When sending the text file without charset option, blat assumes the text file is iso8859 , sets the header and sends the file without conversion, as it assumes that it is iso8859 coded

When sent with charset=UTF-8, it sets the header to utf-8 and converts the file, which it still believes is in iso8859, from iso8850 to uft8, which is possible, as every sequence of 8 bit bytes can legally be interpretet as iso8859 - even utf-8 encoded text.

This could easily be confirmed by doing looking at the text fil ewith any hex editor and taking a network trace of the mail traffic.


Best Regards / Mit freundlichen Grüßen

Christoph


Von: ***@yahoogroups.com [***@yahoogroups.com]" im Auftrag von "lavendelbonbon [***@gmail.com]
Gesendet: Freitag, 14. September 2012 17:39
An: ***@yahoogroups.com
Betreff: [blat] Re: "Umlaute" Problems with UTF-8



PROBLEM Solved or at least Workarounded

Hi all thx for all your advice.

I must admit that I might have not be clear enough
describing problem.
And it actually still exists in the software or at
least in its decription.

Therefore I will try being clearer and post my workaround:

First: I am using blat 3.07

And the situation is:

I am sending a textfile as a mailbody.
This textfile is a an output of another program
so I don't really know how it is coded.

But when I am sendig it with no further options
the Umlaute are mismatched, when viewing the mail in
Thunderbird 15.

The header of the mail shows the following lines:

Content-Transfer-Encoding: 8BIT
Content-Type: text/plain;
charset="ISO-8859-1"

in the menu of TBird you can see that TBird is using
the ISO-8859-1 coding for showing the message.

When I switch the coding in the menu to UTF-8 manually,
everything is shown correctly!

Therefore I thought it would be a good Idea to use
the -charset UTF-8 switch, but oviously it isn't so.
This switch obviously does not only change the charset
header but does other things too which I don't understand.
(and isn't described)

The header lines now show as:

MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset="UTF-8"

TBird now uses UTF-8 from the start but now
the mailbody has changed so the Umlaute ar mismatched again
and I even can't find any coding in TBird manually
that shows tha mail correctly.

Then I tried something desperate
I used the Option -charset FLOPP
assuming the using an nonexistent charset
blat would only change the headerline and nothing
else would be changed.
In that I was right.

And now as Tbird doesn't get any useful
information and especially not a wrong one
about the charset of the mail
it obiously guesses the charset by its own:

And Tbird does it right!

So the problem is solved for my usage of blat by
now by using a nonexistent charset option.

But i think this is not a good tongterm solution
therefore I am posting this.

Lavendel

I am using blat with success for many years now (Thx for the Software)
Today I tried to resolve an problem I have with german "Umlaute" in textfiles, but I wasn't successful.
I am not sure if I am doing something completely wrong.
I am using Thunderbird 15 as my mail client.
I have UTF-8 encoded textfiles I want to use as Mailbodies.
When I send them with no special options the default charset 8859-1 is used
and the Umlaut " ö " and the " ß "in Größe is not shown correctly (as expected).
When I now switch to UTF-8 in the view menu of thunderbird everything is shown correctly.
So for the next step I used the option -charset UTF-8 when sending the textfile
expecting that then everything would be shown correctly.
But the "Größe" now is still not shown correctly in spite of the UTF-8 entry in the header.
Therefore I compared the mail source code of the two mails using the sourcecode viewing option in thunderbird
and surprisingly the word "Größe" shows up different.
Gr=C3=B6=C3=9Fe
GröÃ&#159;e
As a further step I saved the original mail
after recieving it in thunderbird as a eml file
and just edited the Charset header entry
from ISO 8859-1 to UTF-8
without changing anything else.
And voila the mailbody is now shown correctly in thunderbird
when opening the file.
My conclusion is that the -charset switch
is not only changing the header entry (as I expected)
But is doing something else too which it obviously shouldn't.
But as I have no experience with that kind of problems
I might have gotten something completely wrong ?

[Non-text portions of this message have been removed]



------------------------------------

[Chip]

From what lavendelbobon describes it seem quite clear that his utf-8 encoded.

German unlautes can be represented with only 8-bits without the need for
utf-8 encoding. Therefore, it is required that the data being passed from
an application to Blat must be checked for true encoding, because I suspect
the application is using/sending only 8-bit strings instead of Unicode
strings.

Next, which exact flavor of Blat 3.07 was installed? Win98/ME? 32-bit for
Win2000+? 64-bit? A blat log when using -superdebug option would be
helpful.

Chip



------------------------------------

[lavendelbonbon]

Hi chip
here come the logfiles
the first one with and the second one without
the -charset UTF-8 option
and finally the mailbody as it should show up
Hope this is of some help

Lavendelbonbon




[18:46:39,05][19.09.2012]S:> blat\blat "J:\RS_Remotepruefung\2012_09_19_18-46_RS_ERGEBNIS_GESAMT.txt" -to ***@gmail.com -f ***@UTF8.de -s "Remotesicherungsueberpruefung: Fernvergleichsbericht" -server smtp.strato.de -u ***@post.gabimm.de -pw emehlsmtp -charset UTF-8 -superdebug
Blat v3.0.7 (build : Jul 20 2012 01:24:19)
32-bit Windows, Full, Unicode

Checking option -to
Checking option -f
Checking option -s
Checking option -server
Checking option -u
Checking option -pw
Checking option -charset
superDebug: init_winsock(), WSAStartup() returned 0 (NO_ERROR)
superDebug: Hostname <smtp.strato.de> resolved to ip address 81.169.145.133
superDebug: Official hostname is smtp.strato.de
superDebug: Attempting to connect to ip address 81.169.145.133
superDebug: Received 57 bytes:
superDebug: 00000 32 32 30 20 73 6D 74 70 2E 73 74 72 61 74 6F 2E 220 smtp.strato.
superDebug: 00010 64 65 20 5B 6A 6F 73 6F 65 20 6D 6F 31 33 5D 20 de [josoe mo13]
superDebug: 00020 45 53 4D 54 50 20 52 5A 6D 74 61 20 33 30 2E 31 ESMTP RZmta 30.1
superDebug: 00030 35 20 72 65 61 64 79 0D 0A 5 ready..
<<<getline<<< 220 smtp.strato.de [josoe mo13] ESMTP RZmta 30.15 ready
superDebug: Attempting to send 18 bytes:
superDebug: 00000 45 48 4C 4F 20 76 2D 73 69 63 68 65 72 75 6E 67 EHLO v-sicherung
superDebug: 00010 0D 0A ..

Post by Chip

putline>>> EHLO v-sicherung

superDebug: Received 212 bytes:
superDebug: 00000 32 35 30 2D 73 6D 74 70 2E 73 74 72 61 74 6F 2E 250-smtp.strato.
superDebug: 00010 64 65 20 5B 6A 6F 73 6F 65 20 6D 6F 31 33 5D 20 de [josoe mo13]
superDebug: 00020 67 72 65 65 74 73 20 31 37 38 2E 31 35 2E 31 32 greets 178.15.12
superDebug: 00030 35 2E 31 36 30 0D 0A 32 35 30 2D 45 4E 48 41 4E 5.160..250-ENHAN
superDebug: 00040 43 45 44 53 54 41 54 55 53 43 4F 44 45 53 0D 0A CEDSTATUSCODES..
superDebug: 00050 32 35 30 2D 38 42 49 54 4D 49 4D 45 0D 0A 32 35 250-8BITMIME..25
superDebug: 00060 30 2D 50 49 50 45 4C 49 4E 49 4E 47 0D 0A 32 35 0-PIPELINING..25
superDebug: 00070 30 2D 44 45 4C 49 56 45 52 42 59 0D 0A 32 35 30 0-DELIVERBY..250
superDebug: 00080 2D 53 49 5A 45 20 31 30 34 38 35 37 36 30 30 0D -SIZE 104857600.
superDebug: 00090 0A 32 35 30 2D 41 55 54 48 20 43 52 41 4D 2D 4D .250-AUTH CRAM-M
superDebug: 000A0 44 35 20 53 43 52 41 4D 2D 53 48 41 2D 31 20 4C D5 SCRAM-SHA-1 L
superDebug: 000B0 4F 47 49 4E 20 50 4C 41 49 4E 0D 0A 32 35 30 2D OGIN PLAIN..250-
superDebug: 000C0 53 54 41 52 54 54 4C 53 0D 0A 32 35 30 20 48 45 STARTTLS..250 HE
superDebug: 000D0 4C 50 0D 0A LP..
<<<getline<<< 250-smtp.strato.de [josoe mo13] greets 178.15.125.160
<<<getline<<< 250-ENHANCEDSTATUSCODES
<<<getline<<< 250-8BITMIME
<<<getline<<< 250-PIPELINING
<<<getline<<< 250-DELIVERBY
<<<getline<<< 250-SIZE 104857600
<<<getline<<< 250-AUTH CRAM-MD5 SCRAM-SHA-1 LOGIN PLAIN
<<<getline<<< 250-STARTTLS
<<<getline<<< 250 HELP
Sending J:\RS_Remotepruefung\2012_09_19_18-46_RS_ERGEBNIS_GESAMT.txt to ***@gmail.com
Subject: Remotesicherungsueberpruefung: Fernvergleichsbericht
Login name is ***@UTF8.de
superDebug: Attempting to send 15 bytes:
superDebug: 00000 41 55 54 48 20 43 52 41 4D 2D 4D 44 35 0D 0A AUTH CRAM-MD5..

Post by Chip

putline>>> AUTH CRAM-MD5

superDebug: Received 54 bytes:
superDebug: 00000 33 33 34 20 50 44 63 78 59 53 34 77 65 44 51 34 334 PDcxYS4weDQ4
superDebug: 00010 4F 54 59 77 4D 54 67 31 4D 44 55 35 5A 6A 5A 6C OTYwMTg1MDU5ZjZl
superDebug: 00020 4E 54 67 79 51 6A 55 34 51 47 70 76 63 32 39 6C NTgyQjU4QGpvc29l
superDebug: 00030 50 67 3D 3D 0D 0A Pg==..
<<<getline<<< 334 PDcxYS4weDQ4OTYwMTg1MDU5ZjZlNTgyQjU4QGpvc29lPg==
superDebug: Attempting to send 74 bytes:
superDebug: 00000 63 32 31 30 63 45 42 77 62 33 4E 30 4C 6D 64 68 c210cEBwb3N0Lmdh
superDebug: 00010 59 6D 6C 74 62 53 35 6B 5A 53 42 6B 5A 47 51 78 YmltbS5kZSBkZGQx
superDebug: 00020 5A 6A 59 33 59 6A 68 6B 5A 54 67 34 4E 54 49 32 ZjY3YjhkZTg4NTI2
superDebug: 00030 4D 57 49 77 5A 6A 51 32 5A 47 56 6B 5A 47 59 32 MWIwZjQ2ZGVkZGY2
superDebug: 00040 4E 54 51 78 59 51 3D 3D 0D 0A NTQxYQ==..

Post by Chip

putline>>> c210cEBwb3N0LmdhYmltbS5kZSBkZGQxZjY3YjhkZTg4NTI2MWIwZjQ2ZGVkZGY2NTQxYQ==

superDebug: Received 28 bytes:
superDebug: 00000 32 33 35 20 32 2E 37 2E 30 20 4F 4B 20 41 75 74 235 2.7.0 OK Aut
superDebug: 00010 68 65 6E 74 69 63 61 74 65 64 0D 0A henticated..
<<<getline<<< 235 2.7.0 OK Authenticated
superDebug: Attempting to send 40 bytes:
superDebug: 00000 4D 41 49 4C 20 46 52 4F 4D 3A 3C 55 54 46 38 40 MAIL FROM:<UTF8@
superDebug: 00010 55 54 46 38 2E 64 65 3E 20 42 4F 44 59 3D 38 42 UTF8.de> BODY=8B
superDebug: 00020 49 54 4D 49 4D 45 0D 0A ITMIME..
superDebug: Received 36 bytes:
superDebug: 00000 32 35 30 20 32 2E 31 2E 30 20 3C 55 54 46 38 40 250 2.1.0 <UTF8@
superDebug: 00010 55 54 46 38 2E 64 65 3E 20 53 65 6E 64 65 72 20 UTF8.de> Sender
superDebug: 00020 6F 6B 0D 0A ok..
<<<getline<<< 250 2.1.0 <***@UTF8.de> Sender ok
superDebug: Attempting to send 36 bytes:
superDebug: 00000 52 43 50 54 20 54 4F 3A 3C 6C 61 76 65 6E 64 65 RCPT TO:<lavende
superDebug: 00010 6C 62 6F 6E 62 6F 6E 40 67 6D 61 69 6C 2E 63 6F ***@gmail.co
superDebug: 00020 6D 3E 0D 0A m>..
superDebug: Received 51 bytes:
superDebug: 00000 32 35 30 20 32 2E 31 2E 35 20 3C 6C 61 76 65 6E 250 2.1.5 <laven
superDebug: 00010 64 65 6C 62 6F 6E 62 6F 6E 40 67 6D 61 69 6C 2E ***@gmail.
superDebug: 00020 63 6F 6D 3E 20 52 65 63 69 70 69 65 6E 74 20 6F com> Recipient o
superDebug: 00030 6B 0D 0A k..
<<<getline<<< 250 2.1.5 <***@gmail.com> Recipient ok
superDebug: Attempting to send 6 bytes:
superDebug: 00000 44 41 54 41 0D 0A DATA..

Post by Chip

putline>>> DATA

superDebug: Received 48 bytes:
superDebug: 00000 33 35 34 20 45 6E 74 65 72 20 64 61 74 61 20 66 354 Enter data f
superDebug: 00010 6F 72 20 6D 61 69 6C 20 77 69 74 68 20 69 64 20 or mail with id
superDebug: 00020 79 30 31 35 30 62 6F 38 4A 47 64 32 74 45 0D 0A y0150bo8JGd2tE..
<<<getline<<< 354 Enter data for mail with id y0150bo8JGd2tE
superDebug: Attempting to send 1336 bytes:
superDebug: 00000 44 61 74 65 3A 20 57 65 64 2C 20 31 39 20 53 65 Date: Wed, 19 Se
superDebug: 00010 70 20 32 30 31 32 20 31 38 3A 34 36 3A 33 39 20 p 2012 18:46:39
superDebug: 00020 2B 30 32 30 30 0D 0A 46 72 6F 6D 3A 20 55 54 46 +0200..From: UTF
superDebug: 00030 38 40 55 54 46 38 2E 64 65 0D 0A 54 6F 3A 20 6C ***@UTF8.de..To: l
superDebug: 00040 61 76 65 6E 64 65 6C 62 6F 6E 62 6F 6E 40 67 6D ***@gm
superDebug: 00050 61 69 6C 2E 63 6F 6D 0D 0A 58 2D 4D 61 69 6C 65 ail.com..X-Maile
superDebug: 00060 72 3A 20 42 6C 61 74 20 76 33 2E 30 2E 37 2C 20 r: Blat v3.0.7,
superDebug: 00070 61 20 57 69 6E 33 32 20 53 4D 54 50 2F 4E 4E 54 a Win32 SMTP/NNT
superDebug: 00080 50 20 6D 61 69 6C 65 72 20 68 74 74 70 3A 2F 2F P mailer http://
superDebug: 00090 77 77 77 2E 62 6C 61 74 2E 6E 65 74 0D 0A 4D 65 www.blat.net..Me
superDebug: 000A0 73 73 61 67 65 2D 49 44 3A 20 3C 30 31 63 64 39 ssage-ID: <01cd9
superDebug: 000B0 36 38 36 24 42 6C 61 74 2E 76 33 2E 30 2E 37 24 686$Blat.v3.0.7$
superDebug: 000C0 35 38 36 61 36 38 34 38 24 36 33 34 36 35 64 31 586a6848$63465d1
superDebug: 000D0 64 32 35 65 40 73 74 72 61 74 6F 2E 64 65 3E 0D ***@strato.de>.
superDebug: 000E0 0A 53 75 62 6A 65 63 74 3A 20 52 65 6D 6F 74 65 .Subject: Remote
superDebug: 000F0 73 69 63 68 65 72 75 6E 67 73 75 65 62 65 72 70 sicherungsueberp
superDebug: 00100 72 75 65 66 75 6E 67 3A 20 46 65 72 6E 76 65 72 ruefung: Fernver
superDebug: 00110 67 6C 65 69 63 68 73 62 65 72 69 63 68 74 0D 0A gleichsbericht..
superDebug: 00120 4D 49 4D 45 2D 56 65 72 73 69 6F 6E 3A 20 31 2E MIME-Version: 1.
superDebug: 00130 30 0D 0A 43 6F 6E 74 65 6E 74 2D 54 72 61 6E 73 0..Content-Trans
superDebug: 00140 66 65 72 2D 45 6E 63 6F 64 69 6E 67 3A 20 71 75 fer-Encoding: qu
superDebug: 00150 6F 74 65 64 2D 70 72 69 6E 74 61 62 6C 65 0D 0A oted-printable..
superDebug: 00160 43 6F 6E 74 65 6E 74 2D 54 79 70 65 3A 20 74 65 Content-Type: te
superDebug: 00170 78 74 2F 70 6C 61 69 6E 3B 0D 0A 20 63 68 61 72 xt/plain;.. char
superDebug: 00180 73 65 74 3D 22 55 54 46 2D 38 22 0D 0A 0D 0A 56 set="UTF-8"....V
superDebug: 00190 45 52 47 4C 45 49 43 48 53 45 52 47 45 42 4E 49 ERGLEICHSERGEBNI
superDebug: 001A0 53 3D 32 30 0D 0A 0D 0A 2D 0D 0A 2D 0D 0A 2D 0D S=20....-..-..-.
superDebug: 001B0 0A 0D 0A C3 AF C2 BB C2 BF 46 65 72 6E 76 65 72 .........Fernver
superDebug: 001C0 67 6C 65 69 63 68 73 62 65 72 69 63 68 74 3A 20 gleichsbericht:
superDebug: 001D0 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
superDebug: 001E0 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
superDebug: 001F0 20 20 20 20 20 20 20 20 20 20 3D 35 43 3D 0D 0A =5C=..
superDebug: 00200 3D 35 43 31 37 32 2E 32 30 2E 31 2E 36 3D 35 43 =5C172.20.1.6=5C
superDebug: 00210 4B 6F 70 69 65 5F 50 5F 42 61 75 6D 67 61 72 74 Kopie_P_Baumgart
superDebug: 00220 0D 0A 45 72 73 74 65 6C 6C 74 3A 20 31 39 2E 30 ..Erstellt: 19.0
superDebug: 00230 39 2E 32 30 31 32 20 31 38 3A 34 36 3A 33 38 0D 9.2012 18:46:38.
superDebug: 00240 0A 0D 0A 4D 6F 64 75 73 3A 20 20 55 6E 74 65 72 ...Modus: Unter
superDebug: 00250 73 63 68 69 65 64 65 0D 0A 4C 69 6E 6B 65 72 20 schiede..Linker
superDebug: 00260 42 61 73 69 73 6F 72 64 6E 65 72 3A 20 3D 35 43 Basisordner: =5C
superDebug: 00270 3D 35 43 31 37 32 2E 32 30 2E 31 2E 36 3D 35 43 =5C172.20.1.6=5C
superDebug: 00280 4B 6F 70 69 65 5F 50 5F 42 61 75 6D 67 61 72 74 Kopie_P_Baumgart
superDebug: 00290 0D 0A 52 65 63 68 74 65 72 20 42 61 73 69 73 6F ..Rechter Basiso
superDebug: 002A0 72 64 6E 65 72 3A 20 3D 35 43 3D 35 43 31 37 32 rdner: =5C=5C172
superDebug: 002B0 2E 33 30 2E 31 2E 37 3D 35 43 52 53 5F 53 74 61 .30.1.7=5CRS_Sta
superDebug: 002C0 6E 64 5F 54 61 67 65 73 61 6E 66 61 6E 67 3D 35 nd_Tagesanfang=5
superDebug: 002D0 43 50 5F 42 61 75 6D 67 61 72 3D 0D 0A 74 0D 0A CP_Baumgar=..t..
superDebug: 002E0 0D 0A 4C 69 6E 6B 73 73 65 69 74 69 67 65 20 44 ..Linksseitige D
superDebug: 002F0 61 74 65 69 2D 53 69 6E 67 6C 65 73 20 28 30 29 atei-Singles (0)
superDebug: 00300 20 20 47 72 C3 83 C2 B6 C3 83 C2 9F 65 20 C3 83 Gr........e ..
superDebug: 00310 C2 84 6E 64 65 72 75 6E 67 73 64 61 74 75 6D 0D ..nderungsdatum.
superDebug: 00320 0A 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D .---------------
superDebug: 00330 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D ----------------
superDebug: 00340 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D ----------------
superDebug: 00350 2D 2D 2D 2D 2D 0D 0A 0D 0A 52 65 63 68 74 73 73 -----....Rechtss
superDebug: 00360 65 69 74 69 67 65 20 44 61 74 65 69 2D 53 69 6E eitige Datei-Sin
superDebug: 00370 67 6C 65 73 20 28 30 29 20 47 72 C3 83 C2 B6 C3 gles (0) Gr.....
superDebug: 00380 83 C2 9F 65 20 C3 83 C2 84 6E 64 65 72 75 6E 67 ...e ....nderung
superDebug: 00390 73 64 61 74 75 6D 0D 0A 2D 2D 2D 2D 2D 2D 2D 2D sdatum..--------
superDebug: 003A0 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D ----------------
superDebug: 003B0 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D ----------------
superDebug: 003C0 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 0D 0A 0D 0A ------------....
superDebug: 003D0 4C 69 6E 6B 73 73 65 69 74 69 67 20 6E 65 75 65 Linksseitig neue
superDebug: 003E0 72 65 20 44 61 74 65 69 65 6E 20 28 30 29 20 20 re Dateien (0)
superDebug: 003F0 47 72 C3 83 C2 B6 C3 83 C2 9F 65 20 C3 83 C2 84 Gr........e ....
superDebug: 00400 6E 64 65 72 75 6E 67 73 64 61 74 75 6D 0D 0A 2D nderungsdatum..-
superDebug: 00410 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D ----------------
superDebug: 00420 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D ----------------
superDebug: 00430 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D ----------------
superDebug: 00440 2D 2D 2D 0D 0A 0D 0A 52 65 63 68 74 73 73 65 69 ---....Rechtssei
superDebug: 00450 74 69 67 20 6E 65 75 65 72 65 20 44 61 74 65 69 tig neuere Datei
superDebug: 00460 65 6E 20 28 30 29 20 47 72 C3 83 C2 B6 C3 83 C2 en (0) Gr.......
superDebug: 00470 9F 65 20 C3 83 C2 84 6E 64 65 72 75 6E 67 73 64 .e ....nderungsd
superDebug: 00480 61 74 75 6D 0D 0A 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D atum..----------
superDebug: 00490 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D ----------------
superDebug: 004A0 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D ----------------
superDebug: 004B0 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 0D 0A 0D 0A 55 6E ----------....Un
superDebug: 004C0 74 65 72 73 63 68 69 65 64 6C 69 63 68 65 20 44 terschiedliche D
superDebug: 004D0 61 74 65 69 65 6E 20 28 30 29 20 20 20 20 47 72 ateien (0) Gr
superDebug: 004E0 C3 83 C2 B6 C3 83 C2 9F 65 20 C3 83 C2 84 6E 64 ........e ....nd
superDebug: 004F0 65 72 75 6E 67 73 64 61 74 75 6D 0D 0A 2D 2D 2D erungsdatum..---
superDebug: 00500 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D ----------------
superDebug: 00510 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D ----------------
superDebug: 00520 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D ----------------
superDebug: 00530 2D 0D 0A 0D 0A 2E 0D 0A -.......
superDebug: Received 30 bytes:
superDebug: 00000 32 35 30 20 71 75 65 75 65 64 20 61 73 20 79 30 250 queued as y0
superDebug: 00010 31 35 30 62 6F 38 4A 47 64 32 74 45 0D 0A 150bo8JGd2tE..
<<<getline<<< 250 queued as y0150bo8JGd2tE
superDebug: Attempting to send 6 bytes:
superDebug: 00000 51 55 49 54 0D 0A QUIT..

Post by Chip

putline>>> QUIT

superDebug: Received 30 bytes:
superDebug: 00000 32 32 31 20 32 2E 30 2E 30 20 63 6C 6F 73 69 6E 221 2.0.0 closin
superDebug: 00010 67 20 63 6F 6E 6E 65 63 74 69 6F 6E 0D 0A g connection..
<<<getline<<< 221 2.0.0 closing connection


[18:46:42,03][19.09.2012]S:> blat\blat "J:\RS_Remotepruefung\2012_09_19_18-46_RS_ERGEBNIS_GESAMT.txt" -to ***@gmail.com -f ***@plaintext.de -s "Remotesicherungsueberpruefung: Fernvergleichsbericht" -server smtp.strato.de -u ***@post.gabimm.de -pw emehlsmtp -superdebug
Blat v3.0.7 (build : Jul 20 2012 01:24:19)
32-bit Windows, Full, Unicode

Checking option -to
Checking option -f
Checking option -s
Checking option -server
Checking option -u
Checking option -pw
superDebug: init_winsock(), WSAStartup() returned 0 (NO_ERROR)
superDebug: Hostname <smtp.strato.de> resolved to ip address 81.169.145.133
superDebug: Official hostname is smtp.strato.de
superDebug: Attempting to connect to ip address 81.169.145.133
superDebug: Received 57 bytes:
superDebug: 00000 32 32 30 20 73 6D 74 70 2E 73 74 72 61 74 6F 2E 220 smtp.strato.
superDebug: 00010 64 65 20 5B 6A 6F 73 6F 65 20 6D 6F 31 36 5D 20 de [josoe mo16]
superDebug: 00020 45 53 4D 54 50 20 52 5A 6D 74 61 20 33 30 2E 31 ESMTP RZmta 30.1
superDebug: 00030 35 20 72 65 61 64 79 0D 0A 5 ready..
<<<getline<<< 220 smtp.strato.de [josoe mo16] ESMTP RZmta 30.15 ready
superDebug: Attempting to send 18 bytes:
superDebug: 00000 45 48 4C 4F 20 76 2D 73 69 63 68 65 72 75 6E 67 EHLO v-sicherung
superDebug: 00010 0D 0A ..

Post by Chip

putline>>> EHLO v-sicherung

superDebug: Received 212 bytes:
superDebug: 00000 32 35 30 2D 73 6D 74 70 2E 73 74 72 61 74 6F 2E 250-smtp.strato.
superDebug: 00010 64 65 20 5B 6A 6F 73 6F 65 20 6D 6F 31 36 5D 20 de [josoe mo16]
superDebug: 00020 67 72 65 65 74 73 20 31 37 38 2E 31 35 2E 31 32 greets 178.15.12
superDebug: 00030 35 2E 31 36 30 0D 0A 32 35 30 2D 45 4E 48 41 4E 5.160..250-ENHAN
superDebug: 00040 43 45 44 53 54 41 54 55 53 43 4F 44 45 53 0D 0A CEDSTATUSCODES..
superDebug: 00050 32 35 30 2D 38 42 49 54 4D 49 4D 45 0D 0A 32 35 250-8BITMIME..25
superDebug: 00060 30 2D 50 49 50 45 4C 49 4E 49 4E 47 0D 0A 32 35 0-PIPELINING..25
superDebug: 00070 30 2D 44 45 4C 49 56 45 52 42 59 0D 0A 32 35 30 0-DELIVERBY..250
superDebug: 00080 2D 53 49 5A 45 20 31 30 34 38 35 37 36 30 30 0D -SIZE 104857600.
superDebug: 00090 0A 32 35 30 2D 41 55 54 48 20 43 52 41 4D 2D 4D .250-AUTH CRAM-M
superDebug: 000A0 44 35 20 53 43 52 41 4D 2D 53 48 41 2D 31 20 4C D5 SCRAM-SHA-1 L
superDebug: 000B0 4F 47 49 4E 20 50 4C 41 49 4E 0D 0A 32 35 30 2D OGIN PLAIN..250-
superDebug: 000C0 53 54 41 52 54 54 4C 53 0D 0A 32 35 30 20 48 45 STARTTLS..250 HE
superDebug: 000D0 4C 50 0D 0A LP..
<<<getline<<< 250-smtp.strato.de [josoe mo16] greets 178.15.125.160
<<<getline<<< 250-ENHANCEDSTATUSCODES
<<<getline<<< 250-8BITMIME
<<<getline<<< 250-PIPELINING
<<<getline<<< 250-DELIVERBY
<<<getline<<< 250-SIZE 104857600
<<<getline<<< 250-AUTH CRAM-MD5 SCRAM-SHA-1 LOGIN PLAIN
<<<getline<<< 250-STARTTLS
<<<getline<<< 250 HELP
Sending J:\RS_Remotepruefung\2012_09_19_18-46_RS_ERGEBNIS_GESAMT.txt to ***@gmail.com
Subject: Remotesicherungsueberpruefung: Fernvergleichsbericht
Login name is ***@plaintext.de
superDebug: Attempting to send 15 bytes:
superDebug: 00000 41 55 54 48 20 43 52 41 4D 2D 4D 44 35 0D 0A AUTH CRAM-MD5..

Post by Chip

putline>>> AUTH CRAM-MD5

superDebug: Received 54 bytes:
superDebug: 00000 33 33 34 20 50 44 67 31 59 69 34 77 65 44 49 33 334 PDg1Yi4weDI3
superDebug: 00010 4D 6D 45 31 4D 44 67 31 4D 44 55 35 5A 6A 5A 6C MmE1MDg1MDU5ZjZl
superDebug: 00020 4F 45 52 46 4D 45 55 7A 51 47 70 76 63 32 39 6C OERFMEUzQGpvc29l
superDebug: 00030 50 67 3D 3D 0D 0A Pg==..
<<<getline<<< 334 PDg1Yi4weDI3MmE1MDg1MDU5ZjZlOERFMEUzQGpvc29lPg==
superDebug: Attempting to send 74 bytes:
superDebug: 00000 63 32 31 30 63 45 42 77 62 33 4E 30 4C 6D 64 68 c210cEBwb3N0Lmdh
superDebug: 00010 59 6D 6C 74 62 53 35 6B 5A 53 41 31 4E 44 63 79 YmltbS5kZSA1NDcy
superDebug: 00020 4D 7A 6B 35 5A 57 45 32 59 6D 56 68 4D 44 45 31 Mzk5ZWE2YmVhMDE1
superDebug: 00030 4E 54 4A 6A 4E 7A 52 68 4F 47 59 31 4D 57 5A 6A NTJjNzRhOGY1MWZj
superDebug: 00040 59 7A 5A 6D 4D 51 3D 3D 0D 0A YzZmMQ==..

Post by Chip

putline>>> c210cEBwb3N0LmdhYmltbS5kZSA1NDcyMzk5ZWE2YmVhMDE1NTJjNzRhOGY1MWZjYzZmMQ==

superDebug: Received 28 bytes:
superDebug: 00000 32 33 35 20 32 2E 37 2E 30 20 4F 4B 20 41 75 74 235 2.7.0 OK Aut
superDebug: 00010 68 65 6E 74 69 63 61 74 65 64 0D 0A henticated..
<<<getline<<< 235 2.7.0 OK Authenticated
superDebug: Attempting to send 36 bytes:
superDebug: 00000 4D 41 49 4C 20 46 52 4F 4D 3A 3C 70 6C 61 69 6E MAIL FROM:<plain
superDebug: 00010 74 65 78 74 40 70 6C 61 69 6E 74 65 78 74 2E 64 ***@plaintext.d
superDebug: 00020 65 3E 0D 0A e>..
superDebug: Received 46 bytes:
superDebug: 00000 32 35 30 20 32 2E 31 2E 30 20 3C 70 6C 61 69 6E 250 2.1.0 <plain
superDebug: 00010 74 65 78 74 40 70 6C 61 69 6E 74 65 78 74 2E 64 ***@plaintext.d
superDebug: 00020 65 3E 20 53 65 6E 64 65 72 20 6F 6B 0D 0A e> Sender ok..
<<<getline<<< 250 2.1.0 <***@plaintext.de> Sender ok
superDebug: Attempting to send 36 bytes:
superDebug: 00000 52 43 50 54 20 54 4F 3A 3C 6C 61 76 65 6E 64 65 RCPT TO:<lavende
superDebug: 00010 6C 62 6F 6E 62 6F 6E 40 67 6D 61 69 6C 2E 63 6F ***@gmail.co
superDebug: 00020 6D 3E 0D 0A m>..
superDebug: Received 51 bytes:
superDebug: 00000 32 35 30 20 32 2E 31 2E 35 20 3C 6C 61 76 65 6E 250 2.1.5 <laven
superDebug: 00010 64 65 6C 62 6F 6E 62 6F 6E 40 67 6D 61 69 6C 2E ***@gmail.
superDebug: 00020 63 6F 6D 3E 20 52 65 63 69 70 69 65 6E 74 20 6F com> Recipient o
superDebug: 00030 6B 0D 0A k..
<<<getline<<< 250 2.1.5 <***@gmail.com> Recipient ok
superDebug: Attempting to send 6 bytes:
superDebug: 00000 44 41 54 41 0D 0A DATA..

Post by Chip

putline>>> DATA

superDebug: Received 48 bytes:
superDebug: 00000 33 35 34 20 45 6E 74 65 72 20 64 61 74 61 20 66 354 Enter data f
superDebug: 00010 6F 72 20 6D 61 69 6C 20 77 69 74 68 20 69 64 20 or mail with id
superDebug: 00020 4C 30 31 35 32 66 6F 38 4A 47 47 58 4B 54 0D 0A L0152fo8JGGXKT..
<<<getline<<< 354 Enter data for mail with id L0152fo8JGGXKT
superDebug: Attempting to send 1259 bytes:
superDebug: 00000 44 61 74 65 3A 20 57 65 64 2C 20 31 39 20 53 65 Date: Wed, 19 Se
superDebug: 00010 70 20 32 30 31 32 20 31 38 3A 34 36 3A 34 32 20 p 2012 18:46:42
superDebug: 00020 2B 30 32 30 30 0D 0A 46 72 6F 6D 3A 20 70 6C 61 +0200..From: pla
superDebug: 00030 69 6E 74 65 78 74 40 70 6C 61 69 6E 74 65 78 74 ***@plaintext
superDebug: 00040 2E 64 65 0D 0A 54 6F 3A 20 6C 61 76 65 6E 64 65 .de..To: lavende
superDebug: 00050 6C 62 6F 6E 62 6F 6E 40 67 6D 61 69 6C 2E 63 6F ***@gmail.co
superDebug: 00060 6D 0D 0A 58 2D 4D 61 69 6C 65 72 3A 20 42 6C 61 m..X-Mailer: Bla
superDebug: 00070 74 20 76 33 2E 30 2E 37 2C 20 61 20 57 69 6E 33 t v3.0.7, a Win3
superDebug: 00080 32 20 53 4D 54 50 2F 4E 4E 54 50 20 6D 61 69 6C 2 SMTP/NNTP mail
superDebug: 00090 65 72 20 68 74 74 70 3A 2F 2F 77 77 77 2E 62 6C er http://www.bl
superDebug: 000A0 61 74 2E 6E 65 74 0D 0A 4D 65 73 73 61 67 65 2D at.net..Message-
superDebug: 000B0 49 44 3A 20 3C 30 31 63 64 39 36 38 36 24 42 6C ID: <01cd9686$Bl
superDebug: 000C0 61 74 2E 76 33 2E 30 2E 37 24 35 61 36 64 36 34 at.v3.0.7$5a6d64
superDebug: 000D0 33 38 24 36 30 34 32 64 63 66 32 38 30 34 40 73 38$***@s
superDebug: 000E0 74 72 61 74 6F 2E 64 65 3E 0D 0A 53 75 62 6A 65 trato.de>..Subje
superDebug: 000F0 63 74 3A 20 52 65 6D 6F 74 65 73 69 63 68 65 72 ct: Remotesicher
superDebug: 00100 75 6E 67 73 75 65 62 65 72 70 72 75 65 66 75 6E ungsueberpruefun
superDebug: 00110 67 3A 20 46 65 72 6E 76 65 72 67 6C 65 69 63 68 g: Fernvergleich
superDebug: 00120 73 62 65 72 69 63 68 74 0D 0A 43 6F 6E 74 65 6E sbericht..Conten
superDebug: 00130 74 2D 54 72 61 6E 73 66 65 72 2D 45 6E 63 6F 64 t-Transfer-Encod
superDebug: 00140 69 6E 67 3A 20 38 42 49 54 0D 0A 43 6F 6E 74 65 ing: 8BIT..Conte
superDebug: 00150 6E 74 2D 54 79 70 65 3A 20 74 65 78 74 2F 70 6C nt-Type: text/pl
superDebug: 00160 61 69 6E 3B 0D 0A 20 63 68 61 72 73 65 74 3D 22 ain;.. charset="
superDebug: 00170 49 53 4F 2D 38 38 35 39 2D 31 22 0D 0A 0D 0A 56 ISO-8859-1"....V
superDebug: 00180 45 52 47 4C 45 49 43 48 53 45 52 47 45 42 4E 49 ERGLEICHSERGEBNI
superDebug: 00190 53 20 0D 0A 0D 0A 2D 0D 0A 2D 0D 0A 2D 0D 0A 0D S ....-..-..-...
superDebug: 001A0 0A EF BB BF 46 65 72 6E 76 65 72 67 6C 65 69 63 ....Fernvergleic
superDebug: 001B0 68 73 62 65 72 69 63 68 74 3A 20 20 20 20 20 20 hsbericht:
superDebug: 001C0 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
superDebug: 001D0 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
superDebug: 001E0 20 20 20 20 20 5C 5C 31 37 32 2E 32 30 2E 31 2E \\172.20.1.
superDebug: 001F0 36 5C 4B 6F 70 69 65 5F 50 5F 42 61 75 6D 67 61 6\Kopie_P_Baumga
superDebug: 00200 72 74 0D 0A 45 72 73 74 65 6C 6C 74 3A 20 31 39 rt..Erstellt: 19
superDebug: 00210 2E 30 39 2E 32 30 31 32 20 31 38 3A 34 36 3A 33 .09.2012 18:46:3
superDebug: 00220 38 0D 0A 0D 0A 4D 6F 64 75 73 3A 20 20 55 6E 74 8....Modus: Unt
superDebug: 00230 65 72 73 63 68 69 65 64 65 0D 0A 4C 69 6E 6B 65 erschiede..Linke
superDebug: 00240 72 20 42 61 73 69 73 6F 72 64 6E 65 72 3A 20 5C r Basisordner: \
superDebug: 00250 5C 31 37 32 2E 32 30 2E 31 2E 36 5C 4B 6F 70 69 \172.20.1.6\Kopi
superDebug: 00260 65 5F 50 5F 42 61 75 6D 67 61 72 74 0D 0A 52 65 e_P_Baumgart..Re
superDebug: 00270 63 68 74 65 72 20 42 61 73 69 73 6F 72 64 6E 65 chter Basisordne
superDebug: 00280 72 3A 20 5C 5C 31 37 32 2E 33 30 2E 31 2E 37 5C r: \\172.30.1.7\
superDebug: 00290 52 53 5F 53 74 61 6E 64 5F 54 61 67 65 73 61 6E RS_Stand_Tagesan
superDebug: 002A0 66 61 6E 67 5C 50 5F 42 61 75 6D 67 61 72 74 0D fang\P_Baumgart.
superDebug: 002B0 0A 0D 0A 4C 69 6E 6B 73 73 65 69 74 69 67 65 20 ...Linksseitige
superDebug: 002C0 44 61 74 65 69 2D 53 69 6E 67 6C 65 73 20 28 30 Datei-Singles (0
superDebug: 002D0 29 20 20 47 72 C3 B6 C3 9F 65 20 C3 84 6E 64 65 ) Gr....e ..nde
superDebug: 002E0 72 75 6E 67 73 64 61 74 75 6D 0D 0A 2D 2D 2D 2D rungsdatum..----
superDebug: 002F0 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D ----------------
superDebug: 00300 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D ----------------
superDebug: 00310 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D ----------------
superDebug: 00320 0D 0A 0D 0A 52 65 63 68 74 73 73 65 69 74 69 67 ....Rechtsseitig
superDebug: 00330 65 20 44 61 74 65 69 2D 53 69 6E 67 6C 65 73 20 e Datei-Singles
superDebug: 00340 28 30 29 20 47 72 C3 B6 C3 9F 65 20 C3 84 6E 64 (0) Gr....e ..nd
superDebug: 00350 65 72 75 6E 67 73 64 61 74 75 6D 0D 0A 2D 2D 2D erungsdatum..---
superDebug: 00360 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D ----------------
superDebug: 00370 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D ----------------
superDebug: 00380 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D ----------------
superDebug: 00390 2D 0D 0A 0D 0A 4C 69 6E 6B 73 73 65 69 74 69 67 -....Linksseitig
superDebug: 003A0 20 6E 65 75 65 72 65 20 44 61 74 65 69 65 6E 20 neuere Dateien
superDebug: 003B0 28 30 29 20 20 47 72 C3 B6 C3 9F 65 20 C3 84 6E (0) Gr....e ..n
superDebug: 003C0 64 65 72 75 6E 67 73 64 61 74 75 6D 0D 0A 2D 2D derungsdatum..--
superDebug: 003D0 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D ----------------
superDebug: 003E0 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D ----------------
superDebug: 003F0 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D ----------------
superDebug: 00400 2D 2D 0D 0A 0D 0A 52 65 63 68 74 73 73 65 69 74 --....Rechtsseit
superDebug: 00410 69 67 20 6E 65 75 65 72 65 20 44 61 74 65 69 65 ig neuere Dateie
superDebug: 00420 6E 20 28 30 29 20 47 72 C3 B6 C3 9F 65 20 C3 84 n (0) Gr....e ..
superDebug: 00430 6E 64 65 72 75 6E 67 73 64 61 74 75 6D 0D 0A 2D nderungsdatum..-
superDebug: 00440 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D ----------------
superDebug: 00450 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D ----------------
superDebug: 00460 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D ----------------
superDebug: 00470 2D 2D 2D 0D 0A 0D 0A 55 6E 74 65 72 73 63 68 69 ---....Unterschi
superDebug: 00480 65 64 6C 69 63 68 65 20 44 61 74 65 69 65 6E 20 edliche Dateien
superDebug: 00490 28 30 29 20 20 20 20 47 72 C3 B6 C3 9F 65 20 C3 (0) Gr....e .
superDebug: 004A0 84 6E 64 65 72 75 6E 67 73 64 61 74 75 6D 0D 0A .nderungsdatum..
superDebug: 004B0 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D ----------------
superDebug: 004C0 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D ----------------
superDebug: 004D0 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D ----------------
superDebug: 004E0 2D 2D 2D 2D 0D 0A 0D 0A 2E 0D 0A ----.......
superDebug: Received 30 bytes:
superDebug: 00000 32 35 30 20 71 75 65 75 65 64 20 61 73 20 4C 30 250 queued as L0
superDebug: 00010 31 35 32 66 6F 38 4A 47 47 58 4B 54 0D 0A 152fo8JGGXKT..
<<<getline<<< 250 queued as L0152fo8JGGXKT
superDebug: Attempting to send 6 bytes:
superDebug: 00000 51 55 49 54 0D 0A QUIT..

Post by Chip

putline>>> QUIT

superDebug: Received 30 bytes:
superDebug: 00000 32 32 31 20 32 2E 30 2E 30 20 63 6C 6F 73 69 6E 221 2.0.0 closin
superDebug: 00010 67 20 63 6F 6E 6E 65 63 74 69 6F 6E 0D 0A g connection..
<<<getline<<< 221 2.0.0 closing connection


THE CORRECT MAILBODY SHOULD SHOW AS:

VERGLEICHSERGEBNIS

-
-
-

&#65279;Fernvergleichsbericht: \\172.20.1.6\Kopie_P_Baumgart
Erstellt: 19.09.2012 18:46:38

Modus: Unterschiede
Linker Basisordner: \\172.20.1.6\Kopie_P_Baumgart
Rechter Basisordner: \\172.30.1.7\RS_Stand_Tagesanfang\P_Baumgart

Linksseitige Datei-Singles (0) Größe Änderungsdatum
----------------------------------------------------

Rechtsseitige Datei-Singles (0) Größe Änderungsdatum
----------------------------------------------------

Linksseitig neuere Dateien (0) Größe Änderungsdatum
----------------------------------------------------

Rechtsseitig neuere Dateien (0) Größe Änderungsdatum
----------------------------------------------------

Unterschiedliche Dateien (0) Größe Änderungsdatum
----------------------------------------------------

Post by Chip

From what lavendelbobon describes it seem quite clear that his utf-8 encoded.

German unlautes can be represented with only 8-bits without the need for
utf-8 encoding. Therefore, it is required that the data being passed from
an application to Blat must be checked for true encoding, because I suspect
the application is using/sending only 8-bit strings instead of Unicode
strings.
Next, which exact flavor of Blat 3.07 was installed? Win98/ME? 32-bit for
Win2000+? 64-bit? A blat log when using -superdebug option would be
helpful.
Chip

[ykai]

Post by lavendelbonbon
here come the logfiles
superDebug: 001A0 0A EF BB BF 46 65 72 6E 76 65 72 67 6C 65 69 63 ....Fernvergleic

Now "EF BB BF" is the UTF8-BOM, which here appears in the text.
EF-BB-BF is (on purpose) invalid UTF-8. The BOM may only appear at the
very beginning of the text file (as a marker for the reading application
about the encoding of the file).

So blat analysing this file can never identify it as UTF-8.

So in your 1st mail you tell blat, that you want UTF-8. Since the text is
"obviously" NOT UTF-8 blat converts your file to UTF-8, resulting into "double-
encoded" UTF-8.

In your 2nd mail no encoding takes place (after all since it IS NOT UTF-8 it might
be iso-8859-1). Unfortunately the declared charset in the header now does not
match the UTF-8 chars in the text (aside from the UTF-8-invalid EF BB BF).

As described in my earlier mail, this works all as intended if your text really is
UTF-8.

Hm, now what to advise...