Czy naprawdę muszę kodować „&” jako „& amp;”?

&W mojej witrynie używam symbolu „ ” z HTML5 i UTF-8 <title>. Google pokazuje ampersand dobrze na swoich SERP, podobnie jak wszystkie przeglądarki w swoich tytułach.

http://validator.w3.org daje mi to:

i nie rozpoczął odniesienia do znaku. (i prawdopodobnie powinienem uciec jako &.)

Czy naprawdę muszę to zrobić &?

Nie przejmuję się tym, że moje strony sprawdzają poprawność ze względu na sprawdzanie poprawności, ale jestem ciekawy opinii ludzi na ten temat oraz czy jest to ważne i dlaczego.

Tak. Tak jak powiedział błąd, w HTML atrybuty to #PCDATA, co oznacza, że ​​zostały przeanalizowane. Oznacza to, że możesz używać encji znakowych w atrybutach. Używanie &samo w sobie jest niewłaściwe, a jeśli nie dla łagodnych przeglądarek, a fakt, że jest to HTML, a nie XHTML, przerwałby analizę. Po prostu uciekaj jak &i wszystko będzie dobrze.

HTML5 pozwala na pozostawienie go bez zmian, ale tylko wtedy, gdy następujące dane nie wyglądają jak prawidłowe odwołania do znaków. Jednak lepiej jest po prostu uciec od wszystkich wystąpień tego symbolu, niż martwić się, które powinny być, a które nie.

Miej to na uwadze; jeśli nie uciekasz & do & amp ;, jest wystarczająco zły dla danych, które tworzysz (gdzie kod może być bardzo nieprawidłowy), możesz również nie uciekać z ograniczników tagów, co jest ogromnym problemem dla danych przesyłanych przez użytkowników, co może bardzo dobrze prowadzić do wstrzykiwania HTML i skryptów, kradzieży plików cookie i innych exploitów.

Po prostu uniknij kodu. Zaoszczędzi ci to wielu kłopotów w przyszłości.

Pomijając walidację, pozostaje faktem, że kodowanie niektórych znaków jest ważne dla dokumentu HTML, aby mógł poprawnie i bezpiecznie renderować się jako strona internetowa.

Kodowanie, &tak jak &we wszystkich okolicznościach, jest dla mnie łatwiejszą zasadą życia, zmniejszając prawdopodobieństwo błędów i niepowodzeń.

Porównaj następujące: co jest łatwiejsze? co jest łatwiejsze do zrobienia ?

Metodologia 1

1. Napisz treść zawierającą znaki handlowe i handlowe.
2. Zakoduj je wszystkie.

Metodologia 2

(proszę o ziarno soli;))

1. Napisz treść zawierającą znaki handlowe i handlowe.
2. W poszczególnych przypadkach spójrz na każdy znak ampersand. Ustal, czy:
   • Jest izolowany i jako taki jednoznacznie jest znakiem handlowego. na przykład. volt & amp
      > W takim przypadku nie zawracaj sobie głowy kodowaniem.
   • Nie jest izolowany, ale czujesz, że mimo to jest jednoznaczny, ponieważ wynikowa istota nie istnieje i nigdy nie będzie istnieć, ponieważ lista jednostek nigdy nie mogłaby się rozwijać. np. amp&volt
      > W takim przypadku nie zawracaj sobie głowy kodowaniem.
   • Nie jest odizolowany i niejednoznaczny. na przykład. volt&amp
      > Zakoduj to.

??

Reguły HTML5 różnią się od HTML4. Nie jest to wymagane w HTML5 - chyba że znak ampersand wygląda tak, jakby zaczynał nazwę parametru. „& copy = 2” nadal stanowi problem, na przykład, ponieważ & copy; jest symbolem praw autorskich.

Wydaje mi się jednak, że trudniej jest zdecydować się na kodowanie lub nie, w zależności od następującego tekstu. Więc najłatwiejszą drogą jest prawdopodobnie kodowanie przez cały czas.

Myślę, że stało się to bardziej pytaniem „dlaczego stosować się do specyfikacji, kiedy przeglądarki to nie obchodzi”. Oto moja ogólna odpowiedź:

Normy nie są „obecne”. Są „przyszłością”. Jeśli my, jako programiści, przestrzegamy standardów internetowych, wówczas dostawcy przeglądarek są bardziej skłonni do prawidłowego wdrożenia tych standardów i zbliżamy się do całkowicie interoperacyjnej sieci, w której włamania CSS, wykrywanie funkcji i wykrywanie przeglądarki nie są konieczne. Tam, gdzie nie musimy dowiedzieć się, dlaczego nasze układy psują się w konkretnej przeglądarce lub jak to obejść.

W szczególności, jeśli HTML5 nie wymaga użycia & amp; w konkretnej sytuacji i korzystasz z formatu HTML5 (a także oczekujesz, że użytkownicy będą korzystać z przeglądarek zgodnych z HTML5), nie ma powodu, aby to robić.

