#2096 SVN 3343: Flaws in UTF-8 support

[Wes Groleau]

Using FireFox 2.0.0.12 on Mac OS 10.3.9
Site is at SVN 3433
I have seen this behavior with other revsions of PGV, and I think other browsers.

Database encoding is UTF-8.
Browser's default is UTF-8
PHPGedView's display pages and edit forms all specify UTF-8

But when I edit and save text, if I enter a non-breaking space as an HTML entity or as an actual U+00A0 character, when I view the saved item, the NBSP is always turned into an ASCII space, removed completely, or something that displays as a question mark. In the case of ASCII space, if it is edited again and saved, any string of more than one is collapsed into one.

[Greg Roach]

Logged In: YES
user_id=1466942
Originator: NO

If I enter a NBSP (using alt-0160 on Windows), then the unicode representation of U+00A0 is stored in my gedcom, and displays as I'd expect.

Multiple spaces are stored in the gedcom, and are retained on edit. The HTML standard collapses multiple whitespace, so they are only displayed as single spaces.

[Wes Groleau]

Logged In: YES
user_id=1537714
Originator: YES

I should have been clearer. I know that at least some Unicode characters work in GEDCOM. Can't remember whether I tried NBSP.

But in other places, such as FAQ list, news block, etc., the behavior I described does occur.

[Greg Roach]

Can you help us to reproduce this error. If we can't reproduce it, we can't fix it.

[Wes Groleau]

I tried to reproduce in the FAQ list with SVN 4757. The unwanted conversions did not occur with FireFox 3 on Mac OS 10.4.11.