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.

Special characters

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

Across programming languages and text editors, such as Python and C, the “\t” character represents a tab. 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 is widely used 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.

Logic App Scenario

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"
}

The goal

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"
}

The issue

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?

The solution

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 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 a 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, which 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 Logic Apps don’t interpret escaped characters as plain text, and these characters need to be specially treated to be 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!

Author: Luis Rigueira

Luis Rigueira is a Enterprise Integration Consultant at DevScope View all posts by Luis Rigueira