I have the following line
<a id="export" href="data:text/plain;base64,MDow" download="fname">Download</a>
I'd expect this to save a file as fname.txt, however, Chrome always saves it as download.txt. Tested this on firefox, it gives the expected behavior fname.txt.
This suggests that this behavior is intentional and won't be fixed, so my question is, is there a way to download it with the correct filename?
It's not just a security concern
the pseudo specification says:
The attribute can furthermore be given a value, to specify the file
name that user agents are to use when storing the resource in a file
system. This value can be overridden by the Content-Disposition HTTP
header's filename parameters. [RFC6266] In cross-origin situations,
the download attribute has to be combined with the Content-Disposition
HTTP header, specifically with the attachment disposition type, to
avoid the user being warned of possibly nefarious activity. (This is
to protect users from being made to download sensitive personal or
confidential information without their full understanding.)
Sure if the browser detects a header which go against yours, will not use your definition.
Which is not your case...
You have a bad formated base64 text:
this should work.
<a id="export" href="data:text/plain;base64,MDow" download="fname.txt"> Download</a>
And try a diferent encoding if you need a expanded charset than utf-8, use iso-8859-1 insted
example 2
<a download="fname" href="data:image/jpeg;base64,/9j/4AAQSkZJRgABAQAAAQABAAD/2wCEAAkGBwgHBgkIBwgKCgkLDRYPDQwMDRsUCRAKIB0iIiAdHx8kKDQsJCYxJx8fLT0tMTU3Ojo6Iys/RD84QzQ5OjcBCgoKBQUFDgUFDisZExkrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrK//AABEIADAAMAMBIgACEQEDEQH/xAAZAAACAwEAAAAAAAAAAAAAAAAFBgMEBwD/xAAsEAABBAIBAgUDBQEBAAAAAAABAgMEBQYRIQAUBxITIjEVFjIXQVGBkWEz/8QAFAEBAAAAAAAAAAAAAAAAAAAAAP/EABQRAQAAAAAAAAAAAAAAAAAAAAD/2gAMAwEAAhEDEQA/AHXK8lySNmJo8fNE0y1U/UX37X1EtIbDhQr3IPAA0eR/PPQZzL807GdKh2vh/P7KK5KdZhSXnZPboGyQAr+udDZHXZu5F/UWzizLCFA73DnYrT018NRu4W8oAEn/AHjnQPSNjWPxcVg5NKmZVjMruaKVFaZhWIXJVIUAQACBv8dcc7I6DQMlzTKq6jxm5hjH24du1FbdVN9UelYupKiokK0loAfJJI5+ep6TJ80do8gubeLTIh18WSqIpht4dzIbSFIcSVHS2FDelAgn9uoLCkqsq8LKWmmWjMWZGp2LBpKpCEeXysFIW4CCQ1tXJA/b56TcPtr+HR5ZiVuv14bFFMlRJKy4r1I6UpbQWVKOiwQCU6Gv46Brby/NOxgyplr4fwO9itymmZsl5qT26xsEgq/rjjYPRnFMlySTmIo8gNE6y7U/UWH6r1FNLbLgQn3LPII2eB/HPWW5Lj8XKoOMyoeVYzF7aiixXWZtiESUyEgkggA6/LXPOwennCHIv6i1kWHYQp/ZYc1FdehPh2N3CHkggEf7zo6I6Al4jB2NkdA/IpMcsK2dMj1zjk6IXbdDi1qJ8pPtCQn4+eSeOhMaC05kd9CXjWEqrYkOQ7GsGoAMFiYhektSXPxSoJ9y0jkDnqfxOpWrXI0Ln5fFqGWK4OwYrlmI7ovUrX6bxQQfbokeZPu44+OlythOl9S7TOcWaZah6TFgW5TBsLUEe+YhX/qFjYcPyoa6C94lUTU6qrptXf18K+VUtRlV8KaG4Myq8qz6cdtI87gWshKE/BAA+ehr139BnVcr6W9ZefE2qP0UR/WjJyEnfbvDY93GlN/lo/HVHKnb+uyqnnW9RWSocmAzBiSKKM4uM1HU4SgxVK4TIABKNcAFOh1VRcUuMZHKYtI2YJrZcNbyW7NCBbt3q167psKISFBKTpz8gd9Bp2FNYhkOOO2M3FKmvegqLFimTWstNNTEISpw870kEn8tEa56I439A+6l/a/2l2fYHz/TfT+udx6g3vycelry/wDfNrrMa+L6uK3UFrLYS4dh69jCjx7PeXSbFxsBDEhPwvzDhaBslfweiXgvj7tVmProqL2Eyqk8klyzilto2vqNlQbOh7dDgHng9AZzduL+otnKmV8Kf2WHOymmZrAdjdwh5RBIP+caOiekbGsgi5VByaLMxXGYvbUUqU09CrgiSmQkAAgknX5b452B1qWV41kknMTeY+KJ1l2p+nPsWvqKaW2XCtXtQOQRocn+eOgzmIZp2M6LDqvD+B3sVyK69CjPNSe3WNEAhP8AfOxsDoA1rMunGPDmEitWqhiMVljJsAwstMOIBCvO5+CUhHuO/j53rqS5g4rc5uqLDvWbWZZtFLr1nMafrY9c46QW4hGymQknbaTsAE9Xsq8Pc0sYNPBqL5mLDjU7MGXH7x5EZ2QkELPlSnSkkEDnkgcjq1X+EzTeR49YyO1js1VdGDiYOkOv3rSworVtHuSR8nhR4+OgBrFfBtYuH1dJUzbJMxDSrOsiJcnQ6Lzel6rjqfc3LQoBRVrygkH/AJ03YiLX73ktzMnrJ8OFAXDagx7Bbtl7HU6dkNnj1de1ahrk610queE+Vfe865h3jMCHNnuOOqhS3WrL6ct3zFIIRrza/YkjYHTx4eYX9q/VXJhZlTJM95xqcr32Sq5Xl0lxwpBKtp8xA42d9B//2Q==" >image code</a>
Note: My ".txt" extension at download attribute is not necessary but it is good practice
Edit2: TEsted in 37.0.2058.2
fidle:
http://jsfiddle.net/yL8UZ/
Related
I was sent a hyperlink to a Tableau Public link by a client. When I tried opening it, I got a 404 exception. I wrote back to the client but was told by the same that the link was working fine. I visited his profile page and was able to open the presentation there, but the URL that ended up working was slightly different than the one behind the original, non-functioning link.
Here's the anonymized URL behind the original link
https://public.tableau.com/profile/[client_name]%23!/vizhome/Project-AirportDelay/FlightPerformancesinUSA?publish=yes
And here's the URL via the profile page:
https://public.tableau.com/profile/[client_name]#!/vizhome/Project-AirportDelay/FlightPerformancesinUSA
The only differences I see are ?publish=yes and %23!. I tried appending the former, ?publish=yes, to the working URL, and it was still functional. So I suspect that it has to do with the other difference %23! vs. #!. Could the first work because he is opening it from his computer where he is likely logged onto Tableau Public? What's the difference between these syntax? Any ideas about why the original hyperlink might not be functional?
For obvious privacy reasons, I can't provide the whole URL.
It looks like the basic URL pattern for passing filters ?publish=yes
and
%23 is the URL encoded representation of #
The first # after the authority component starts the fragment component. If the # should be part of the path component or the query component, it has to be percent-encoded as %23.
As # is a reserved character, these URIs aren’t equivalent:
http://example.com/foo#bar
http://example.com/foo%23bar
There are countless ways how a URI reference could become erroneous. The culprit is often a software, like a word processor, where someone pastes the correct URI, and the software incorrectly percent-encodes it (maybe assuming that the user didn’t paste the real/correct URI).
Copy-pasting the URI from the browser address bar into a plain text document should always work correctly.
I need to create a website (in PHP) that has filenames that include international characters.
For example: transportører.php (notice the 'o' with the diagonal line through it).
So I happily create the file, save it, and upload it to the web server. Whenever I LINK to this file, however, it all goes wrong. I'll have the usual link syntax:
My Link Text
Upon clicking such a link, the web browser attempts to navigate to a non-existent page:
The requested URL /transportører.php was not found on this server.
Notice how the filename has been mutated? The "ø" character in "transportører.php" has been changed into the bizarre "ø" symbol (that's not a comma after the "A", by the way, but an actual component of the symbol itself).
There's obviously some sort of translation going on here, but what, why, and how do I prevent it?
I think, it's two possible reasons:
html encoding
Possibly the encoding of the html file is wrong, so the link is actually pointing to a wrong path. Add
<meta charset="UTF-8">
in the head section of your file.
server settings
If the server is resolving the link wrongly (you can check this by typing the address of your norwegian-named.php in the browser and see if it is replaced), you need to know which server you are using and investigate in this direction. For apache, How to change the default encoding to UTF-8 for Apache? looks promising.
As the URL isn’t percent-encoded in the hyperlink, browsers assume¹ UTF-8 for percent-encoding it, where ø becomes %C3%B8.
However, your server seems to expect/use ISO 8859-1 (instead of UTF-8), where ø becomes %F8.
A quick fix would be to link to the ISO 8859-1 percent-encoded URL:
transportører
(A better fix would be to let your server use UTF-8 for everything, and then to use the UTF-8 percent-encoded URL in the hyperlink.)
¹ Either by default, or because the linking page seems to use UTF-8 (at least according to the HTTP header Content-Type: text/html; charset=UTF-8).
Well, this is embarrassing. Everything was - in actual fact - working correctly. The 404 error made the filename LOOK "wrong" - e.g. transportører.php. However, this is actually correct. That is how HTML seems to reference the file "behind the scenes". So to the browser, "transportører.php" is synonymous with "transportører.php"
What was happening was that FileZilla (my FTP client) objects to international characters. It was changing the filename during upload.... replacing the international characters with "something else". The filenames LOOKED correct on the screen (when I viewed the website folder with Linux Mint's native FTP client), but the underlying character coding was NOT correct. The web-browsers could tell the difference, and hence didn't associated my links with the (mutated) file names, hence triggering an error 404.
The solution in a nutshell: I used Linux Mint native FTP to upload my files, overwriting the ones uploaded by FileZilla, and everything just sprang into life.
Thanks to everyone who offered advice... it was all good stuff, just not the solution in this particular case.
I have a form to select images for a gallery, and I want to allow user to select only jpg,gif and png image formats.
And now, for testing, I change extension of a image to .bmp like "image1.bmp", and when I click in my input file to select a image, this "image1.bmp" is hidden, but If I select "show all files", this "image1.bmp" appears, and I can select this "image1.bmp" and send this image in my form. And Im inserting this image with this format on database.
This is normal using accept="image/gif, image/jpg, image/jpeg, image/png"??
Because what I wanted is to block all formats that are not gif,jpg or png.
I have this input file:
<input type="file" name="img[]" multiple="multiple" accept="image/gif, image/jpg, image/jpeg, image/png" />
This is common browser behavior. Browsers that support the accept attribute use it to create an initial file filter, but they do not prevent the user from changing or removing the filter and thereby selecting and submitting any file they like. The purpose of the attribute is to help users select files of appropriate types.
What browsers should do is less clear. HTML 4.01 says that the accept attribute “specifies a comma-separated list of content types that a server processing this form will handle correctly. User agents may use this information to filter out non-conforming files when prompting a user to select files to be sent to the server”. The reference to server-side processing may be misleading. The attribute affects client-side (browser) behavior only. The intent is to say that the attribute value should be written according to what file type(s) are expected from the user; it is more or less self-evident that the server-side form handler should be written so that it is capable of handling the specified type(s).
HTML5 LC is more verbose. It says that the attribute “may be specified to provide user agents with a hint of what file types will be accepted”. It then describes how it could be used by a browser to provide an adequate user interface. It also says: “User agents should prevent the user from selecting files that are not accepted by one (or more) of these tokens.” This might be sensible, but browsers do not actually do that. Even if they did, the attribute would not constitute a security measure of any kind (because a user could edit the form, or write a form of his own, or use a browser that ignores the accept attribute). Its purpose is to protect a normal user from making mistakes, like submitting a file of a type that will be rejected by the server-side handler.
(Browsers interpret the accept attribute value in rather simple way. They work on filename extensions, so if you name a GIF file, or a plain text file, or a binary program file so that its name ends with .png, they will treat it as a PNG image file, instead of inspecting the content of the file. The .bmp extension is problematic, since it commonly means Windows Bitmap, for which there is no registered MIME type; browsers may treat the nonstandard notation image/bmp as corresponding to .bmp.)
You cannot block sending of files. What you can do is to deal with files properly server-side, and there you should not of course rely on filename extensions but detect the types from the file content.
Clearly if you click "show all" can obviously see other files.
Your question is not quite hide or show, but filter at the time of upload, you have two solutions:
1) SERVER-SIDE:
With php (just an example) and regExp:
if (preg_match('#^image\/(png|)$#', $_FILES[$i]['img']['type']) === false) {
echo 'Invalid extension!';
} else {
//Save file
}
2) CLIENTE-SIDE:
With javascript use determinater lib:
https://github.com/rnicholus/determinater
Changing the extension does not change the mimetype of the file. Do the same test with an actual BMP file.
The accept attribute is not widely accepted. Chrome and IE10+ support it. If you're using anything else, like Firefox, Safari, or Opera, it won't work. You can read more here: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/Input
This means that like Guilherme suggested, you'll need a client side or server side check. I'd suggest both. Client site will immediately tell an unsuspecting user, while the server side will help filter malicious users. However, beware, there is some debate on how MIME type detection isn't exactly reliable. You can Google around if you want to find out more about that.
I'm only asking because I tried sending an email (with PEAR) which containd an image whose name was something like "header image_3021" and noticed that it didn't show up in the email.
When I checked the SRC in the recieved email the space was replaced with + and that somehow made the link point to the wrong file. Now, IIRC, + is a correct encoding for spaces in URLs yet the browser could not locate "header+image_2031".
I checked the original content of the email both with Gmail's show original and in the server logs and the space was still there, so the replacement was done either by the browser or by Gmail's rendering process.
I have since modified my upload algorithms to not allow spaces in filenames but I have to ask: What's the best way to make sure the browser will display images with spaces in their file names? Replace them with %20 myself? Let the browser do it? Just disallow them?
Definitely encode them. By doing so, you remove the nuance of how different clients will interpret the string. As #mr alien said, there are out of box php functions that will handle that for you.
Some of my users are creating links that look like
<a href='http:/some_local_path'>whatever</a>
I've noticed that Firefox interprets this as
<a href='/some_local_path'>whatever</a>
Can I count on this occurring in all browsers? Or should I remove the http:/s myself?
This is an unusual URL, but is not invalid. The URL spec says that omitted components are defaulted from the base url, which can be provided explicitly in a <base> tag, or absent that, the current URL of the page.
When a browser sees /some_local_path, it is missing a scheme and a host, so it takes them from the base url. When your users put http:/some_local_path, it has an explicit scheme, but is missing a host, so the host defaults to the base url. If your page is an http: page, then the two URLs will be interpreted identically.
All that said, those URLs are almost certainly not what your users intended. You'll be helping them if you point out their error.
It's always best to validate data entered by users. Inevitably, you'll get something unexpected.