I got a bit of a weird issue here. (Either that, or I'm just overlooking something stupidly simple.)
I have a file upload form, and I want it to only accept certain types of files amongst which MS Word documents. I added the .doc and .docx MIME-types (application/msword and application/vnd.openxmlformats-officedocument.wordprocessingml.document respectively) to the accept attribute of the file input field, yet when I hit "choose file", the .doc and .docx files are still greyed out as not allowed to be uploaded.
So, what am I missing? Any help or pointers would be greatly appreciated!
(And yes, I know the form-check isn't a good way to filter uploaded files. I've got PHP covering that, this is more of a convenience for the user, so they don't go and upload a disallowed file.)
Support of the accept attribute has been poor but is slowly becoming more common. On my Google Chrome 19, the element <input type="file" accept="application/vnd.openxmlformats-officedocument.wordprocessingml.document,application/msword" /> works so that the selection is limited to .doc and .docx files. Other browsers generally ignore such an accept attribute, though e.g. Firefox supports some simple cases like accept="image/gif".
In addition to this, browsers may map MIME types to filename extensions (which is generally what file systems treat as “file type” indicators) in different ways. Therefore, although the attribute may work in some situations, it might make things worse when the mapping is different.
I'm the MIME type for Word files likely isn't registered with the browser, so the Word file is being reported as application/octet-stream. In general, MIME type filtering in HTML forms does not work reliably, except for common image MIME types.
You could create a JavaScript solution to check the extension of the file.
Related
I am creating a HTML 5 user manual. This contains a number of image folders and js fodlers. Now i wish to distribute this as a single document. In Windows there is mht or something to that effect. Is there any way I can do this on ubuntu that is not browser or OS dependent?
notice that :MHTML, short for MIME HTML, is a web page archive format used to bind resources which are typically represented by external links (such as images, Flash animations, Java applets, audio files) together with HTML code into a single file. The content of an MHTML file is encoded as if it were an HTML email message, using the MIME type multipart/related. The first of the file is normally encoded HTML; subsequent parts are additional resources identified by their original URLs and encoded in base64. This format is sometimes referred to as MHT, after the suffix .mht given to such files by default when created by Microsoft Word, Internet Explorer or Opera. MHTML is a proposed standard, circulated in a revised edition in 1999 as RFC 2557.
So try to save document as regular html with none of dependency. this will be run at any OS independently.
Well, as far as I know you won't be able to really distribute this manual as HTML OS independent.
BUT: you can distribute it as PDF, ZIP-file, host it anywhere, ePub, etc. These are pretty good options for your needs. Safari has a pretty cool feature called webarchive, but this only zips ONE single page to a viewable, always-the-same-looking page. And it will only be viewable with Safari. So you'd have to do this for ALL your pages...
My web application has an feature wherein preformatted RTF documents are used as templates and the user can select the source of data and then merge with the RTF documents templates to create merged RTF files. The RTF templates have placeholders which get replaced with user selected content. The final doc can either be saved or opened directly if word/wordpad is available on the local users machine.
Now, I have a requirement to display the merged document to the user for confirmation. The user may either print or save the document to the system directly. The display should not be word/wordpad application but should be within the application itself, using textarea or something similar to render the document. Can you please let me know if its possible to render the RTF document in textarea or not. Along with the displayed content, there should be options to print and save the document.If I have to convert the RTF to Html and then display the html content in textarea , please let me know how i can do the conversion and then display the html in the page.
That's a very difficult requirement. First of all, let's dismiss the idea about a <textarea>, because it does not support any formatting at all. All the WYSIWYG editors you've seen out there are based on <iframe>s.
Secondly, no browser can directly display a RTF. You can embed it as an <object>, and some might show it (IE probably will), but I can't say which ones won't. Portable devices almost certainly won't. But you should test this though, maybe it works well enough after all.
Failing that, HTML conversion is also out of question, because RTF has very very many features that cannot be emulated in HTML. There are some converters out there (google), but but they will all come with serious limitations. If you want full support, you will have to do your own rendering via Canvas or Flash or something.
To this end I'd suggest checking out Google Docs. They've gone through all of this hassle and have a rather feature-full engine for displaying most possible documents. I think it was also possible to embed them in your own webapges, though I've never checked it out myself.
Use a <PRE> tag to Display/Render RTF doc in browser.
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 have .txt files which are mostly (truly) html document (they have the header, body, html tags etc.). (I'm working in Windows environment here). I would like any browser to readily read them as html document (html document with normal .html suffix). Right now i have to rename the .txt file to be able to read it in the browser (Ex: myfile.txt -> myfile.txt.htm). Any trick we can apply to fool the browser right away?
Relative question: Is there any code i could add on top of those .txt file so that only .txt files with that code will be open as html document and seen as such by browsers? (code could be anything added with hexadecimal editor ot plain ascii). Thanks.
Since you're reading the file directly off of your file system (ie: using a file: URL rather than http: or something else) your browser is using the extension to determine the content-type of the file. How this mapping from extension to content type is made varies from browser to browser (and also from OS to OS to a certain extent).
First off, I should say that I'd be a bit afraid of making this sort of change. There's probably lots of code that has a hard-coded assumption that .txt maps to text/plain, so altering that mapping is likely to expose all sorts of nasty bugs. Caveats aside, here's what you need to do:
In Firefox, ExternalHelperAppService is used to determine the type of file: URIs. Note that one of the steps is to use a hard-coded list of extension to type mappings, which most likely has .txt mapping to text/plain.
In IE the file type mappings come from OS settings. It varies a bit depending on which version of Windows you're dealing with, but usually in the same general part of the settings where you choose which program to run for each extension you can also set a mime-type for each extension. (This is also the place Firefox looks in the "the Operating System is asked for a MIME type" step mentioned on the page I linked to above, BTW.) If you sent the MIME type for .txt to text/html you should get the behavior you want.
It is the HTTP headers which tells your browser what kind of data it is transfering so you have to edit the settings of your web server
Save the text with its htm-codes in WORDPAD as OPEN Document text.
Use in the name of the file the extension .htm.
This worked for me.