In a Mac/Windows project for a customer, we have a function to compose an email to be sent to the administrators. We create the body of the message, call encodeURLComponent, make it part of a mailto: url which we then show.
This works fine on their Windows clients. But, when they do it on a Mac, using Outlook 2013 for Mac as their mail client, the email is received with all the url encodings in place - e.g., all spaces substituted by “%20”
Instead of this from a Windows client:
[code]USER INSTRUCTIONS: Please provide your manager’s name, and any additional information.
AHA! Now that is something worth trying. I’m currently just using “endOfLine,” which would be different on Mac and Windows. I’ll modify the project, deeply, and see what happens.
[quote=196927:@Michel Bujardet]It simply is an URL encoded line.
For some reason, DecodeURLComponent was not applied. Check your code.
I checked, it does decode fine on my Mac.[/quote]
I realize that. It’s not our app that decodes it. We build a URL, and pass it to the mail client with showURL :
[code]dim s, mailAddr , BodyStr, subjStr as string
I’ve used the same code successfully in other Mac projects, but always using Maill.app as the client. I’m hoping that Outlook for Mac is expecting the CRLF as Kem suggests.
[quote=196941:@Kem Tekinay]
bodyStr = EncodeURLComponent( ReplaceLineEndings( bodyStr, EndOfLine.Windows ) )
[/quote]
Yep. Just did that. Now, to build, deploy, and finally to get one of their Mac users to try it tomorrow.
The old Microsoft Exchange client in Windows 95 used to do the same thing. Kept the URL encoded data passed to it from the browser no matter what we did.
I wish you luck with this. Our “solution” was to switch mail clients. Lucky for us it was an internal only need.
