-Original Message-
From: Christian Roth [EMAIL PROTECTED]
An 'ü' would therefore be encoded like this:
ü = Unicode: 0xFC
= UTF-8: 0xC3 0xBC
= URL: %C3%BC
(At least this is what I am doing with URLs with hi-ASCII
characters in
my own product.)
This is getting more and
Am 21.10.2005 hat PowerMail Engineering geschrieben:
The normal case should be, that the body text is transfered *how_it_is*!
And just this is not the case with PM.
I have not thoroughly checked the RFCs recently about this point, but I
think nothing is specified for encoding non US-ASCII
Rene Merz wrote:
The normal case should be, that the body text is transfered *how_it_is*!
And just this is not the case with PM.
I have not thoroughly checked the RFCs recently about this point, but I
think nothing is specified for encoding non US-ASCII characters in a
mailto URL; and non
And I know, how I can handle this problem: Inside FileMaker I have to
resolve all the umlauts into two letters. It isn't smart, but it helps.
But this is what the standard tells you to do with the mail to as well.
Space should be encoded to %20, so this means that umlauts would be %dc
or %fc,
Would be nice if it would be that easy!
But the encoding Über with #220; stops all transfer-flow of the body
text just after that encoding; the rest of the mail text remains empty.
The reason is obvious: the ampersand-sign () is strictly reserved for
the codification of the mailto-string.
(See
Le 21/10/05 à 13:04, [EMAIL PROTECTED] a écrit :
maybe you can create the html mail with a html editor or BBEdit or what
ever and send it as a attachment by PM. The body should be empty then.
I know this solution, but it is not very convenient ... saving and
attaching a file ...
Thank you
maybe you can create the html mail with a html editor or BBEdit or what
ever and send it as a attachment by PM. The body should be empty then.
All the best
Matthias
---
Admilon Consulting GmbH
http://www.admilon.com
iChat/AIM: MatKoyasan
Tel.
Well, I learned something today. It's not a FM bug, but nor is it a PowerMail
bug. It's a STANDARDS issue. Check out RFC 2368, it seems that you must encode
the body= part of the mailto: according to the RFC. My guess is that in the
Apple Message Frameworks they are handling this for you,
Jérôme:
Reindexing spam does not seem to work on my PowerMail.
I have a spam message that is promoting the company Allixon. My filter is:
Spam: actions
Filter incoming messages
Conditions:
Spam rating is high
Actions:
Move message into folder: Spam
Don't
No it isn't a FileMaker problem at all!
It's a pure PowerMail-bug!
Doing the same with Apple mail.app it works fine! Diactrictic signs are
transfered as they are, no need to encode them.
This is a problem with FileMaker. I remember that at Apple we had to
write a bunch of custom email headers
This is a problem with FileMaker. I remember that at Apple we had to write a
bunch of custom email headers for the email in order to have FileMaker do what
we needed with non US-ASCII characters. I'll dig through my old scripts and see
if I can dig up anything, but I only have access to the
I abuse mailto for transfering mails from FileMaker to PowerMail and to
send them therefrom.
Example of the FileMaker(FM)-script:
--
mailto:FM_FIELD_ADDRESS?subject=
FM_FIELD_SUBJECTbody=FM_FIELD_MAILTEXT
--
Works fine.
Unfortunately PowerMail doesn't support from= in the mailto
12 matches
Mail list logo
