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?
Related
Basically when i copy the full path of the website into the browser it shows me the contents just fine. However when I refresh the browser whilst editing the code to see how it looks I get the following error message and have to copy the full path again to see the results.
Your file was not foundIt may have been moved or deleted. ERR_FILE_NOT_FOUND?
A bit of explaining as to why you are getting %2520 is :
The common space character is encoded as %20. The % character is encoded as %25.
The way you get %2520 is when your url already has a %20 in it, and gets url-encoded again, which transforms the %20 to %2520
C:\Users\moh20\Desktop\Personal Portfolio\index.html <-- There is space between personal and portfolio.
If you provide a local file path only, the browser is expected to encode and protect all characters.
So that space which is treated as %20 is again encoded (only % sign needs encoding here) to %2520.
Solution :
Pass the url along with proper protocol like file://
You can do that in two ways :
1. Right-click on your HTML file and select to open it in a browser to view it.
2. Manually type the protocol along with full file path.(or you can just replace %2520 to %20 in the second url after refreshing).
Well here´s the thing, I am using the Terminal to do this. With a text editor such as nano I create a plain text file with the content: "GIF89a2017" and I save it as rare.gif
Here´s the thing, when I do file rare.gif it gives me this output: rare.gif: GIF image data, version 89a, 12338 x 14129 and that is indicating that it is a GIF image with a resolution of 12338 x 14129 and that's what I don't understand. Where´s that resolution coming from?
Another thing is, I thought extension didn't really decide what type of file it is, for example when I take a .gif and convert it into and .exe it still recognises it as a GIF image with the file command. I'm gonna guess that in the problem that I have it is recognised as a GIF image because it was created with the GIF extension but I'd like to know why.
Thanks to everyone!
Where´s that resolution coming from?
It's coming from the (bogus) GIF89 header you put in the file. The four bytes following "GIF89a" define the width and height. Each one is stored as a 16-bit unsigned integer. The characters you put there -- 2017 -- are interpreted as:
32 30 ("20") -- 0x3032 = 12338
31 37 ("17") -- 0x3731 = 14129
I'm gonna guess that in the problem that I have it is recognised as a GIF image because it was created with the GIF extension but I'd like to know why.
No, file doesn't look at extensions. It's because the file had a semi-valid GIF header. If you changed the header to something that didn't start with "GIF89a", it will no longer be recognized as a GIF.
I want to extract these telephone numbers from the website, either as an image or if possible as a string.
Here is an example from the website: Link
As you can see the telephone number is an image.
However I cant seem to view the image when I open the image source:
<img src="http://www.callmyname.sg/search/display_phone_number/VUhkVE1WOW5BV1lFWWxSbVhUdFRObGMzQlRBRU9nPT0=">
But when put into html and viewed in a browser, you can see the image fine.
It's a solution to prevent people like you from scraping their website :)
The url http://www.callmyname.sg/search/display_phone_number/VUhkVE1WOW5BV1lFWWxSbVhUdFRObGMzQlRBRU9nPT0= leads to a script that generates the image - probably based on the argument.
VUhkVE1WOW5BV1lFWWxSbVhUdFRObGMzQlRBRU9nPT0=
Since it ends with an equals sign, I tried to decode it as base64:
UHdTMV9nAWYEYlRmXTtTNlc3BTAEOg==
Now it looks even more like base64, so I tried another round:
PwS1_gfbTf];S6W70:
So it's clearly not plaintext (or not encoded with base64), which would be ridiculous and would let you extract the number this way. They either use some special cipher, or store the numbers in database with this as identifier.
I don't think you can steal the phone number easily, only using OCR perhaps.
When you visit the URL, you will get garbage, since they do not send proper MIME header
�PNG IHDR�,���tRNS���7X}4IDATx���_HZo�g�� E��p��l��EHTx!]�DtQ�M�.x3��.dx�*b]Dl"]�D���bQq.B����Z2$��:ȡ�wq��9�s���Cx>W�}���ٳ��ڶ����]���Ǐ�/_���ݿ���ahh���\q����������555�=���*�"�*�*�f�����}uu�e�d2���o����?00p����J%ȴds���BB�˲�`�`0RJy����n�{cc�e�H$b�ۻ����(�~�_����A4�Z��_�V|��J�w�����t:��333.��ƕ������+^����L`���֑��W��3�X�" y���$p'U"��F���y���z&�ioo��萟�*� ����\�L&Sx����p�e���ׯ_R��y�J%�~����|qq��|e�Z%:�J�{��q��nW�ՉD"�J��~�n4��������̔Ty���qF���>BwGa�z����������8��ߡc�f��B�>!�Ub�N�s���|�F�^/B���Lj��i��NfJ��͛D"����� o!t��`����fvv�eم��V���D)�����x���d2966&�n� ^,0O4��(!D��l�h46�-�~��Tً>B�"�Q�>,�P��ok#U \�BU,�P���=G SA+GIEND�B`�
but it's really just ordinary PNG image:
img http://www.callmyname.sg/search/display_phone_number/VUhkVU5scGlBV1lDWWdFelVEUUhZQWRvQlRZR013PT0=
It's a PNG image, but the server doesn't specify the right content header. It tells your browser that is't an html page in UTF-8 encoding, so you just see some garbage (including the letters PNG at the start).
The <img> tag though doesn't know how to display text so it just tries to load it as an image (and with success).
I don't see a way to extract the numbers in any other way than just reading the image. Because it contains only numbers and will have a similar format all the time, maybe you can find a simple way to parse it instead of using a full fledged OCR library.
It's actually a png-file, generated by a computer before being displayed. You can reference it fine from any other page though, and you should also be able to download it easily (right click, save as ...) Note: I tested this, make sure you save the image with the extension .png and not .html which it will default to.
<img src="http://www.callmyname.sg/search/display_phone_number/QkNOVE1RODNBV1lDWWdVM1V6ZFZNZ1JyRFQ0Rk1BPT0=">
In Safari, when I drag an image from the browser window to the desktop the image take its filename from the last part of the URL. For example:
http://www.mysite.com/images/05
the image name is
05.jpeg
Is this a behaviour consistent across all (recent IE8+) browsers?
Can I decide an arbitrary filename the image will get when dragged out of the browser?
I tried (in Safari) to set the name and alt tag of the image but this doesn't have any effect.
Maybe can I decide the filename setting it in the header of the server response when the image is served?
One method is to specify the desired filename in the header of the response when the file is served.
I'm on php so...
header('Content-disposition: inline; filename=the-image.jpg');
When the image is dragged from the browser window to the desktop the file name is the-image.jpg
Unfortunately this is not consistent across all browsers, in particular Firefox doesn't follow the rule and sticks to the last part of the URL for giving the name.
The solution that works across all browsers is to avoid specifying the name in the header of the response and set the name as the last part of the URL.
As I can manage the routes for my website the solution I adopted is to let the route to images end with a string that is ignored by the server and has the sole purpose of defining a filename for the image in case it's dragged out of the browser.
For example:
http://www.my-site.com/images/05/my%20custom%20filename.jpg
What tells the server what image the client wants is the parameter following images, so 05 in the example.
It's important to note that the filename must be URI-component encoded, escaping spaces, slashes, percents, and so on...
The filename, to be OS friendly, should then be scrubbed from slashes, back-slashes and other characters that may eventually create mess.
We have a web application that creates a web page. In one section of the page, a graph is diplayed. The graph is created by calling graphing program with an "img src=..." tag in the HTML body. The graphing program takes a number of arguments about the height, width, legends, etc., and the data to be graphed. The only way we have found so far to pass the arguments to the graphing program is to use the GET method. This works, but in some cases the size of the query string passed to the grapher is approaching the 2058 (or whatever) character limit for URLs in Internet Explorer. I've included an example of the tag below. If the length is too long, the query string is truncated and either the program bombs or even worse, displays a graph that is not correct (depending on where the truncation occurs).
The POST method with an auto submit does not work for our purposes, because we want the image inserted on the page where the grapher is invoked. We don't want the graph displayed on a separate web page, which is what the POST method does with the URL in the "action=" attribute.
Does anyone know a way around this problem, or do we just have to stick with the GET method and inform users to stay away from Internet Explorer when they're using our application?
Thanks!
One solution is to have the page put data into the session, then have the img generation script pull from that session information. For example page stores $_SESSION['tempdata12345'] and creates an img src="myimage.php?data=tempdata12345". Then myimage.php pulls from the session information.
One solution is to have the web application that generates the entire page to pre-emptively
call the actual graphing program with all the necessary parameters.
Perhaps store the generated image in a /tmp folder.
Then have the web application create the web page and send it to the browser with a "img src=..." tag that, instead of referring to the graphing program, refers to the pre-generated image.