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.
Related
I am trying to generate email signatures for my entire company so I am using a script to fill in an HTML template with each individual's information and generating an HTML file that I would like to use for the signature. The generation of the HTML works fine and I can load the HTML into chrome and it displays 100% correctly.
I would prefer to not have to host these images somewhere at the moment and would like them to be embedded in the e-mail. We can achieve this by using outlook on each individuals machine to create the signature by hand, but again we want to avoid that. Ideally, we will generate these templates and then automatically put these files on each employee's computer so all we have to do is select the signature from outlook.
The problem we are having is that when we do this, the image does not load. It seems that outlook won't allow base64 encoded images? I've tried to work around this by trying to attach the image to the email and then referencing it, but this doesn't seem to work either. I used this template. I got the boundary from a test email I sent myself, but I don't even know if this is a good way to go about this either.
In short, is there a way to create an .htm file for outlook signatures that includes the image inside the .htm file?
External image file that will be added as an attachment is the only way - Word (which renders HTML messages in Outlook) does not support base64 embedded images.
Try to create a new signature with an image in Outlook and see how they reference the images.
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).
I send the same email to gmail (the image is loaded correctly) and outlook (Failed to load the given URL).
In gmail i have this html code:
http://xxx/~mgxzbmdx/joomla/images/stories/virtuemart/vendor/logo.png
In Outlook this one:
https://dub113.mail.live.com/Handlers/ImageProxy.mvc?bicild=&canary=nUc%2fUMnrf0l9V5rzT3XB4Cb5axSzPUBWqwI5uP2ZjrU%3d0&url=http%3a%2f%2fx.x.x.x%2f%7emgxzbmdx%2fjoomla%2fimages%2fstories%2fvirtuemart%2fvendor%2flogo.png
Any idea about the reason?
The problem is the file type.
HTML emails should only use .gif or .jpg.
Try with a new picture format. I suppose you use a .png file because it has transparency? It saddens me that I have to tell you this, but you'll be better off faking transparency with split images in nested tables. That's the only way for a html-email not to break.
I think the issue lies with your method/software. Looks like your / are getting converted to %2f which gmail seems to be smart enough to interpret, but Outlook is not. See if there is something in Virtuemart or Joomla that you can turn off link encoding or something like that.
I'm developing a function (C#, ASP.NET 4) which creates and downloads a .ics file.
I'm trying to figure out what restrictions there are on the html within the X-ALT-DESC property. For example, if I send this:
X-ALT-DESC;FMTTYPE=text/html:<html><body><ul><li style="font-weight:bold">#1</li><li>#2</li></ul><table border=1><tr><td>table test</td></tr></table><span style="font-weight:bold">Site Visit Agenda</span><br/><span>8:00 AM</span><br/><span>Check in with management<br/>Facility Inspection<br/>Training and Meeting Setup</span></tr></table></body><html>
When I open the downloaded file, it opens in Outlook 2010, so that seems o.k. While the list stuff renders as I'd expect, the table border doesn't show, nor do either of the font-weight settings get rendered. (On the plus side, the html tags aren't rendered as text, it just doesn't format the alt desc like you'd see in a browser with the same HTML).
Of course, we're trying to figure out what HTML we can and cannot use to format the information we want to show up in the alt description.
Searching around, I can't find anything which talks about what's allowed and what isn't.
Thanks to anyone who has a pointer.
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