Basic .html webpages and encoding types when saving; does it make any difference?

[Clint1]

I don't see an appropriate forum to ask this, so I have to ask it here. I recently changed from the cPanel "x2" to the "x3" type theme/layout for my main website. Among the differences, in the "Legacy File Manager" area when you open any page it asks about the encoding you want to use. (This does not happen with the x2 theme). It then selects or guesses on the encoding and you can go with that, or select another from a REALLY LONG list in a drop-down menu. (I found out that prompt can be bypassed by changing a setting in the current non-legacy File Manager). But the options are still there if you want to change encoding. Also once the page is opened and you go to edit it, at the top is also the drop-down menu about the encoding which you can choose when saving the page changes.

So here's what I don't understand. All of my .html pages were created the same way, either in Notepad or Metapad, basic text. So why is it the detected encoding is so different for my .html pages? Here's a list of the encodings for few I opened to check this:
ansi_x3.110-1983
iso-8859-1
us-ascii
big5

Again, these are all the same basic .html types of webpages. Now I would have thought all of them would be "us-ascii". But as you can see, they are not. There may be even more encoding types. How did they get this way? Does it really make any difference, or should I re-save all the pages as us-ascii? Is there any search engine advantages by using one type of encoding or the same encoding for all pages?

BTW, I tried changing one of the "big5" detected pages to the us-ascii option and it would not take! It kept going back to "big5". And, the type of fonts you see in the edit window (which displays the source code) are totally different for this "big5". All the other types are shown as the same font, but "big5" looks rather "scrunched up". (The fonts people see on the webpages, all look the same and as they should).

Thanks.

[kgun]

Originally Posted by Clint1

I don't see an appropriate forum to ask this, so I have to ask it here. I recently changed from the cPanel "x2" to the "x3" type theme/layout for my main website. Among the differences, in the "Legacy File Manager" area when you open any page it asks about the encoding you want to use. (This does not happen with the x2 theme).

I don't know about x2 and x3. New to me. Do we need further information to answer your question? Nevertheless here is my fast contribution.

Originally Posted by Clint1

Basic .html webpages and encoding types when saving; does it make any difference?

Originally Posted by Clint1

So here's what I don't understand. All of my .html pages were created the same way, either in Notepad or Metapad, basic text. So why is it the detected encoding is so different for my .html pages? Here's a list of the encodings for few I opened to check this:
ansi_x3.110-1983
iso-8859-1
us-ascii
big5

May be I misunderstand your questions / problem, but I use Dreamweaver 2004 mx and have no problems. A List apart is the authoritative site on encoding and document types. DigitalStart.net: The starting point for English speaking surfers and webmasters (see second item on vertical menu below "Start" on the horizontal tool bar).

Originally Posted by Clint1

Is there any search engine advantages by using one type of encoding or the same encoding for all pages?

Do you mean SEO advantage?

[wige]

As far as different encodings, most are the same for the lower ASCII characters. I believe for the ones you list you shouldn't have a problem as they are all comprable - the difference is in the extended characters which would not be used in most cases on a US site.

Notepad does have a default encoding, based on the computer you are using. If you switch between computers it is possible you could end up saving some files with different encodings. It is also possible that X3 can't determine which encoding you are using and is just making a guess, which is probably based on a limited charset causing it to guess different encodings for different documents.

[Clint1]

Originally Posted by kgun

I don't know about x2 and x3. New to me. Do we need further information to answer your question? Nevertheless here is my fast contribution.

Thanks, like I said x2 didn't have those options, so you may need to be familiar with x3 to know what I mean.

Do you mean SEO advantage?

I guess that's what I mean. I'm wondering if one's pages are something odd like "big5" could have a negative effect on SE bot spidering, as compared to another encoding like us-ascii.

[Clint1]

Originally Posted by wige

As far as different encodings, most are the same for the lower ASCII characters. I believe for the ones you list you shouldn't have a problem as they are all comprable - the difference is in the extended characters which would not be used in most cases on a US site.

