Generally the page's encoding is followed, unless the server specifies an encoding. As the <meta>
tag seems to specify what you're expecting, and as manually switching to that value helps, it sounds like the server you're getting the page from is sending an incorrect encoding (Windows-1252) in the headers to the browser.
The proper way to fix it is to configure the server properly. For a company webserver, this probably means bugging the server admin to do it.
To see the (wrong) headers, if you're familiar with such tools, you can use things like Firebug's "Net" panel in Firefox, or Web Inspector's "Resources" panel in Chrome or Safari. Or, if you don't know these tools and the web site is publicly accessible, then you easily see the server's headers online using, for example, Web-Sniffer.
Assuming the login page specifies the same as the actual pages, then this yields:
Content-Type: text/html
...without any value for charset
. Not sure if a browser should then still interpret that <meta>
tag, but apparently Firefox is ignoring it, and making some best guess.
Firefox ignoring it might be caused by the HTML source. The <meta>
tag should always be specified within <head>
before anything else, as it might also apply to the title, scripts, CSS and so on. On this site, it doesn't and, even worse, the HTML is a total mess:
<SCRIPT LANGUAGE=JavaScript SRC="/dergi/_ScriptLibrary/pm.js"></SCRIPT>
<SCRIPT LANGUAGE=JavaScript>
thisPage._location = "/dergi/giris/login.asp";
</SCRIPT>
<FORM name=thisForm METHOD=post>
<HTML>
<style type="text/css">
<!--
[..]
-->
</style>
<HEAD>
[..]
<META HTTP-EQUIV="CONTENT-TYPE" CONTENT="TEXT/HTML; CHARSET=WINDOWS-1254">
<META NAME="GENERATOR" CONTENT="Microsoft FrontPage 5.0">
<META NAME="AUTHOR" CONTENT="[removed to protect the innocent...]">
<TITLE>YAYSAT DERGİ RAPORLARI</TITLE>
</HEAD>
<BODY>
<center>
[..]
</center>
</body>
<INPUT type=hidden name="_method">
<INPUT type=hidden name="_thisPage_state" value="">
</FORM>
</html>
Huge developer fail.
(Incidentally, Web-Sniffer shows <meta http-equiv=content-type content="text/html; charset=ISO-8859-1">
, but that is due to its values for Accept-Charset
. Firebug shows <META HTTP-EQUIV="CONTENT-TYPE" CONTENT="TEXT/HTML; CHARSET=WINDOWS-1254">
just like in the question.)
I've found that the easiest way to do this within Word is to open the new document (that you want to import the style to).
To do this, first open the Styles Window (Alt+Ctrl+Shift+S), and click on Manage Styles.
At the bottom of the Manage Styles window is Import/Export....
You can then choose another file by closing your normal.dotm file, and using Open File to select file with style(s), then copying the required styles across.
Works for 2013, 2010, 2007.
In 2007 the Manage Styles is a small icon in the Styles Window
In pictures:
Best Answer
As @dnbrv commented, this is not an encoding issue but probably a font problem. Try first changing the font of some problematic text segment to Arial Unicode MS. This probably won’t help (as Word should be able to switch font automatically). In that case, you might check out the identity of some problem character: place the cursor right after a character and enter Alt+X. The character should now turn to its Unicode number, which can be used to analyze the nature of the problem. You could also download and install a very large font like Code2000 to see whether it can show the characters.
On the other hand, if the document is not originally in Word format, there might have been a problem in importing it into Word. The extension .doc does not as such guarantee anything.