Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2a) Gecko/2002091318 Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.2a) Gecko/2002091408 On http://piology.org/, hover over the links. The link target is displayed. This is true for all the links except for one which never displays: "amtliche Regelung der deutschen Rechtschreibung" The page validates and this link is just like any other link on that page. I have no clue, why this should be different. pi

This is probably invalid. A URI should consist of CDATA, but the URI in the example contains something that looks like a character reference. In the testcase, the string #%A797 is used (same as in the given URI), together with #%0797, the latter which in the status bar will show that it is indeed parsed somehow (some hebrew character plus 97 will be rendered).

If you think the URI is not correct, what would be correct? Basically, it is meant to be #§97, which is encoded. pi

Well, have a look at http://www.flightlab.com/~joe/sgml/cdata.html for some tips. Of course you should just put it as "#§97" in the code.

Actually, the URI encoding would be #%C2%A797, although Mozilla will automatically convert to this.

OK, thanks, I got the point. I forgot that the page is utf-8 and that would have an effect here. pi

@pi: It does not matter in what encoding your page is sent. The URI reference (URI+'#'+fragment) simply contains the character sequence <percent sign>, <latin capital letter a>, <digit 7>, <digit 9>, <digit 7>. It does not matter which encoding the URI is sent in (it might even be written down on paper). From the URI spec: | o A URI is a sequence of characters, which is not always | represented as a sequence of octets. @all: The URI reference here consists of the URI (http://www.duden.de/schreibung/regelwerk/zeichen_11.html) and a fragment specifier (%A797). The URI is not interesting here (but could be). The fragment specifier now represents the octet sequence 0xA7, 0x39, 0x37 (where 0xA7 had to be encoded as it can't be directly encoded by a URI-safe ASCII character,). Fragments are evaluated in the context of the document given by the URI. So it depends on the document format whether 0xA7, 0x39, 0x37 is a valid fragment identifier. For example, a binary format might also specify binary fragment identifiers. | 4.1. Fragment Identifier (...) | The semantics of a fragment identifier is a property of the data | resulting from a retrieval action, regardless of the type of URI used | in the reference. Therefore, the format and interpretation of | fragment identifiers is dependent on the media type [RFC2046] of the | retrieval result. The character restrictions described in Section 2 | for URI also apply to the fragment in a URI-reference. Note that section 2 only says which octets may be represented directly as ASCII characters and which have to be encoded. It does not say that octet values over 0x7F are not allowed or that they must be UTF-8. This is entirely left to the document format of the object pointed to by the URI part. So http://www.duden.de/schreibung/regelwerk/zeichen_11.html#%A797 is a perfectly valid URI. Mozilla should be able to handle and display it without problems. ----------------------- It's a completly different question how the octet sequence 0xA7, 0x39, 0x37 should be mapped against named anchors in the context of the document refrenced by the URI. This should be defined by the document format but HTML does not define it. (It has a recommendation to encode raw non-ASCII characters in URI references as UTF-8, and then with the %-encoding of the URI spec, but that's a completly different issue.) However, I believe what Mozilla should do is to (in this order): 1. Try to interpret the data as UTF-8 (the result is a sequence of characters) and match it agains the characters that make up the id/name specifiers. 2. Try to interpret the data as being in the charset used for the document (pointed to by the URI, not the one containing the URI).

*** This bug has been marked as a duplicate of 169388 ***

v