Windows Phone URI association deep links and the ampersand

Hyperlink

A few weeks ago I stumbled on an issue while using ampersand (&) in a URI association deep link with query string parameters!

Let’s start by assuming I have a Windows Phone app capable of handling deep links with “my-app:” moniker. Now take a look at the following sample link:

my-app://do/stuff/?param1=a%26b&param2=c

We can easily see a query string with two parameters, and after decoding their values, we get param1 = "a&b" and param2 = "c".

If we use the Launcher.LaunchUriAsync(uri) method to open the link, this is what will arrive in the internal UriMapper:

/Protocol?encodedLaunchUri=my-app%3A%2F%2Fdo%2Fstuff%2F%3Fparam1%3Da%2526b%26param2%3Dc

By retrieving and decoding the encodedLaunchUri from the previous link, the result will be "my-app://do/stuff/?param1=a%26b&param2=c", matching the original uri, as we would expect!

If we now use a web page with that link on it instead, open the page inside Internet Explorer on the phone and tap on the link, this is what will get to the app UriMapper:

/Protocol?encodedLaunchUri=my-app%3A%2F%2Fdo%2Fstuff%2F%3Fparam1%3Da%26b%26param2%3Dc

If we do as before and retrieve and decode the encodedLaunchUri, we will get "my-app://do/stuff/?param1=a&b&param2=c", which in this case, doesn’t match the original deep link!

This behavior is due to Internet Explorer in Windows Phone, as it seems to decode all links before trying to navigate to them, and when it can’t perform the navigation (e.g. when the link isn’t a http:// or https:// link) it just sends it to the platform to handle it, but by that time the link has already been wrongly re-encoded!

So far I haven’t been able to find any way of bypassing this issue, apart of simply not using the & in my apps deep links… and my advice to you is to proceed just like this!

  • Pingback: Windows Store Developer Links – 2013-09-13 | Dan Rigby()

  • Pingback: Windows Phone URI association deep links and the ampersand()

  • I’ve found the workaround for this thanks to the hell I have to go through with SharePoint. Instead of using a standard ampersand in the parameter, use a fullwidth ampersand instead. When it gets decoded through the WebBrowser control, it will be in the format of the following:

    “/Protocol?encodedLaunchUri=contoso:TestFullWidth?parameter1=a%EF%BC%86b&parameter2=blah”

    further decoding the fullwidth ampersand bytes from parameter1 then converting it to a standard ampersand should do the trick.

    • Upon further review of what I’ve done. This is still another way NOT to use the standard ampersand (like you suggested) so I guess this isn’t really a workaround.