Discussion:
Character set, code page conversion problem
Horský Vladimír
2013-12-27 12:24:10 UTC
Permalink
Hi guys

I have been using blat 2.6.2. for many years. Now I tried to use the newest
version 3.1.1 and have got big problems with national Czech characters.
On my Windows there is Windows-1250 and when I use blat, everytime the
received e-mail has national characters improperly shown.
It looks like blat now does some defult conversion/translation, but does it
probably improperly and that DLL version works differently from EXE version.
Could you please write me, how to use blat.dll correctly to send e-mail with
national characters?

Vladimir


Details:
I tested it with test text with Czech characters: "Test nastavení:
ěščřžýáíé" (if you can't see the national characters, the text is "Test
nastaveni(i acute,237,0xED): e(e caron,236,0xEC)s(s caron,154,0x9A)c(c
caron,232,0xE8)r(r caron,248,0xF8)z(z caron,158,9E)y(y acute,253,0xFD)a(a
acute,225,0xE1)i(i acute)e(e acute,233,OxE9)"). You can see details on
Windows-1250 code page e.g. on http://en.wikipedia.org/wiki/Windows-1250 or
http://msdn.microsoft.com/en-us/library/cc195052.aspx.
When converted to UTF-8 this text looks like this:
EFBBBF54657374206E6173746176656EC3AD3A20C49BC5A1C48DC599C5BEC3BDC3A1C3ADC3A9

I am using blat.dll called directly from application.

1) When I do not use the -charset option and send this parameter to
blat.dll:
- -server smtp.seznam.cz -hdrencq -log
"C:\TEMP\test\email.log" -overwritelog -superdebug -priority 1 -u
***@... -pw **** -f "V.H. <***@...>" -to "***@..." -subject "Test
nastavení: ěščřžýáíé" -body "Test nastavení: ěščřžýáíé"

then in log is this text:
superDebug: 00150 53 75 62 6A 65 63 74 3A 20 3D 3F 55 54 46 2D 38 Subject:
=?UTF-8
superDebug: 00160 3F 51 3F 54 65 73 74 5F 6E 61 73 74 61 76 65 6E
?Q?Test_nastaven
superDebug: 00170 3D 43 33 3D 39 44 3D 33 41 3F 3D 0D 0A 20 3D 3F
=C3=9D=3A?=.. =?
superDebug: 00180 55 54 46 2D 38 3F 51 3F 5F 3D 43 33 3D 42 44 3D
UTF-8?Q?_=C3=BD=
superDebug: 00190 43 33 3D 39 43 3D 43 35 3D 39 34 3D 43 32 3D 42
C3=9C=C5=94=C2=B
superDebug: 001A0 30 3D 43 33 3D 39 37 3D 43 35 3D 39 39 3D 43 33
0=C3=97=C5=99=C3
superDebug: 001B0 3D 39 46 3D 43 33 3D 39 44 3D 43 33 3D 39 41 3F
=9F=C3=9D=C3=9A?
superDebug: 001C0 3D 0D 0A 4D 49 4D 45 2D 56 65 72 73 69 6F 6E 3A
=..MIME-Version:
superDebug: 001D0 20 31 2E 30 0D 0A 43 6F 6E 74 65 6E 74 2D 54 72
1.0..Content-Tr
superDebug: 001E0 61 6E 73 66 65 72 2D 45 6E 63 6F 64 69 6E 67 3A
ansfer-Encoding:
superDebug: 001F0 20 71 75 6F 74 65 64 2D 70 72 69 6E 74 61 62 6C
quoted-printabl
superDebug: 00200 65 0D 0A 43 6F 6E 74 65 6E 74 2D 54 79 70 65 3A
e..Content-Type:
superDebug: 00210 20 74 65 78 74 2F 70 6C 61 69 6E 3B 0D 0A 20 63
text/plain;.. c
superDebug: 00220 68 61 72 73 65 74 3D 22 55 54 46 2D 38 22 0D 0A
harset="UTF-8"..
superDebug: 00230 0D 0A 54 65 73 74 20 6E 61 73 74 61 76 65 6E C3 ..Test
nastaven.
superDebug: 00240 9D 3A 20 C3 BD C3 9C C5 94 C2 B0 C3 97 C5 99 C3 .:
.............
superDebug: 00250 9F C3 9D C3 9A 0D 0A 2E 0D 0A
..........

2)When I use -charset Windows-1250 and send this parameter to blat.dll:
- -server smtp.seznam.cz -charset Windows-1250 -hdrencq -log
"C:\TEMP\test\email.log" -overwritelog -superdebug -priority 1 -u
***@... -pw **** -f "V.H. <***@...>" -to "***@..." -subject "Test
nastavení: ěščřžýáíé" -body "Test nastavení: ěščřžýáíé"

then in log is this text:
superDebug: 00140 34 36 40 73 65 7A 6E 61 6D 2E 63 7A 3E 0D 0A 53
***@seznam.cz>..S
superDebug: 00150 75 62 6A 65 63 74 3A 20 3D 3F 55 54 46 2D 38 3F ubject:
=?UTF-8?
superDebug: 00160 51 3F 54 65 73 74 5F 6E 61 73 74 61 76 65 6E 3D
Q?Test_nastaven=
superDebug: 00170 43 33 3D 39 44 3D 33 41 3F 3D 0D 0A 20 3D 3F 55
C3=9D=3A?=.. =?U
superDebug: 00180 54 46 2D 38 3F 51 3F 5F 3D 43 33 3D 42 44 3D 43
TF-8?Q?_=C3=BD=C
superDebug: 00190 33 3D 39 43 3D 43 35 3D 39 34 3D 43 32 3D 42 30
3=9C=C5=94=C2=B0
superDebug: 001A0 3D 43 33 3D 39 37 3D 43 35 3D 39 39 3D 43 33 3D
=C3=97=C5=99=C3=
superDebug: 001B0 39 46 3D 43 33 3D 39 44 3D 43 33 3D 39 41 3F 3D
9F=C3=9D=C3=9A?=
superDebug: 001C0 0D 0A 4D 49 4D 45 2D 56 65 72 73 69 6F 6E 3A 20
..MIME-Version:
superDebug: 001D0 31 2E 30 0D 0A 43 6F 6E 74 65 6E 74 2D 54 72 61
1.0..Content-Tra
superDebug: 001E0 6E 73 66 65 72 2D 45 6E 63 6F 64 69 6E 67 3A 20
nsfer-Encoding:
superDebug: 001F0 71 75 6F 74 65 64 2D 70 72 69 6E 74 61 62 6C 65
quoted-printable
superDebug: 00200 0D 0A 43 6F 6E 74 65 6E 74 2D 54 79 70 65 3A 20
..Content-Type:
superDebug: 00210 74 65 78 74 2F 70 6C 61 69 6E 3B 0D 0A 20 63 68
text/plain;.. ch
superDebug: 00220 61 72 73 65 74 3D 22 57 49 4E 44 4F 57 53 2D 31
arset="WINDOWS-1
superDebug: 00230 32 35 30 22 0D 0A 0D 0A 54 65 73 74 20 6E 61 73
250"....Test nas
superDebug: 00240 74 61 76 65 6E C3 9D 3A 20 C3 BD C3 9C C5 94 C2 taven..:
.......
superDebug: 00250 B0 C3 97 C5 99 C3 9F C3 9D C3 9A 0D 0A 2E 0D 0A
................