Cóż, jeśli pochodzi z danych wejściowych użytkownika, to absolutnie tak, z oczywistych powodów. Pomyśl, jeśli sama witryna tego nie zrobiła: tytuł tego pytania pojawiłby się, ponieważ naprawdę muszę zakodować „&” jako „&”?

Jeśli to po prostu coś takiego, echo '<title>Dolce & Gabbana</title>';to mówiąc ściśle, nie musisz. Byłoby lepiej, ale jeśli nie, żaden użytkownik nie zauważy różnicy.

Czy możesz nam pokazać, jaka jest twoja titlerzeczywistość? Kiedy przesyłam

<!DOCTYPE html>
<html>
<title>Dolce & Gabbana</title>
<body>
<p>am i allowed loose & mpersands?</p>
</body>
</html>

na http://validator.w3.org/ - wyraźnie prosząc go o użycie eksperymentalnego trybu HTML 5 - nie ma żadnych skarg na &...

W HTML a &oznacza początek odwołania, albo odwołania do znaku, albo odwołania do encji . Od tego momentu analizator składni oczekuje albo #oznaczenia odwołania do znaku, albo nazwy encji oznaczającej odwołanie do encji, po których następuje zarówno ;. To jest normalne zachowanie.

Ale jeśli nazwa odniesienia lub po prostu otwarcie odniesienia &następuje białej przestrzeni lub innych ograniczników podoba ", ', <, >, &, zakończenie ;, a nawet odniesienia do reprezentowania równinę &można pominąć:

<p title="&amp;">foo &amp; bar</p>
<p title="&amp">foo &amp bar</p>
<p title="&">foo & bar</p>

Tylko w tych przypadkach ;można pominąć zakończenie lub nawet sam odnośnik (przynajmniej w HTML 4). Myślę, że HTML 5 wymaga zakończenia ;.

Ale specyfikacja zaleca zawsze używać odwołania takiego jak odwołanie do znaku &lub odwołanie do bytu, &aby uniknąć pomyłek:

Autorzy powinni użyć „ &” (dziesiętnie ASCII 38) zamiast „ &”, aby uniknąć pomyłki z początkiem odwołania do znaku (otwarty separator encji). Autorzy powinni również używać „ &” w wartościach atrybutów, ponieważ odwołania do znaków są dozwolone w ramach wartości atrybutów CDATA.

Jeśli użytkownik przekaże go tobie lub skończy w adresie URL, musisz go uciec.

Jeśli pojawia się w tekście statycznym na stronie? Wszystkie przeglądarki dostaną to w jedną stronę, nie martw się o to, ponieważ będzie działać.

Aktualizacja (marzec 2020): Walidator W3C nie narzeka już na ucieczkowe adresy URL.

Sprawdzałem, dlaczego URL obrazu musi uciekać, dlatego wypróbowałem go na https://validator.w3.org . Wyjaśnienie jest całkiem miłe. Podkreśla, że ​​nawet adresy URL wymagają zmiany znaczenia. [PS: Wydaje mi się, że nie zostanie usunięty, gdy zostanie zużyty, ponieważ potrzeba adresu URL &. Czy ktoś może to wyjaśnić?]

<img alt="" src="foo?bar=qut&qux=fop" />

W dokumencie znaleziono odwołanie do jednostki, ale nie ma zdefiniowanego odwołania o tej nazwie. Często jest to spowodowane błędną pisownią nazwy odniesienia, niekodowanymi znakami ampersands lub pozostawieniem końcowego średnika (;). Najczęstszą przyczyną tego błędu są niezakodowane znaki handlowe w adresach URL, zgodnie z opisem WDG w „Ampersands w adresach URL”. Odwołania do encji zaczynają się od ampersandu (&) i kończą średnikiem (;). Jeśli chcesz użyć dosłownego znaku handlowego i w swoim dokumencie, musisz go zakodować jako „&” (nawet w adresach URL!). Uważaj, aby kończyć odwołania do encji średnikiem, ponieważ referencje encji mogą zostać zinterpretowane w związku z następującym tekstem. Należy również pamiętać, że w nazwanych odniesieniach encji rozróżniana jest wielkość liter; I Aelig; i… są ​​różnymi znakami.

Tak, powinieneś spróbować podać poprawny kod, jeśli to możliwe.

Większość przeglądarek po cichu naprawi ten błąd, ale istnieje problem z poleganiem na obsłudze błędów w przeglądarkach. Nie ma standardu obsługi niepoprawnego kodu, więc każdy producent przeglądarki musi spróbować ustalić, co zrobić z każdym błędem, a wyniki mogą się różnić.

Niektóre przykłady, w których przeglądarki mogą zareagować inaczej, to umieszczenie elementów wewnątrz tabeli, ale poza komórkami tabeli lub zagnieżdżenie łączy między sobą.

W twoim konkretnym przykładzie prawdopodobnie nie spowoduje to żadnych problemów, ale korekcja błędów w przeglądarce może na przykład spowodować zmianę przeglądarki z trybu zgodnego ze standardami na tryb dziwactwa, co może spowodować całkowity awarię układu.

