international characters not displaying properly (accents/etc)

RESOLVED EXPIRED

Status

()

Core
Internationalization
RESOLVED EXPIRED
15 years ago
12 years ago

People

(Reporter: Jorge Asch, Assigned: smontagu)

Tracking

({intl})

Trunk
x86
Windows 2000
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

15 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130

When Mozilla encounters access or international characters in a HTML file it's
not displaying properly (it displays a question mark instead). I know the
correct syntax is é instead of just "é", but still, it works on previous
versions and other browsers (Mozilla 1.0, Netcape, Internet Explorers).

And there are lots of sites out there that do not comform to good html writing.
Specially in non-english languages...

A weird note. Sometimes they display OK... (about 20% of the time). Not sure
what causes them to display OK or not, even tough the HTML is unchanged.

Reproducible: Always

Steps to Reproduce:
1. open page 
2. look for accents in header below image
3. find ?'s intead



Expected Results:  
á instead of ?
ñ instead of ?
you get the picture
(Reporter)

Comment 1

15 years ago
Well, even tough I type the correct accents on the MEMO box, they don't show up
properly on the Description History of the problem...

Try this: ALT-164 ñ (shows two characters). ALT-130 é (should be an "e" with accent)
That site worksforme, linux trunk build 2002-12-09-22.

What are your charset autodetect settings?
Assignee: asa → smontagu
Component: Browser-General → Internationalization
QA Contact: asa → ylong
(Reporter)

Comment 3

15 years ago
Created attachment 108986 [details]
This is how I see the page... on both of my workstations.

Comment 4

15 years ago
This works for me on WinXP / 12-10 trunk build with both auto-detect OFF and
auto-detect Universal.

Reporter: what is your browser default charset? when you saw the problem, does
the charset is marked as your browser default charset?

Can you try to clear Cache (Edit | Preferences | Advanced | Cache) or create a
new profile to see if you can reproduce it?
Keywords: intl
(Reporter)

Comment 5

15 years ago
If I clear the cache the problem is solved... but after several minutes/hours it
goes back to not showing them properly.

Comment 6

15 years ago
Well, if you never go to pages other than western charset page, then the
different charset never be cached.  But if you visit some pages which has
different charset like UTF-8 or whatever else, then cache will remember, and
this will help if you go to the same page next time.

Since the page that you mentioned: http://www.cidgallup.com/ doesn't has html
charset meta-tag, so it could be affected by cache.  But if you clear the cache
or manually select the correct one, then next time when you visit that page
again, the page will be displayed properly.

It's a correct behavior for me.
(Reporter)

Comment 7

15 years ago
Hmm. I still wonder why with 1.0 or 1.1 I never had this problem. I also noticed
it's not only accents/etc, but also Copyright and Registered signs among others...

Comment 8

13 years ago
For page http://aninhadinamarca.weblogger.terra.com.br/ I have to set character 
coding' to Unicode UTF-8 before seeing this page correct. 

This goes for both Linux (Mozilla 1.7.3) and Windows (some older version)

Internet Explorer shows it correct.

PS: I know this is an old thread, but the issue covers exactly my problem.
(Assignee)

Comment 9

13 years ago
(In reply to comment #8)
http://aninhadinamarca.weblogger.terra.com.br/ is declared as ISO-8859-1 in the
HTTP headers but is in fact in UTF-8. This is the same as issue as bug 236325
(and others, probably)
This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/
This bug has been automatically resolved after a period of inactivity (see above
comment). If anyone thinks this is incorrect, they should feel free to reopen it.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → EXPIRED
You need to log in before you can comment on or make changes to this bug.