3)When I use -charset UTF-8 and send this parameter to blat.dll:
- -server smtp.seznam.cz -charset UTF-8 -hdrencq -log
"C:\TEMP\test\email.log" -overwritelog -superdebug -priority 1 -u
***@... -pw **** -f "V.H. <***@...>" -to "***@..." -subject "Test
nastavení: ěščřžýáíé" -body "Test nastavení: ěščřžýáíé"

then in log is this text:
superDebug: 00150 53 75 62 6A 65 63 74 3A 20 3D 3F 55 54 46 2D 38 Subject:
=?UTF-8
superDebug: 00160 3F 51 3F 54 65 73 74 5F 6E 61 73 74 61 76 65 6E
?Q?Test_nastaven
superDebug: 00170 3D 43 33 3D 39 44 3D 33 41 3F 3D 0D 0A 20 3D 3F
=C3=9D=3A?=.. =?
superDebug: 00180 55 54 46 2D 38 3F 51 3F 5F 3D 43 33 3D 42 44 3D
UTF-8?Q?_=C3=BD=
superDebug: 00190 43 33 3D 39 43 3D 43 35 3D 39 34 3D 43 32 3D 42
C3=9C=C5=94=C2=B
superDebug: 001A0 30 3D 43 33 3D 39 37 3D 43 35 3D 39 39 3D 43 33
0=C3=97=C5=99=C3
superDebug: 001B0 3D 39 46 3D 43 33 3D 39 44 3D 43 33 3D 39 41 3F
=9F=C3=9D=C3=9A?
superDebug: 001C0 3D 0D 0A 4D 49 4D 45 2D 56 65 72 73 69 6F 6E 3A
=..MIME-Version:
superDebug: 001D0 20 31 2E 30 0D 0A 43 6F 6E 74 65 6E 74 2D 54 72
1.0..Content-Tr
superDebug: 001E0 61 6E 73 66 65 72 2D 45 6E 63 6F 64 69 6E 67 3A
ansfer-Encoding:
superDebug: 001F0 20 71 75 6F 74 65 64 2D 70 72 69 6E 74 61 62 6C
quoted-printabl
superDebug: 00200 65 0D 0A 43 6F 6E 74 65 6E 74 2D 54 79 70 65 3A
e..Content-Type:
superDebug: 00210 20 74 65 78 74 2F 70 6C 61 69 6E 3B 0D 0A 20 63
text/plain;.. c
superDebug: 00220 68 61 72 73 65 74 3D 22 55 54 46 2D 38 22 0D 0A
harset="UTF-8"..
superDebug: 00230 0D 0A 54 65 73 74 20 6E 61 73 74 61 76 65 6E C3 ..Test
nastaven.
superDebug: 00240 9D 3A 20 C3 BD C3 9C C5 94 C2 B0 C3 97 C5 99 C3 .:
.............
superDebug: 00250 9F C3 9D C3 9A 0D 0A 2E 0D 0A
..........

4) And even when I convert the input subject and body into UTF-8 format:
- -server smtp.seznam.cz -charset UTF-8 -hdrencq -log
"C:\TEMP\test\email.log" -overwritelog -superdebug -priority 1 -u
***@... -pw **** -f "V.H. <***@...>" -to "***@..." -subject "Test
nastavenĂ­: Ä>ščĹTžýáíĂC" -body "Test nastavenĂ­: Ä>ščĹTžýáíĂC"

then in log there is:
superDebug: 00150 53 75 62 6A 65 63 74 3A 20 3D 3F 55 54 46 2D 38 Subject:
=?UTF-8
superDebug: 00160 3F 51 3F 54 65 73 74 5F 6E 61 73 74 61 76 65 6E
?Q?Test_nastaven
superDebug: 00170 3D 45 32 3D 39 34 3D 39 43 3D 43 35 3D 39 46 3D
=E2=94=9C=C5=9F=
superDebug: 00180 33 41 3F 3D 0D 0A 20 3D 3F 55 54 46 2D 38 3F 51 3A?=..
=?UTF-8?Q
superDebug: 00190 3F 5F 3D 45 32 3D 39 34 3D 38 30 3D 43 35 3D 41
?_=E2=94=80=C5=A
superDebug: 001A0 34 3D 45 32 3D 39 34 3D 42 43 3D 43 33 3D 41 44
4=E2=94=BC=C3=AD
superDebug: 001B0 3D 45 32 3D 39 34 3D 38 30 3D 43 35 3D 42 39 3D
=E2=94=80=C5=B9=
superDebug: 001C0 45 32 3D 39 34 3D 42 43 3D 43 33 3D 39 36 3D 45
E2=94=BC=C3=96=E
superDebug: 001D0 32 3F 3D 0D 0A 20 3D 3F 55 54 46 2D 38 3F 51 3F 2?=..
=?UTF-8?Q?
superDebug: 001E0 3D 39 34 3D 42 43 3D 43 35 3D 42 43 3D 45 32 3D
=94=BC=C5=BC=E2=
superDebug: 001F0 39 34 3D 39 43 3D 43 35 3D 42 42 3D 45 32 3D 39
94=9C=C5=BB=E2=9
superDebug: 00200 34 3D 39 43 3D 43 33 3D 41 44 3D 45 32 3D 39 34
4=9C=C3=AD=E2=94
superDebug: 00210 3D 39 43 3D 43 35 3D 39 46 3D 45 32 3D 39 34 3F
=9C=C5=9F=E2=94?
superDebug: 00220 3D 0D 0A 20 3D 3F 55 54 46 2D 38 3F 51 3F 3D 39 =..
=?UTF-8?Q?=9
superDebug: 00230 43 3D 43 34 3D 39 39 3F 3D 0D 0A 4D 49 4D 45 2D
C=C4=99?=..MIME-
superDebug: 00240 56 65 72 73 69 6F 6E 3A 20 31 2E 30 0D 0A 43 6F Version:
1.0..Co
superDebug: 00250 6E 74 65 6E 74 2D 54 72 61 6E 73 66 65 72 2D 45
ntent-Transfer-E
superDebug: 00260 6E 63 6F 64 69 6E 67 3A 20 71 75 6F 74 65 64 2D ncoding:
quoted-
superDebug: 00270 70 72 69 6E 74 61 62 6C 65 0D 0A 43 6F 6E 74 65
printable..Conte
superDebug: 00280 6E 74 2D 54 79 70 65 3A 20 74 65 78 74 2F 70 6C nt-Type:
text/pl
superDebug: 00290 61 69 6E 3B 0D 0A 20 63 68 61 72 73 65 74 3D 22 ain;..
charset="
superDebug: 002A0 55 54 46 2D 38 22 0D 0A 0D 0A 54 65 73 74 20 6E
UTF-8"....Test n
superDebug: 002B0 61 73 74 61 76 65 6E E2 94 9C C5 9F 3A 20 E2 94
astaven.....: ..
superDebug: 002C0 80 C5 A4 E2 94 BC C3 AD E2 94 80 C5 B9 E2 94 BC
................
superDebug: 002D0 C3 96 E2 94 BC C5 BC E2 94 9C C5 BB E2 94 9C C3
................
superDebug: 002E0 AD E2 94 9C C5 9F E2 94 9C C4 99 0D 0A 2E 0D 0A
................

5) Using the same parameter like in point 2) but with BLAT.EXE (that is
WITH -charset Windows-1250 parameter) in command line window (CMD.EXE)
outputs the e-mail that has correctly coded only Subject, but incorrectly
coded Body.
Command:
C:\temp\blat\3.1.1\full>blat - -server smtp.seznam.cz -charset
Windows-1250 -hdrencq -log
"C:\TEMP\test\email.log" -overwritelog -superdebug -priority 1 -u
***@... -pw **** -f "V.H. <***@...>" -to "***@..." -subject "Test
nastavení: ěščřžýáíé" -body "Test nastavení: ěščřžýáíé"

Part of log:
superDebug: 00140 66 36 40 73 65 7A 6E 61 6D 2E 63 7A 3E 0D 0A 53
***@seznam.cz>..S
superDebug: 00150 75 62 6A 65 63 74 3A 20 3D 3F 55 54 46 2D 38 3F ubject:
=?UTF-8?
superDebug: 00160 51 3F 54 65 73 74 5F 6E 61 73 74 61 76 65 6E 3D
Q?Test_nastaven=
superDebug: 00170 43 33 3D 41 44 3D 33 41 3F 3D 0D 0A 20 3D 3F 55
C3=AD=3A?=.. =?U
superDebug: 00180 54 46 2D 38 3F 51 3F 5F 3D 43 34 3D 39 42 3D 43
TF-8?Q?_=C4=9B=C
superDebug: 00190 35 3D 41 31 3D 43 34 3D 38 44 3D 43 35 3D 39 39
5=A1=C4=8D=C5=99
superDebug: 001A0 3D 43 35 3D 42 45 3D 43 33 3D 42 44 3D 43 33 3D
=C5=BE=C3=BD=C3=
superDebug: 001B0 41 31 3D 43 33 3D 41 44 3D 43 33 3D 41 39 3F 3D
A1=C3=AD=C3=A9?=
superDebug: 001C0 0D 0A 4D 49 4D 45 2D 56 65 72 73 69 6F 6E 3A 20
..MIME-Version:
superDebug: 001D0 31 2E 30 0D 0A 43 6F 6E 74 65 6E 74 2D 54 72 61
1.0..Content-Tra
superDebug: 001E0 6E 73 66 65 72 2D 45 6E 63 6F 64 69 6E 67 3A 20
nsfer-Encoding:
superDebug: 001F0 71 75 6F 74 65 64 2D 70 72 69 6E 74 61 62 6C 65
quoted-printable
superDebug: 00200 0D 0A 43 6F 6E 74 65 6E 74 2D 54 79 70 65 3A 20
..Content-Type:
superDebug: 00210 74 65 78 74 2F 70 6C 61 69 6E 3B 0D 0A 20 63 68
text/plain;.. ch
superDebug: 00220 61 72 73 65 74 3D 22 57 49 4E 44 4F 57 53 2D 31
arset="WINDOWS-1
superDebug: 00230 32 35 30 22 0D 0A 0D 0A 54 65 73 74 20 6E 61 73
250"....Test nas
superDebug: 00240 74 61 76 65 6E C3 AD 3A 20 C4 9B C5 A1 C4 8D C5 taven..:
.......
superDebug: 00250 99 C5 BE C3 BD C3 A1 C3 AD C3 A9 0D 0A 2E 0D 0A
................