What do you mean by "lower" ASCII characters and "extended"? As in case, or something else? I use &#064 for the @ symbol, (I had to remove the ; from that code), and some other things like © and & , does that have anything to do with this? I don't need to worry about any of this for basic USA/English text and fonts?

It is also possible that X3 can't determine which encoding you are using and is just making a guess, which is probably based on a limited charset causing it to guess different encodings for different documents.

Yeah that's what I mentioned it was doing, it even says it's guessing (something like "..our best to determine the type of encoding used..."). But my concern was, does it matter if it doesn't get it right?

Thanks.

[wige]

There are a few variables that effect the default encoding - program, operating system and file system, etc. Generally, however, English characters can be represented in 8 bits or less (ASCII is actually 7 bits, 8859 is 8, etc). Longer encodings allow for larger sets of characters.

Basically, encoding is something you can't see - it is different from what & is converted to in a browser - the encoding is actually indicating how the &, a, m, p and ; are stored on the hard drive or transmitted from system to system as ones and zeros. For example, an ASCII encoding indicates that each character is 7 bits long. 8859 indicates that each character is 8 bits long. And UTF-16BE indicates that each character is 16 bits long, sorted differently than UTF-16LE. If the wrong encoding is selected, you will usually see the problem quickly in a text editor because the characters will be all garbled. However, in many encodings that have similar lengths, the lower portion of the character (first 7-8 bits in a 16-bit or larger encoding system) will be the same - you might not realize you are using the wrong encoding until you enter a character in the extended space, such as an international accent mark.

[deepsand]

Originally Posted by Clint1

What do you mean by "lower" ASCII characters and "extended"?

The original ASCII code provided for 7 data bits & an optional parity bit, which, when not used, was set to zero; thus, a maximum of 128 characters, decimal values 0 thru 127, was supported.

Extended ASCII incorporated the 8th bit into the data bits, thus doubling the number of supported characters to 256.

The tables at Ascii Table - ASCII character codes and html, octal, hex and decimal chart conversion show both the original, or lower, 128 characters as well as the most commonly used set of upper 128 ones.

Unlike ASCII, UTF (Unicode Transformation Format) is a variable length encoding method, ranging from 1 to 4 bytes. Single byte characters in the value range 0 to 127 represent the same characters as does 7 bit ASCII, thus providing for backward compatibility.

Thus, an application that is expecting data to be in a particular encoding, i.e. ASCII or UTF, will, when presented with data in the other, properly display such only if all bytes have values in the lower ASCII range of 0 to 127.

[Clint1]

Thanks for all the info guys, but I'm still not clear on answers to these:

I'm wondering if one's pages are something odd like "big5" or other, could have a negative effect on SE bot spidering, as compared to another encoding like us-ascii.

And ......it even says it's guessing (something like "..our best to determine the type of encoding used..."). But my concern was, does it matter if it doesn't get it right?

(Deepsand did you ever get the email I sent? I sent it to the address to gave me. And I see you edited your post due to spelling, check out ieSpell - Spell Checker add-on for Internet Explorer it checks/fixes typos for any text input boxes, works on IE5 and later).

[deepsand]

The meta tag "charset" parameter is used for declaring the character set being used by a document.

The tag for this page, for example, is <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1" /> .

Note, though, that server settings can override in-document declarations.

For more, see W3C I18n article: Character encodings .

Got your e-mail; will get to as soon as I can.

[Clint1]

Ok....thanks again for the info.....but.....

Thanks for all the info guys, but I'm still not clear on answers to these:

I'm wondering if one's pages are something odd like "big5" or other, could have a negative effect on SE bot spidering, as compared to another encoding like us-ascii.

And ......it even says it's guessing (something like "..our best to determine the type of encoding used..."). But my concern was, does it matter if the File Manager doesn't get it right?

[deepsand]

Well, if the encoding used is different from that specified via said meta tag parameter, and the content contains anything other than bytes with values in the decimal range of 0 to 127, then there is certainly the possibility that the indexing engine will be unable to properly parse the content.

