1. Home
  2. Forums Index
  3. Server Side / Apache Web Server 9:09 am May 21, 2026

Forum Moderators: phranque

Message Too Old, No Replies

Changing to UTF-8

notepad/php includes/phpMy Admin/Correct steps to follow?

         

actolearn

10:50 pm on Aug 6, 2013 (gmt 0)

10+ Year Member



Hello ~
Would like to change website from iso-8859-1 to utf-8. All urls were created with Notepad and automatically saved as ANSI.

Website built with notepad/apache database/phpMyAdmin/php includes/xhtml strict.

Questions:
1. Replace <meta http-equiv="content-type" content="text/html; charset=iso-8859-1" /> with
<meta http-equiv="content-type" content="text/html; charset=utf-8" />.

Do I just change all files head section from iso-8859-1 to utf-8 and then "Save as UTF-8"? Or need to open file/highlight/copy & paste into new notepad file and then save as utf-8? I know this is what I would need to do if saved files in Word but not sure what to do since saved as ANSI.

2. php.ini file, find:
;default_charset = "iso-8859-1" and change to
default_charset = "utf-8" (W/O semi-colon at beginning).

3. There is a default.html in my public.html folder which was automatically included by my hosting company when I opened account. I've never used it. I made my own index.html. Can I delete this default.html file? (just an add'l question...)

4. For my host account/database account, MySQL indicates "MySQL charset: UTF-8 Unicode (utf8). Does this mean I WON'T need to do anything to my database table re change from iso-8859-1 to utf-8?

5. For whatever steps above I need to take, should I do them in a certain order?

