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.
Related
I am developing a game using HTML. I found a font I want to use. I installed it correctly on the computer, and I imported it into the CSS file, however; I am unable to use the character that I specifically wanted from the font. It loads in the editor, but not when the page renders on the frontend.
The character I really like is &
My browser that I load my webpage with is Chrome.
The editor that I can see the character in is Visual Studio Code.
I use the VS Code Live Server to load the page into chrome, and Icon Font File Preview extensions.
How do I resolve the issue? What information should I add?
I'm developing a basic web page with css file on my local machine and testing by opening the html file in the browser straight from the filesystem.
This works, but now since using the Chrome developer tools to play around with different styles by editing the css file under the Sources tab, whenever I refresh the page none of the CSS loads until I again edit it in the sources tab - just adding a return to the end is enough to load all the CSS.
Also, occasionally when refreshing the page, the Sources tab shows the contents of the css file as corrupt (a load of random characters)
I've run the css through a validator and that says it is all fine and there is no javascript on the page
I'm not a web developer so probably missing something obvious...
This is happening because you are editing css inside the Inspect Element (Chrome developer tools).
This is because the css literally lives on a webpage and it is pulled from your actual css file on your desktop (css file from the folder of your website).
Because of this, you are never actually changing an actual css on your computer, just in the browser, and that is temporary, because the same old css from your computer will load everytime you reload the page (untill you modify the css on your computer).
You should edit your changes in your actual css file on your computer inside your text editor (notepad++, visual studio code, atom, sublime text, etc ...).
That way, it is going to work as you want ! Hope you understood what I meant, if not, just tell me, so I can clarify again :)
Add this to the nginx configuration:
http {
include /etc/nginx/mime.types;
....
}
this solved it for me.
Thanks
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.
If you save a txt file and open it w/ chrome or firefox, I noticed that the the doctype declaration isn't added when I inspect the element in question. Instead it's just 'html.'
Is there any reason for this? Because it does make a difference to the 'pre' format's style and layout when you do add doctype html.
Edit: OK, when a browser opens up a txt (whether locally or thorugh HTTP) it does not open a txt file, but converts it to raw html. And Matt Ball is wrong - because the browser is not opening a txt file - it's converting a txt file to html. Example: gutenberg.org/cache/epub/4300/pg4300.txt Now inspect it's element - you'll notice it's not display the actual txt file but an html document
The doctype is a signal from the programmer to the browser, originally intended as a shibboleth to indicate that the programmer knows what they're doing.
The browser already knows what it's doing when it's opening a text file: not opening an HTML file.
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.