{"id":51548,"date":"2021-01-30T03:01:56","date_gmt":"2021-01-29T17:01:56","guid":{"rendered":"http:\/\/www.rjmprogramming.com.au\/ITblog\/?p=51548"},"modified":"2021-01-30T07:00:30","modified_gmt":"2021-01-29T21:00:30","slug":"iframe-srcdoc-equals-utf-8-issue-primer-tutorial","status":"publish","type":"post","link":"https:\/\/www.rjmprogramming.com.au\/ITblog\/iframe-srcdoc-equals-utf-8-issue-primer-tutorial\/","title":{"rendered":"Iframe Srcdoc Equals UTF-8 Issue Primer Tutorial"},"content":{"rendered":"
\"Iframe<\/a>

Iframe Srcdoc Equals UTF-8 Issue Primer Tutorial<\/p><\/div>\n

Do you remember how with Javascript document.querySelectorAll Client Pre-emptive Iframe Tutorial<\/a>, recently, we said …<\/p>\n

\nWhy can\u2019t we manage this new functionality in the one pass through the \u201conload\u201d event logic? Well, any self-respecting webpage content will contain both apostrophe and double quote characters (let alone line feeds and carriage returns) ( but we can if we can get to a Javascript DOM statement like <\/font>document.getElementById(\u2018ifsd\u2019).srcdoc=atob((\u201d + ioissrc).split(\u2018;base64,\u2019)[1]).replace(\u2018<\/bo\u2019 + \u2018dy>\u2019, \u2018 <style> \u2018 + selectorplusis + \u2018<\/style> <\/bo\u2019 + \u2018dy>\u2019);<\/font> )<\/font><\/p><\/blockquote>\n

? Well, that is true, initializing an iframe’s srcdoc<\/a> attribute at the same time as the iframe is created can be tricky for HTML data of any complexity. Recently, though, we realized that the …<\/p>\n


\ndocument.getElementById(\u2018ifsd\u2019).srcdoc=atob((\u201d + ioissrc).split(\u2018;base64,\u2019)[1]).replace(\u2018<\/bo\u2019 + \u2018dy>\u2019, \u2018 <style> \u2018 + selectorplusis + \u2018<\/style> <\/bo\u2019 + \u2018dy>\u2019);<\/font>
\n<\/code><\/p>\n

… can be problematic, too, with UTF-8 (unicode) data (perhaps to do with UTF-16 surrogate pairs (we are not sure)<\/font>). Of course, discovering this during that recent web application “Testing out document.querySelectorAll” in the blog posting thread owning the blog post above, as well as Javascript document.querySelectorAll Textarea Placeholder Tutorial<\/a>‘s penchant for using as an absolute URL (thanks Wikipedia<\/a>) …<\/p>\n


\nHTTP:\/\/www.wikipedia.org\/wiki\/Einstein<\/a>
\n<\/code><\/p>\n

… we discovered it outputting strings like …<\/p>\n


\nKingdom of W\u00c3\u00bcrttemberg
\n<\/code><\/p>\n

… rather than, the better …<\/p>\n


\nKingdom of W\u00fcrttemberg
\n<\/code><\/p>\n

… leading us to be led down an “irrelevant PHP file_get_contents encoding problem garden path” until we undertook today’s “proof of concept” fgc_utf_fix.php<\/a>‘s live run<\/a> simplifying (and thus paring down) the methodologies of that “Testing out document.querySelectorAll” project and decoupling it and putting it back together, plus a good hour of logical calm reasoning, led us to deduct that it was not file_get_contents that was the problem but that [iframe].srcdoc=[HTMLcontent] causing the issue when that [HTMLcontent] contains UTF-8 unicode data. That makes sense. Not all UTF-8 data fits with an initialization statement designed for character data that is made up of one byte per character, so there could be mis-mappings doing this.<\/p>\n

But then we stumbled upon the excellent Function to fix ut8 special characters displayed as 2 characters (utf-8 interpreted as ISO-8859-1 or Windows-1252)<\/a> and adapted its PHP code into a Javascript function equivalent that could help put “Humpty Dumpty back together again”. Cute, huh?!<\/p>\n

If this was interesting you may be interested in this<\/a> too.<\/p>\n