Discussion:
non-ASCII support
(too old to reply)
Robert Vanyi
2008-10-01 15:01:02 UTC
Permalink
Hi,

I'm just trying to use blat.exe in an internationalized environment,
which means, I may have non-ASCII / non-English characters in the
following strings:

- subject line
- sender email (only local part - domain part uses punycode)
- name of the attachment file
- local hostname (used in HELO)

Is there any chance that these are/will be supported by blat?

Do the RFCs restrict the local part of the sender email address to ASCII?

Thanks in advance,
Robert
Tim Musson
2008-10-01 15:19:23 UTC
Permalink
Hey Robert,

On Wednesday, October 1, 2008 at 11:01:02 AM you wrote

RV> I'm just trying to use blat.exe in an internationalized environment,
RV> which means, I may have non-ASCII / non-English characters in the
RV> following strings:

RV> - subject line
RV> - sender email (only local part - domain part uses punycode)
RV> - name of the attachment file
RV> - local hostname (used in HELO)

RV> Is there any chance that these are/will be supported by blat?

RV> Do the RFCs restrict the local part of the sender email address to ASCII?

If I recall correctly Blat does all that now. If you don't get a
better answer, I would suggest you try it. I don't have an address
with non ASCII chars (which is the only part I am not sure about), so
can't test it...
--
Tim Musson
Flying with The Bat! eMail v3.99.29
Some people are like Slinkies . . . not really good for anything, but
you still can't help but smile when you see one tumble down the
stairs.
Blat Manager, current version is 2.6.2, see www.blat.net
Robert Vanyi
2008-10-01 16:34:22 UTC
Permalink
Hi Tim,
Post by Tim Musson
Hey Robert,
RV> I'm just trying to use blat.exe in an internationalized environment,
RV> which means, I may have non-ASCII / non-English characters in the
RV> - subject line
RV> - sender email (only local part - domain part uses punycode)
RV> - name of the attachment file
RV> - local hostname (used in HELO)
RV> Is there any chance that these are/will be supported by blat?
RV> Do the RFCs restrict the local part of the sender email address to ASCII?
If I recall correctly Blat does all that now. If you don't get a
better answer, I would suggest you try it. I don't have an address
with non ASCII chars (which is the only part I am not sure about), so
can't test it...
C:\ >blat テスト.txt -to ***@...
Blat v2.6.2 w/GSS encryption (build : Feb 25 2007 12:06:19)

unknown error code 123 when trying to open ???.txt

If your mailer doesn't display the filename correctly, it is a
japanese string with three characters:
katakana TE (U+30C6)
katakana SU (U+30B9)
katakana TO (U+30C8)
from this page: http://ja.wikipedia.org/wiki/%E3%83%86%E3%82%B9%E3%83%88

This is a UTF-16 string, which can only be handled correctly, if the
application (in our case blat) has a wmain function. I was browsing
the code, but I could only find a main function, which means every
command-line parameter is converted to the local codepage. However
Japanese characters are not in the English codepage, resulting in
placeholder characters (question marks).

If it is the case, blat won't be able to handle command-line
parameters that are not in the local codepage.

Thanks,
Robert
Tim Musson
2008-10-01 16:52:42 UTC
Permalink
Hey Robert,
Post by Tim Musson
RV> I'm just trying to use blat.exe in an internationalized environment,
RV> which means, I may have non-ASCII / non-English characters in the
C:\>blat ???.txt -to ***@...
RV> Blat v2.6.2 w/GSS encryption (build : Feb 25 2007 12:06:19)

RV> unknown error code 123 when trying to open ???.txt

RV> If your mailer doesn't display the filename correctly, it is a
RV> japanese string with three characters:
RV> katakana TE (U+30C6)
RV> katakana SU (U+30B9)
RV> katakana TO (U+30C8)
RV> from this page:
RV> http://ja.wikipedia.org/wiki/%E3%83%86%E3%82%B9%E3%83%88

RV> This is a UTF-16 string, which can only be handled correctly, if the
RV> application (in our case blat) has a wmain function. I was browsing
RV> the code, but I could only find a main function, which means every
RV> command-line parameter is converted to the local codepage. However
RV> Japanese characters are not in the English codepage, resulting in
RV> placeholder characters (question marks).

My client did display the chars correctly, but I can't send them
without changes...

RV> If it is the case, blat won't be able to handle command-line
RV> parameters that are not in the local codepage.

What does adding -charset UTF-16 to your command line do for you? I am
not sure it will work for you, but I did find it in the list archives.
You can just search for UIT-16 in this lists archive to read the
thread.
--
Tim Musson
Flying with The Bat! eMail v3.99.29
They say you can't have too much of a good thing, wish I'd been part
of that study.
Blat Manager, current version is 2.6.2, see www.blat.net
Robert Vanyi
2008-10-01 17:55:48 UTC
Permalink
Hi Tim,
Post by Tim Musson
Hey Robert,
Post by Tim Musson
RV> I'm just trying to use blat.exe in an internationalized environment,
RV> which means, I may have non-ASCII / non-English characters in the
RV> Blat v2.6.2 w/GSS encryption (build : Feb 25 2007 12:06:19)
RV> unknown error code 123 when trying to open ???.txt
RV> If your mailer doesn't display the filename correctly, it is a
RV> katakana TE (U+30C6)
RV> katakana SU (U+30B9)
RV> katakana TO (U+30C8)
RV> http://ja.wikipedia.org/wiki/%E3%83%86%E3%82%B9%E3%83%88
RV> This is a UTF-16 string, which can only be handled correctly, if the
RV> application (in our case blat) has a wmain function. I was browsing
RV> the code, but I could only find a main function, which means every
RV> command-line parameter is converted to the local codepage. However
RV> Japanese characters are not in the English codepage, resulting in
RV> placeholder characters (question marks).
My client did display the chars correctly, but I can't send them
without changes...
RV> If it is the case, blat won't be able to handle command-line
RV> parameters that are not in the local codepage.
What does adding -charset UTF-16 to your command line do for you? I am
not sure it will work for you, but I did find it in the list archives.
You can just search for UIT-16 in this lists archive to read the
thread.
I've searched the archives for UTF-16, but the posts I have found were
about the encoding of the _contents_. My issue is with command line
parameters, and opening files with non-ASCII characters in the
_filename_. In my software I solved this issue by using the Unicode
Windows API and wmain(int argv, wchar_t *argv[]). I suppose blat is
using main(int argc, char *argv[]), and I don't know if the rest of
the code is prepared to handle Unicode command line parameters, eg.
filenames. Since I have no time to explore and/or update the code I've
posted my questions to the discussion group.

Nevertheless, I'll try -charset UTF-16, but at the moment I have no
access to my win2k8 test server.

Thanks for your help.

Robert
James Booth
2008-10-02 18:48:10 UTC
Permalink
I have no idea if this will work, but have you tried invoking blat from PowerShell instead of cmd.exe? PowerShell installs as a feature on Windows Server 2008, and seems to use Unicode by default for a lot of things.

jhb








_________________________________________________________________



[Non-text portions of this message have been removed]
Robert Vanyi
2008-10-03 11:46:20 UTC
Permalink
Tim, James,

I really appreciate your help.
Post by James Booth
I have no idea if this will work, but have you tried invoking blat from
PowerShell instead of cmd.exe? PowerShell installs as a feature on Windows
Server 2008, and seems to use Unicode by default for a lot of things.
Unfortunately nothing helps. I was trying to use command-line option
-charset UTF-16 and also running from PowerShell, but I got the same
error. I was also trying to start blat using a Windows API call
CreateProcessW, which passes Unicode parameters, but that didn't help
either.

I was reading some more documentation, and I'm pretty sure that blat
won't be able to process non-ASCII characters in the command-line
other than those in the system's current codepage, unless blat is
using

int wmain(int argc, wchar_t *argv[])

or

LPTSTR GetCommandLine();

to get the command-line.

Do you know the source code? Is blat using any of these Microsoft
specific functions?

Thanks,
Robert

ps:
wmain - http://msdn.microsoft.com/en-us/library/6wd819wh(VS.71).aspx
GetCommandLine - http://msdn.microsoft.com/en-us/library/ms683156.aspx
Chip
2008-10-03 22:31:33 UTC
Permalink
<snip>
Post by Robert Vanyi
Unfortunately nothing helps. I was trying to use command-line option
-charset UTF-16 and also running from PowerShell, but I got the same
error. I was also trying to start blat using a Windows API call
CreateProcessW, which passes Unicode parameters, but that didn't help
either.
I was reading some more documentation, and I'm pretty sure that blat
won't be able to process non-ASCII characters in the command-line
other than those in the system's current codepage, unless blat is
using
int wmain(int argc, wchar_t *argv[])
or
LPTSTR GetCommandLine();
to get the command-line.
Do you know the source code? Is blat using any of these Microsoft
specific functions?
Thanks,
Robert
wmain - http://msdn.microsoft.com/en-us/library/6wd819wh(VS.71).aspx
GetCommandLine - http://msdn.microsoft.com/en-us/library/ms683156.aspx
The source does not yet use wide character names. I will try to make time
this weekend and week to make it have wide character support. It will take
a lot of changes, so I will need some volunteers to check it over when I am
done.

