In eclipse, I've created a couple of files, added some text and displayed it in the local server. My problem is that instead of utf-8 characters like "ć", "ś" I get some trash like "Ä". All files have .php extension, though it doesn't matter.
Actually, what's strange, with opera some files display those characters properly, while others don't. Using firefox all files show trash.
I've tried project -> properties -> text file encoding -> other (utf-8). It doesn't work.
What's wrong?
It's like that both on localhost and on external servers.
You need to tell the browser what the encoding of the file is. Add a charset tag to the head:
<meta charset="utf-8" />
Without telling what the encoding is, the browser has to guess. Different browser will make different guesses, some guesses work better for some kind of files, and worse for others.
Related
I have an assignment in which I have to style an html document using CSS. The comments in the CSS file are in Swedish and when the CSS file is displayed in a browser the Swedish characters get scrambled. So I added "#charset "UTF-8";" to the beginning of my CSS file and that fixed the problem when I view the file in a browser locally. But part of the assignment is to upload the CSS file on to a server so it can be corrected. Once I upload it to the server and try to view it in the browser its back to a scrambled mess.
Give this a try on your CSS file
latin1_swedish_ci
Replace UTF-8 with this one. Also you can use a general one on your HTML
<meta charset="character_set">
I have come to the conclusion that it is a browser issue. Curiously, Firefox displays the Swedish characters of a CSS file even without using #charset "UTF-8" when opened locally but not when opened from my uni server, even with the #charset "UTF-8". Chrome requires the added #charset "UTF-8" to display the Swedish characters when opened locally which also works when opened from the server.
I am looking for a site for somebody, and fixing errors as I find them.
There is no Favicon.. that is ok, I can fix that.
My question is, do browsers (or certain browsers, Chrome in this case) request favicon.ico as soon as they load a site.. or maybe on check that there is no alternative icon path mentioned in the source.. irrespective of whether "favicon.ico" is actually mentioned in the page source?
That was the original behaviour, yes. /favicon.ico was an implicitly present file which (some) browsers would check for. Only later did that actually morph into a proper standard with <meta> tags, arbitrary file names and image formats other than .ico.
I have struck a strange issue. I have some images on the page which are rendered from Data URI's, and I would like to enable my users to copy them to the clipboard.
However, for some reason, neither Firefox nor Chrome seems to allow me to do that.
As an example take this page:
<!doctype html>
<html>
<head>
<meta http-equiv="X-UA-Compatible" content="IE=edge" />
<meta charset="utf-8" />
<title>Clipboard Test</title>
</head>
<body>
<img id="target" src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAEsAAABHCAYAAABPjLqRAAAAAXNSR0IArs4c6QAAAARnQU1BAACxjwv8YQUAAAAJcEhZcwAADsMAAA7DAcdvqGQAAAASdEVYdFNvZnR3YXJlAEdyZWVuc2hvdF5VCAUAAA5HSURBVHhe7dq5qmXVFsbxehYDM8EHMDEwU7BBQd9BM81MNTMTxA5DMdBAjATBJlDRQLED+75sEF9A9+U3L//FOMt9yrL0BudcCz7GmKP5xphjzbX22vvUhe+///5w8eLFw3fffXf49ttvDz/88MOmk9Zi4Kuvvjp88803y14M+48//rg4wFqM2K+//nqLF2sN1uzFyq9esXNd/NTlqieOrG86f7aZV71yIFu8088X+C+UJCgjPTuwIYgU2L/88suVU76YyOMDA5p8DW0OLu7qyJt8rWdcvfDh/eKLL5Zkwz1zXBCSP764gN1wy89f79YXFEBUUlfDyaghcuqziHi2yOnI6bOpJFQj3oCPPe7yi68WNAx2enyTowGIK8baRa4GW3XoUP+AswFutyGCjGyGBRWUWAEE1hqoeTn50svZ5+LDS58188etp1kDii0PGggbOXujk138YuJRQ0x8uBwevmZQ7IVJGCnHLAwSZhwf4hrllyMGR03kJ/nJ8m0om3V2eWR8Tr91zzZ5ckAtMaAHfrpca5Anp5j8s1b1YPLjYyPXyaLMzdIjihQkW/OXM2/h7GKAT04+G+PHS87acy23vHjqJ8mXFNNJ4rfOxzYHlQ3KpfOXB2x7nguTiLNmSkjmJyfBtMUVz2w8ruzlT74kFAPiArvhVYOsRrbi9ieELb3hluNC0qvN16m15lu3oQUgEBBRdgkzuTXidHK/sXzpFSWLrbnq5KsHeqcsWzJ/kn32Y80ef9BDz0OopxAfPX769sySAAXub6EISXZSoWw42mxXr1wQmy0pDuSwdZta11O3YDZ+9jhJvvrir1Z59SrW868c3D1b2aC9VKd86zUsCQIRcqRPKSkyOdC6mCB2NmBd0TmQhi5GfJvtBJcPNlbd+MrLFhedTY41fc8349LFqG3Nbl/xk9ttqBDDHBx7iZGKg4jafKTxhb0tvnzy2IDNurhQT9CFqR45kT9+YCP1zR7ay08//bT8XbyZS6/u+jRs4/QPP/zwcOONNx6uuuqqBfoHH3ywEiRrnIxgbkSh4mq++JrotuObp2yi3DjjBf5qpPNbdyrk8sU/bdYNzzr+asgRWx5p7ZSurzsMFgLd07fccss2LPonn3yyCpRMVtjmJ/DxiSeLrYFs9Nk0XUw87CA2FEtWR9/ZsovFwQ7WMy9Yq9sFLVYu3uKyX5hEEj/77LM/DOvTTz/dNtCmJ3BA/vjinvz0GikW4q05OtDjnzHl5ws9wKtl3YmDOUT54tjpcaphgHzW1bnQECwQOEXHhlWTFamwRoAv8rhI4CNrbNYDPNY1xl8+vbU6rXGSYuKKJ94GBuxyemyokz2ffBLKz07fXkpdAcU///zzo8MSI7HGFajxWXhulqzgCy+8cHjyySc3P4jvFmhNihdnOBrF1QYgW3nQaZ19QXHlQnFqVKc+6A0ZJ4gRv/1EI0CwweyHZYB8EiteU7N4vjkQvC+//PLh+uuvP1x99dWHxx57bNnEQxv3iZQNX/l8+OqPr01CNfFUj826nuKLp37z81VXDD2efPQLOS3IY8NiM/mSEdV8kk+xms72/vvvH26//faNz8AeffTRbaPBhZBTPySwzc3pw10gx5qPXk0no9s1bjHyZq/xzbj49r2xk+sBP5s69mloWILbQM0ns1W4grgefPDBjSsY2COPPLLibQwHvXxrSK83ehLUMAC2ZDxQrgvoYpByssuxbm89ivKng5g1LEklHntmsSmkmRqq6Ww2XWGw9owymDmo0C0pp1M1G61BfnonNv5s6dUmxRW/t4utd5icE9Xl94hgW5+Gs9nTbsP8oFjNAOKGVYHnn3/+cO21154Y0B4GZqDluGB03A0CJzudD+jiW4sVN2OC24/PHruocsXO+PjIqVcb1s/Kc+OnDUtww4iILUIcGhLz9ttvH+64444TgzkNnbB5QmtOnWpUh1/PDXbGdmLENmzrNpxfj1BMXNZkHzb1RFd3fd0pQZFjL6V9GlYcqWIVQVgBg73nnntODOTPYGCPP/74xtVw1Kg/On/1xbEbXB/7fOLaINjPHEa++OOplqHw708gbL+UkshOG1ZTn0UnEQ4FHnjggRODuFw0MJvXeJuBNgf1APkaAFmMAcHDDz98eOONN7Z+89Xz7B/sjez0zrz16tA06cce8AbIHzG9eGiQXjz/7Dl1KRjYE088sWrgjNdaHY2TbSLw2yCdj/7xxx8f7rvvvsX77LPPrjxccYppL0lzqDY/G87i10upBTKGY8Nya/E31FkINPjaa6+tF8/yrhRzYLOWPrs1wBr48utDjGfmnXfeuXHef//9y2cPxeOwBsNhUy9e8dNG325DBvLYA94AZ1ybiPidd9657Af65aBbUo1qgY1Vk54f2vhLL710uOGGG07w3XrrreunJ/7iwZD2fA21mp22NayZLOi0T8NJJlE83RfvYy+efxedMDUaCp2seeibBTzzzDNHHwPXXHPN4ZVXXlk84uJpeNbHnlETbOuZhaQpH7sNe8CHksU/9dRTa2OzuX8KeL1W6C+0QUPyqpL+0EMPXbIP3xgaQnsmA5+9GRgdxFiT1utXB0DiyB07WR6WGuKvkJzLefH8u5gnTMPq16+13u69996juRNeZ9wFBtIwXOwGAXxs7VOd/OT2zMp42m2oOTEIkL733nv/6HPqUjAwz7BOQHj33XcPd91119GcPa677rrD66+/vnpvrw2cbH9qpIN4awNcJ8uiE3NsWG7DGpUs5u677z7RzP8aBtbvYfp98cUX//Ag/zN4hbAHe45n6nxm0DzIhmu9TlaB5LFh9fCTRL/SF8+/CwPz887TTz99Rbe/V4guvG8cPfPmkIIhgVinim2dLMESPZdOO1ni4KOPPjrcfPPNJ5o4K/AK4S9V9mo4DQEaWM+rDg+09zWsmXjaHyw8+LoFp/8swSvEq6++ug3Bvu0/3ZDsEwyLj3SIxKw/soJpC77UHywk7l8tzhq8Qthnp6sBebw4MB0ew7Ff/ma03rOm4djJMsCS9/6zBq8QHiWGBYbTrWf/7h577U6it/f13ZDRgn5sWH2RRrY/eWcNXiHeeuut7XDYMxicGdhntx+9wyRm3YYm27CO3YZuPfetJMf1LA8LnnvuuW1QBgMOzDxh0IlqeCf+unOpYUkWc5Yf8MErhIveqdmfIGgeZB9+2/91ANM97TYs+aw/4KFfIey3/dtfYGtA0Ilbvzr0IJO0HwadrStw1h/w0K8QPeQ7QR41ZpBseO19uw1zHhtWrw5iz8PJAq8Q9g09k+yPNDz21nQD3P7IynjayWpYjuN5GZZXCM8t++pkNRi23hDmfLaXUgvG/QOcjjS/n0TOw7C8Qrz55ptrTwZif27JOY8GJwa2P4V19I6drF73JZ6XYYFfIRoUaSD22ElrSM1n3YYNjH7a153IzsN7VvAK0TDmDMDQSAfFM42+Daujd+xk9Uup2PM0rNtuu239CtFg7N8+naJOV/Y1LA9tk2tYx96zDEgMnIeX0uAVwp/wDKZb0FCSMF+rtv/aTcL/w0vpRL9CtP9OVJjrdbIYCt4/wOn96sB/1r9I7+EVYj6T7TFpQG7L1uul1LB6pT/tPctxhF9++eXw+++/H87Lv99+++3w888/r2FAt18Dohsaub4bWhiWYRwbVi9vkYjva0LkbPniZKe7OvLpU8YTh/o4Ou1sfRLhADGkXBCLqzh5dDLu4sUBW/2J7T+rqc1G1mOc5DpZGmCgn3ayesiLBXoNIwo4agpspmFVvFNMx8M+uVrTSZsmywf5cun1Hkec7G20ocZLh/oVl58UX1wXaD3gK0o/7QGPDBFyyeUhZe+k1Yy4GhXLzxa6QJooL9QgWXy+em0gbNWon+LZgE0NnOzW80TDjLeuJ4eEdPq2P4UJop+nV4MrwU033bT9BchcXEzDp6/bkKErdt5eDf4q7N0bgbl0Gsk1LAuD4iT/HdbJx86867ZfHTL+O6z/DqsPJUMCh+nE//wjPcjO03vUX/1n77/++us2IAPrw2T7z2yG5qEmaE5UIPAHfjn5kIJ4dn7rYsXEVy4UP+GTqk9C+dnrYdaOMx4+uvwuflzgk80e2fa1i3eiyHLmO9g6WRTgLLlGyVATCGuSreKgGbG4rNNxtcaR3aZJa6jRXklg31Mf5+Im+Pb7mL7Zq7pQXHn5y03yr5MlqQ1MvWZLotuEmGkvJ1K5bVZxfmArXiy/jbNlJ+XHB9bp7PEGNnkkVKe49kJWx5o+axSTnD3I2f4zW8lODRTYg65Cs7Fya4A+m6sZEtiyFzM56LPJqZPVno8La3axEHexBhcXWV61xFgHefue7Im+Tla3VfenZkrkn1KBriYZEbtc4JvF+cXxZZ82uQ2bXf1OGcQhliyWzBavWLZQ/p5Pjfk84u9ghHjrZ3vAz4bmsCILEewln6tYjLyGQAdxxYrhEwPZ97HxG2wbFt+FiotOgvw2Hx/wue3l4BQD1Y5TXL3J46Of+J9/UEP0mp3IFon1fBbNfGgYbYwtHpsptvx4y6ODfPGt+cTT5bjAOJJx7nWQS8ptP2zium1nPDvbdrIERUpCzZCa1ci+ALvYmsQT2NsUsJHVSMZXHTX2MdWZPPLYy7Wed0V2OshL1xc5efCzA5tTGKfY9QYvsGRrRbqfrdkrDBHKy0YPFY0L6K35g/h9DLs1Xvq04yVtoHW51g2Snh/YqtM+Qf16bU3i6eQDru3P92QbF9w0BfHX1CwUaYTTnq1m29z0k9XP1ibzVa8+6mnm9hxqPf1ke9JHtvzxzr2zz4tYzDpZETCCiUpsyj0o2SQ1gIqzFVdMXBD3rBUPOykvnU9cF4K9E2Aw9cbOD+6E+KfdurzsbMXN2Hy48YE13osXLx7+A1szFjfFBZ3lAAAAAElFTkSuQmCC"/>
</body>
</html>
available here if you want to try it.
Right clicking on the image and choosing 'Copy Image' does not seem to work for Chrome, Firefox or IE11. However right click and 'Save Image As...' does work.
Since it seems consistent across all browsers, I am assuming there must be a deliberate decision not to allow such images to be copied. Is it related to CORS - since the data URI has a different origin?
Is there anything I can do to allow these images to be copied?
The background to this is that I am trying to make it possible for users of my web application to copy SVG images onto the clipboard. I am able to convert the SVG images into PNG data URIs, which I can even save on the user's computer, but I cannot seem to get them onto the clipboard. If there are other / better ways to do this then please feel free to point them out instead!
UPDATE It seems this might be related to the receiving application rather than the browser. After seeing the comments from #Mi-Creativity I re-tested using additional applications. Pasting such images into MS Paint does seem to work, while pasting them into MS Office applications does not. Unfortunately for me that is the main use case of my users.
I installed the inside clipboard tool and used that to compare data on the clipboard when using a data URI vs. a normal HTTP URI for the image. Using Chrome, in both cases there are four formats placed on the clipboard:
CF_BITMAP
CF_DIB
CF_DIBV5
HTML
The first three are identical in content. The HTML version is different - they contain snippets of the HTML document, one with a data URI and the other with a HTTP URI.
Armed with this additional information I did some more googling and found this similar previously reported problem.
It seems the likely cause is that MS Office applications are attempting to paste in the HTML version, which fails because Office does not understand data URIs, and ignoring the more useful bitmap versions available on the clipboard.
Users can work around this by using the 'paste-special' option, although it is a lot fiddlier than I would like.
I have used <img> tag in html for displaying images. The image gets displayed in Internet Explorer 10, but it is not visible in mozilla, chrome. Could someone please tell me the reason why?
<img src="file:///d:/maruthi.jpg" style="width: 150px; height: 140px;" alt="Photo">
Chrome stops access to local file:// links from with in http:// page for security reasons by default.
file:// is not allowed in Chrome and Firefox for security reasons by default, but this answer shows you how to change those settings. Really, you should set up a lightweight local server.
The <img> tag is standard across all browsers (except text-based browsers like Lyx). That should work, however given that it is a local path it may be that you are testing it in a different environment that can't access that path?
Review this wikipedia page on the file URI scheme and it will also highlight that some browser will limit access to local files for security reasons.
The original title to OP's question is NOT misleading - it is perfectly valid. However, they did not say whether they were using Windows or Linux. Windows and Windows programs (like DOS from which they originated) are completely indiscriminate with regard to the use of upper or lower case in filenames.
Two possibilities to consider:
Linux is fully case sensitive, including its use of filenames. Yourfile.JPG is NOT recognized as being the same as Yourfile.jpg! I recently migrated from Windows to Linux and encountered exactly the same problem with Firefox. It displayed images in sites on the internet, but not in perfectly valid local HTML and CSS markup. Later, I noticed that the Windows image-editing program I'd been using had saved all the images with uppercase .JPG or .PNG extensions. A few that I'd previously renamed manually had lowercase extensions - these DID display normally! Linux 'properties' for those files identified them correctly as JPEG files, while those with uppercase extensions were simply identified as IMAGE. Also, my markup references all images with lowercase extensions (professional usage). When non-displaying image file extensions were changed to lowercase, they all displayed correctly.
If Steve is still using Windows, it's possible that Internet Explorer is displaying local images for the same reason as above. Firefox, though, uses a different engine (Mozilla) and, being open-source, maybe more strict with regards to case sensitivity in file names. However, I'm not in a position to check this out. Maybe someone else can test.
i have used in jsp as this : and working in firefox and chrome
<a href="Welcome.jsp"><img src="home.jpg">
I have a very strange problem:
I use xsl to show an html picture where the source is defined in the xml file like this:
<pic src="..\_images\gallery\smallPictures\2009-03-11 אפריקה ושחור לבן\020.jpg" width="150" height="120" />
[the funny chars are Hebrew- ;) ]
Now comes the strange part:
When testing the file locally it works on Firefox and Safari but NOT in IE and opera. (file://c:/file.xml)
Next I send the file to the host throw FTP (nothing more)
Than it suddenly works with all browsers when calling the page from the host: (http://www.host/file.xml)
The question is how can the server send the xml file to my browser in a way that my browser can read, while the same browser cannot read the same file stored locally ?!
I always thought that both HTML(xml) and pictures are sent to the client which is responsible to load the page - so how come the same files works for my webhost provider and not for me?
And what makes it totally strange is that IE is not alone - Opera joins it with this strange behavior.
Any ideas?
Thanks alot
Asaf
When you open the file locally, there is no server to serve up HTTP headers. That's a big difference at least. Try examining the coding the browser thinks the page is in, when it's opened manually from disc, and when served over HTTP.
If headers are set correctly by either your script, or the server, then that is likely why.
This is most likely an encoding problem. Try to specify the encoding explicitly in the generated HTML page by including the following META element in the head of the page (assuming that your XSLT is set to generate UTF-8):
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
...
</head>
...
This tells the browser to use UTF-8 encoding when rendering the page (You can actually see the encoding used in Internet Explorer's Page -> Encoding menu).
The reason why this works when the page is served by your web server is that the web server tells the browser already what encoding the response has in one of the HTTP headers.
To get a basic understanding what encoding means I recommend you to read the following article:
The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets
..\_images\gallery\smallPictures\2009-03-11 אפריקה ושחור לבן\020.jpg
that's a Windows filepath and not anything like a valid valid URI. You need to:
replace the \ backslashes with /;
presumably, remove the .., if you're expecting the file to be in the root directory;
replace the spaces (and any other URL-unfriendly punctuation) with URL-encoded versions;
for compatibility with browsers that don't properly support IRI (and to avoid page encoding problems) non-ASCII characters like the Hebrew have to be UTF-8-and-URL-encoded.
You should end up with:
<img src="_images/gallery/smallPictures/2009-03-11%20020/%D7%90%D7%A4%D7%A8%D7%99%D7%A7%D7%94%20%D7%95%D7%A9%D7%97%D7%95%D7%A8%20%D7%9C%D7%91%D7%9F%10.jpg"/>
There's no practical way you can convert filepath to URI in XSLT alone. You will need some scripting language on the server, for example in Python you'd use nturl2path.pathname2url().
It's generally better to keep the file reference in URL form in the XML source.
#Asaf, I believe #Svend is right. HTTP headers will specify content type, content encoding, and other things. Encoding is likely the reason for the weird behavior. In the absence of header information specifying encoding, different browsers will guess the encoding using different methods.
Try right-clicking on the page in the browser and "Show page info". Content encoding should be different when you serve it from a server, than when it's coming straight from your hard drive, depending on your browser.