6) Using the same parameter like in point 1) but with BLAT.EXE (that is
WITHOUT -charset parameter) or in point 3) (i.e. WITH -charset UTF-8
parameter) in command line window (CMD.EXE) outputs the fully correct
e-mail. These are the only two methods how to output correct e-mail with
national letters.
Command:
C:\temp\blat\3.1.1\full>blat - -server smtp.seznam.cz -hdrencq -log
"C:\TEMP\test\email.log" -overwritelog -superdebug -priority 1 -u
***@... -pw **** -f "V.H. <***@...>" -to "***@..." -subject "Test
nastavení: ěščřžýáíé" -body "Test nastavení: ěščřžýáíé"

Part of log:
superDebug: 00140 34 32 40 73 65 7A 6E 61 6D 2E 63 7A 3E 0D 0A 53
***@seznam.cz>..S
superDebug: 00150 75 62 6A 65 63 74 3A 20 3D 3F 55 54 46 2D 38 3F ubject:
=?UTF-8?
superDebug: 00160 51 3F 54 65 73 74 5F 6E 61 73 74 61 76 65 6E 3D
Q?Test_nastaven=
superDebug: 00170 43 33 3D 41 44 3D 33 41 3F 3D 0D 0A 20 3D 3F 55
C3=AD=3A?=.. =?U
superDebug: 00180 54 46 2D 38 3F 51 3F 5F 3D 43 34 3D 39 42 3D 43
TF-8?Q?_=C4=9B=C
superDebug: 00190 35 3D 41 31 3D 43 34 3D 38 44 3D 43 35 3D 39 39
5=A1=C4=8D=C5=99
superDebug: 001A0 3D 43 35 3D 42 45 3D 43 33 3D 42 44 3D 43 33 3D
=C5=BE=C3=BD=C3=
superDebug: 001B0 41 31 3D 43 33 3D 41 44 3D 43 33 3D 41 39 3F 3D
A1=C3=AD=C3=A9?=
superDebug: 001C0 0D 0A 4D 49 4D 45 2D 56 65 72 73 69 6F 6E 3A 20
..MIME-Version:
superDebug: 001D0 31 2E 30 0D 0A 43 6F 6E 74 65 6E 74 2D 54 72 61
1.0..Content-Tra
superDebug: 001E0 6E 73 66 65 72 2D 45 6E 63 6F 64 69 6E 67 3A 20
nsfer-Encoding:
superDebug: 001F0 71 75 6F 74 65 64 2D 70 72 69 6E 74 61 62 6C 65
quoted-printable
superDebug: 00200 0D 0A 43 6F 6E 74 65 6E 74 2D 54 79 70 65 3A 20
..Content-Type:
superDebug: 00210 74 65 78 74 2F 70 6C 61 69 6E 3B 0D 0A 20 63 68
text/plain;.. ch
superDebug: 00220 61 72 73 65 74 3D 22 55 54 46 2D 38 22 0D 0A 0D
arset="UTF-8"...
superDebug: 00230 0A 54 65 73 74 20 6E 61 73 74 61 76 65 6E C3 AD .Test
nastaven..
superDebug: 00240 3A 20 C4 9B C5 A1 C4 8D C5 99 C5 BE C3 BD C3 A1 :
..............
superDebug: 00250 C3 AD C3 A9 0D 0A 2E 0D 0A
.........




------------------------------------
--
Homepage:
http://www.blat.net
Chip
2013-12-27 21:35:02 UTC
Permalink
<big snip>

I believe that I have this solved with the next version. The issue appears
to be only in the DLL. I found another tiny issue moments ago when I tested
the dll with your message, and I am currently building the next two versions
to be released today.

Chip



------------------------------------
--
Homepage:
http://www.blat.net
Vladimír Horský
2013-12-28 06:46:58 UTC
Permalink
OK, Chip.
I will try to test it immediatelly as you will prepare it.
If you want you can send me the newer version for testing before releasing
it for public use.

Regards

Vladimir


---------- Původní zpráva ----------
Od: Chip <***@att.net>
Datum: 27. 12. 2013
Předmět: Re: [blat] Character set, code page conversion problem

"<big snip>

I believe that I have this solved with the next version. The issue appears
to be only in the DLL. I found another tiny issue moments ago when I tested
the dll with your message, and I am currently building the next two versions

to be released today.

Chip



------------------------------------
--
Homepage:
http://www.blat.net

</body>

<!--~-|**|PrettyHtmlStart|**|-~-->
<head>
<style type="text/css">
<!--
#ygrp-mkp {
border: 1px solid #d8d8d8;
font-family: Arial;
margin: 10px 0;
padding: 0 10px;
}

#ygrp-mkp hr {
border: 1px solid #d8d8d8;
}

#ygrp-mkp #hd {
color: #628c2a;
font-size: 85%;
font-weight: 700;
line-height: 122%;
margin: 10px 0;
}

#ygrp-mkp #ads {
margin-bottom: 10px;
}

#ygrp-mkp .ad {
padding: 0 0;
}

#ygrp-mkp .ad p {
margin: 0;
}

#ygrp-mkp .ad a {
color: #0000ff;
text-decoration: none;
}
#ygrp-sponsor #ygrp-lc {
font-family: Arial;
}

#ygrp-sponsor #ygrp-lc #hd {
margin: 10px 0px;
font-weight: 700;
font-size: 78%;
line-height: 122%;
}

#ygrp-sponsor #ygrp-lc .ad {
margin-bottom: 10px;
padding: 0 0;
}

#actions {
font-family: Verdana;
font-size: 11px;
padding: 10px 0;
}

#activity {
background-color: #e0ecee;
float: left;
font-family: Verdana;
font-size: 10px;
padding: 10px;
}

#activity span {
font-weight: 700;
}

#activity span:first-child {
text-transform: uppercase;
}

#activity span a {
color: #5085b6;
text-decoration: none;
}

#activity span span {
color: #ff7900;
}

#activity span .underline {
text-decoration: underline;
}

.attach {
clear: both;
display: table;
font-family: Arial;
font-size: 12px;
padding: 10px 0;
width: 400px;
}

.attach div a {
text-decoration: none;
}

.attach img {
border: none;
padding-right: 5px;
}

.attach label {
display: block;
margin-bottom: 5px;
}

.attach label a {
text-decoration: none;
}

blockquote {
margin: 0 0 0 4px;
}

.bold {
font-family: Arial;
font-size: 13px;
font-weight: 700;
}

.bold a {
text-decoration: none;
}

dd.last p a {
font-family: Verdana;
font-weight: 700;
}

dd.last p span {
margin-right: 10px;
font-family: Verdana;
font-weight: 700;
}

dd.last p span.yshortcuts {
margin-right: 0;
}

div.attach-table div div a {
text-decoration: none;
}

div.attach-table {
width: 400px;
}

div.file-title a, div.file-title a:active, div.file-title a:hover, div.file-title a:visited {
text-decoration: none;
}

div.photo-title a, div.photo-title a:active, div.photo-title a:hover, div.photo-title a:visited {
text-decoration: none;
}

div#ygrp-mlmsg #ygrp-msg p a span.yshortcuts {
font-family: Verdana;
font-size: 10px;
font-weight: normal;
}

.green {
color: #628c2a;
}

.MsoNormal {
margin: 0 0 0 0;
}

o {
font-size: 0;
}

#photos div {
float: left;
width: 72px;
}

#photos div div {
border: 1px solid #666666;
height: 62px;
overflow: hidden;
width: 62px;
}

#photos div label {
color: #666666;
font-size: 10px;
overflow: hidden;
text-align: center;
white-space: nowrap;
width: 64px;
}

#reco-category {
font-size: 77%;
}

#reco-desc {
font-size: 77%;
}

.replbq {
margin: 4px;
}

#ygrp-actbar div a:first-child {
/* border-right: 0px solid #000;*/
margin-right: 2px;
padding-right: 5px;
}

#ygrp-mlmsg {
font-size: 13px;
font-family: Arial, helvetica,clean, sans-serif;
*font-size: small;
*font: x-small;
}

#ygrp-mlmsg table {
font-size: inherit;
font: 100%;
}

#ygrp-mlmsg select, input, textarea {
font: 99% Arial, Helvetica, clean, sans-serif;
}

#ygrp-mlmsg pre, code {
font:115% monospace;
*font-size:100%;
}

#ygrp-mlmsg * {
line-height: 1.22em;
}

#ygrp-mlmsg #logo {
padding-bottom: 10px;
}


#ygrp-msg p a {
font-family: Verdana;
}

#ygrp-msg p#attach-count span {
color: #1E66AE;
font-weight: 700;
}

#ygrp-reco #reco-head {
color: #ff7900;
font-weight: 700;
}

#ygrp-reco {
margin-bottom: 20px;
padding: 0px;
}

#ygrp-sponsor #ov li a {
font-size: 130%;
text-decoration: none;
}

#ygrp-sponsor #ov li {
font-size: 77%;
list-style-type: square;
padding: 6px 0;
}

#ygrp-sponsor #ov ul {
margin: 0;
padding: 0 0 0 8px;
}

#ygrp-text {
font-family: Georgia;
}

#ygrp-text p {
margin: 0 0 1em 0;
}

#ygrp-text tt {
font-size: 120%;
}

#ygrp-vital ul li:last-child {
border-right: none !important;
}
-->
</style>
</head>

<!--~-|**|PrettyHtmlEnd|**|-~-->
</html>
<!-- end group email -->
Vladimír Horský
2013-12-28 16:32:36 UTC
Permalink
Hello Chip

I tested the version 3.1.2 and it looks the DLL version now works the same
as EXE version. Thanks.

But still have one question.
When I use this format (where body text is contained inside file):
blat.exe "C:\temp\Text_in_CP852.txt" ... -charset CP852 ...
where Text_in_CP852.txt contains text in code page 852, or similar
blat.exe "C:\temp\Text_in_Win1250.txt" ... -charset Windows-1250 ...
it works correctly.

But when I use format, where body text is specified with option parameter -
body
blat.exe - -charset CP852 ... -body "Some text in code page 852" ...
or
blat.exe - -charset Windows-1250 ... -body "Some text in code page 1250" ...
then it looks the text inside body option is properly converted to UTF-8
format but is in final message prepended with 'Content-Type: ... charset="CP
852" ' (or 'Content-Type: ... charset="Windows-1250" ' in second case) and
this is not correct as mail reader tries to show UTF-8 formatted text in
improper character set.

By me the text inside -body option should not be converted to UTF-8 (in
contrast to other parameters like -to, -subject,..., that are correctly
converted to UTF-8 even with =?UTF-8? introduction although different char
set specified). Is not it?

Regards

Vladimir


---------- Původní zpráva ----------
Od: Chip <***@att.net>
Datum: 27. 12. 2013
Předmět: Re: [blat] Character set, code page conversion problem

"<big snip>

I believe that I have this solved with the next version. The issue appears
to be only in the DLL. I found another tiny issue moments ago when I tested
the dll with your message, and I am currently building the next two versions

to be released today.

Chip



------------------------------------
--
Homepage:
http://www.blat.net

</body>

<!--~-|**|PrettyHtmlStart|**|-~-->
<head>
<style type="text/css">
<!--
#ygrp-mkp {
border: 1px solid #d8d8d8;
font-family: Arial;
margin: 10px 0;
padding: 0 10px;
}

#ygrp-mkp hr {
border: 1px solid #d8d8d8;
}

#ygrp-mkp #hd {
color: #628c2a;
font-size: 85%;
font-weight: 700;
line-height: 122%;
margin: 10px 0;
}

#ygrp-mkp #ads {
margin-bottom: 10px;
}

#ygrp-mkp .ad {
padding: 0 0;
}

#ygrp-mkp .ad p {
margin: 0;
}

#ygrp-mkp .ad a {
color: #0000ff;
text-decoration: none;
}
#ygrp-sponsor #ygrp-lc {
font-family: Arial;
}

#ygrp-sponsor #ygrp-lc #hd {
margin: 10px 0px;
font-weight: 700;
font-size: 78%;
line-height: 122%;
}

#ygrp-sponsor #ygrp-lc .ad {
margin-bottom: 10px;
padding: 0 0;
}

#actions {
font-family: Verdana;
font-size: 11px;
padding: 10px 0;
}

#activity {
background-color: #e0ecee;
float: left;
font-family: Verdana;
font-size: 10px;
padding: 10px;
}