Who is your host? Big5 is a Chinese encoding, used for displaying Traditional Chinese characters.

[Clint1]

Originally Posted by deepsand

Well, if the encoding used is different from that specified via said meta tag parameter,

What if you don't use the meta tag parameters?

and the content contains anything other than bytes with values in the decimal range of 0 to 127, then there is certainly the possibility that the indexing engine will be unable to properly parse the content.

I don't think they do, I'm still not quite clear on that. Like I said, the HTML code is just the English 26 letter alphabet and 0-9, and some punctuation. So is that within the range of 0-127?

Who is your host? Big5 is a Chinese encoding, used for displaying Traditional Chinese characters.

Web Site Hosting and Business Web Hosting Plans from Reliable web site hosting Provider . Yeah I thought the font kind of looked like "Chinese fonts in English" (for lack of a better term). They kind of have that "oriental look" to them, even though they are English.

Thanks.

It took about 20 minutes for me to get to this frickin' page due to the refresh loop problem.

[wige]

Originally Posted by Clint1

What if you don't use the meta tag parameters?

There are a few different places where the character encoding is specified - a meta tag, the <html> tag, and the headers as sent by the server. Generally, the server headers take priority as they are set by the server, based on the encoding of the document itself.

I don't think they do, I'm still not quite clear on that. Like I said, the HTML code is just the English 26 letter alphabet and 0-9, and some punctuation. So is that within the range of 0-127?

Generally, the lower 127 values are the same from one encoding to another. These characters are the English alphabet and punctuation, plus a few other characters such as file seperators and keyboard commands (DEL, Newline, TAB, etc). Since most other charsets only differ from ASCII in the extended portion, you won't notice a difference between charsets. For example, in ASCII, "A" is |01000001|. In ISO-8859-1, "A" is still |01000001|. In UTF-8, "A" is still |01000001|. The difference between these three encodings is the characters in the extended portion of the set. The easiest way I can think to explain this is that when the leading bit is 0, most encodings are the same. When the leading bit is not 0, such as for European accent characters, the encodings differ. Also, some encodings are longer, for example, instead of the 8 bits of ASCII and ISO-8859-1, UTF16 is 16 bits in length.

Yeah I thought the font kind of looked like "Chinese fonts in English" (for lack of a better term). They kind of have that "oriental look" to them, even though they are English.

I should note that the font is generally seperate from the character set. The character set determines whether those eight ones and zeros are an "A" or a "B" - whether that A or B is displayed in Courier or Verdana is up to the software. It's possible that the editor (or browser) is applying the oriental styling so that you can tell that this other encoding is in use.

It took about 20 minutes for me to get to this frickin' page due to the refresh loop problem.

Still looking into this. Probably the best clue from here would be a header capture from that addon I mentioned last from the last issue.

[Clint1]

Originally Posted by wige

There are a few different places where the character encoding is specified - a meta tag, the <html> tag, and the headers as sent by the server. Generally, the server headers take priority as they are set by the server, based on the encoding of the document itself.

How can the headers sent by the server be controlled, or can they? If they can't be controlled so-to-speak, then I guess it's "controlled" by the original raw encoding that the text editor gave it.

Generally, the lower 127 values are the same from one encoding to another. These characters are the English alphabet and punctuation, plus a few other characters such as file seperators and keyboard commands (DEL, Newline, TAB, etc). Since most other charsets only differ from ASCII in the extended portion, you won't notice a difference between charsets. For example, in ASCII, "A" is |01000001|. In ISO-8859-1, "A" is still |01000001|. In UTF-8, "A" is still |01000001|. The difference between these three encodings is the characters in the extended portion of the set. The easiest way I can think to explain this is that when the leading bit is 0, most encodings are the same. When the leading bit is not 0, such as for European accent characters, the encodings differ. Also, some encodings are longer, for example, instead of the 8 bits of ASCII and ISO-8859-1, UTF16 is 16 bits in length.

Yeah I gotcha there, good explanation, thanks.

Still looking into this. Probably the best clue from here would be a header capture from that addon I mentioned last from the last issue.

Now the notification emails are coming in again in the raw unformatted plain text! No line breaks, no paragraphs, everything all smashed together, and no links are clickable. It's like the emails were sent through some kind of "stripper".

I don't remember if the refresh problem was happening in FF. I THINK, maybe Deepsand is using FF, and he said it happened to him. So Deepsand maybe you could check that header response with that plugin. I'll try to remember to try the page in FF when it happens again.

So, all this good information, and still no one has told me if these encodings have any bearing on the way a SE bot spiders the pages, and, if mine are not all the same is that a bad thing.

[wige]

ISO-8859-1 is kind of the preferred encoding of the web. However, most encodings such as UTF-8 and US-ASCII should be well supported, and won't adversely affect your search engine placement - as long as the search engine can read it, you will be fine. Differences from document to document should also not be a problem. Worst comes to worst and a user agent doesn't support the specific character set, the user agent will treat the document as though it is in US-ASCII. Also, your server may even transcode the document (change it's encoding on the fly to correspond with the encodings that the user agent supports) to maximize compatibility.

The only one I might be concerned about would be the files that are in Big5. I am not sure how well that is supported, and it should probably be changed unless you are using Chinese characters - Big5 is 16bits in length, so it sends twice as much data per character as ISO-8859-1. However, just like ISO-8859-1 and UTF-8, Big5 still uses the ASCII set for the lower 7 bits of the first byte, meaning it is interchangeable with other 16bit character sets.

That being said, in the long run I would try to go for consistency, probably converting documents to 8859.

I should probably ask, when you upload documents onto the server, are you using FTP, and uploading the document in ASCII mode?

[Clint1]

Originally Posted by wige

The only one I might be concerned about would be the files that are in Big5. I am not sure how well that is supported, and it should probably be changed unless you are using Chinese characters - Big5 is 16bits in length, so it sends twice as much data per character as ISO-8859-1. However, just like ISO-8859-1 and UTF-8, Big5 still uses the ASCII set for the lower 7 bits of the first byte, meaning it is interchangeable with other 16bit character sets.

Thanks again. Ok, I mentioned before that I tried changing a "big5" page to us-ascii and it would not change. I even took the source code and copy/pasted it into the file of the File Manager! No telling how long that's been going on because as I mentioned this was never an option and never seen in cPanel x2 themes, only x3. (This is the cPanel Demo login for the host I think I'm going to go with), and you can see the x3 theme. Click "Legacy File Manager" under "Files", then click any of those ".wysiwygPro_edit" files or the htaccess file, then "Edit" at the right pane, and see the encoding prompt. http://74.52.116.98:2082/login?user=demo&pass=demo (demo & demo if those don't show in the URL here).

I should probably ask, when you upload documents onto the server, are you using FTP, and uploading the document in ASCII mode?

I don't use FTP for that. I use the File Manager to make page changes, and I also use it to upload programs and PDF files. I use FTP to make an FTP backup of everything, and it (old WS_FTP) is set to "Auto" so it automatically switches between Binary and ASCII as needed. Rarely, maybe once, I've restored the site using FTP and it was also set that way.

When I create a new page, I just start it in Notepad, Metapad more recently, then paste that into the blank area of the File Manager for the new page. If the new page is similar to others, I just copy/paste the code from another page, then modify it. So that's why this doesn't make any sense to me why there would be more than one encoding type showing up in that File Manager area. I am consistent, but for some reason x3 File Manager sees it differently!

[Clint1]

Ahhh, being new to the x3 them, I didn't know this: Once you click to Edit the file and the source code page opens up to edit it, there's a toolbar at the top (you'll see it). Since the file is already opened, I didn't see the need to click the "Open" button. But this time I took a page that was claimed as ansi_x3.110-1983, and in the drop-down I THEN changed that to ISO-8859-1, THEN I clicked "Open" again, and it opened in that encoding. THEN I was able to save it in that encoding. So obviously that's the trick to changing pages' encoding.

[deepsand]

In the "File Manager," as opposed to the "Legacy File Manage," selecting a file and then clicking on "Edit" automatically pops up a panel re. encodings, with the option to disable auto-detect of encoding and/or manual selction of encoding to be used.

[deepsand]

Originally Posted by Clint1

Now the notification emails are coming in again in the raw unformatted plain text! No line breaks, no paragraphs, everything all smashed together, and no links are clickable. It's like the emails were sent through some kind of "stripper".

Odd that you should mention that just now, as it only a short time ago occurred to me that I'd not seen that particular problem for quite some time now.

Originally Posted by Clint1

I don't remember if the refresh problem was happening in FF. I THINK, maybe Deepsand is using FF, and he said it happened to him. So Deepsand maybe you could check that header response with that plugin. I'll try to remember to try the page in FF when it happens again.

Which "plugin" are you referring to?

[Clint1]

Originally Posted by deepsand

In the "File Manager," as opposed to the "Legacy File Manage," selecting a file and then clicking on "Edit" automatically pops up a panel re. encodings, with the option to disable auto-detect of encoding and/or manual selction of encoding to be used.

I know, see my first post on this thread. ".....(I found out that prompt can be bypassed by changing a setting in the current non-legacy File Manager). But the options are still there if you want to change encoding."

You can still see the drop-down menu of the encodings, and the encoding it "chose", that's how I found out about the odd encodings.

[Clint1]

Originally Posted by deepsand

Which "plugin" are you referring to?

I forgot that info was a different thread. https://addons.mozilla.org/en-US/firefox/addon/6647 . But I don't remember the thread now or I'd paste the info about it here or give a link to it. He may have to tell us how to use it to maybe diagnose the refresh problem.

[deepsand]

Originally Posted by Clint1

I know, see my first post on this thread. ".....(I found out that prompt can be bypassed by changing a setting in the current non-legacy File Manager). But the options are still there if you want to change encoding."

You can still see the drop-down menu of the encodings, and the encoding it "chose", that's how I found out about the odd encodings.

So you did. My not remembering that owes to the fact that when you started the thread I'd not been able to see what you were seeing, and not therefore able to put all that you then said in context for better later recall, so that I simply had no memory of your mention of the regular File Manager.

Hopefully this means that I'm fired, as I could certainly use the rest.

[Daniel L.]

(Edited out. I see one of my helpers here [Danny] was logged in using FF.).

[Clint1]

Well I'm having to use FF now because this page is in the refresh loop for me again in IE. But it didn't do it in FF. I guess I'd have to use FF all the time here and just hope I may catch it with HTTPFox running. (Updated: now the page is working IE).

Originally Posted by deepsand

So you did. My not remembering that owes to the fact that when you started the thread I'd not been able to see what you were seeing, and not therefore able to put all that you then said in context for better later recall, so that I simply had no memory of your mention of the regular File Manager.

I was just letting you know that I was aware that could be done.

Hopefully this means that I'm fired, as I could certainly use the rest.

Fired from......?

"Rest"? What is "rest"?? I hear of that, but I forget what it was. I'll have to look that up.....................................Ok, ah yes, I remember that now.

HA!! "A bodily state characterized by minimal functional and metabolic activities". "Minimal functional activities", I guess that means I must be "resting" all the time. I'm minimally functional. ROTFLMAO.

[deepsand]

At the moment, I've got this page open in both FF 3.5 & IE 6, with no odd behavior.

Who is Daniel L.?

[Clint1]

That's been edited now. Sort of an "employee" for me from time to time. Obviously he doesn't post here much (and obviously prefers FF).

It happened to me again on IE6. I'm beginning to find that sometimes I can click "Stop" on the toolbar at a specific time, then click the "Refresh" button and sometimes it will reload then stop and go back to normal. They key is clicking the Stop button at the right time.

[deepsand]

Still okay here on both browsers.

And, as I've an alarm going off in 5 & 1/2 hrs., and a 1/2 hr.+ drive to home, I'm about ready to call it a wrap for tonight.

Enjoy.

[wige]

Is this happening in IE6 specifically? Or does it occur in Firefox from time to time as well, just more rarely? If it is limited to IE6 I have some thoughts on a possible cause, but if it affects other browsers it would have to be something different.

There are only a few ways to cause a page to redirect, for all browsers other than IE6, these are limited to scripts, redirect headers, and meta redirects. If it happens in Firefox, I would start by using the web developer toolbar addon and disable Meta Redirects. You could also disable Javascript. That would at least rule out the redirection being cause by those sources. The header addon should show in the response codes if the page request is getting a looping 301 redirection, however Firefox at least is supposed to detect infinite redirects and display an error message (unless you are bouncing between two pages over and over)

[Clint1]

What I said above in post #17 about finding how to do this, not true. Today, the files have all reverted back to their previous mysterious encodings!

I just got through trying to paste the code of one page into Notepad, in the event Metapad may have some kind of "encoding" we don't know about, and that didn't change
anything--same strange behavior after copy/pasting it from Notepad. (Oddly enough, plain Jane basic Notepad has the option of encoding saving if you "Save as.....". It defaults to ANSI, and the only other options there are "Unicode", "Unicode big endian", and "UTF-8").

This was never an issue in the older cPanel x2 theme, because it was simply not an option. When files where opened, there was no option for decoding the encoding as there is in the File Manager of x3. And, this is not solely a Legacy File Manager bug, because it's still happening on the new NON-Legacy File Manager.
So the issue is not specific to anything "Legacy".

I started to think that the true operational behavior of this function was that the drop-down encoding menu may only be for the way the files are OPENED, and it may have nothing to do with the way the files are SAVED. But no, that's not it, look at what it says below the drop-down menu options:

"We have attempted to auto-detect the encoding of this file. However, this is not a foolproof process since some files will display properly with multiple different encodings. You should select the encoding that this file was originally created with. It is very important that you select the proper encoding; saving your file with the wrong encoding may result in the corruption of your text."

Note the blue part. So according to that, you ARE supposed to be able to save the files with (different?) encoding. Further:

"If you are only using a Western European language like English, Spanish or French without any special characters you can safely assume "ISO-8859-1" will work just fine. If you are using a non-western language or you have special characters that are not HTML encoded in your file, you should enter "utf-8". If your file appears with text like this: or [images were here] you may have selected the incorrect encoding. If this happens, you should immediately abort the edit and select the correct encoding. You should not save the file; this will likely corrupt the text permanently".

Sounds serious! Well, the problem is you can OPEN the files in any encoding you want, but, cannot SAVE it in any encoding you want. Sounds like that's a bad idea to make the x3 theme like that! Why not just keep like it was in x2 when this was never any problem??? (Another example of newer versions being buggy). cPanel needs to be asked that, especially since the encoding cannot be changed. (I would ask cPanel about this myself, but a few years back I tried to contact them about something else and they wouldn't give me the time of day. They said my host would have to contact them! I fail to understand that. I contacted my new hosts, HostGator [so far so good] about this and they've never had anyone ask them this before, so they've never noticed it. Maybe they will ask cPanel).

