Description

When inserting HTML code with URL query parameters into HTML blocks in the Unlayer email editor, ampersand (&) characters in URLs are incorrectly converted to "not equal" (¬) symbols followed by the next character. This breaks URL functionality in the generated email templates.

Reproduction Steps

1. Create a new email template in Unlayer
2. Add an HTML block component to the template
3. Edit the HTML block and insert HTML that contains a URL with query parameters
4. Save the HTML block
5. Check the rendered HTML or the exported HTML

Example Code

Original HTML input:

<td valign="middle" class="lg_pic">
    <a href="{{link}}&note=5" style="border-width:0;" target="_blank">
        <img src="https://example.com/images/5-stars.png" alt="5 étoiles" title="5 étoiles" style="border:0;">
    </a>
</td>

Resulting HTML output:

<td valign="middle" class="lg_pic">
    <a href="{{link}}¬e=5" style="border-width:0;" target="_blank">
        <img src="https://example.com/images/5-stars.png" alt="5 étoiles" title="5 étoiles" style="border:0;">
    </a>
</td>

Expected Behavior

The ampersand character should be preserved as-is or properly encoded as & in the HTML output, but should not be converted to a different character that breaks URL functionality.

Environment

• Unlayer version: "vue-email-editor": "latest",
• Framework version: Vue.js ["^3.1.0"]

Additional Context

This issue specifically affects template variables in URLs. When using URL query parameters with the ampersand character after a merge tag/template variable (like {{link}}&note=5), the ampersand is combined with the next character to form the "not equal" character, breaking the URL structure.

We've attempted various workarounds including:

1. Pre-encoding the ampersand as & - still results in character conversion
2. Using URL-encoded characters - inconsistent results
3. Creating merged template variables - requires significant template changes

Impact

This bug prevents us from using query parameters in URLs that contain template variables, which breaks critical functionality in our email campaigns where we need to pass parameters for tracking and routing purposes.

Possible Solution

A fix could involve either:

1. Preserving special characters in HTML blocks without conversion
2. Properly encoding ampersands as HTML entities without combining them with following characters
3. Adding a configuration option to disable special character processing in HTML blocks

Thank you for looking into this issue. Please let me know if you need any additional information or clarification.