Merge pull request #285173 from ecfan/uuf

[Content Health][UUF] Non-Unicode payload - Use base64ToBinary, not base64ToString

Author: prmerger-automator[bot]

articles/logic-apps/support-non-unicode-character-encoding.md

@@ -4,7 +4,7 @@ description: Handle non-Unicode characters in Azure Logic Apps by converting tex
 ms.service: azure-logic-apps
 ms.topic: how-to
 ms.reviewer: estfan, azla
-ms.date: 01/04/2024
+ms.date: 08/21/2024
 ---
 
 # Support non-Unicode character encoding in Azure Logic Apps
@@ -13,25 +13,26 @@ ms.date: 01/04/2024
 
 When you work with text payloads, Azure Logic Apps infers the text is encoded in a Unicode format, such as UTF-8. You might have problems receiving, sending, or processing characters with different encodings in your workflow. For example, you might get corrupted characters in flat files when working with legacy systems that don't support Unicode.
 
-To work with text that has other character encoding, apply base64 encoding to the non-Unicode payload. This step prevents Logic Apps from assuming the text is in UTF-8 format. You can then convert any .NET-supported encoding to UTF-8 using Azure Functions. 
+To work with text that has other character encoding, apply base64ToBinary encoding to the non-Unicode payload. This step prevents Azure Logic Apps from assuming the text is in UTF-8 format. You can then convert any .NET-supported encoding to UTF-8 using Azure Functions. 
 
-This solution works with both *multi-tenant* and *single-tenant* workflows. You can also [use this solution with the AS2 connector](#convert-payloads-for-as2).
+This solution works with both *multitenant* and *single-tenant* workflows. You can also [use this solution with the AS2 connector](#convert-payloads-for-as2).
 
 ## Convert payload encoding
 
-First, check that your trigger can correctly identify the content type. This step ensures that Logic Apps no longer assumes the text is UTF-8. 
+First, check that your trigger can correctly identify the content type. This step ensures that Azure Logic Apps no longer assumes the text is UTF-8. 
 
-In triggers and actions that have the property **Infer Content Type**, select **No**.  You can usually find this property in the operation's **Add parameters** list. However, if the operation doesn't include this property, the content type is set by the inbound message.
+In triggers and actions that have the property **Infer Content Type**, select **No**.  You can usually find this property in the operation's **Advanced parameters** list. However, if the operation doesn't include this property, the content type is set by the inbound message.
 
 The following list shows some of the connectors where you can disable automatically inferring the content type:
+
 * [OneDrive](/connectors/onedrive/)
 * [Azure Blob Storage](/connectors/azureblob/)
 * [Azure File Storage](/connectors/azurefile/)
 * [File System](/connectors/filesystem/)
 * [Google Drive](/connectors/googledrive/)
 * [SFTP - SSH](/connectors/sftpwithssh/)
 
-If you're using the Request trigger for `text/plain` content, you must set the `charset` parameter that is in the call's `Content-Type` header. Otherwise, characters might become corrupted, or the parameter doesn't match the payload's encoding format. For more information, review [how to handle the `text/plain` content type](logic-apps-content-type.md#text-plain).
+If you're using the **Request** trigger for `text/plain` content, you must set the `charset` parameter that is in the call's `Content-Type` header. Otherwise, characters might become corrupted, or the parameter doesn't match the payload's encoding format. For more information, review [how to handle the `text/plain` content type](logic-apps-content-type.md#text-plain).
 
 For example, the HTTP trigger converts the incoming content to UTF-8 when the `Content-Type` header is set with the correct `charset` parameter:
 
@@ -49,7 +50,7 @@ If you set the `Content-Type` header to `application/octet-stream`, you also mig
 
 ## Base64 encode content
 
-Before you [base64 encode](workflow-definition-language-functions-reference.md#base64) content to a string, make sure that you [converted the text to UTF-8](#convert-payload-encoding). Otherwise, characters might return corrupted.
+Before you [base64 encode](workflow-definition-language-functions-reference.md#base64) content to a string, make sure that you [convert the text to UTF-8](#convert-payload-encoding). Otherwise, characters might return corrupted.
 
 Next, convert any .NET-supported encoding to another .NET-supported encoding. Review the [Azure Functions code example](#azure-functions-version) or the [.NET code example](#net-version):
 
@@ -210,6 +211,8 @@ Example output:
 
 If you need to send a non-Unicode payload from your workflow, do the steps for [converting the payload to UTF-8](#convert-payload-encoding) in reverse. Keep the text in UTF-8 as long as possible within your system. Next, use the same function to convert the base64-encoded UTF-8 characters to the required encoding. Then, apply base64 decoding to the text, and send your payload.
 
+When you consume the return value from Azure Functions, make sure to use the [**base64ToBinary** function](workflow-definition-language-functions-reference.md#base64tobinary), not the **base64ToString** function.
+
 ## Convert payloads for AS2
 
 You can also use this solution with non-Unicode payloads in the [AS2 v2 connector](logic-apps-enterprise-integration-as2.md). If you don't convert payloads that you pass to AS2 to UTF-8, you might experience problems with the payload interpretation. These problems might result in a mismatch with the MIC hash between the partners because of misinterpreted characters.