I know us-ascii and ISO-8859-1 are ok. But my problem, issue, with all of this is what does odd encodings like "big5" or "ansi_x3.110-1983" do to a search engine bot's ability to properly parse the page? According to Wige, nothing, but it might with the "big5" encoding. If that answer is an undeniable, definite "not a thing", then all this is a moot point. But at the very least I'm most curious as to what the problem is with cPanel, why is it doing this.

I just found out one thing, pages shown as "big5", today at least, cannot be opened then saved as ISO-8859-1. But they can be opened and then saved as US-ASCII. I don't get it. If that still holds tomorrow, then I guess that should at least fix or help with the potential 'big5' encoding problem.

[Clint1]

Originally Posted by wige

Is this happening in IE6 specifically? Or does it occur in Firefox from time to time as well, just more rarely? If it is limited to IE6 I have some thoughts on a possible cause, but if it affects other browsers it would have to be something different.

I don't know if that's addressed to me, or "quicksand". If him, I don't know, but like I said yesterday I think he said it had it happen to him on FF, and in checking over this thread that appeared to have happened on another thread. I can't find the thread.

[wige]

As far as big5, I actually seem to remember reading something about "safe conversion" which involved converting the 16-bit big5 to 7-bit US-ASCII before converting it back to another encoding. I think this is a way to prevent extended characters from getting garbled by actually removing them.

