I'm attempting to customize the webUI of a Tasmota binary for an espressif based device. My goal is to embed a base64 encoded PNG into the main page so that the image is available even if the internet connection is unavailable.
I have converted a sample image to base64 via CLI as well as several online converters, and have validated the base64. if I plug the data URI into my browser, the image renders correctly, but if I compile the binary and flash the device to view the page, I receive an error and a broken thumbnail.
my current image is
iVBORw0KGgoAAAANSUhEUgAAAEgAAAAPCAMAAABwbnmhAAADAFBMVEUAAAD////+/v79/f38/Pz7+/v6+vr5+fn4+Pj39/f29vb19fX09PTz8/Py8vLx8fHw8PDv7+/u7u7t7e3s7Ozr6+vq6urp6eno6Ojn5+fm5ubl5eXk5OTj4+Pi4uLh4eHg4ODf39/e3t7c3Nzb29va2trY2NjX19fW1tbV1dXU1NTT09PS0tLR0dHQ0NDPz8/Ozs7Nzc3MzMzLy8vKysrJycnIyMjHx8fGxsbFxcXExMTDw8PCwsLBwcHAwMC9vb27u7u3t7e1tbWysrKxsbGwsLCtra2rq6upqamoqKimpqalpaWkpKSjo6OioqKhoaGgoKCenp6ampqZmZmYmJiXl5eVlZWTk5OSkpKRkZGQkJCPj4+Ojo6NjY2MjIyLi4uJiYmIiIiHh4eGhoaFhYWEhISBgYGAgIB/f39+fn59fX18fHx6enp5eXl3d3d1dXVycnJwcHBvb29ra2tqamppaWloaGhnZ2dmZmZlZWVkZGRiYmJhYWFfX19eXl5dXV1cXFxbW1taWlpZWVlYWFhXV1dWVlZVVVVUVFRTU1NSUlJRUVFQUFBPT09NTU1MTExLS0tKSkpISEhHR0dGRkZFRUVDQ0NBQUFAQEA/Pz8+Pj49PT08PDw7Ozs6Ojo5OTk4ODg3Nzc2NjY0NDQyMjIxMTEvLy8uLi4tLS0rKysqKiopKSkoKCgnJycmJiYlJSUkJCQjIyMiIiIhISEgICAfHx8dHR0cHBwbGxsZGRkYGBgWFhYVFRUUFBQTExMSEhIREREQEBAPDw8ODg4NDQ0MDAwLCwsKCgoJCQkICAgHBwcGBgYFBQUEBAQDAwMCAgIBAQH///8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAfIeyiAAABAHRSTlP//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////wD/////////////////////////////////////////////////////////////c2WY+gAAAAlwSFlzAAALEwAACxMBAJqcGAAABxhpVFh0WE1MOmNvbS5hZG9iZS54bXAAAAAAADw/eHBhY2tldCBiZWdpbj0i77u/IiBpZD0iVzVNME1wQ2VoaUh6cmVTek5UY3prYzlkIj8+IDx4OnhtcG1ldGEgeG1sbnM6eD0iYWRvYmU6bnM6bWV0YS8iIHg6eG1wdGs9IkFkb2JlIFhNUCBDb3JlIDYuMC1jMDAyIDc5LjE2NDQ2MCwgMjAyMC8wNS8xMi0xNjowNDoxNyAgICAgICAgIj4gPHJkZjpSREYgeG1sbnM6cmRmPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5LzAyLzIyLXJkZi1zeW50YXgtbnMjIj4gPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9IiIgeG1sbnM6eG1wPSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvIiB4bWxuczpkYz0iaHR0cDovL3B1cmwub3JnL2RjL2VsZW1lbnRzLzEuMS8iIHhtbG5zOnBob3Rvc2hvcD0iaHR0cDovL25zLmFkb2JlLmNvbS9waG90b3Nob3AvMS4wLyIgeG1sbnM6eG1wTU09Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC9tbS8iIHhtbG5zOnN0RXZ0PSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvc1R5cGUvUmVzb3VyY2VFdmVudCMiIHhtcDpDcmVhdG9yVG9vbD0iQWRvYmUgUGhvdG9zaG9wIDIxLjIgKE1hY2ludG9zaCkiIHhtcDpDcmVhdGVEYXRlPSIyMDIxLTAxLTIxVDE3OjQxOjAxLTA4OjAwIiB4bXA6TW9kaWZ5RGF0ZT0iMjAyMS0wMS0yOFQxODo1NTozNi0wODowMCIgeG1wOk1ldGFkYXRhRGF0ZT0iMjAyMS0wMS0yOFQxODo1NTozNi0wODowMCIgZGM6Zm9ybWF0PSJpbWFnZS9wbmciIHBob3Rvc2hvcDpDb2xvck1vZGU9IjIiIHBob3Rvc2hvcDpJQ0NQcm9maWxlPSJzUkdCIElFQzYxOTY2LTIuMSIgeG1wTU06SW5zdGFuY2VJRD0ieG1wLmlpZDo2ZjJlM2NiYi05NjI1LTQwNjMtOTlmMi05MDZkNDc3ZTgzNmUiIHhtcE1NOkRvY3VtZW50SUQ9ImFkb2JlOmRvY2lkOnBob3Rvc2hvcDpmYTE1NDdjZi03MzhmLWYwNDMtOWNjNC1mMGNhMTM1ZWI3YTEiIHhtcE1NOk9yaWdpbmFsRG9jdW1lbnRJRD0ieG1wLmRpZDo3OWRlMGZkYy0zZDAyLTQ4NzYtYWVmZC03Zjg0ZWUxN2QyNDciPiA8eG1wTU06SGlzdG9yeT4gPHJkZjpTZXE+IDxyZGY6bGkgc3RFdnQ6YWN0aW9uPSJjcmVhdGVkIiBzdEV2dDppbnN0YW5jZUlEPSJ4bXAuaWlkOjc5ZGUwZmRjLTNkMDItNDg3Ni1hZWZkLTdmODRlZTE3ZDI0NyIgc3RFdnQ6d2hlbj0iMjAyMS0wMS0yMVQxNzo0MTowMS0wODowMCIgc3RFdnQ6c29mdHdhcmVBZ2VudD0iQWRvYmUgUGhvdG9zaG9wIDIxLjIgKE1hY2ludG9zaCkiLz4gPHJkZjpsaSBzdEV2dDphY3Rpb249ImNvbnZlcnRlZCIgc3RFdnQ6cGFyYW1ldGVycz0iZnJvbSBpbWFnZS9naWYgdG8gaW1hZ2UvcG5nIi8+IDxyZGY6bGkgc3RFdnQ6YWN0aW9uPSJzYXZlZCIgc3RFdnQ6aW5zdGFuY2VJRD0ieG1wLmlpZDo3ODExOTllZS1kNzdjLTRmM2ItODRmZi05ZmRlMGJlY2I5M2QiIHN0RXZ0OndoZW49IjIwMjEtMDEtMjhUMTc6MjM6NDQtMDg6MDAiIHN0RXZ0OnNvZnR3YXJlQWdlbnQ9IkFkb2JlIFBob3Rvc2hvcCAyMS4yIChNYWNpbnRvc2gpIiBzdEV2dDpjaGFuZ2VkPSIvIi8+IDxyZGY6bGkgc3RFdnQ6YWN0aW9uPSJzYXZlZCIgc3RFdnQ6aW5zdGFuY2VJRD0ieG1wLmlpZDo2ZjJlM2NiYi05NjI1LTQwNjMtOTlmMi05MDZkNDc3ZTgzNmUiIHN0RXZ0OndoZW49IjIwMjEtMDEtMjhUMTg6NTU6MzYtMDg6MDAiIHN0RXZ0OnNvZnR3YXJlQWdlbnQ9IkFkb2JlIFBob3Rvc2hvcCAyMS4yIChNYWNpbnRvc2gpIiBzdEV2dDpjaGFuZ2VkPSIvIi8+IDwvcmRmOlNlcT4gPC94bXBNTTpIaXN0b3J5PiA8L3JkZjpEZXNjcmlwdGlvbj4gPC9yZGY6UkRGPiA8L3g6eG1wbWV0YT4gPD94cGFja2V0IGVuZD0iciI/PrCJQdUAAADOSURBVDgRY2CkEmAYjAYxMDBoI/gMDBuROQwMoXAWXNwGmQOSycQwCKxhBQGDrFB4UDbEICFknQwMC/AaZAFVBeWmwA1C8ifDQoiaqSjmMqDoNGWYj2oSsotgIoyMWyBqOnEaZMwwDS6Bw6ADDOwIzcy4vAamdFHdhIg1DyBrPwMLsjNwGATV7IiqCm7QBUbGvQxMqCGO1SC4I0LhqrRhBrmB+XuQQgKVgWwQkqICGAtukAOQcQSh5ChQ8ChUDZjkQRiEEu6+COvODsq8BgBH7haTEIBidQAAAABJRU5ErkJggg==
and my insertion is
"<img src='data:image/png;charset=utf-8;base64,**base64string**'>"
which I have tried both with and without specifying charset, I've tried inserting my code within or around div and p tags...
this webserver is contained within a .ino which I am compiling with platformio, hence the outer " " and the inner ' '
safari is reporting: Failed to load resource: Data URL decoding failed
when I view the source, I see
<img src='data:image/png;charset=utf-8;base64,iVBORw0KGgoAAAANSUhEUgAAAR8AAAA6CAMAAAC+n61OAAADAFBMVEUAAAD////+/v79/f38/Pz7+/v6+vr5+fn4+Pj39/f29vb19fX09PTz8/Py8vLx8fHw8PDv7+/u7u7t7e3s7Ozr6+vq6urp6eno6Ojn5+fm5ubl5eXk5OTj4+Pi4uLh4eHg4ODf39/e3t7c3Nzb29va2trY2NjX19fW1tbV1dXU1NTT09PS0tLR0dHQ0NDPz8/Ozs7Nzc3MzMzLy8vKysrJycnIyMjHx8fGxsbFxcXExMTDw8PCwsLBwcHAwMC9vb27u7u3t7e1tbWysrKxsbGwsLCtra2rq6upqamoqKimpqalpaWkpKSjo6OioqKhoaGgoKCenp6ampqZmZmYmJiXl5eVlZWTk5OSkpKRkZGQkJCPj4+Ojo6NjY2MjIyLi4uJiYmIiIiHh4eGhoaFhYWEhISBgYGAgIB/f39+fn59fX18fHx6enp5eXl3d3d1dXVycnJwcHBvb29ra2tqamppaWloaGhnZ2dmZmZlZWVkZGRiYmJhYWFfX19eXl5dXV1cXFxbW1taWlpZWVlYWFhXV1dWVlZVVVVUVFRTU1NSUlJRUVFQUFBPT09NTU1MTExLS0tKSkpISEhHR0dGRkZFRUVDQ0NBQUFAQEA/Pz8+Pj49PT08PDw7Ozs6Ojo5OTk4ODg3Nzc2NjY0NDQyMjIxMTEvLy8uLi4tLS0rKysqKiopKSkoKCgnJycmJiYlJSUkJCQjIyMiIiIhISEgICAfHx8dHR0cHBwbGxsZGR</div><div id=' l1' name='l1'>
it's clearly not pulling all of the base64 or truncating it. I'm counting 799 characters in the browser debug of the base64 string, despite the full length of the string is 5168 characters. additionally, safari is complaining about eb('l1').innerHTML = s; citing "null is not an object" and I've no idea what that means or where's coming from.
I'll be the first to admit that I have a tenuous grasp of HTML, even less of CSS, and even less of web language contained within a .ino
happy to receive any pointing in any direction, if this is too big of a can of worms to digest.
oh, also I suppose it's possible to enable SPIFFS and just host the .png on the device's filesystem, but I'm probably even further away from understanding how to implement that. if that's easier, I'm more than willing to go down that road.
Flash size is 1M and binary is currently 602K, so there is some room left.
source code available at https://github.com/arendst/Tasmota/releases/
Tasmota v9.2.0
EDIT:
I have created a 5px x 5px (and consequently 1px x 1px) test image, and same issue. if I load the page and debug, I see the error. If I edit the source html and paste the correct code and close the ", the image then loads.
the browser shows:
<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAUAAAAFCAIAAAACDbGyAAAK3GlDQ1BEaXNwbGF5AABIiZWXB1BTWReAz3uphIQWCEVK6E2QXqWEHkBBOohKSAIJJYQUVOzK4gquBRURLCu6IqLg6grIWhALtkWw9wVZVNR1sWBDZR/wE/x35p9/9sycd7935txT3tw7cx4ALZUjFuegagC5IpkkJjSAmZScwiT1AQLaoAY4sOBwpWJWdHQkYDK+fiMIwLubI0+Aa3YjseDfiQaPL+ViYVIxTudJubkYt2L6lSuWyABwGIPpXJl4hP/AWFOCFYjxhxHOHGU8dYTTx5g56hMXE4ixCwCZyuFIMgGo/pidWcDNxOJQ0zB2EPGEIozXYezLFXB4GHdiPDk3N2+EP2NshfmLAWhmGHukfxMz87/ipyvicziZCh7ra1TIQUKpOIcz/19+mv8vuTny8RwWmFIFkrCYMUZuZ+dFKFiUPj1qnIW8cX/ktkAeFj/OXGlgyjjzOEERir050yPHOUMYwlbEkbHjxpkvDY4dZ0lejCJXhiSQNc4cyUReeXa8wi7gsxXxCwVxieNcIEyYPs7S7NiICZ9AhV0ij1HUzxeFBkzkDVH0niv9pl8hW7FXJogLU/TOmaifL2JNxJQmKWrj8YOCJ3ziFf5iWYAilzgnWuHPzwlV2KUFsYq9MuxwTuyNVnzDLE549DhDHAhADiLgAR8kkA55kAMyYEIQCEEKYuyNA9hxkvHnyUaaC8wTz5cIMwUyJgu7gXwmW8S1n8x0cnByBBi5z2NH5A1j9J4ijIsTtvxWAM8</div><div id=" l1'="" name="l1">
I can see that the base64 is truncated, and the SRC URL is no longer closed by a second set of ". if I manually insert the closing " paste the remainder of the code into the source, the image then renders.
it looks like something in the string (or perhaps a length restriction in the webserver.ino is breaking this?
I am developing an interactive software for thermodynamic calculations using an html help file with "anchor/target" features to select the appropriate part of the help file when the user types a ? as answer to a question.
This works well but at present a new browser window is opened each time the user types a "?". I would prefer to start a new tag if there already is a browser window opened.
At present my program activate the help by creating a character with the content: browser "file:helpfile#target"
and then call the Fortran subroutine execute_system_command(character).
"browser" can be firefox or whatever is the preferred browser by the user (on Mac including path);
"helpfile" contains the path and name of the my html help file;
"target" is a text which depend on the question asked by the software to localize the appropriate help text.
How can I modify this so I open a new tag in the browser (if it is already opened) rather than starting a new browser window?
Maybe something like "target=_blank" can be added?
My program is written in the new Fortran standard so I have no facilities that might be available in Java or Python. It must work using different browsers on different OS.
As #Vladimir pointed out I ment a "tab", there are so many terms. But the answers I had made me reconsider which browser I could use. And I made some new discoveries.
On Windows I used the old Explorer because the path to Firefox contains a space and when I tried to start Firefox to open a file
I had to enclose "C:\Program ...\firefox" within double quotes. That works to start the browser but if I want the browser to open a file I must enclose that also within double quote and that did not work. I am not sure if the problem was the Fortran intrinsic EXECUTE_COMMAND_LINE(txt) or deeper down. But the old Explorer I could start without "" and just enclose "file:/help.html" with "".
So now I tried to be smart wrote a test program enclosing just the directories with a space within using "" i.e.
C:"Program Files\Mozilla Firefox"\firefox.exe "file:/help.html"
in the call to EXEXUTE...
and that worked and opened the helpfile in a tab as is my default.
Problem solved? No, when I had exchanged the browser with path in the program and tested it did not find the browser. The reason was that I have a test that the browser exist using another Fortran intrinsic INQUIRE and as I understand doublequotes are not legal inside file names so INQUIRE did not find firefox when there are " inside the path. Only if " are used around the whole file name it worked. So back to square one? No, I simply removed the " in the path+browser before calling INQUIRE, then used the path with "" inside when calling EXECTUE ...
and now it everything works as I wanted!
I work with a legacy ASP.NET web application that has URLs that use query string values to pass information between pages. I ran into an issue with a couple of URLs that contain spaces, numbers, and dashes that I'm trying to understand.
Here's an example of the URL:
http://myserver.com/SelectReport.aspx?Name=My Report&ReportFile=my_financial_report&ReportTitle=My Financial Planning Across A 1-Year Or 2-Year Outlook
The problematic part of the URL is the ReportTitle query string value.
When I click the link in Internet Explorer 11 or Microsoft Edge, I get a Cant' reach this page. It took too long to connect to this website. Error Code: INET_E_CONNECTION_TIMEOUT error. It should be noted that the link works fine if I turn ON compatibility view settings in Internet Explorer 11.
When I click the link in Google Chrome, I get a `This site can't be reached. The connection was reset. ERR_CONNECTION_RESET" error.
If I delete the 2 in 2-Year, the link works. However, if I delete the 1 in 1-Year and leave 2-Year alone, the link does not work. I'd like to know why removing the 2 in 2-Year allows the link to work, but removing the 1 in 1-Year does not. This is true whether I replace spaces with %20 or not. Does anyone know the answer?
I know that I can replace the spaces in the ReportTitle query string value with plus signs (+) and it will work. This is likely the route I will take to fix the issue, but I was hoping to understand the issue better.
Thanks!
This is the continuation of my comments in the original post. I am writing this answer to share the demo example. It may not be a full answer.
There is absolutely no difference when you have spaces, or spaces are replaced by %20 or spaces are replaced by +. Also, I mentioned earlier your URL has valid characters including -.
See the three links below. I suspect it is your application that is dealing with URL encoding, decoding and having issues. It is not a general problem.
With Spaces
<br>
With %20
<br>
With +
So I have a pretty fresh WordPress installation and am working on a custom theme. I have noticed that special characters aren't displaying properly.
At the moment if I try and use a ' or a "" it is displaying as an í.
I have the character encoding set to UTF-8 in my header and also the browser. I have tried in two browsers and it is the same. If I view the page source it is displaying the correct code for an apostrophe.
If I use the FireFox developer tools and manually edit the HTML and add a " or ' in to the text then it displays this correctly.
I have checked the database and the ' or " is showing correctly in there and the database is set as utf-general.
The page in question so you can see what I mean:
http://dev.evaske.com/Liverpool/about-us-2/
Any ideas what else I can try?
EDIT:
So I've managed to get it down to the fact that cause it's font-face, it doesn't like the fact that WP is outputting the ’. Is there a way to make it so that this isn't happening and it just pulls the "" instead of ’?
I've got a legacy app just starting to misbehave, for whatever reason I'm not sure. It generates a bunch of HTML that gets turned into PDF reports by ActivePDF.
The process works like this:
Pull an HTML template from a DB with tokens in it to be replaced (e.g. "~CompanyName~", "~CustomerName~", etc.)
Replace the tokens with real data
Tidy the HTML with a simple regex function that property formats HTML tag attribute values (ensures quotation marks, etc, since ActivePDF's rendering engine hates anything but single quotes around attribute values)
Send off the HTML to a web service that creates the PDF.
Somewhere in that mess, the non-breaking spaces from the HTML template (the s) are encoding as ISO-8859-1 so that they show up incorrectly as an "Â" character when viewing the document in a browser (FireFox). ActivePDF pukes on these non-UTF8 characters.
My question: since I don't know where the problem stems from and don't have time to investigate it, is there an easy way to re-encode or find-and-replace the bad characters? I've tried sending it through this little function I threw together, but it turns it all into gobbledegook doesn't change anything.
Private Shared Function ConvertToUTF8(ByVal html As String) As String
Dim isoEncoding As Encoding = Encoding.GetEncoding("iso-8859-1")
Dim source As Byte() = isoEncoding.GetBytes(html)
Return Encoding.UTF8.GetString(Encoding.Convert(isoEncoding, Encoding.UTF8, source))
End Function
Any ideas?
EDIT:
I'm getting by with this for now, though it hardly seems like a good solution:
Private Shared Function ReplaceNonASCIIChars(ByVal html As String) As String
Return Regex.Replace(html, "[^\u0000-\u007F]", " ")
End Function
Somewhere in that mess, the non-breaking spaces from the HTML template (the s) are encoding as ISO-8859-1 so that they show up incorrectly as an "Â" character
That'd be encoding to UTF-8 then, not ISO-8859-1. The non-breaking space character is byte 0xA0 in ISO-8859-1; when encoded to UTF-8 it'd be 0xC2,0xA0, which, if you (incorrectly) view it as ISO-8859-1 comes out as "Â ". That includes a trailing nbsp which you might not be noticing; if that byte isn't there, then something else has mauled your document and we need to see further up to find out what.
What's the regexp, how does the templating work? There would seem to be a proper HTML parser involved somewhere if your strings are (correctly) being turned into U+00A0 NON-BREAKING SPACE characters. If so, you could just process your template natively in the DOM, and ask it to serialise using the ASCII encoding to keep non-ASCII characters as character references. That would also stop you having to do regex post-processing on the HTML itself, which is always a highly dodgy business.
Well anyway, for now you can add one of the following to your document's <head> and see if that makes it look right in the browser:
for HTML4: <meta http-equiv="Content-Type" content="text/html;charset=utf-8" />
for HTML5: <meta charset="utf-8">
If you've done that, then any remaining problem is ActivePDF's fault.
If any one had the same problem as me and the charset was already correct, simply do this:
Copy all the code inside the .html file.
Open notepad (or any basic text editor) and paste the code.
Go "File -> Save As"
Enter you file name "example.html" (Select "Save as type: All Files (.)")
Select Encoding as UTF-8
Hit Save and you can now delete your old .html file and the encoding should be fixed
Problem:
Even I was facing the problem where we were sending '£' with some string in POST request to CRM System, but when we were doing the GET call from CRM , it was returning '£' with some string content. So what we have analysed is that '£' was getting converted to '£'.
Analysis:
The glitch which we have found after doing research is that in POST call we have set HttpWebRequest ContentType as "text/xml" while in GET Call it was "text/xml; charset:utf-8".
Solution:
So as the part of solution we have included the charset:utf-8 in POST request and it works.
In my case this (a with caret) occurred in code I generated from visual studio using my own tool for generating code. It was easy to solve:
Select single spaces ( ) in the document. You should be able to see lots of single spaces that are looking different from the other single spaces, they are not selected. Select these other single spaces - they are the ones responsible for the unwanted characters in the browser. Go to Find and Replace with single space ( ). Done.
PS: It's easier to see all similar characters when you place the cursor on one or if you select it in VS2017+; I hope other IDEs may have similar features
In my case I was getting latin cross sign instead of nbsp, even that a page was correctly encoded into the UTF-8. Nothing of above helped in resolving the issue and I tried all.
In the end changing font for IE (with browser specific css) helped, I was using Helvetica-Nue as a body font changing to the Arial resolved the issue .
I was having the same sort of problem. Apparently it's simply because PHP doesn't recognise utf-8.
I was tearing my hair out at first when a '£' sign kept showing up as '£', despite it appearing ok in DreamWeaver. Eventually I remembered I had been having problems with links relative to the index file, when the pages, if viewed directly would work with slideshows, but not when used with an include (but that's beside the point. Anyway I wondered if this might be a similar problem, so instead of putting into the page that I was having problems with, I simply put it into the index.php file - problem fixed throughout.
The reason for this is PHP doesn't recognise utf-8.
Here you can check it for all Special Characters in HTML
http://www.degraeve.com/reference/specialcharacters.php
Well I got this Issue too in my few websites and all i need to do is customize the content fetler for HTML entites. before that more i delete them more i got, so just change you html fiter or parsing function for the page and it worked. Its mainly due to HTML editors in most of CMSs. the way they store parse the data caused this issue (In My case). May this would Help in your case too