#activity span {
font-weight: 700;
}

#activity span:first-child {
text-transform: uppercase;
}

#activity span a {
color: #5085b6;
text-decoration: none;
}

#activity span span {
color: #ff7900;
}

#activity span .underline {
text-decoration: underline;
}

.attach {
clear: both;
display: table;
font-family: Arial;
font-size: 12px;
padding: 10px 0;
width: 400px;
}

.attach div a {
text-decoration: none;
}

.attach img {
border: none;
padding-right: 5px;
}

.attach label {
display: block;
margin-bottom: 5px;
}

.attach label a {
text-decoration: none;
}

blockquote {
margin: 0 0 0 4px;
}

.bold {
font-family: Arial;
font-size: 13px;
font-weight: 700;
}

.bold a {
text-decoration: none;
}

dd.last p a {
font-family: Verdana;
font-weight: 700;
}

dd.last p span {
margin-right: 10px;
font-family: Verdana;
font-weight: 700;
}

dd.last p span.yshortcuts {
margin-right: 0;
}

div.attach-table div div a {
text-decoration: none;
}

div.attach-table {
width: 400px;
}

div.file-title a, div.file-title a:active, div.file-title a:hover, div.file-title a:visited {
text-decoration: none;
}

div.photo-title a, div.photo-title a:active, div.photo-title a:hover, div.photo-title a:visited {
text-decoration: none;
}

div#ygrp-mlmsg #ygrp-msg p a span.yshortcuts {
font-family: Verdana;
font-size: 10px;
font-weight: normal;
}

.green {
color: #628c2a;
}

.MsoNormal {
margin: 0 0 0 0;
}

o {
font-size: 0;
}

#photos div {
float: left;
width: 72px;
}

#photos div div {
border: 1px solid #666666;
height: 62px;
overflow: hidden;
width: 62px;
}

#photos div label {
color: #666666;
font-size: 10px;
overflow: hidden;
text-align: center;
white-space: nowrap;
width: 64px;
}

#reco-category {
font-size: 77%;
}

#reco-desc {
font-size: 77%;
}

.replbq {
margin: 4px;
}

#ygrp-actbar div a:first-child {
/* border-right: 0px solid #000;*/
margin-right: 2px;
padding-right: 5px;
}

#ygrp-mlmsg {
font-size: 13px;
font-family: Arial, helvetica,clean, sans-serif;
*font-size: small;
*font: x-small;
}

#ygrp-mlmsg table {
font-size: inherit;
font: 100%;
}

#ygrp-mlmsg select, input, textarea {
font: 99% Arial, Helvetica, clean, sans-serif;
}

#ygrp-mlmsg pre, code {
font:115% monospace;
*font-size:100%;
}

#ygrp-mlmsg * {
line-height: 1.22em;
}

#ygrp-mlmsg #logo {
padding-bottom: 10px;
}


#ygrp-msg p a {
font-family: Verdana;
}

#ygrp-msg p#attach-count span {
color: #1E66AE;
font-weight: 700;
}

#ygrp-reco #reco-head {
color: #ff7900;
font-weight: 700;
}

#ygrp-reco {
margin-bottom: 20px;
padding: 0px;
}

#ygrp-sponsor #ov li a {
font-size: 130%;
text-decoration: none;
}

#ygrp-sponsor #ov li {
font-size: 77%;
list-style-type: square;
padding: 6px 0;
}

#ygrp-sponsor #ov ul {
margin: 0;
padding: 0 0 0 8px;
}

#ygrp-text {
font-family: Georgia;
}

#ygrp-text p {
margin: 0 0 1em 0;
}

#ygrp-text tt {
font-size: 120%;
}

#ygrp-vital ul li:last-child {
border-right: none !important;
}
-->
</style>
</head>

<!--~-|**|PrettyHtmlEnd|**|-~-->
</html>
<!-- end group email -->
Chip
2013-12-29 02:49:42 UTC
Permalink
Post by Vladimír Horský
Hello Chip
I tested the version 3.1.2 and it looks the DLL version now works the same as EXE version. Thanks.
But still have one question.
blat.exe "C:\temp\Text_in_CP852.txt" ... -charset CP852 ...
where Text_in_CP852.txt contains text in code page 852, or similar
blat.exe "C:\temp\Text_in_Win1250.txt" ... -charset Windows-1250 ...
it works correctly.
But when I use format, where body text is specified with option parameter -body
blat.exe - -charset CP852 ... -body "Some text in code page 852" ...
or
blat.exe - -charset Windows-1250 ... -body "Some text in code page 1250" ...
then it looks the text inside body option is properly converted to UTF-8 format but is in final message prepended with 'Content-Type: ... charset="CP852" ' (or 'Content-Type: ... charset="Windows-1250" ' in second case) and this is not correct as mail reader tries to show UTF-8 formatted text in improper character set.
By me the text inside -body option should not be converted to UTF-8 (in contrast to other parameters like -to, -subject,..., that are correctly converted to UTF-8 even with =?UTF-8? introduction although different char set specified). Is not it?
Regards
Vladimir,

If the message body is specified on the command line, or if the message body comes from a Unicode encoded file, then –charset should not be necessary because the data itself is already in Unicode format. Unicode format is intended to be character set independent; whether it truly is or not, I don’t know.
If the message body comes from an ANSI formatted text file, then –charset is needed when that character set is not ANSI.
If you use the .DLL to send messages, then –charset may or may not be necessary. A lot depends on your own code, whether your code uses 16-bit characters (wchar) or 8-bit characters (char), and if you call the SendW() or SendA() entry points in the .DLL. If your program is Unicode aware, using 16-bit characters, then you should be calling the SendW() routine, and you may not need to specify –charset. Calling the SendA() routine ought to require the –charset option.
Hope this helps, but I would be curious to know how accurate this information is for your usage.
Chip
Vladimír Horský
2013-12-29 13:28:07 UTC
Permalink
Hi Chip