Chip


------------------------------------
--
Homepage:
http://www.blat.net
James George
2008-10-01 21:29:59 UTC
Permalink
Tim,
 
If you can help me, I appreciate it, otherwise maybe you can refer me to someone.
 
I am calling blat.exe thru visual basic via shell command.    How can I get blat to return an error back to my program  or via text file or something. 
 
 
 
Here is my code:
   Dim strPageCommand As String
    Dim pstrAppPath As String
    Dim pstrEmailTo As String
    Dim pstrEmailFrom As String
    Dim pstrSubject As String
    Dim pstrAttachment As String
    Dim dblResult As Double
    Dim A As Integer
    Dim pstrAppPathofBlat As String
   
    pstrAppPathofBlat = App.Path & "\blat.exe "
    pstrEmailTo = "***@comerica.com, ***@comerica.com, ***@comerica.com"
    pstrEmailFrom = "***@comerica.com"
    pstrSubject = "***TEST CSRVIEW RUSH REQUEST "
    pstrAttachment = App.Path & "\request.rtf"
    pstrAttachment = "request.rtf"
 '   strPageCommand = "c:\csrview\blat.exe C:\csrview\message.TXT -to ""***@comerica.com"" -attach ""c:\csrview\request.rtf"" -server 10.7.5.27 -port 25 -subject ""This is a test"" -f ""***@comerica.com"" -try 1"
    strPageCommand = pstrAppPathofBlat & Chr$(34) & pstrAppPath & "message.txt" & Chr$(34) & " " _
        & "-to " & Chr$(34) & pstrEmailTo & Chr$(34) & " " _
        & "-server 10.7.5.27 -port 25 " _
        & "-subject " & Chr$(34) & pstrSubject & Chr$(34) & " " _
        & "-attach " & Chr$(34) & pstrAttachment & Chr$(34) & " " _
        & "-f " & Chr$(34) & pstrEmailFrom & Chr$(34) & " " _
        & "-try 1"
    dblResult = Shell(strPageCommand, vbMaximizedFocus)
End Sub

--- On Wed, 10/1/08, Tim Musson <***@ameritech.net> wrote:

From: Tim Musson <***@ameritech.net>
Subject: Re: [blat] non-ASCII support
To: "Robert Vanyi" <***@yahoogroups.com>
Date: Wednesday, October 1, 2008, 12:52 PM






Hey Robert,
Post by Tim Musson
RV> I'm just trying to use blat.exe in an internationalized environment,
RV> which means, I may have non-ASCII / non-English characters in the
C:\>blat ???.txt -to robert.vanyi@ ...
RV> Blat v2.6.2 w/GSS encryption (build : Feb 25 2007 12:06:19)

RV> unknown error code 123 when trying to open ???.txt

RV> If your mailer doesn't display the filename correctly, it is a
RV> japanese string with three characters:
RV> katakana TE (U+30C6)
RV> katakana SU (U+30B9)
RV> katakana TO (U+30C8)
RV> from this page:
RV> http://ja.wikipedia .org/wiki/ %E3%83%86% E3%82%B9% E3%83%88

RV> This is a UTF-16 string, which can only be handled correctly, if the
RV> application (in our case blat) has a wmain function. I was browsing
RV> the code, but I could only find a main function, which means every
RV> command-line parameter is converted to the local codepage. However
RV> Japanese characters are not in the English codepage, resulting in
RV> placeholder characters (question marks).

My client did display the chars correctly, but I can't send them
without changes...

RV> If it is the case, blat won't be able to handle command-line
RV> parameters that are not in the local codepage.

What does adding -charset UTF-16 to your command line do for you? I am
not sure it will work for you, but I did find it in the list archives.
You can just search for UIT-16 in this lists archive to read the
thread.
--
Tim Musson
Flying with The Bat! eMail v3.99.29
They say you can't have too much of a good thing, wish I'd been part
of that study.
Blat Manager, current version is 2.6.2, see www.blat.net


















[Non-text portions of this message have been removed]
Tim Musson
2008-10-02 11:51:35 UTC
Permalink
Hey James,

On Wednesday, October 1, 2008 at 5:29:59 PM you wrote

