Dreamweaver can't read å ä ö

Hey there!

I have a swedish keyboard, and i use å ä ö to write articles for example. Dreamweaver’s design view can read them but as soon as I preview in broswer it looks like this, all these wierd signs is either å ä ö - Idag hÃ¥ller jag fortfarande pÃ¥ att bygga hemsidan som inom kort tid är klar.

Sometimes it works on some websites I have and sometimes not, on this it dosent, but on my other it shows it. So its like sometimes yes and sometimes not, And it dosent matter if I write it fom the code view.

Is there any soloution?

Make sure that

  1. Dw is set to encode pages as UTF-8
  2. Your server sends the page with the UTF-8 encoding
  3. you specify UTF-8 as your encoding in the meta element after your opening <head> tag.

E.g.


<head>
<meta charset="utf-8">

If you want, show us the page in question and we can check your page and server encoding.

UTF-8 is a more universal character set that recognizes non-roman characters.

Oh, thanks. I usually delete <meta charset=“utf-8”> in the beginning, in though of its something unnecessary. :slight_smile:

Thanks man again and again!

If you have that meta element but the server is sending out a different encoding, the server setting will override the page setting. Have a look at this current thread:

I will!

9 times out of 10, that meta is redundant (as long as you are using latin-only English characters). But anytime you go beyond A-Z, 0-9 and punctuation marks, you should always specify an encoding (usually UTF-8 is your safest bet).

Yep. From now on I guess I’ll choose that one always :P.

Also, declaring the meta tag helps avoid an unusual (and unlikely) hack, known as the UTF-7 hack.

search for “utf-7” to specifically read about it.

For this reason my meta tag is the first thing in the <head>, even before the title. Joel also mentions how browsers will stop at that tag and go back knowing they are reading things now with the right encoding (never mind that what the server states in the HTTP Header always takes precedence… sometimes that Header isn’t there at all). So I might be saving a nanosecond of time for the browser : )

Arg, sorry, the Joel article doesn’t mention the hack, just UTF-7 in general.

But I brought it up so first Wikipedia has a little bit about it but then in case you thought this really was only old IE [url=http://securethoughts.com/2009/05/exploiting-ie8-utf-7-xss-vulnerability-using-local-redirection/]read more here.

Also Google had security holes based on utf-7 which makes this encoding seem more and more interesting :slight_smile: