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¶m2=cWe 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%3DcBy retrieving and decoding the encodedLaunchUri from the previous link, the result will be "my-app://do/stuff/?param1=a%26b¶m2=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%3DcIf we do as before and retrieve and decode the encodedLaunchUri, we will get "my-app://do/stuff/?param1=a&b¶m2=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!
