Annoying tags on displayed webpages

[esonline]

Hi

I am new to JaguarPC, having joined just two weeks ago.

Problem 1: On my websites, I seem to be getting this annoying '<' tag displayed on top left of some affected pages. So, far, I have found that by deleting the affected .htm or .php file, and reuploading it to the server, the annoying tag disappears.

But, as I update files very regularly and therefore carry out frequent uploading of these files, this situation is quite irritating.

Problem 2: Also, I get '!!' -- inverted exclamation mark tags -- which come about because of a blank spacing between html tags -- eg.<p>　</p> and <p align="left">　</td>.

The support chap was helpful. He deleted the annoying tags but that wasn't what I really wanted. You see, I have thousands of pages with plain html and it is a monumental task for me to go into these files to fix the html. On HostForWeb and Verio servers, my websites do not have these two problems. I am wondering why.

Can anyone help me out, please?

Thanks.

[Sara]

I don't know if I can help you, but it would be a help to those who can if you would post a link to your site.

[esonline]

Hi Sara

Thanks for your thoughts.

Here's a URL where the '<' tag appears on the top left corner of page:
- http://www.singaporeontheweb.net/hom...gsingapore.htm


Here's two URLs where the '!!' -- inverted exclamation marks -- show up:

- http://www.singaporeontheweb.net/pre...edbypolice.htm

- http://www.singaporeontheweb.net/pre...efor20 08.htm

Thanks.

[Sara]

I see those tags in the source too and I suspect they might be showing up because of the editor you're using. Front Page is notorious for doing weird stuff to pages.

Just from looking at your site in general I would suggest that you look into a content management system of some sort.

[esonline]

Hi Sara

Thanks.

The website's content has evolved since 1999 -- before CMS were within my means -- and is now too large and therefore time-consuming to convert into CMS. I actually am trying out using MAMBO on another website which contains a more concise version of the content. But it hasn't been able to replicate the standard of the original website.

Though FrontPage has its drawbacks, I have preferred it over others for the simple reason that it enables me to create new pages of content quickly and efficiently. As the website is a news and happenings sort of stuff, this speed is of utmost importance.

Also, the same website on HostForWeb and Verio servers do not give these tag problems. I am still wondering why. Since I have shifted over to JaguarPC, I cannot be looking back. It's a choice that I am happy with. I spent five years with HFW and nearly five years with Verio and I can safely say JaguarPC's support is right up there where standard is concerned.

So that's why I am posting in the forum -- to find out why some servers are more discerning than others in interpreting html and also to see whether there's an easier solution than modifying those thousands of html files manually.

Regards.

[jason]

Generally speaking, whenever you start seeing strange markup on your pages, it is because the server is specifying the wrong character set to use in displaying the page. The web browser uses the character set to determine, for example, whether to display the page using a Roman, Greek, Chinese, or Cyrillic characters. When the browser specifies a char set that is not the one the page was saved in you tend to see unexpected characters or missing characters. This is because the character set being used defines a different character (or no character) with the same byte value of a character you intended to display.

Your server is returning the ISO-8859-1 charset on your pages (Standard Latin). It is quite possible that your pages were saved using a different charset, such as UTF-8 but the server defaults to (older) Latin charset that was (and actually still is) widely used in the US.

This document defines some ways that you can tell the browser to use a different charset. You could also see if support can prevent your site from sending any charset in the headers--I suspect that, with your other hosts, no charset value was sent, leading the browser to default to UTF-8.

Good luck.

--Jason

[thisisit3]

Looking at your html code, its just plain wrong. This isn't an issue with Jag or the type of hosting service, your html code contains wrong characters which are out of the HTML scope.

<<html>

The extra "<" is correctly displayed because its a character out of the HTML page.

Its very simple to solve, if you are using Linux or another unix flavor then you can just do a search and replace in multiple files like this:

perl -pi -e "s/<<html>/<html>/g;" *.html

(i may be wrong about the < and > in a regular expression but i think the above will just work)

[esonline]

Thanks Jason for opening my eyes to new things. Though I have been running websites since 1999, and reading widely, I am still a greenhorn when it comes to server matters.

I am loath to send in another support ticket after having received the following reply:

QUOTE -----------
We have edited your scripts and removed the extra tags '<' and '!' from there.Please check it now the urls are loading fine without any tag that were being displayed earlier.If you still face any problem then please contact with your developer to with your scritps.
----------- UNQUOTE

The answer given wasn't exactly what I was seeking. I could very well have deleted the tags myself but I was actually trying to learn what was happening wrongly. I wasn't using any scripts either. The files were plain html files.


Thanks Thisisit3 for your comments. The extra '<' tag does not exist in my html files on my pc. Somehow, when the file is uploaded onto the server, this '<' gets into the html file. So to get rid of the tag, I simply delete the file on the server and reupload the same file. But, this can be a tedious exercise as it means physically checking every file that gets uploaded onto the server.

Thanks.

[jason]

Make sure that your FTP client is set to upload your HTML fies as plain text (often called ASCII mode). Every platform saves text files a bit differently, so using ASCII mode ensures the file gets reformatted the proper format of the receiving platform. In English that means that, when you upload a file from your PC (or Mac) to the Unix server the file gets converted from PC (or Mac) format to Unix format.

Your problem doesn't seem characteristic of a transfer problem, but I figured I'd throw it out there anyway, just to cover all bases.

--Jason

[esonline]

Thanks Jason.

I actually do not use the AUTO option when uploading files via FTP. I flag html ftp uploads as ASCII and images as BINARY.

After reading your earlier comments, I went into my InterWorx panel -- siteworx -- for the website and tried my hand at setting different default charsets. (There's this neat little user-friendly feature which lets you set global htaccess for mime, charsets, etc) But the tags stubbornly remain in place.

Sorry for the late response, it's just after dawn here in Singapore.

Regards.

[AlexKall]

Thanks Jason for opening my eyes to new things. Though I have been running websites since 1999, and reading widely, I am still a greenhorn when it comes to server matters.

I am loath to send in another support ticket after having received the following reply:

QUOTE -----------
We have edited your scripts and removed the extra tags '<' and '!' from there.Please check it now the urls are loading fine without any tag that were being displayed earlier.If you still face any problem then please contact with your developer to with your scritps.
----------- UNQUOTE

The answer given wasn't exactly what I was seeking. I could very well have deleted the tags myself but I was actually trying to learn what was happening wrongly. I wasn't using any scripts either. The files were plain html files.


Thanks Thisisit3 for your comments. The extra '<' tag does not exist in my html files on my pc. Somehow, when the file is uploaded onto the server, this '<' gets into the html file. So to get rid of the tag, I simply delete the file on the server and reupload the same file. But, this can be a tedious exercise as it means physically checking every file that gets uploaded onto the server.

Thanks.

I've tried that aproch before aswell and failed! They are good at solving problems but not explaining them. I doubt they have time for it