[UPDATE] I found two links useful to me:
http://mrcoles.com/blog/canvas-composite-operations-demo-animation/
http://tutorials.jenkov.com/html5-canvas/composition.html
Recently when I learn canvas, I find there is more than one way to specify the image src:
You can give a image-URI, like : www.XYZ.com/abc.png
You can give a data-URI, like: data:image/svg+xml;base64,'+ hexcode;
You can give a data-URI from canvas like: canvas.toDataURL("image/png");
I am a little confused about what the difference among them and wondering how browser processes them?
Thanks
It's simply a matter of what the browser supports. The browser will look at the protocol header of the string and if it recognizes it try to interpret it. For example:
If it starts with "http://" or "https://" it will parse the rest of the string with that as a basis. Then try to connect using the HTTP(S) protocol to the server and communicate over this protocol. The protocol itself is specified in RFCs. If all OK, then data is transferred from server to browser which then goes to the next step interpreting the received data itself (this can happen during or after the data has loaded completely).
If the string starts with "data:" the browser will assume a Data-URI protocol (if it supports this protocol). If not, it will consider the source invalid. As it does not need to connect to any external resources in this case, it will validate the content of it and use it if valid. Data-URI will be converted to binary data (the base-64 representation will be converted back to binary form).
(2. and 3. are the same BTW. It's not hexcode that is appended, but a base-64 encoded string, ie. ASCII representation. Other representations are possible but not common).
Then there are other protocols which the browser may support, such as Blob-URL and perhaps some browser will allow FTP (ftp://), and some allow file:// given certain restrictions.
Related
I am trying to save a file using FileSaver library which will save the file using Chrome's and Firefox's Save As dialog.
Ex: I have certain filename like testing:testing1:testing2.csv.
Now when the Save As dialog pops up, I am seeing filename converted to
testing-testing1-testing2.csv for Chrome
and
testing_testing1_testing2.csv for Firefox.
Is there any way we can suppress this conversion of characters?
Thanks
No.
File names can't contain, among other characters, the colon : (On Windows machines). If you want to make sure your application is compatible with Windows, keep that in mind.
These are the disallowed characters:
\/:*?"<>|
Firefox & Chrome probably replace all of those by the dash / underscore.
The filename is merely a suggestion. RFC 2616 states that:
19.5.1 Content-Disposition
The Content-Disposition response-header field has been proposed as a
means for the origin server to suggest a default filename if the user
requests that the content is saved to a file. This usage is derived
from the definition of Content-Disposition in RFC 1806 [35].
RFC 1806 further states that:
It is important that the receiving MUA not blindly use the suggested
filename. The suggested filename SHOULD be checked (and possibly
changed) to see that it conforms to local filesystem conventions, does
not overwrite an existing file, and does not present a security
problem (see Security Considerations below).
Long story short, different file systems have different restrictions on filenames. The browser is free to fix the filename if it cannot be used as-is.
I have pretty standard javascript/XHR drag-and-drop file upload code, and just came across an unfortunate real-world snag. I have a file on my (Win7) desktop called "TEST-é-TEST.txt". In Chrome (30.0.1599.69), it arrives at the server with filename in UTF-8, which works out fine. In Firefox (24.0), the filename seems mangled when it arrives at the server.
I didn't trust what Firebug/Chrome might be telling me about the encoding, so I examined the hex of the request packet. Everything else is the same except the non-ASCII character is indeed being encoded differently in the two browsers:
Chrome: C3 A9 (this is the expected UTF-8 for that character)
Firefox: EF BF BD (UTF-8 "replacement character"?!)
Is this a Firefox bug? I tried renaming the file, replacing the é with ó, and the Firefox hex was the same... so such a mangle really seems like a browser bug. (If Firefox were confusedly sending along ISO-8859-1, for example, without touching it, I'd see an E9 byte, and I could handle that on the server side, but it shouldn't mangle it!)
Regardless of the reason, is there something I can do on either the client or server sides to correct for this? If a replacement character is indeed being sent to the server, then it would seem unrecoverable there, so I almost certainly need to do it on the client side.
And yes, the page on which this code exists has charset=utf-8, and Firefox confirms that it perceives the page as UTF-8 under View>Character Encoding.
Furthermore, if I dump the filename to console.log, it appears fine there--I guess it's just getting mangled in/after setRequestHeader("X-File-Name",file.name).
Finally, it would seem that the value passed to setRequestHeader() should be able to have code points up to U+00FF, so U+00E9 (é) and U+00F3 (ó) shouldn't cause a problem, though higher codes could trigger a SyntaxError: http://www.w3.org/TR/XMLHttpRequest2/#the-setrequestheader-method
Thanks so much for Boris's help. Here's a summary of what I discovered through our interactions in comments:
1) The core issue is that HTTP Request headers are supposed to be ISO-8859-1. Prior versions of Chrome and Firefox both passed along UTF-8 strings unchanged in setRequestHeader() calls. This changed in FF24.0 (and apparently will be changing in Chrome soon too), such that FF drops high bytes and passes along only the low byte for each character. In the example I gave in the question, this was recoverable, but characters with higher codes could be mangled irretrievably.
2) One workaround would be to encode on the client side, e.g.:
setRequestHeader('X-File-Name',encodeURIComponent(filename))
and then decode on the server side, e.g. in PHP:
$filename=rawurldecode($_SERVER['HTTP_X_FILE_NAME'])
3) Note that this is only problematic because my ajax file upload approach is to send the raw file data in the request body, so I need to send the filename via a custom request header (as shown in many tutorials online). If I used FormData instead, I wouldn't have to worry about this. I believe if you want solid, standards-based unicode filename support, you should use FormData and not the request header approach.
I am integrating yahoo open ID for my site. My site is running for different languages( en, jp, cn etc.). When I am trying to logged in from english site with yahoo opend ID then its fine but when the same this I tried from japanese or chinese site then it's not redirecting me to yahoo open id login.
Each time I am getting the below error from javascript
Error: The character encoding of the plain text document was not
declared. The document will render with garbled text in some browser
configurations if the document contains characters from outside the
US-ASCII range. The character encoding of the file needs to be
declared in the transfer protocol or file needs to use a byte order
mark as an encoding signature. Source File:
http://uatstorefrontjpcr.mobi-book.com/ReturnFromSocial/LogOnYahoo
Line: 0
Can anyone suggest what to do.
I have used SocialAuth-net.dll for this purpose. I have set all required wrapper in web.config. Same coding is okay with Google and facebook open ID.
Your web server is probably sending back a response with a Content-Type of text/plain. When a web browser receives a response with that content type, it doesn't know what encoding should be used to decode it; since you haven't told it how to decode it, different browsers might choose different ways.
The solution is to provide an explicit encoding. For example, if you know that the text is UTF-8 encoded, then you could provide it in a header like so:
Content-Type: text/plain; charset=UTF-8
According to an informational page from the W3C, you can get ASP.Net to include that bit in the header using Response.ContentEncoding. Again using UTF-8 as an example, you can set it like so:
Response.ContentEncoding = Encoding.UTF8;
In HTML, script element has optional charset attribute.
What is the purpose of it?
When is it useful?
If your javascript files are encoded with a different encoding than the page is using, you can use the charset attribute to tell the browser how to interpret it.
For example, if the page is using Latin1, but the JS file was created with UTF-8.
The purpose of the charset parameter is to specify the encoding of the external script in cases where the encoding is not specified at the HTTP protocol level. It is not meant to override encoding information in HTTP headers, and it does not do that.
This is useful when the author cannot control HTTP headers and the headers do not specify character encoding. It is also useful for offline files, such as in a local copy of a web page accessed directly, not via an HTTP server, so that no HTTP headers exist.
In practice, it is not very useful. If you need to use non-Ascii characters in a JavaScript file, you can use UTF-8 encoding. If you use UTF-8 with a leading BOM, the BOM acts as a useful indicator that lets browsers infer the encoding. But it does not hurt to additionally use charset=utf-8.
Each JavaScript file is a separate element from page, after all you can even load JS from some remote author's server that otherwise have no relations to your page at all. Just as with any other external element, you can manually specify "charset" if remote server returns wrong charset for some reason or just to be sure.
Also, if you have write access to this JS file yourself, you may want to replace all non-ASCII with Unicode position escapes - this will guarantee that symbols will always be interpreted correctly, no matter what encoding is specified in headers. Some JS minifiers, like Google Closure Compiler, can do it for you automatically.
have a browser program that lets the user play chess - move pieces etc. trying to let the user download the resultant pgn (Content-Type: PGN) directly from browser.
does it have something to do with data:URI? is there some example somewhere?
only interested in modern browsers
I am not quite sure if I understand your question correctly. Do you mean you generate an image in PNG format but the browser does not offer download, instead shows the image directly?
If so, the solution is to indicate a file for download by setting the appriopriate MIME type as HTTP header "content type".
In PHP you do it like this:
header("Content-Type: application/force-download");
or
header("Content-Type: application/octet-stream");
When the browser receives this MIME type it will not try to display the content itself.
You can use a Data URI but there are some limitations. Here's an example, based on my answer to an earlier question. The first thing you'll note is that you can't really control the filename, but it works OK in Firefox and Chrome other than that, but probably not so well in IE (I've not tried it).
Assuming you can already generate the PGN as a string, the code to create a Data URI is quite straightforward:
function exportData(data, target) {
var exportLink = document.createElement('a');
exportLink.setAttribute('href', 'data:application/x-chess-pgn;base64,' + window.btoa(data));
exportLink.appendChild(document.createTextNode('sample.pgn'));
document.getElementById(target).appendChild(exportLink);
}
Just set data with whatever you're generating and set up an element to hold the link once it's created.
In the future we'll have better solutions for this sort of issue, but there's no browser support for it yet.