Powinieneś więc poprawić takie błędy w kodzie, jeśli nie w ogóle, aby lista błędów w walidatorze była krótka, abyś mógł dostrzec poważniejsze problemy.

Kilka lat temu otrzymaliśmy raport, że jedna z naszych aplikacji internetowych nie wyświetlała się poprawnie w przeglądarce Firefox. Okazało się, że strona zawierała wyglądający tag

<div style="..." ... style="...">

W obliczu atrybutu powtarzanego stylu IE łączy oba style, podczas gdy Firefox używa tylko jednego z nich, stąd różne zachowanie. Zmieniłem tag na

<div style="...; ..." ...>

i na pewno to rozwiązało problem! Morał tej historii jest taki, że przeglądarki mają bardziej spójną obsługę prawidłowego HTML niż nieprawidłowego HTML. Więc napraw już swoje przeklęte znaczniki! (Lub użyj HTML Tidy, aby to naprawić.)

jeśli &jest używany w html , powinieneś go uciec

Jeśli &jest używany w ciągach javascript, np. alert('This & that');Lub document.href, nie musisz go używać.

Jeśli używasz document.write, powinieneś go użyć np document.write(<p>this &amp; that</p>)

Zależy to od prawdopodobieństwa, że ​​średnik znajdzie się w pobliżu &, powodując, że wyświetli coś zupełnie innego.

Na przykład, mając do czynienia z danymi wejściowymi od użytkowników (powiedzmy, jeśli umieścisz podany przez użytkownika temat postu na forum w tagach tytułu), nigdy nie wiesz, gdzie umieszczają losowe średniki, i może losowo wyświetlać dziwne byty. Więc zawsze uciekaj w takiej sytuacji.

W przypadku własnego statycznego html można go pominąć, ale tak proste jest włączenie prawidłowego ucieczki, że nie ma dobrego powodu, aby go unikać.

Jeśli naprawdę mówisz o tekście statycznym

<title>Foo & Bar</title>

przechowywane w jakimś pliku na dysku twardym i podawane bezpośrednio przez serwer, a następnie tak: prawdopodobnie nie trzeba go uciekać.

Ponieważ jednak obecnie jest bardzo mało treści HTML, które są całkowicie statyczne, dodam następujące zastrzeżenie, które zakłada, że ​​treść HTML jest generowana z innego źródła (zawartość bazy danych, dane wejściowe użytkownika, wynik wywołania usługi internetowej, wynik API starszego typu,. ..):

Jeśli nie uciekać się proste &, to są szanse, również nie uciec &lub  lub <b>lub <script src="http://attacker.com/evil.js">lub inny nieważny tekst. Oznaczałoby to, że w najlepszym przypadku wyświetlasz niepoprawnie swoje treści i bardziej prawdopodobne jest, że podejrzewasz ataki XSS .

Innymi słowy: kiedy już sprawdzasz i unikasz innych, bardziej problematycznych przypadków, prawie nie ma powodu, aby pozostawić niezupełnie zepsuty, ale wciąż nieco podejrzany, samodzielny i niezamknięty.

nie jestem pewien, czy jest to przydatne dla kogoś ... walczyłem z tym przez chwilę ... oto chwalebna regex, którego możesz użyć, aby naprawić wszystkie linki, javascript, treść. Musiałem poradzić sobie z mnóstwem starszych treści, których nikt nie chciał poprawić.

Dodaj to do zastąpienia renderowania na stronie wzorcowej lub kontrolce:

Proszę nie płonąć mną za umieszczenie tego w niewłaściwym miejscu:

// remove the & from href="blaw?a=b&b=c" and replace with & 
//in urls - this corrects any unencoded & not just those in URL's
// this match will also ignore any matches it finds within <script> blocks AND
// it will also ignore the matches where the link includes a javascript command like
// <a href="javascript:alert{'& & &'}">blaw</a>
html = Regex.Replace(html, "&(?!(?<=(?<outerquote>[\"'])javascript:(?>(?!\\k<outerquote>|[>]).)*)\\k<outerquote>?)(?!(?:[a-zA-Z][a-zA-Z0-9]*|#\\d+);)(?!(?>(?:(?!<script|\\/script>).)*)\\/script>)", "&amp;", RegexOptions.Singleline | RegexOptions.IgnoreCase);

Łącze ma dość dobry przykład, kiedy i dlaczego może trzeba się uciec &do&

https://jsfiddle.net/vh2h7usk/1/

Co ciekawe, musiałem uciec od postaci, aby odpowiednio ją przedstawić w mojej odpowiedzi tutaj. Jeśli miałbym użyć wbudowanej opcji przykładowego kodu (z panelu odpowiedzi), mogę po prostu wpisać &i wygląda to tak, jak powinno. Ale jeśli miałbym ręcznie użyć tego <code></code>elementu, to muszę uciec, aby poprawnie go przedstawić :)