6. Do I ALSO need to add following to my .htaccess file?
AddCharset UTF-8 .php
(If yes, should I also add .html next to the .php since I use both extensions on my website?

Below is what I have in my htaccess file for my home page so does something else need to be added to this "AddCharset UTF-8" line?

(I've included a partial example of my htaccess file at bottom of this post, in case you need to see it.)
#6index.html no longer shows on home page url
RewriteCond %{THE_REQUEST} ^[A-Z]{3,9}\ /([^/]+/)*index\.html\ HTTP/
RewriteRule ^(([^/]+/)*)index\.html http://www.example.com/$1 [R=301,L]
........................................................
this is a partial example of my .htaccess file:

RewriteEngine on
#1Use PHP5 as default
AddHandler application/x-httpd-php5 .php .html

#2keep here at top
ErrorDocument 404 /notfound.html

#3underscore to hypen
RewriteRule ^new_products\.html$ http://www.example.com/new-products.html [R=301,L]

#4redirect to url with correct php ext
RewriteRule ^table-blue\.html$ http://www.example.com/table-blue.php [R=301,L]

#5cache images for 1 week, do not require revalidation
<FilesMatch "\.(gif|jpe?g|JPG|png|flv|swf|ico)$">
Header set Cache-Control: "max-age=604800"
</FilesMatch>

#6index.html no longer shows on home page url
# always keep above canonical code
RewriteCond %{THE_REQUEST} ^[A-Z]{3,9}\ /([^/]+/)*index\.html\ HTTP/
RewriteRule ^(([^/]+/)*)index\.html http://www.example.com/$1 [R=301,L]

#7canonical always to www
RewriteCond %{HTTP_HOST} !^(www\.example\.com)?$
RewriteRule (.*) http://www.example.com/$1 [R=301,L]
........................................................

Thx so much for any help! AC

g1smd

10:57 pm on Aug 6, 2013 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member Top Contributors Of The Month



Get yourself a "proper" editor like EditPlus or Sublime Text. Highly recommend the latter. The basic editors that come with Windows are limited in functionality. They also have a habit of not playing nice - especially in the placing of an invisible BOM (Byte Order Mark) at the start of the file. Additionally, the "Unicode" saved from WordPad is UTF-16-LE not UTF-8.

htaccess and database - unlikely to need to change anything.
the default index file - you can likely delete it (make a backup copy elsewhere for a while).

Before you change anything, you'll need to look at the existing HTTP Headers the site returns when serving pages. Use the Live HTTP Headers extension for Firefox to do this. The character set is often already defined in the HTTP headers.

actolearn

11:05 pm on Aug 6, 2013 (gmt 0)

10+ Year Member



I tried notepad++ a couple of times but I'm so used to using just plain Notepad. Is there a problem with Bom with Notepad?

What's the advantage of my switching to Sublime Text for what I'm doing right now? Thx.

g1smd

11:16 pm on Aug 6, 2013 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member Top Contributors Of The Month



You get syntax highlighting, autocomplete of brackets, and lots of time-saving features. Various stuff that takes dozens of actions in other editors can be done in one click or a combination key press. The editor can directly upload to a website.

You do not want the file to save with BOM at the beginning. It completely breaks a site.

actolearn

11:56 pm on Aug 6, 2013 (gmt 0)

10+ Year Member



ok, so I'll just use notepad++ (since I already have it) so
can save file in utf-8 without appending bom. So, I will
copy from notepad/paste to new notepad++ and save as UTF-8
- correct?

Is there something else I can use besides HTTP Live Headers? It makes me want to poke out my eyes. I tried it
before and I gave up.

Does the following give you enough info to help me? This is what I got using [validator.w3.org...]

Info below is for one of my product pages.
Warning 1 Suggestion 1
XHTML 1.0 - text/html Information
Character encoding Code
HTTP Content-Type No encoding information found Content-Type: text/html
Byte order mark (BOM) No
Meta tag iso-8859-1 <meta http-equiv="content-type" content="text/html; charset=iso-8859-1"/>
Language Code
HTML tag en <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
HTTP Content-Language None found
Text direction Code
Default direction LTR (by default)
Class & id names Code
Non-ascii class or id names None
Non-NFC class or id names None
Request headers Code
Accept-Language en-US en Accept-Language: en-US,en;q=0.5
Accept-Charset None found


Warning Incorrect use of meta encoding declarations
Suggestion Non-UTF-8 character encoding declared

wilderness

12:08 am on Aug 7, 2013 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member Top Contributors Of The Month



If you like NotePad?
Look at "Search and Replace 98" a free html editor that offers replacement of lines and/or portions.

It's fast and does multiple pages, depending upon your configuration choice.

There are other html editors that work in the same fashion as NotePad and do not require opening each file individually.

lucy24

12:53 am on Aug 7, 2013 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member Top Contributors Of The Month



Here's the short version:

Changing the meta charset line (or global equivalent in htaccess) will not change the encoding of a file that already exists. The charset/encoding declaration is purely for the browser's information; the browser has no way of knowing whether the encoding info is actually correct. Humans can tell, because some bits will display as garbage.

More stuff:

Files that are officially ISO-Latin-1 (8859-1) are de facto read by browsers as Windows-Latin-1, which includes codepoints that are not used by 8859-1 and that will create unicode errors (the dreaded black diamond with a ? in it). If your Latin-1 pages contain anything like curly quotes or long dashes, they are really Windows-Latin-1 and will need to be handled accordingly.

Awkward detail: If you put a file-encoding default in htaccess, this will override any information given in the individual files. (This is contrary to most situations, where a more-specific source overrides a more-general source.) So you can't simply declare it globally and then change your pages bit by bit as you get around to them.

Meta tag iso-8859-1 <meta http-equiv="content-type" content="text/html; charset=iso-8859-1"/>

Warning Incorrect use of meta encoding declarations
Suggestion Non-UTF-8 character encoding declared

If someone has a translation of these two lines-- which appear to flatly contradict each other-- I really want to hear it.

Finally:
When shopping for a text editor, try to find one that can do two things: save a file with a new encoding AND reinterpret a file that is already open. Many text editors can't do the second step; you have to close a document and then say what encoding you want to use before opening.

Beyond-finally, the good news:
If a page contains no non-ASCII characters, it does not matter if the encoding is wrong. In English it really is possible to work entirely in ASCII, at least if you're willing to use entities (yuk) for things like proper apostrophes and nonbreaking spaces.

actolearn

3:03 am on Aug 7, 2013 (gmt 0)

10+ Year Member



g1smd: Ok, I've used Live HTTP Headers Extension. I saved a bunch of info but not sure what all you need to look at. Is below good? Does it tell you what we need to know? What info should I be looking for?

HTTP/1.1 200 OK
Date: Wed, 07 Aug 2013 02:22:29 GMT
Server: Apache
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Length: 3468
Keep-Alive: timeout=10, max=30
Connection: Keep-Alive
Content-Type: text/html
....................................................

lucy24:
Changing the meta charset line (or global equivalent in htaccess) will not change the encoding of a file that already exists.

But if I change my meta charset line and save the new url file as utf-8, that will take the place of my old iso url file - correct?


The charset/encoding declaration is purely for the browser's information; the browser has no way of knowing whether the encoding info is actually correct. Humans can tell, because some bits will display as garbage.

Yes, I've seen this and it's quite irritating for the reader. According to my research, most people seem to think that utf-8 is more universal which is why I wanted to switch. Should I not even bother?

And if I decide to go ahead and make the change...File change or global equivalent in htaccess - just do one or the other - not both?

wilderness:
If you like NotePad?
Look at "Search and Replace 98" a free html editor that offers replacement of lines and/or portions.

Thank you - I will check this one out also once I know a little more of what exactly I need to do.

GOING off-line for the evening. Will check back tomorrow. Thanks to all ~

lucy24

7:14 am on Aug 7, 2013 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member Top Contributors Of The Month



But if I change my meta charset line and save the new url file as utf-8, that will take the place of my old iso url file - correct?

Yes. One part is the file itself. The other part is what the file tells a browser. You just have to make sure they give the same information.

But that reminds me! You may need to check the settings in whatever program you use for FTP. Worst case: html is sent as text using the ftp program's default file encoding, probably based on your OS, so the files that were UTF-8 on your hard drive will turn into 8859-1 on arrival. Details of the fix will depend on your specific OS and software. Options include changing the default encoding, or sending text as raw data instead.

File change or global equivalent in htaccess - just do one or the other - not both?

You can do both. If the individual pages already contain a charset declaration then you need to change it so it's correct for the changed encoding. When a user reopens a cached page, or one they've temporarily saved to disk, I don't know if the browser remembers the header info (from htaccess) or falls back on what the page itself says. If you save a file in one browser and open it in a different one, then obviously all the browser can use is the page-internal information.

If you find a text editor to change all the pages globally without opening them one at a time, you should be able to change the words at the same time. And as long as you're there, make sure every page has a lang="something", preferably attached to the <html> element. If any page title contains non-ASCII characters, make sure the charset declaration comes before the <title> tag.

Any current browser, even MSIE, can read the "charset" declaration. So it really shouldn't matter what encoding you use. The huge advantage to UTF-8 is that once you've done it, you never need to think about it again. "Can I use a macron here, or do I need to go look up an entity?" Just type the character and there you are.

Finally, do make a proper change. People have been complaining for decades now about websites that persist in using up-and-down "keyboard" apostrophes and quotation marks, even though they look horrible. It's understandable in forums or other ugc because browsers may not have-- or people may choose not to use-- options like "smart quotes". But when it's a permanent www page, there's no excuse.

actolearn

6:39 pm on Aug 7, 2013 (gmt 0)

10+ Year Member



If you find a text editor to change all the pages globally without opening them one at a time, you should be able to change the words at the same time. And as long as you're there, make sure every page has a lang="something", preferably attached to the <html> element. If any page title contains non-ASCII characters, make sure the charset declaration comes before the <title> tag.

Thank you - mine was already set up this way but a good reminder.

Checked my ftp (filezilla) and renders in utf-8.

I've checked some of my url files in http live headers and all is 200 ok or else 304 (which if I understand correctly, is fine).

I'm going to start the process now. I'll check back to see if any other suggestions or comments or if I massively mess things up...

Thx for the help ~

lucy24

11:47 pm on Aug 7, 2013 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member Top Contributors Of The Month



304 means you have a good browser combined with a correctly configured server :)

The document is past its stated expiration date, but rather than re-download from scratch, the browser first asks the server if the file has in fact changed since the previous download. If it hasn't, the server spits out a "no change" (304). Formally it's the response to a conditional GET [w3.org].

actolearn

12:25 am on Aug 8, 2013 (gmt 0)

10+ Year Member



HELP! These are the steps I followed that completely broke my site - 500 error:

#1 This is what I have at top of files but as a php include:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8" />
................................................................

#2 added below lines to my .htaccess file:

AddDefaultCharset Off

# switching to utf
AddDefaultCharset utf-8 .html .php .css .js
................................................

#3 in my /public_html/php.ini I found
;default_charset = "iso-8859-1" and replaced with default_charset = "UTF-8"
................................................

#4 Did this for a few of my files (both php and html extensions/my home page, category page, product page):
Opened in notepad++/encoding tab/"Encode in UTF-8 w/o BOM"/on some I also clicked "Convert to UTF-8 w/o BOM" because wasn't sure if I need to do one or both)/saved/downloaded.

At bottom right corner was "Dos\Windows ANSI as UTF-8 INS" after I chose the encoding/then saved and downloaded
................................................

Below is error I got for my entire site:

Internal Server Error
The server encountered an internal error or misconfiguration and was unable to complete your request.
Please contact the server administrator, webmaster@example.com and inform them of the time the error occurred, and

anything you might have done that may have caused the error.
More information about this error may be available in the server error log.

Additionally, a 500 Internal Server Error error was encountered while trying to use an ErrorDocument to handle the request.
Apache Server at www.example.com Port 80
............................................................

So then I tried putting my php.ini file back to original status/still didn't work. Then deleted the lines I had added to my htaccess file Then website worked again/even the pages I saved as utf-8.

Can't figure out what I did wrong so any help would be appreciated.

actolearn

3:11 am on Aug 8, 2013 (gmt 0)

10+ Year Member



when I used http tool, info showed error:
Http content-type iso-8859-1
byte order mark (BOM) No
Meta tag (utf-8)

I think this means there's something wrong on the server side but I can't tell what.


I tried just this line in htaccess file:
AddDefaultCharset Off - this gave me same error as above so deleted that and tried
AddDefaultCharset utf-8 and got same error again

lucy24

4:10 am on Aug 8, 2013 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member Top Contributors Of The Month



when I used http tool, info showed error:
Http content-type iso-8859-1
byte order mark (BOM) No
Meta tag (utf-8)

I think this means there's something wrong on the server side

Definitely something wrong, but I can't begin to imagine why it would create a 500-class error. At worst I'd expect some parts of the browser page to display garbage.

But wait!
Somewhere along the line you mentioned a php setting. Are you also reading in material from a database? If there's an encoding mismatch, results can be calamitous, because some codepoints recognized in ISO-Latin-1 are simply not valid in UTF-8. In the case of displaying text it's not a major issue; you just see garbage. But if a file is trying to get information from a database in order to construct a page...

Opened in notepad++/encoding tab/"Encode in UTF-8 w/o BOM"/on some I also clicked "Convert to UTF-8 w/o BOM" because wasn't sure if I need to do one or both)/saved/downloaded.

The exact wording is application-specific. The easiest way to tell is to make a document containing at least one visible non-ASCII Latin-1 character. Say, an accented letter é. Save both ways under different names. Now open both with the same settings and see if they're different.

When I change the encoding of a document in SubEthaEdit, it always asks if I want to convert or reinterpret-- even if it's a brand new, empty document so there's nothing to change. So it's possible there really is no difference in your case.

Why are you turning off the default charset if you're going to turn right around and set a new one?

:: detour to check what mine says ::

Oh. I don't say anything about default at all. I have the minimalist form AddCharset.

:: further detour to refresh memory on the difference, which I suspect is major ::

This mapping is added to any already in force, overriding any mappings that already exist for the same extension.
<snip>
The AddCharset directive is useful for both to inform the client about the character encoding of the document so that the document can be interpreted and displayed appropriately, and for content negotiation, where the server returns one from several documents based on the client's charset preference.

OK so far. This is for AddCharset under mod_mime; AddDefaultCharset is in a completely different area-- core, in fact-- which makes me uneasy.

Bingo. Where's the "lightbulb" icon? The problem is in the syntax. With AddDefaultCharset, you don't list extensions. Just on (which defaults to 8859-1), off, or some charset name other than 8859-1. Hence the 500 error.
This directive specifies a default value for the media type charset parameter (the name of a character encoding) to be added to a response if and only if the response's content-type is either text/plain or text/html. This should override any charset specified in the body of the response via a META element, though the exact behavior is often dependent on the user's client configuration. A setting of AddDefaultCharset Off disables this functionality. AddDefaultCharset On enables a default charset of iso-8859-1. Any other value is assumed to be the charset to be used

Short version: You don't need AddDefaultCharset at all. Use AddCharset and the server should be happy again.

actolearn

12:32 pm on Aug 8, 2013 (gmt 0)

10+ Year Member



Short version: You don't need AddDefaultCharset at all. Use AddCharset and the server should be happy again.

my Apache version is 2.2.24
The reason I used AddDefaultCharset is because at [w3.org...] I read this:
Server setup
How to make the server send out appropriate charset information depends on the server. You will need the appropriate administrative rights to be able to change server settings.

Apache. This can be done via the AddCharset (Apache 1.3.10 and later) or AddType directives, for directories or individual resources (files). With AddDefaultCharset (Apache 1.3.12 and later), it is possible to set the default charset for a whole server. For more information, see the article on Setting 'charset' information in .htaccess.


I'll try just AddCharset.

To get my site back up, I reversed my steps but left my utf8 saved files as is with the meta utf8. That worked and left me with the tests showing http headers were iso but files are utf-8. Leaving like this for now so can keep trying/testing until http and meta both show utf-8 or until I give up.

For my files that have meta utf8 the only difference from my iso files is the > symbol is now a wrong looking symbol. This is where I have my rdf.data breadcrumb links (home/category name/sub-cat name). That's fine for now for my testing.

But wait!
Somewhere along the line you mentioned a php setting. Are you also reading in material from a database? If there's an encoding mismatch, results can be calamitous, because some codepoints recognized in ISO-Latin-1 are simply not valid in UTF-8. In the case of displaying text it's not a major issue; you just see garbage. But if a file is trying to get information from a database in order to construct a page...

Yes, I'm definitely using a database. Looking at my db info: phpMyAdmin/db table/table options/utf8_general_ci so I thought that was correct. I'll check a few of my table columns to see if ISO latin is in there somewhere but thought I read it wouldn't matter. I'll double check my research on this.

Thx for hanging in there with me. Going off to try yet again. Will post with results later this morning. Need to wake up with some strong tea first!

actolearn

7:47 pm on Aug 8, 2013 (gmt 0)

10+ Year Member



Hello ~ Just a quick update. Still having problems...

Working in my .htaccess file and trying below one at a time:

AddCharset (500 internal server error)
AddCharset .html (500 internal server error)
AddCharset .php (500 internal server error)

Then tried below (one at a time) and site stays up (no 500 error) but still getting the error re iso-8859-1/utf-8.

AddCharset UTF-8 .php
AddCharset UTF-8 .html
AddCharset UTF-8 .php .html
AddCharset .php .html (HAVE KEPT IN htaccess file for now even though getting error)

Error:
HTTP Content-Type iso-8859-1 Content-Type: text/html; charset=iso-8859-1
Byte order mark (BOM) No
Meta tag utf-8 <meta http-equiv="content-type" content="text/html; charset=utf-8"/>

Explanation: The following character encoding declarations are inconsistent:
Content-Type: text/html; charset=iso-8859-1
<meta http-equiv="content-type" content="text/html; charset=utf-8"/>

I really can't figure out how to fix this:(

actolearn

9:41 pm on Aug 8, 2013 (gmt 0)

10+ Year Member



Just an update:

I deleted any mention of charset from htaccess file.

In php.ini file I exchanged
;default_charset = "iso=8859-1" for
default_charset = "utf-8"

Checking with http tool the HTTP and meta match (utf-8 as desired). I still have a little error but I no longer have a squiggle where there shouldn't be one. The > symbol shows up correctly instead.

HTTP Content-Type utf-8 Content-Type: text/html; charset=utf-8
Byte order mark (BOM) UTF-8
Meta tag utf-8 <meta http-equiv="content-type" content="text/html; charset=utf-8"/>

NOW the only error I get is
UTF-8 BOM found at start of file

The UTF-8 Byte Order Mark (BOM) was found at the beginning of the page.


I'll keep working on this since I probably messed up while going back and forth, up and down and sideways...

lucy24

9:57 pm on Aug 8, 2013 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member Top Contributors Of The Month



AddCharset (500 internal server error)
AddCharset .html (500 internal server error)
AddCharset .php (500 internal server error)

I should think so, if those are actual quotes! Apache is VERY particular about syntax. A misplaced comma will bring the whole site crashing to the ground. To repeat what I said above, AddCharset and AddDefaultCharset use different syntax. But the form used here is valid for neither one.

AddCharset UTF-8 .php .html

This and only this is the correct syntax [httpd.apache.org]. (Forums auto-linking may eat the "addcharset" fragment.) 
AddCharset charset extension [extension] ...

You MUST list one charset and one extension. You MAY add additional extensions, or you can make a separate statement for each extension.

AddCharset .php .html (HAVE KEPT IN htaccess file for now even though getting error)

This form is wrong, and will always be wrong, so delete it.

Are .php and .html the filename extensions you actually use? It doesn't matter about extensionless URLs, if any, just the physical files. Filetypes may be listed generically as "text/html", but when you name an extension in the form ".html" that means .html ONLY, not .htm.

Setting aside LiveHeaders messages, how do the pages display in your browser? Are non-ASCII characters correct or incorrect?

Examples:
UTF-8 é (e-acute) interpreted as 8859-1 will display as ü (A-tilde followed by 1/4) *
UTF-8 ü (u-umlaut) interpreted as 8859-1 will display as é (same followed by copyright sign)

Other direction:
8859-1 é and ü interpreted as UTF-8 will display as [black diamond with question mark] -- though here the browser may override the charset declaration and use 8859-1 instead.


* If your browser displays this page in 8859-1 instead of UTF-8, this in turn will become A-tilde A-circumflex 1/4 and so on. You can toggle back and forth indefinitely.

actolearn

10:54 pm on Aug 8, 2013 (gmt 0)

10+ Year Member



Are .php and .html the filename extensions you actually use? It doesn't matter about extensionless URLs, if any, just the physical files. Filetypes may be listed generically as "text/html", but when you name an extension in the form ".html" that means .html ONLY, not .htm.

Yes, I only use .php and .html (not .htm). My home page is extensionless and all other files are saved as .html or .php and appear with an .html or .php extension in url.

Sorry but not sure I understood your last post. Did you read my 9:41 pm post? I deleted any mention of charset from my .htaccess file. Are you saying I should put something back in? I did find that page you linked to when I was researching all of this but it was hard for me to understand.

SO, do I need to put something back into my .htaccess file re charset?

I checked another one of my test pages and it works fine/passed the http test with no errors = no bom errors and http and meta matched as utf-8.

Now my pages that I have not converted to saving as utf-8 w/o BOM yet show a dark little diamond with ? in middle instead of >. I will need to fix those now but first I need to understand you better. I'll wait for your answer about putting something about charset back into my htaccess file.

lucy24

11:49 pm on Aug 8, 2013 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member Top Contributors Of The Month



Oops, no, typed too slow so I didn't see the most recent post.

If you've got correct charset declarations in each individual page then you don't need anything in htaccess. It's just insurance in case you forgot the "charset" declaration entirely. A charset line in htaccess can actually make things worse if you have some pages that are something other than utf-8, because the browser may then display them incorrectly.

Now my pages that I have not converted to saving as utf-8 w/o BOM yet show a dark little diamond with ? in middle instead of >.

That's the UTF-8 "can't display this character" symbol. You get it when the browser tries to interpret something as UTF-8 when it's in some other encoding, most likely a one-byte encoding like Latin-1. If you have nothing about charset in htaccess, AND the individual document's charset declaration is correct, then you should never see this symbol. Unless, ahem, you've intentionally typed it. If you empty the cache and refresh the window, does it still show up?

"correct charset declaration" = the stated encoding matches the encoding that was actually used for the current file

actolearn

1:13 am on Aug 9, 2013 (gmt 0)

10+ Year Member



OK ~ so sounds like I'm good to go. Once I save my files correctly I shouldn't have any more wrong looking symbols judging by the 3 I've worked on so far - those look great.

Thank you for helping me work through all this. AC
 

Join The Conversation

Moderators and Top Contributors

Hot Threads This Week

  1. Home
  2. Forums Index
  3. Server Side / Apache Web Server 9:09 am May 21, 2026