Friday Fact: Logic Apps don’t interpret escaped characters as plain text, even inside a string.

In the realm of Logic Apps, the treatment of escaped characters differs from handling plain text.

Let’s look into a scenario were understanding special characters, or as they’re commonly known, escaped characters, becomes very important. Specifically, let’s spotlight the ” \t ” special character.

Across various programming languages and text editors, such as Python and C, “\t” symbolizes a tab character. When embedded within a string, “\t” indicates that a tab space should be inserted at that juncture during the string’s display or processing. This convention finds extensive application in text formatting and aligning content for readability.

However, the roster of special characters doesn’t conclude with just the tab character:

• “\n” signifies a Newline or Line Feed.
• “\r” denotes a Carriage Return.
• “\b” corresponds to a Backspace.
• “\f” stands for a Form Feed.
• “\v” signifies a Vertical Tab.

Let’s contextualize this within a Logic App configured with a trigger when an HTTP request is received and a response of “Content/Type: application/json” and using Postman to send the following JSON to the Logic App:

{
    "filename": "Report\t2024.pdf"
}

Not surprisingly, the response mirrors the input:

{
    "filename": "Report\t2024.pdf"
}

But let’s say that our objective is to eliminate the special character, resulting in:

{
    "filename": "Report2024.pdf"
}

One might instinctively think of using a variable for example containing an expression to remove the special character, being the expression the following:

replace(triggerBody()?['filename'],'\t','') 

And this is not entirely wrong, the only problem is that this is also not entirely right, because as you can see, the outcome remains unchanged:

{
    "filename": "Report\t2024.pdf"
}

This prompts the question: what’s happening here? To understand it, we need to enter the CodeView of the Logic App:

 

Looking with care we can understand that within the variable an anomaly surfaces: a backslash is appended to the expression on the variable we’ve instantiated:

"value": "@{replace(triggerBody()?['filename'],'\\t','')}"

If we try to rectify this, for example, using another variable with an expression to eradicate the characters, but unfortunately this will increase the issue with double backslashes, as evidenced in the modified variable within the CodeView:

"value": "@{replace(variables('RemoveSpecialCharacter'),'\\\\t','')}" 

So, what’s the resolution?

Let’s proceed with a single variable with the earlier expression:

replace(triggerBody()?[‘filename’],’\t’,”)

Now, navigate to the Logic App’s CodeView and manually remove the extra backslash :

"value": "@{replace(triggerBody()?['filename'],'\t','')}" 

Moving back to the designer and in inspecting the expression inside the variable, the extra ‘\t’ metamorphoses into a tangible tab:

replace(triggerBody()?['filename'],'	','')

Next with the Logic App saved, execute a new request via Postman.

Now we finally have the desired outcome:

{
    "filename": "Report2024.pdf"
}

This methodology extends to other enumerated special characters.

But wait, what if you do not want to venture into the Code View? Is there any other solution? The good news is that yes, that is another solution!

So instead of using the code view, just add variable, with the following expression:

decodeUriComponent(replace(uriComponent(triggerBody()?['filename']),'%09',''))

What will this expression do?

The “\t” can be represented as a Unicode character, so in this expression we need to encode the string first and do a replace for the %09 character, that is the representation of the “\t” in Unicode, now if you send the postman request again you will see the result is the one we expected!

With this in mind, we can learn that that Logic Apps don’t interpret escaped characters as plain text, and these characters need to be specially treated to being removed from undesired situations.

Stay tuned for more content like this! See you next Friday with another Friday Fact!

To lazy to read? We’ve got you covered! Check out our video version of this content!

Hope you find this helpful! If you enjoyed the content or found it useful and wish to support our efforts to create more, you can contribute towards purchasing a Star Wars Lego for Sandro’s son!

Happy automating!