JG> If you can help me, I appreciate it, otherwise maybe you can refer
JG> me to someone.

This is a list and anyone can chime in.

JG> I am calling blat.exe thru visual basic via shell command. How can
JG> I get blat to return an error back to my program or via text file
JG> or something.

That is a VBS question. I am not a VBS programmer, and this is not a
VBS programming list. Blat.exe and blat.dll both return errorlevels in
a standard way. If you know how to do it for other programs, Blat
should work the same way.

The list of Return Codes is here:
http://www.blat.net/examples/blat_return_codes.htm
--
Tim Musson
Flying with The Bat! eMail v3.99.29
Why don't you ever see the headline "Psychic Wins Lottery"?
Blat Manager, current version is 2.6.2, see www.blat.net
Anthony Youngman
2008-10-01 15:34:03 UTC
Permalink
Hi,

Why not read the rfcs? www.ietf.org/rfcs<http://www.ietf.org/rfcs> iirc - if not google is your friend.

821, 822, 2821, 2822 also iirc.

The effort is time well spent - they're clear, informative, and make life a lot easier when you can quote chapter-and-verse at lusers and/or phbs. Plus it helps you not be a luser yourself!

Cheers,
Wol

________________________________
From: ***@yahoogroups.com [mailto:***@yahoogroups.com] On Behalf Of Robert Vanyi
Sent: 01 October 2008 16:01
To: ***@yahoogroups.com
Subject: [blat] non-ASCII support


Hi,

I'm just trying to use blat.exe in an internationalized environment,
which means, I may have non-ASCII / non-English characters in the
following strings:

- subject line
- sender email (only local part - domain part uses punycode)
- name of the attachment file
- local hostname (used in HELO)

Is there any chance that these are/will be supported by blat?

Do the RFCs restrict the local part of the sender email address to ASCII?

Thanks in advance,
Robert



[Non-text portions of this message have been removed]
Robert Vanyi
2008-10-01 17:48:27 UTC
Permalink
Hi Wol,

Thanks for the info on the RFC numbers.

I do read them, but my main profile is internationalization and not
emailing. That's what I'm using blat for. ;-)

Furthermore, for the actual issue - blat being able to handle
non-ASCII command-line parameters - the RFCs are irrelevant. However,
when I was trying to figure out, which parameters can contain
non-ASCII characters, I did this based on the RFCs:

- The domain names cannot have non-ASCII characters (RFC 1035, Section
2.3.1), that's why I wasn't asking anything about blat being able to
handle non-ASCII SMTP server names. I'm converting the STMP server
name to ASCII using punycode (RFC 3492)

- The attachment file name (RFC 2231, Section 4) and the subject line
(RFC 2047, Section 8) can have non-ASCII characters.

- The domain name parameter of HELO cannot have non-ASCII characters
(RFC 2821, Section 2.3.5), however blat is getting it directly from
Windows, so I'm unable to convert that to ASCII. My question in this
case if blat is doing anything with that.

- Regarding the local part of the emails I was confused, because RFC
2822 states "[t]he local-part portion is a domain dependent string. In
addresses, it is simply interpreted on the particular host as a name
of a particular mailbox." Furthermore the syntax allows using special
characters in the local-part (RFC 2822, section 3.4 and 3.2.4),
therefore I couldn't exclude the possibility of having some tricky
syntax there (just like there is RFC 3490 for internationalized domain
names). I was hoping someone with more experience can answer this
question with a simple yes/no.

But again, my questions have more to do with blat being a Windows
application that takes command-line parameters, rather than being an
application that sends emails.

Best regards,
Robert
Post by Anthony Youngman
Hi,
Why not read the rfcs? www.ietf.org/rfcs<http://www.ietf.org/rfcs> iirc - if
not google is your friend.
821, 822, 2821, 2822 also iirc.
The effort is time well spent - they're clear, informative, and make life a
lot easier when you can quote chapter-and-verse at lusers and/or phbs. Plus
it helps you not be a luser yourself!
Cheers,
Wol
________________________________
Sent: 01 October 2008 16:01
Subject: [blat] non-ASCII support
Hi,
I'm just trying to use blat.exe in an internationalized environment,
which means, I may have non-ASCII / non-English characters in the
- subject line
- sender email (only local part - domain part uses punycode)
- name of the attachment file
- local hostname (used in HELO)
Is there any chance that these are/will be supported by blat?
Do the RFCs restrict the local part of the sender email address to ASCII?
Thanks in advance,
Robert
Continue reading on narkive:
Loading...