XHTML и & (Амперсанд) кодирование

Мой сайт XHTML Transitional совместим , за исключением одной вещи: и (амперсанд) в URL-адресе записываются как есть, вместо &

То есть все URL-адреса моих страниц обычно таковы:

<a href="#" onclick="location.href='http://www.foo.com/page.aspx?x=1&y=2'; return false;">Foo</a>

Но XHTML validator генерирует эту ошибку:

не может генерировать системный идентификатор для общей сущности "y"

... и он хочет, чтобы url был написан следующим образом:

<a href="#" onclick="location.href='http://www.foo.com/page.aspx?x=1&amp;y=2'; return false;">Foo</a>

Проблема в том, что IE и Firefox неправильно обрабатывают URL-адрес и игнорируют параметр y. Как я могу заставить эту ссылку работать и правильно проверять?

Мне кажется, что невозможно писать страницы XHTML, если браузеры не работают со строгими закодированными URL-адресами XHTML.

Вы хотите видеть в действии? Посмотрите разницу между этими двумя ссылками (скопируйте и вставьте их так, как они есть):

http://stackoverflow.com/search?q=ff&sort=newest

http://stackoverflow.com/search?q=ff&amp;sort=newest

Ответ 1

Я только что попробовал это. То, что вы пытались сделать, является правильным. В HTML, если вы пишете ссылку, символы & должны быть закодированы как &. Вы только кодировали бы & как %26, если бы вы хотели, чтобы значение параметра содержало амперсанд. Я просто написал простую HTML-страницу, содержащую ссылку: <a href="Default2.aspx?param1=63&param2=hel">Click me</a> и он работал нормально: default2.aspx получил назначенные параметры, и источник прошел проверку.

Кодирование & как & требуется в HTML, а не в ссылке. Когда браузер увидит & в источнике HTML для ссылки, он будет интерпретировать его как амперсанд, и цель ссылки будет такой, как предполагалось. Если вы вставляете URL-адрес в адресную строку браузера, он не ожидает, что он будет HTML и не пытается интерпретировать кодировку HTML, которую он может содержать. Вот почему ваш пример ссылок, который вы предлагаете нам скопировать/вставить в браузер, не работает и почему мы не ожидаем, что они будут работать.

Если вы разместите немного больше своего фактического кода, мы сможем увидеть, что вы сделали неправильно, но вы, кажется, направляетесь в правильном направлении, используя & в ваших якорных тегах.

Ответ 2

Это была моя ошибка: уже был закодирован элемент управления гиперссылкой &, поэтому мой url http://foo?x=1&y=2 был закодирован до http://foo?x=1&amp;y=2

Обычно, amp внутри url правильно обрабатывается браузерами, как вы сказали. Благодаря

Ответ 3

вы можете использовать & вместо и в своем URL-адресе на своей странице.

Это должно позволить ему проверять строгий xhtml...

<a href="http://www.foo.com/page.aspx?x=1&amp;y=2">Foo</a>

Примечание. Если используется функцией ASP.NET Request.QueryString, строка запроса не использует кодировку XML, она использует URL-кодирование:

/mypath/mypage?b=%26stuff

Итак, вам нужно предоставить функцию перевода '&' в% 26

Примечание: в этом случае Server.URLEncode( "neetu and geetu" ), который будет производить neetu +% 26 + geetu, не то, что вы хотите, так как вам нужно перевести и в% 26, а не просто "&". Вы должны добавить вызов replace(), примененный к результату URLEncode, чтобы заменить '% 26amp;' на "% 26".

Ответ 4

Чтобы быть более тщательным: используйте &, числовую ссылку на символ.

Поскольку & является ссылкой на символ символа:

Ссылки на символьные сущности определены на языке разметки определение. Это означает, например, что для HTML только конкретный диапазон символов (определенный спецификацией HTML) может быть представленный как ссылки на сущность символа (и который включает только небольшое подмножество диапазона Unicode).

Это происходит от мудрых людей в W3C (читайте этот для большего).

Конечно, это не очень большая сделка, но предложение W3C заключается в том, что числовое значение будет действительным и пригодным для использования везде и всегда, в то время как названный "отлично" для HTML, но не более того.

Ответ 5

Проблема хуже, чем вы думаете - попробуйте в Safari. & Амп; амп; преобразуется в & # 38; и хэш заканчивает URL. Правильный ответ заключается в том, чтобы не выводить XHTML - нет причин, которые оправдывают больше времени на разработку и отчуждение пользователей Mac.