I am using Visual FoxPro that is older system using 8-bit chars.
When I want to send email in different code page I prepared predefined texts
in files (in appropriate code pade or in UTF-8). Content of this file I read
into variables and tries to send it via blat. So that I have in variable
text formated in UTF-8. And supposed when I use blat format:
        DECLARE INTEGER "Send" IN ("blat.dll") AS BlatSend STRING blatstring
        lnRet=BlatSend('- -server smtp.seznam.cz -charset UTF-8 ...... -body
"'+lcTxt+'"')
that the blat will interpret the text in parameter -body as text formated in
UTF-8.
But it looks the text is supposed in system default code page, converted
(again) into UTF-8 and then send.

How to use BLAT to send email body in different code page from nonunicode
application?

The only method it looks work is to copy content of variable into temporary
file and then use this BLAT format:
        lnRet=BlatSend('C:\temp\tempfile.txt -server smtp.seznam.cz ......')

Vladimir



---------- Původní zpráva ----------
Od: Chip <***@att.net>
Datum: 29. 12. 2013
Předmět: Re: [blat] Character set, code page conversion problem

"
 









Vladimir,




If the message body is specified on the command line, or if the message body
comes from a Unicode encoded file, then –charset should not be necessary
because the data itself is already in Unicode format.  Unicode format is
intended to be character set independent; whether it truly is or not, I don’
t know.



 



If the message body comes from an ANSI formatted text file, then –charset is
needed when that character set is not ANSI.



 



If you use the .DLL to send messages, then –charset may or may not be
necessary.  A lot depends on your own code, whether your code uses 16-bit
characters (wchar) or 8-bit characters (char), and if you call the SendW()
or SendA() entry points in the .DLL.  If your program is Unicode aware,
using 16-bit characters, then you should be calling the SendW() routine, and
you may not need to specify –charset.  Calling the SendA() routine ought to
require the –charset option.



 



Hope this helps, but I would be curious to know how accurate this
information is for your usage.



 



Chip








Community email addresses:
  Post message: ***@yahoogroups.com
  Subscribe:    blat-***@yahoogroups.com
  Unsubscribe:  blat-***@yahoogroups.com
  List owner:   blat-***@yahoogroups.com



Yahoo! Groups
(http://groups.yahoo.com/;_ylc=X3oDMTJjbmVwbWJ2BF9TAzk3NDc2NTkwBGdycElkAzMxMTEzNwRncnBzcElkAzE3MDUwMDczODkEc2VjA2Z0cgRzbGsDZ2ZwBHN0aW1lAzEzODgyODUzNzk-)

Switch to: Text-Only
(mailto:blat-***@yahoogroups.com?subject=Change Delivery Format: Traditional)
, Daily Digest
(mailto:blat-***@yahoogroups.com?subject=Email Delivery: Digest) •
Unsubscribe(mailto:blat-***@yahoogroups.com?subject=Unsubscribe) •
Terms of Use(http://info.yahoo.com/legal/us/yahoo/utos/terms/) • Send us
Feedback
(mailto:***@yahoogroups.com?subject=Feedback on the redesigned individual mail v1)







.





"=
Chip
2013-12-29 21:38:09 UTC
Permalink
Post by Vladimír Horský
Hi Chip
I am using Visual FoxPro that is older system using 8-bit chars.
DECLARE INTEGER "Send" IN ("blat.dll") AS BlatSend STRING blatstring
lnRet=BlatSend('- -server smtp.seznam.cz -charset UTF-8 ...... -body "'+lcTxt+'"')
that the blat will interpret the text in parameter -body as text formated in UTF-8.
But it looks the text is supposed in system default code page, converted (again) into UTF-8 and then send.
How to use BLAT to send email body in different code page from nonunicode application?
lnRet=BlatSend('C:\temp\tempfile.txt -server smtp.seznam.cz ......')
Vladimir

Have you tried blat.dll for Win98/WinMe? This flavor does not support Unicode, so it might be your best choice with Visual FoxPro. Sorry that I do not have Visual FoxPro to test.

Chip
Mike Mattos
2013-12-29 21:51:56 UTC
Permalink
It isn’t Foxpro that is doing the conversion, rather the windows system call to run the blat dll.



But the suggested fix, ( save the text to a file ) has other advantages from a debugging and logging perspective, and really doesn’t slow things down much.



Mike Mattos



Never attribute to malice that which can be adequately explained by stupidity.

But don't rule out malice.



From: ***@yahoogroups.com [mailto:***@yahoogroups.com] On Behalf Of Chip
Sent: December-29-13 16:38
To: ***@yahoogroups.com
Subject: Re: [blat] Character set, code page conversion problem
Post by Vladimír Horský
Hi Chip
I am using Visual FoxPro that is older system using 8-bit chars.
DECLARE INTEGER "Send" IN ("blat.dll") AS BlatSend STRING blatstring
lnRet=BlatSend('- -server smtp.seznam.cz -charset UTF-8 ...... -body "'+lcTxt+'"')
that the blat will interpret the text in parameter -body as text formated in UTF-8.
But it looks the text is supposed in system default code page, converted (again) into UTF-8 and then send.
How to use BLAT to send email body in different code page from nonunicode application?
lnRet=BlatSend('C:\temp\tempfile.txt -server smtp.seznam.cz ......')
Vladimir

Have you tried blat.dll for Win98/WinMe? This flavor does not support Unicode, so it might be your best choice with Visual FoxPro. Sorry that I do not have Visual FoxPro to test.



Chip







[Non-text portions of this message have been removed]
Vladimír Horský
2013-12-30 13:22:09 UTC
Permalink
Hi guys

Thank you for all your help.
I think all information are sufficient for finishing my job.

So far I have not read about W98 version of the blat. I will try it.
Is there some documentation with differences of various versions (W98/W2K,
32/64,...)?
32-bit version is working on 64-bit Windows. What are the pros for using 64-
bit version of Blat?

Happy New Year

Vladimir


---------- Původní zpráva ----------
Od: Mike Mattos <***@rogers.com>
Datum: 29. 12. 2013
Předmět: RE: [blat] Character set, code page conversion problem

"
 



It isn’t Foxpro that is doing the conversion, rather the windows system call
to run the blat dll.

But the suggested fix, ( save the text to a file ) has other advantages from
a debugging and logging perspective, and really doesn’t slow things down
much.

Mike Mattos

Never attribute to malice that which can be adequately explained by
stupidity.

But don't rule out malice.





"



 
"





Have you tried blat.dll for Win98/WinMe? This flavor does not support
Unicode, so it might be your best choice with Visual FoxPro. Sorry that I do
not have Visual FoxPro to test.

Chip






"=
Skand Bhargava
2013-12-30 22:09:43 UTC
Permalink
Not sure but I feel that if your application from where you are using blat.dll is 64 bit, you will have to use 64 bit blat.dll.

Skand
-----Original Message-----
From: ***@yahoogroups.com [mailto:***@yahoogroups.com]On Behalf Of Vladimír HorskÜ
Sent: 30 December, 2013 5:22 PM
To: ***@yahoogroups.com
Subject: RE: [blat] Character set, code page conversion problem



Hi guys

Thank you for all your help.
I think all information are sufficient for finishing my job.

So far I have not read about W98 version of the blat. I will try it.
Is there some documentation with differences of various versions (W98/W2K, 32/64,...)?
32-bit version is working on 64-bit Windows. What are the pros for using 64-bit version of Blat?

Happy New Year

Vladimir



---------- Původní zpráva ----------
Od: Mike Mattos <***@rogers.com>
Datum: 29. 12. 2013
Předmět: RE: [blat] Character set, code page conversion problem




It isn’t Foxpro that is doing the conversion, rather the windows system call to run the blat dll.

But the suggested fix, ( save the text to a file ) has other advantages from a debugging and logging perspective, and really doesn’t slow things down much.

Mike Mattos

Never attribute to malice that which can be adequately explained by stupidity.

But don't rule out malice.








Have you tried blat.dll for Win98/WinMe? This flavor does not support Unicode, so it might be your best choice with Visual FoxPro. Sorry that I do not have Visual FoxPro to test.

Chip



=
Mike Mattos
2013-12-30 22:50:35 UTC
Permalink
Visual Foxpro is 32 bit in any case. But the conversion is NOT by Foxpro, it is by the operating system and blat. Foxpro is acting only as a scripting language in this instance.



I suspect you would create the same situation with Visual Basic or compiled C code. A variable created in a different character set than the default of the OS will always have issues if passed as a parameter to the OS



Mike Mattos



Never attribute to malice that which can be adequately explained by stupidity.

But don't rule out malice.



From: ***@yahoogroups.com [mailto:***@yahoogroups.com] On Behalf Of Skand Bhargava
Sent: December-30-13 17:10
To: ***@yahoogroups.com
Subject: [Bulk] RE: [blat] Character set, code page conversion problem





Not sure but I feel that if your application from where you are using blat.dll is 64 bit, you will have to use 64 bit blat.dll.



Skand

-----Original Message-----
From: ***@yahoogroups.com [mailto:***@yahoogroups.com]On Behalf Of Vladimír HorskÜ
Sent: 30 December, 2013 5:22 PM
To: ***@yahoogroups.com
Subject: RE: [blat] Character set, code page conversion problem



Hi guys

Thank you for all your help.
I think all information are sufficient for finishing my job.

So far I have not read about W98 version of the blat. I will try it.
Is there some documentation with differences of various versions (W98/W2K, 32/64,...)?
32-bit version is working on 64-bit Windows. What are the pros for using 64-bit version of Blat?

Happy New Year

Vladimir

---------- Původní zpráva ----------
Od: Mike Mattos <***@rogers.com>
Datum: 29. 12. 2013
Předmět: RE: [blat] Character set, code page conversion problem





It isn’t Foxpro that is doing the conversion, rather the windows system call to run the blat dll.

But the suggested fix, ( save the text to a file ) has other advantages from a debugging and logging perspective, and really doesn’t slow things down much.

Mike Mattos

Never attribute to malice that which can be adequately explained by stupidity.

But don't rule out malice.






Have you tried blat.dll for Win98/WinMe? This flavor does not support Unicode, so it might be your best choice with Visual FoxPro. Sorry that I do not have Visual FoxPro to test.

Chip

=





[Non-text portions of this message have been removed]
Chip
2013-12-31 06:43:58 UTC
Permalink
Post by Horský Vladimír
Hi guys
Thank you for all your help.
I think all information are sufficient for finishing my job.
So far I have not read about W98 version of the blat. I will try it.
Is there some documentation with differences of various versions (W98/W2K, 32/64,...)?
32-bit version is working on 64-bit Windows. What are the pros for using 64-bit version of Blat?
Happy New Year
Vladimir,

There is no online documentation that I am aware of which explains the differences. Therefore ---
32-bit Blat for Windows 98 and Windows Me does not support 16-bit Unicode characters, because those versions of Windows do not support it. Windows NT should also lack support for Unicode.
32-bit Blat for Windows 2000 and newer does support Unicode characters. When Blat reads text files, it will check if the file is plain ANSI text or not. If Blat finds a Byte Order Marker (BOM) in the first bytes of the file, Blat will convert the data to Unicode so it can be processed.
64-bit Blat supports Unicode characters, and can run only with 64-bit Windows. If your current or future applications are going to be written for 64-bit, then you will need to use the 64-bit Blat.dll. I do not believe that 32-bit applications can call the 64-bit Blat.dll, nor can 64-bit applications call 32-bit Blat.dll.
If your applications are being compiled for Unicode, then you should use the Unicode version of Blat.dll. If your applications are not being compiled for Unicode, then they will be using 8-bit Multi-Byte Character Set (MBCS) and should probably use the 32-bit Blat for Windows 98/Me.
What are the pros for using 64-bit Blat? For most people, there are no reasons to use a 64-bit Blat.exe or 64-bit Blat.dll. Blat.exe does not need to be 64-bit, because it does not require enough memory to exceed 32-bit memory limitations. Blat.exe and Blat.dll are built from the same source code in the same build process. Since some folks might need a 64-bit Blat.dll, it makes sense for me to build a 64-bit Blat.exe at the same time.
--
Chip
Continue reading on narkive:
Loading...