Bug/feature request for mailto: URLs with parameters

General JUCE discussion
1

Hi, I have this code:

const URL u(T("mailto:me@mysite.com?subject=string with spaces"));
u.launchInDefaultBrowser();

…and it works fine on my Windows XP machine, unless for the subject, which shows up as “string+with+spaces” in Thunderbird.

I said to myself: “ah, right, URL encoding!”, and so I encoded the spaces with the usual %20 strings:

const URL u(T("mailto:me@mysite.com?subject=string%20with%20spaces"));
u.launchInDefaultBrowser();

surprisingly enough, the email shows up AGAIN with subject “string+with+spaces”.

I investigated a little and found out that the parameters get converted to their internal representation within the URL class with a call to removeEscapeChars, and then they are converted back to URL encoding with a call to addEscapeChar when needed.

The problem here is that Thunderbird (and some other, I fear) doesn’t recognize the + as a way to encode the “space” character.
Thus, what I’d like is an additional boolean parameter encodeSpaceAsPlus for the addEscapeChars function, which would work like this:

    while (*utf8 != 0)
    {
        const char c = *utf8++;

        if (encodeSpaceAsPlus && c == ' ')
        {
            result += T('+');
        }
        else if (CharacterFunctions::isLetterOrDigit (c)

When encodeSpaceAsPlus is true, things work as usual. When it is false, the “else” branch of the if takes care for converting it to %20.

Functions calling addEscapeChars would need to take that extra parameter as well, for passing it to addEscapeChars.

What do you think about it?

2

That’s annoying! I thought the plus/space thing was standard URL behaviour, but if not, I should probably just drop it altogether, as there’s no harm in using %20 instead.

3

I thought so too, but if I think about how I would encode the space in a url, the %20 comes to my mind, not the +… probably other developers around the world just get away with it :slight_smile:

according to the current behaviour, the Doxygen documentation for addEscapeChars is not formally correct, as in the example it states that spaces will be converted to %20 instead of +

4

Ok, I think I’ll just ditch the ‘+’ altogether.