With these files, are you editing them locally then uploading them to the remote server, or editing them directly on the server?

I started to think that the true operational behavior of this function was that the drop-down encoding menu may only be for the way the files are OPENED, and it may have nothing to do with the way the files are SAVED. But no, that's not it, look at what it says below the drop-down menu options:

"We have attempted to auto-detect the encoding of this file. However, this is not a foolproof process since some files will display properly with multiple different encodings. You should select the encoding that this file was originally created with. It is very important that you select the proper encoding; saving your file with the wrong encoding may result in the corruption of your text."

The encoding is for both opening and saving your file. Lets say your file starts with |01000001| - when the editor reads that, it needs to know what encoding to use to figure out what letter those ones and zeros represents. Then, when you close the file, it will overwrite the existing file with the specified encoding.

Doing some research into this, it looks like CPanel now gives this prompt when opening ANY file that ends with .html. Nobody seems to be able to figure out why, or how to stop it.

[Clint1]

Originally Posted by wige

As far as big5, I actually seem to remember reading something about "safe conversion" which involved converting the 16-bit big5 to 7-bit US-ASCII before converting it back to another encoding. I think this is a way to prevent extended characters from getting garbled by actually removing them.

I can't remember if I tried going from big5 to ASCII (sleeeepy), but I'll try that tonight.

With these files, are you editing them locally then uploading them to the remote server, or editing them directly on the server?

I edit them on the server with cPanel's File Manager. MUCH quicker. And that was on the x2 version of cPanel. My hosts just told me they'll contact cPanel about it. (My new hosts, HostGator has been absolutely awesome. A Dozen+ emails back and forth just today alone, and if it would have been my last host I'd be waiting a week for the first response, which wouldn't make any sense anyway). So hopefully cPanel will be like HG and not like my previous hosts. But I have a feeling cPanel doesn't care.

[/I]The encoding is for both opening and saving your file. Lets say your file starts with |01000001| - when the editor reads that, it needs to know what encoding to use to figure out what letter those ones and zeros represents. Then, when you close the file, it will overwrite the existing file with the specified encoding.

Doing some research into this, it looks like CPanel now gives this prompt when opening ANY file that ends with .html. Nobody seems to be able to figure out why, or how to stop it.

Hmm, interesting. If you searched for this, what terms did you use? I tried searching for this earlier and couldn't find anything pertaining to this (and I'm pretty good with an advanced search ). Now, you know the prompt can be stopped, using the new File Manager and "Settings". I got rid if the prompt. The problem is when saving the page you can't change the encoding.

Thanks.

[wige]

I searched for "cpanel file manager character encoding" without the quotes, and got a lot of forum posts on the topic.

[deepsand]

Originally Posted by wige

Is this happening in IE6 specifically? Or does it occur in Firefox from time to time as well, just more rarely?

I observed the auto-refresh problem during one period of several consecutive days only, perhaps 2 to 3 weeks ago, on the "Who's Online" page only. To the best of my recollection, that was while using FF 3.0.11, although, given that I generally have multiple browsers running (FF, IE & Safari), with multiple windows, with multiple tabs in all but IE, it is possible that it may have been IE 6.

[Clint1]

Originally Posted by wige

I searched for "cpanel file manager character encoding" without the quotes, and got a lot of forum posts on the topic.

Ok thanks. I searched for cPanel encoding x3 save OR saving since this is only on the x3 theme.