Hi Marketo Nation,
Curious if there's a standard for URL encoding in Velocity scripts. Below is a {{my.Calendly_Link}} custom token script that outputs a Calendly link. However, the URL printed at the end has non-ASCII characters such as = (equals sign), as well as & (ampersand).
Here's the current script (without URL encoding) at line 12:
#if(($lead.Owner_Calendly_Link__c.isEmpty() || $lead.Owner_Calendly_Link__c == "-") && $lead.Number_of_Opportunities == "0")
#set($calendlylink = "calendly.com/fresh-tracks-canada")
#elseif($OpportunityList.get(0).Owner_Calendly_Link__c.isEmpty() || $OpportunityList.get(0).Owner_Calendly_Link__c == "-")
#set($calendlylink = "calendly.com/fresh-tracks-canada")
#elseif((!$lead.Owner_Calendly_Link__c.isEmpty() && $lead.Owner_Calendly_Link__c != "-") && $lead.Number_of_Opportunities == "0")
#set($calendlylink = "${lead.Owner_Calendly_Link__c}")
#elseif(!$OpportunityList.get(0).Owner_Calendly_Link__c.isEmpty() && $OpportunityList.get(0).Owner_Calendly_Link__c != "-")
#set($calendlylink = "${OpportunityList.get(0).Owner_Calendly_Link__c}")
#else
#set($calendlylink = "calendly.com/fresh-tracks-canada")
#end
https://${calendlylink}/1?text_color=000000&primary_color=e42f3a
Based on my front-end testing, it doesn't seem necessary - just practicing some due diligence.
Thanks!
Solved! Go to Solution.
"&" and "=" are very much ASCII characters, ASCII #38 and #61 respectively.
You appear to be talking about HTML encoding, not URL encoding. These are very different things. You don't want to URL-encode the "=", that will break your query string. (You don't need to HTML-encode "=" either, but it would be harmless.)
The "&" character should indeed be HTML encoded to not break if you use special sequences in query params (and it certainly is possible to break a link, you just have to test with the right/wrong chars):
https://${calendlylink}/1?${esc.html("text_color=000000&primary_color=e42f3a")}
"&" and "=" are very much ASCII characters, ASCII #38 and #61 respectively.
You appear to be talking about HTML encoding, not URL encoding. These are very different things. You don't want to URL-encode the "=", that will break your query string. (You don't need to HTML-encode "=" either, but it would be harmless.)
The "&" character should indeed be HTML encoded to not break if you use special sequences in query params (and it certainly is possible to break a link, you just have to test with the right/wrong chars):
https://${calendlylink}/1?${esc.html("text_color=000000&primary_color=e42f3a")}
You're right, those are ASCII characters, I think my doubts were around them being "unsafe". Which they are, and this is exactly the resolution I was looking for. Thanks!
"=" is not unsafe in a URL. If you're using it to delimit query names from query values, it must not be escaped.
It's good to know that caveat. So in that event, would you recommend no escaping for this line?
In this particular use case, the queries are only there to improve UX as it customizes the landing page design - we're not looking to track the query names and values.
However, if there is any typo in the query section of the URL structure, the primary and text color values of the actual landing page will be misaligned with our brand. In other words, we are looking to ensure that the URLs are outputting correctly when the token is read in the email deployment to maintain brand consistency.
It's good to know that caveat. So in that event, would you recommend no escaping for this line?
No, you can and should escape it using the code I gave above.
But HTML escaping doesn't touch the "=" character. It is not a reserved character and there is no risk of parsing confusion.
URL encoding -- percent-encoding -- which you are not using, would affect the "=" sign, which is why you never want to encode the "=" itself unless you're using it as only a character, not a delimiter. For example, if you have a variable
QmlzaG95IFJpYWQ=
(which happens to be the Base64 encoded form of "Bishoy Riad")
then you would URL-encode that so it becomes
QmlzaG95IFJpYWQ%3D
and only then would you put it in a query value, for example
http://example.com?fullName=QmlzaG95IFJpYWQ%3D