I was wondering if any of the modern browsers actually cache the embedded images -- base64 strings, or not?
Also is that a possibility in the near future? based on the official documents by either W3C or major browsers.
I don't think so, because you're missing an Resource Identifier as the key for the cached image. With embedded images you only have the data itself.
Furthermore a potential conditional request for inlined images must be at the level of the HTML document containing it. The inlined image is just data with no additional request. But HTTP does not support something like conditional requests for parts of the data.
As I understand it, if the base64 string is part of the HTML document (inline) then it will both have to be downloaded and parsed as an image each time the document is downloaded - there is no way to cache fragments of documents. If it is a background image in an external CSS file then it can be cached with the CSS file, but will still need to be parsed with every request. I have also read that base64 encoding adds circa 30% overhead on top of the image bytes, but this can largely be negated by gzipping.
Browsers can cache downloaded files. If the Base64 string is in a text (or JSON) file then it can be cached. This data can then be used directly in the HTML (or if JSON, parsed with Javascript and used with HTML).
Related
Learning how to utilize Bootstrap, I noticed that the thumbnails had strange markup for the image source (at least, strange to me.)
<img data-src="holder.js/260x120" alt="260x120" style="width: 260px; height: 120px;" src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAQQAAAB4CAYAAAAUn4wEAAAGP0lEQVR4Xu3aPUsdWxQG4LEwKiSFTbQTsUwsRfDvp7KRVBFrEVIEsRFT+HHvHJjDODrH96ghQ9aT5nLD8rjXs/Z+3TNx5fLy8qHxhwABAv8LrAgE+4AAgU5AINgLBAjMBQSCzUCAgECwBwgQeCrghmBXECDghmAPECDghmAPECCwQMAjg+1BgIBHBnuAAAGPDPYAAQIeGewBAgQSAe8QEiU1BIoICIQig9YmgURAICRKaggUERAIRQatTQKJgEBIlNQQKCIgEIoMWpsEEgGBkCipIVBEQCAUGbQ2CSQCAiFRUkOgiIBAKDJobRJIBARCoqSGQBEBgVBk0NokkAgIhERJDYEiAgKhyKC1SSAREAiJkhoCRQQEQpFBa5NAIiAQEiU1BIoICIQig9YmgURAICRKaggUERAIRQatTQKJgEBIlNQQKCIgEIoMWpsEEgGBkCipIVBEQCAUGbQ2CSQCAiFRUkOgiIBAKDJobRJIBARCoqSGQBEBgVBk0NokkAgIhERJDYEiAgKhyKC1SSAREAiJkhoCRQQEQpFBa5NAIiAQEiU1BIoICIQig9YmgURAICRKaggUERAIRQatTQKJgEBIlNQQKCIgEIoMWpsEEgGBkCipIVBEQCAUGbQ2CSQCAiFRUkOgiIBAmOCgT09Pm4uLi/nKPn361BweHj5a6eXlZfP9+/fm/v5+9vfP1ZyfnzdnZ2fzr9vd3W329vZe3fHJyUnTft+tra1mf3//0ecka37v9by6EV84KiAQJrY5ukM3XFb/wA/DoKvtH9Th4etqXhsK/c8bBkKy5vdez8TG9s8sRyBMaJS3t7fNt2/fmru7u6Y7uP2D9PXr1+bz58/N8fFxc319/aRmZWWlOTo6atbW1uY13eHtfoKvr6/Pbhurq6tx58MD3w+EZdf8HuuJF65waQGBsDTZn/uC7vB3B3tjY6MZHridnZ1ZaLSPCu3hb2uGf/o3iDZEtre3Z1f99hHj4eFh9nU3NzfzR44ufIZf1w+f9nu0YfL79+9HjwzJmjc3N+ffa2w9z/Xx56R98piAQJj43hge0g8fPswOV/vf9oBeXV3NOuj/1B4e/mGwdIey+8nffs7BwUHT/n978+g+qw2d9jby8ePH5suXL09uHWN0Y2vuwmhsPRMfRYnlCYQJj7k7kO0h7d4hjD2Lt20MaxbdNNqXi/3bR3uL+PnzZ9P/mj5Nfy3PvVTsahet+aX1THgUZZYmECY66v7B6h+kfiAM3zN0db9+/Zr960JyANM3/0kgvLTmZD0THUeZZQmECY567GC1S00eB7rHiuSK3r8ljN0O2u/7UiC8dc3tDcWfvy8gEP7+DB6tYNHBWjYQ2s966SXe8PcHxh4HFgVCuuZkPRMbR7nlCISJjbx70bfMs/zwTX/6z47920b70vDHjx+zm0AXIuk7hNes+S3/DDqxkf1TyxEIExrn2C8cdUt87ncT+stf5heTnvuJv+iQjt0Q3rrm1/6i1ITG9k8tRSBMaJzD6/twaf3DMzyIz131F70w7L7X2Iu+4eeNBcIya05fYE5oJOWWIhDKjVzDBMYFBILdQYDAXEAg2AwECAgEe4AAgacCbgh2BQECbgj2AAECbgj2AAECCwQ8MtgeBAh4ZLAHCBDwyGAPECDgkcEeIEAgEfAOIVFSQ6CIgEAoMmhtEkgEBEKipIZAEQGBUGTQ2iSQCAiEREkNgSICAqHIoLVJIBEQCImSGgJFBARCkUFrk0AiIBASJTUEiggIhCKD1iaBREAgJEpqCBQREAhFBq1NAomAQEiU1BAoIiAQigxamwQSAYGQKKkhUERAIBQZtDYJJAICIVFSQ6CIgEAoMmhtEkgEBEKipIZAEQGBUGTQ2iSQCAiEREkNgSICAqHIoLVJIBEQCImSGgJFBARCkUFrk0AiIBASJTUEiggIhCKD1iaBREAgJEpqCBQREAhFBq1NAomAQEiU1BAoIiAQigxamwQSAYGQKKkhUERAIBQZtDYJJAICIVFSQ6CIgEAoMmhtEkgEBEKipIZAEQGBUGTQ2iSQCAiEREkNgSICAqHIoLVJIBEQCImSGgJFBARCkUFrk0AiIBASJTUEiggIhCKD1iaBREAgJEpqCBQREAhFBq1NAonAfyCREfyopr43AAAAAElFTkSuQmCC">
What's going on here, and why is this being done? Is the image somehow saved to local storage at some point in base64?
To clarify, I'm asking about the src="image:/ part.
What you are seeing is not the HTML5 data- attribute, but the data URI scheme. To quote Wikipedia:
The data URI scheme ... provides a way to include data in-line in web
pages as if they were external resources. This technique allows
normally separate elements such as images and style sheets to be
fetched in a single HTTP request rather than multiple HTTP requests,
which can be more efficient.
What you're seeing is the base64-encoded image data, in this case a PNG. When browsers see this, they decode the data as instructed, and display it as if it were an external resource.
Given this image's size, the creators of Bootstrap rightly believe it is more efficient to inline the image like this rather than keeping it separate. Had they kept it separate, it would require an additional HTTP request to load the image, which increases the total load time of the page.
In the case of Bootstrap, what I think you are seeing is Javascript being used to generate the data that goes in the src attribute.
If you look at the raw source (not the source in the inspector), you will probably not see the src attribute, only data-src.
The data-src attribute is an instruction to javascript to use the holder.js script to generate the data to go in the src.
So holder.js generates the image, which is then loaded into the img as a data uri as explained by the other answers.
I need to create an HTML file that will be stored on disk; later a user will attach this file to an email and send it to a user who will click on the file to have it display in their browser. My customer requires that the image file be embedded directly in the saved html file, not as a link to a URL that gets loaded when the doc is opened in the browser.
I've seen (and tried) the base64 code that looks like this:
<IMG SRC="data:image/gif;base64,
but my images are 150K or larger and at least in IE8, they are too big to display properly.
Is there another way to get large images embedded (not linked) into an HTML document? Remember, I won't have a program running that is interacting with the browser.
IE 8 has a data uri limit of 32k (http://en.wikipedia.org/wiki/Data_URI_scheme), which is why things are failing for you there. Also, Versions of I.E. below 8 won't support this.
That I know of, there is no way around this. You could, however, break up the image and encode separate parts of it. Since it sounds like this content isn't dynamic in any way, that might not be too hard. Otherwise, you might just want to use a CSS hack to server a different style to IE8 and below or attempt to load the image from a server for those browsers.
Thanks to all, but Albert's post gave me the answer, a bit indirectly, though. I originally created my html document as an email and imbedded the image directly in the email, mixing htm & mime. All I needed to do was change the extension on my document from .htm to .mht.
The pertinent part of my document code is:
<img border=3 width="360" height="360" src="cid:001#mime.mail"></table></div></body></html>
--_=_Boundary_001_VXUXGWO1.FBLEINFI
Content-Type: application/octet-stream; name="1.jpg"
Content-Disposition: attachment; filename="1.jpg"
Content-ID: <001#mime.mail>
Content-Transfer-Encoding: base64
Content-Description: 1.jpg
/9j/4AAQSkZJRgABAQAAAQABAAD/2wBDAA...
Notice the src="cid:001#mime.mail" corresponds to the Content-ID tag just above where the actual image data starts.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Is it safe to serve an image on the web without an extension?
I'd like to use something like <img src="advertisements/12" style="border: 1px solid"> in a page. FireFox won't display it, which makes me think I have to have a file extension for the file. Am I right here (for the other browsers too), or does FF like mime types?
EDIT
I've tried all sorts of stuff and it still won't work. I now put an extension on the file correctly (.swf for Flash, for example). I've changed the directory, etc etc. When I call file_exists(), The file is there, all happy and such, however I absolutely cannot get it to render on the page. It could either be a .PNG in an img tag, or a Flash object. Neither works. What am I doing wrong :-(
Also, if I rename a non-uploaded file to the file the script is looking for, that works fine, but the uploaded ones don't...
Yes, you should be able to.
Browsers initially don't look at the filename, they look at the MIME type listed in the Content-type header in the response from the HTTP server. If the content type is image/jpeg, or png or gif or whatever, things are good and it will happily render the image.
If there is no valid MIME type, some browsers will try to guess what the type is. They'll look at the extension of object being request, or they'll look at the first few bytes. If that fails, then you get a redex.
That used to cause some woes back in the early days of Firefox / Firebird, because it was strict about mime types and often refused to render something without a valid MIME type. IE made a guess, and so many sloppy web servers would serve up pages that would render fine in IE, but not in others. These days though, things are much better.
So, as long as your web server is providing the right MIME type when the img object is requested, you'll be good to go. If you are having problems, check what your web server is doing when "advertisements/12" is requested.
What is the server returning? The file extension isn't used for anything, really. The browser is checking for the Content-type header, which should be something like image/jpeg or whatever type of image you're serving.
This is used pretty often in sites which dynamically serve images, often from a database. I've seen plenty of image URLs like image.aspx?id=37 which, while it technically has an "extension" doesn't really mean that it's an image. It's all in the HTTP header values.
Providing a MIME type might help, although the server should theoretically be providing the correct one. If it's a specialized PHP (or similar) script that's serving up the image, you have to make sure you set the HTTP Content-Type header to the appropriate MIME type.
If you want to avoid using the <img> tag, you can use <div> in conjuntion with CSS backgrounds, but that's not going to help if the browser doesn't recognize advertisements/12 as any known image type.
2022 Edit:
Wow! Well, it worked good enough back then... But, for modern day detection there is https://www.php.net/manual/en/function.exif-imagetype.php ...with webp detection as of v7.1.
I found myself with similar image viewing problems after renaming images uploaded from web forms. Since I could have a mix of gif, jpg, jpeg, or png files I went looking at the file properties.
What I ended up doing was checking the MIME type (which is usually within the $_FILES array while processing the uploaded files) and appending an associated extension to the file name.
if($_FILES[$fieldname]['type'][$key]=='image/gif') {
$ext='.gif';
}
if($_FILES[$fieldname]['type'][$key]=='image/jpeg') {
$ext='.jpg';
}
if($_FILES[$fieldname]['type'][$key]=='image/pjpeg') {
$ext='.jpg';
}
if($_FILES[$fieldname]['type'][$key]=='image/png') {
$ext='.png';
}
List of common image mime types.
--Which did fix my problem as my browser was trying to download my images as binary files without the filename extension.
Server - Debian, Apache 2.2, PHP 5.3
Web Client - Kubuntu 11.10 ,Firefox
I have a web application that will display logos. Some of the logos will be in GIF format. Some will be in JPEG format.
I'd like to standardize a file naming convention, so that I can find the logo file given the company's Primary Key. For example "British Petroleum" has a PK of 1459, and their logo is stored in /Images/Logos/C1459
So my question is this:
Are the file extensions important? Can I just save the files, and strip off the .JPG or .GIF and expect all browsers to be able to identify and render the file? Or do some broswers rely on the file extension for identification?
I've tried this on a test machine with IE7 and it works fine, but I don't want to assume that all other browsers work the same.
EDIT:
A Follow up question. Hows does IIS determine the MIME Type of a extension-less file?
More important to a browser is the MIME type transmitted along with the file during download - historically, some did fall back to heuristics such as file extension or trying to calculate based on the bytes transmitted, but if the MIME type is correct, there would be no need.
You'll definitely want to test it in as many browsers as possible, but it should be fine. As long as the file format is correct and the MIME type is being conveyed properly, the browser should merrily display the image just fine. (A lot of sites will have "images" with URLs like: /images/dbimage.aspx?id=123)
Edit: More important to the testing than different browsers, actually, is different image types. If there are any image types that don't get sent with the correct MIME type, you'll want to identify those and either address them or disallow them.
This seems a bit back-to-front to me. Why not:
1) Convert all images to the same type when you first store them?
or
2) Search for a company's image using a wildcard search (ie match /Images/Logos/C1459.*) and load the file that returns a positive match. As you are using primary keys, you can be confident that you should only find one match for each company.
I am receiving a BASE64 encoded string from a WebService. The string represents an HTML page, and I can use built-in ColdFusion functions to convert and display it. However, I need a GIF representation of the HTML page, and I'm wondering if there's any way to do this using ColdFusion.
NOTE: The website I'm working on is ColdFusion 8.
UPDATE: As it turns out, the vendor gave me incorrect instructions (different from their documentation). I don't need to output a GIF of the document they are sending, so this is a non-issue now. However, seeing as the question has received 6 upvotes already, I'm going to leave the it open, as I'm curious if there is - or will be - an answer someday.
You could save the html to the file system, and use this technique for creating URL Thumbnails
Since CFIMAGE's writeToBrowser doesn't allow you to output a GIF (as you've no doubt found out), you'd have to take the image and save it to the filesystem as a gif, then write an HTML IMG tag pointing to that GIF file.
You can't write a gif but you can take the base64 and write it to the browser as a png.