- TLC Home Home
- Discussions Discussions
- Documentation Documentation
- Knowledge Base Knowledge Base
- Education Education
- Blog Blog
- Support Desk Support Desk
07-13-2016 05:27 AM - last edited on 08-17-2017 07:40 AM by kathleen_jo
In the Publish Settings under UTF-8 Encoding, I am sent to
https://community.tealiumiq.com/t5/iQ-Tag-Management/Publish-Configuration/ta-p/13632#implementation
However I get the error that I cannot view this page. Can someone update the link in Tealium iQ please?
I have 2 questions regarding this:
1. Does this mean that publishes will encode "special" characters correctly in the JavaScript code (äöüßéè etc.) without having to use the Unicode signs for them anymore?
2. What happens to the code parts where Unicode signs are in use today? Do we have to change the Unicode characters to the UTF-8 characters or will they continue to work?
Thanks!
Solved! Go to Solution.
07-13-2016 08:10 AM
Hi @loldenburg. The link is now fixed. Thank you for bringing this to my attention.
07-13-2016 09:01 AM
07-13-2016 12:13 PM
Okay let me see if I can find you some assistance @loldenburg.
07-14-2016 02:14 AM
In answer to your questions:
1. Does this mean that publishes will encode "special" characters correctly in the JavaScript code (äöüßéè etc.) without having to use the Unicode signs for them anymore?
Correct, you can have "special" characters in the JS now with no issues. Without having to use the workaround of unicode characters.
2. What happens to the code parts where Unicode signs are in use today? Do we have to change the Unicode characters to the UTF-8 characters or will they continue to work?
These will continue to act like they have done. You can either switch them over to their retrospective charater or quite happily leave them as they are.
Adrian
07-14-2016 06:28 AM
01-31-2018 07:25 PM
01-31-2018 10:38 PM
Hi @CesarFlorero, you could do this in an extension. So for example, you might create an After Load Rules extension thus:
var decodeEntities = function(input){ return $('<textarea />').html(input).val(); }; var recodeEntities = function(input){ return encodeURIComponent(decodeEntities(input)); }; if(b.website_section){ b.website_section = recodeEntities(b.website_section); }
For the sake of being quick and easy, it needs jQuery to work, but it'll convert any HTML entities first to their unicode equivalents, and then it'll URLEncode them. You can skip the URL encoding if the tags you're mapping that data to will do that for themselves as part of building their respective querystrings, but it's left for the sake of completeness..
02-01-2018 12:41 AM - edited 02-01-2018 12:43 AM
@UnknownJ's approach may work, but it is imho not the most browser-resource-friendly approach (moreover getting values by scraping them from form fields is something I would not recommend unless for a temporary "hack"). The UTF-8 support in the publish settings did the job for us, so try that.
02-01-2018 03:29 AM
If the text section: türkmenistan
is inside the utag.js or utag.#.js file then yes this will solve your issue, as the publish engine will keep the encoding the same. It will not however convert section: türkmenistan
--> section: türkmenistan
.
If you are pulling from the page then, again this is determined from the pages encoding type. If the page is set to UTF-8 then again you should see the correct value.
Adrian
02-01-2018 06:46 AM
@adrian_browning @loldenburg @UnknownJ Thank you guys for the quick response. I am new to Tealium and I appreciate all the help I can get.
To follow up on your response, I am attaching a couple of screen shots to better illustrate my dilemma. I have not made any changes to my Publish settings yet.
This is what my UDO looks like currently. Notice the unicode characters.
Strangely the UTAG Debugger tools shows this, notice how this "appears correct", but...
If I look at the Chartbeat pixel and try to validate the correct variable, it shows the special characters.
I hoping all of this can be resolve if I just update my Publish settings or is this more complecated than I thougth?
Again, Thanks for your help on this.
Cesar
02-02-2018 02:54 AM
So looking at that I think your best option is to run the values through a function to convert, something like:
function convertHTMLCodeToString(htmlString){ htmlString = htmlString || ""; return htmlString.replace(/&#(\d+);/g, function(group, htmlNum){ return String.fromCharCode(htmlNum); });
}
Adrian
02-02-2018 09:41 AM
02-02-2018 12:11 PM - edited 02-06-2018 02:34 AM
The code indeed is generic. You can paste it into a JS extension scoped to All Tags, then loop through the whole b
object.
function convertHTMLCodeToString(htmlString){ htmlString = htmlString || ""; return htmlString.replace(/&#(\d+);/g, function(group, htmlNum){ return String.fromCharCode(htmlNum); }); } for (var prop in utag.loader.GV(b)) { if (utag.ut.typeOf(b[prop]) !== "string") continue; b[prop] = convertHTMLCodeToString(b[prop]); }
Adrian
02-03-2018 02:03 PM - last edited on 02-05-2018 12:08 PM by kathleen_jo
Again, Thank you for all your help with this. :) What do you mean loop through the whole 'b' object, @adrian_browning? Could you share a screenshot of what this is exactly?
Cesar
02-06-2018 02:34 AM
Here is an example of how I would use this in iQ.
Making sure to select Execution: Before Load Rules, to make sure you can use these decoded strings in Load Rule evaluation.
Adrian
04-18-2019 02:48 PM
04-18-2019 02:49 PM
05-13-2019 01:50 PM
Hi @loldenburg,
Do you mind giving it a shot now? I just confirmed the URL redirect with our community platform provider, and tested it with success. Feel free to send me a private message if you see anything else amiss.
Kristen
Copyright All Rights Reserved © 2008-2023