& converted to & in campaign browser software

oROEchimaru

Supreme [H]ardness
Joined
Jun 1, 2004
Messages
4,662
We are having issues with our html designs, where our code for & which is error free gets converted by the browser to & ... which then generates errors when we send out our email... since it is invalid code to have & instead of the full & name

I tried using the html number and name... both cause the same issue.

Is there a way to force a browser not to make these conversions? i had the same issue in firefox and internet explorer
 
You are looking for a way to have a browser *not* process an HTML special code?

You're really going to have to provide more technical details on this e-mail -- the message itself (or a realistic sample), the subject (or a realistic sample), the e-mail message encoding type, who is sending the message and how (by single person, bulk mailer service, desktop e-mail client), etc.
 
thanks so much for your help!

we use campaign enterprise... marketing software that you access the interface in the browser.

if you have code, such as &=blah for tracking... it is an error... valid code for html must be & or ≡ not the symbol &=. So to fix this, you in theory would swap out & for &

Now, if you throw corrected code with &amp instead of & (html) into campaign enterprise, and save it.. the browser then converts &amp to &. This then recreates the error, making your code invalid once again.

Even worse, is ≡ becomes &, which then no longer is an equal sign, so our tracking and other links are now broken.

Any way to get a browser or a program to stop doing this? its happening in ie and firefox... converting the characters to their symbols rather than leaving them as code.
 
Browsers do not have a problem with "&" or "&".

Sounds like the campaign enterprise software is the root of the problem. If anything, it's either an issue with the version of campaign enterprise you are using, or an alternate approach is needed.

I'd still like to see responses to the previous questions I had posted: Sample text/html, the e-mail message encoding type, and how the person views the message (ie: is there an inconsistency between viewing the e-mail from an e-mail client versus a webmail app?).

There's also an inconsistency with where the error is being reported. You're saying "browser", but this is an e-mail sending app or service? So the recipient could view it from a browser (ie: webmail) or an e-mail client (ie: outlook).
 
& gets parsed by browsers into &.

Then, when you get the attribute value or text node value, you need to convert back.

For example:

Code:
<!DOCTYPE html>
<html>
    <head>
        <meta charset="utf-8">
        <title></title>
        <script>
            var textReserved = /(<)|(>)|(&)|(\u00A0)/g;
            function escapeTextNodeValue(data) {
                return data.replace(textReserved, function(m, a, b, c) {
                    if (a) return "&lt;";
                    if (b) return "&gt;"
                    if (c) return "&amp;";
                    return "&nbsp;"
                });
            }
            var attrReserved = /(<)|(>)|(&)|(")|(\u00A0)/g;
            function escapeAttrNodeValue(value) {
                return value.replace(attrReserved, function(m, a, b, c, d) {
                    if (a) return "&lt;";
                    if (b) return "&gt;";
                    if (c) return "&amp;";
                    if (d) return "&quot;";
                    return "&nbsp;";
                });
            }
            window.onload = function() {
                var test = document.links[0];
                alert(test.href);
                alert(escapeAttrNodeValue(test.href));
                alert(test.firstChild.data);
                alert(escapeTextNodeValue(test.firstChild.data));
            };
        </script>
    </head>
    <body>
        <p><a href="http://www.example.com/?var1=this&amp;var2=that">1 &lt; 2</a></p>
    </body>
</html>

But, not sure if that'll help as more info is needed on how the email is generated etc.
 
@Shadow2531
Interesting bit on string rewriting. That approach also assumes that whatever is viewing the HTML e-mail message (Yahoo webmail, Outlook, etc.) will allow Javascript within the message to execute. I'm not sure if this would be allowed (gut instinct says no).


But yes, there needs to be more info on all facets of this post to understand and resolve the problem.
 
"&amp; gets parsed by browsers into &."

this is whats happening.

1. campaign enterprise is marketing software... it has a browser interface.

2. you login... through a browser at the ip address.

3. you have a section to post html code... any code in the world in html/xhtml

4. you have a section to post the plain text. basically copy the text from the html and paste it here.

5. you choose your database, and smtp server... then save.

6. you can then send a test... or open the campaign back up to modify it.

An html example is not needed... since ALL html code... that uses &amp; or &equiv; is then parsed by the browser... to & and =... removing the code.

So in steps 5/6... if you save the campaign and open it back up. All your &amp; codes will be switched to & and all &equiv; will be switched to & (its messed up... the program or browser switches it to the &sign and not = sign)...

you can imagine any html example...

<html>
<body>
<p>
&amp; &amp; &equiv; &equiv;
</p>
</body>
</html>

when you open it back up it will be:
<html>
<body>
<p>
& & = =
</p>
</body>
</html>
 
The HTML sample you posted of what gets returned by the campaign software is what is seen when you do a "View Source"? I'm guessing "yes", but want to be 100% certain on this...

Assuming your response is "yes", the problem does seem with the campaign software. Likely it's doing some regular expression checks or HTML encoding/decoding that is mucking up what you want it to save.

Does the campaign software have any administration options to change how it handles characters, such as treating all characters as literals without adjustment? If not, then do they have any support options? I'm guessing (yet again) that this is something that was purchased or is an external website or subscriber service.
 
i posted an upset support ticket with them.. they were like "maybe we'll send it to the dev team" and i was like... MAYBE?!?!?

their goal is to send marketing emails... these are used for tracking advertising... and they are thinking "maybe"? lol

thats the soul purpose their company exists.
 
any new ideas guys?

they said its in their dev schedule... which would cost us 2000$ :(
 
How about using &# 38; (remove space) instead of &amp;? Both are equal to &. Maybe the software isn't smart enough to convert that to &.

edit: Or maybe you can just encode the whole &amp; like &amp;amp;. It could change back to & after the second save.
 
the 2nd option would probably work in the email... but when they click view online, it would then be broken probably... since they need to match...

i tried the 1st option... that didn't work either... same conversion:(

thanks for your help and ideas! i tried a few alternative browsers today, all the same issue too.
 
that would work in the email version.. but if a user clicks "View online" at the top of hte email to visit the live page... the real website... the links would be broken since &amp;amp is not valid... only &amp;
 
You may want to evaluate other e-mail campaign software/services. I can't think of any from past experience, but it shouldn't be too hard to find a few and immediately test them out with the HTML being used with the current provider.
 
you cannot use php code in an email i believe so this would not be an option for us, thanks tho.

plus our web designers probably have no experience with php.
 
you cannot use php code in an email i believe so this would not be an option for us, thanks tho.

plus our web designers probably have no experience with php.

PHP code in an email no, but you can certainly use PHP to write the HTML that goes into the email...

I was just offering another solution for you.
 
PHP code in an email no, but you can certainly use PHP to write the HTML that goes into the email...

I was just offering another solution for you.

The e-mail is part of a bulk mailing campaign that is done by an outside company. They are the ones who actually send the message, so the technical approach of generating and sending the SMTP message is handled by them. The OP has no access to that.

Creating or generating the HTML is not the issue - Notepad, Dreamweaver, a PHP app, etc. would all create the same markup being sent to the browser. The HTML itself is what the outside bulk e-mailing agency is choking on.
 
thanks for your help guys.

they said they "might fix" it. in my support ticket. so I created a new support ticket asking, PLEASE FIX it... lol and they wrote back "we passed it on to the dev team already"...

but their fix is 2-3k! and who knows when they'll even fix it.

for 2-3k we could probably buy different software that has better bounce tracking features... but its hard to find one that lets us use our mail server and not a browser mail server on their site (that charges like a penny per email... that would turn our like 2k$/month costs to like 2/million lol).

thanks again... if anyone has an idea to turn this off in a browser let me know. -jer
 
any firefox tweakers know how to maybe stop conversion from happening in about:config?
 
ascii conversion is a basic function of the browser, you aren't going to be able to escape it. especially since the problem actually lies with the campaign application, not the browser. the ideal solution would be to have campaign allow for escape characters for ascii sequences that you wish to pass on unconverted. $2-3k worth of dev for a 10 minute bug fix is ridiculous, tell them to fix it or you'll find a new application to use.
 
yeah i have... lol

i guess i have to wait until they fix it if ever... i think their solution is to say "oh its not fixable" when they could simply build us a non-browser client as they have for their demo.
 
err... so it fixes and works with some stuff. but now hot-ims the ad tracking service, doesn't recognize %26, but they recoginze %xx almost all other html codes.

so it fixed some issues, and broke others! so now we have to wait for these companies to fix their code.
 
Back
Top