'&'를 '& amp;'로 인코딩해야합니까?


207

&내 사이트에서 HTML5 및 UTF-8과 함께 ' '기호를 사용하고 있습니다 <title>. Google은 제목의 모든 브라우저와 마찬가지로 SERP에 앰퍼샌드를 표시합니다.

http://validator.w3.org 가 나에게 이것을주고 있습니다 :

& 문자 참조를 시작하지 않았습니다. (그리고 아마도로 탈출했을 것 &amp;입니다.)

정말로해야합니까 &amp;?

유효성 검사를 위해 유효성을 검사하는 내 페이지에 대해 소란스럽지 않지만 이것에 대한 사람들의 의견을 듣고 궁금하고 중요한 이유는 무엇인지 궁금합니다.


63
사양은 그렇게 말하지 않습니다. 포스터는 모든 시나리오에서 앰퍼샌드를 이스케이프 처리 할 필요가없는 HTML5를 나타냅니다.
Matthew Wilson

2
의견을 찾고 있고 유효성 검사에 까다 롭지 않다는 것은 커뮤니티 위키 여야합니다. 대답 할 객관적인 근거가 없음을 의미합니다.
Richard JP Le Guen

6
@Richard : 정말로 요? 나는 "유효성 검증이 중요하지 않다"는 것에 동의하지 않지만, 이것은 이것을 매우 객관적인 질문으로 본다.
Joachim Sauer

2
@YiJiang 현재 웹 브라우저 는 사용자 를 이해 하기 위해 많은 노력을 기울이고 있습니다 . 그리고 구글도 마찬가지 입니다. 사양의 일부입니다. 미래의 웹 브라우저 덜 용서할 있습니다. 따라서 Wikipedia가 어떻게하는지 확인하고 복사하는 것이 좋습니다.
unixman83

2
HTML 사양은 쓰레기 입력을 수락한다고 말합니다. 그것은 당신의 사이트가 지금 헛소리 될 수 있다는 것을 의미합니까? 닫을 필요가있는 태그를 닫고 물건을 피하십시오! 사람들에게 오십시오.
doug65536

답변:


143

예. 오류가 말했듯이 HTML에서 속성은 #PCDATA이며 구문 분석되었음을 의미합니다. 이는 속성에서 문자 엔터티를 사용할 수 있음을 의미합니다. &자체적으로 사용 하는 것은 잘못된 것이며 관대 한 브라우저에 적합하지 않으며 이것이 XHTML이 아닌 HTML이라는 사실 때문에 구문 분석이 중단됩니다. 그냥 탈출하면 &amp;모든 것이 잘 될 것입니다.

HTML5를 사용하면 이스케이프를 해제 할 수 있지만 다음에 나오는 데이터가 유효한 문자 참조처럼 보이지 않을 때만 가능합니다. 그러나 어떤 것이 필요하고 어떤 것이 필요하지 않은지에 대해 걱정하는 것보다이 심볼의 모든 인스턴스를 피하는 것이 좋습니다.

이 점을 명심하십시오. 이스케이프하지 않고 & amp;로 이동하지 않으면 생성 한 데이터 (코드가 매우 유효하지 않은 경우)에 적합하지 않으며, 태그 구분 기호를 이스케이프 처리하지 않을 수도 있습니다. 이는 사용자가 제출 한 데이터에 큰 문제입니다. HTML 및 스크립트 삽입, 쿠키 도용 및 기타 악용으로 이어질 수 있습니다.

코드를 피하십시오. 앞으로 많은 문제를 해결할 것입니다.


9
어떤 브라우저도 & 자체를 "오해"하지 않습니다. 기존의 모든 브라우저는 "&"로 표시합니다. 그가 그것을해야 할 실질적인 이유를 명시 적으로 요구하고 그가 검증에 관심이 없다고 진술 한 것을 고려 ..
Thomas Bonini

47
예. 그러나 도덕적으로 브라우저의 부담과 "좋은"오류 처리에 의존 해야 합니까? 아니면 올바른 코드를 작성해야합니까?
Delan Azabani

8
@Delan : 내가 작성하는 모든 페이지를 검증하려고하지만, 그가 "도덕적으로"신경 쓰지 않는다는 그의 질문을 읽음으로써 이해합니다. 그는 그것이 작동하는지 아닌지 걱정합니다. 그것들은 서로 다른 두 가지 철학이며 장단점이 있으며 "올바른"것은 없습니다. 예를 들어이 웹 사이트는 유효성이 검사되지는 않지만 훌륭한 웹 사이트입니다.
토마스 보니 니

3
@Andreas,하지만 브라우저는 올바른 코드를 해석하는 방법에 충분한 버그가 있습니다. 무의미한 마크 업을 보낼 때 올바른 결과를 얻는 것은 그들의 노래에 따라 다릅니다. 이 예제에서는 오늘 작동하고 다음 예제에서는 실패합니다 (예 : & 뒤에 어딘가에 세미콜론이있는 경우)
Jon Hanna

11
모든 사람들이 HTML5에 대해 이야기하는 것 같지만, 원래 질문은 HTML5가 사용되고 있다는 것입니다. HTML5는 명시 적으로 이스케이프 처리되지 않은 &이 상황에서 & 뒤에 오는 것이 & 일반적으로 엔티티로 확장되지 않는 한 (예 : & copy = 2는 문제가 있지만 & x = 2는 괜찮습니다) 허용합니다.
Matthew Wilson

55

유효성 검사 이외에도 특정 문자를 인코딩하는 것이 HTML 문서에 중요하므로 웹 페이지로 올 바르고 안전하게 렌더링 할 수 있습니다.

저에게있어 모든 상황에서 &와 같이 인코딩 &amp;하는 것은 더 쉬운 규칙이며 오류와 실패 가능성을 줄입니다.

다음을 비교하십시오 : 어느 것이 더 쉬운가요? 이는 쉽게 까지 놈에 ?

방법론 1

  1. 앰퍼샌드 문자가 포함 된 내용을 작성하십시오.
  2. 그것들을 모두 인코딩하십시오.

방법론 2

(소금 한알로주세요)

  1. 앰퍼샌드 문자가 포함 된 내용을 작성하십시오.
  2. 사례별로 각 앰퍼샌드를보십시오. 다음을 결정하십시오.
    • 그것은 격리되어 있으며, 분명하게 앰퍼샌드입니다. 예. volt & amp
       >이 경우 인코딩을 방해하지 마십시오.
    • 독립 체는 아니지만 결과 엔티티가 존재하지 않으며 엔티티 목록이 절대로 진화 할 수 없기 때문에 존재하지 않기 때문에 모호하지 않다고 생각합니다. 예를 들어 amp&volt
       >이 경우 인코딩을 방해하지 마십시오.
    • 고립되지 않고 모호합니다. 예. volt&amp
       > 인코딩하십시오.

??


3
두 번째 경우 amp&volt 모호합니다. &volt이제 엔티티 참조입니까?
Gumbo

6
@Gumbo 앰퍼샌드 amp&volt가 모호한 앰퍼샌드 가 아닙니다 (HTML 사양의 정의에 따라). mathiasbynens.be/notes/ambiguous-ampersandsmothereff.in/ampersands#amp%26volt를 참조하십시오 .
Mathias Bynens

@MathiasBynens 지금까지 (2019) 모호한 앰퍼샌드 의 정의는 2011 년 mathiasbynens.be/notes/ambiguous-ampersands 에서 인용 한 정의와 약간 다르게 변경된 것 같습니다 .
Jacob C., Reinstate Monica 님이

21

HTML5 규칙은 HTML4와 다릅니다. 앰퍼샌드가 매개 변수 이름을 시작하는 것처럼 보이지 않는 한 HTML5에서는 필요하지 않습니다. "& copy = 2"는 예를 들어 & copy; 저작권 기호입니다.

그러나 다음 텍스트에 따라 인코딩하거나 인코딩하지 않기로 결정하기가 더 어려워 보입니다. 가장 쉬운 방법은 아마도 항상 인코딩하는 것입니다.


2
속성 값을 인용하는 것과 같습니다. 반드시 그럴 필요는 없지만 항상 그렇게해도 잘못 될 수는 없습니다.
Paul D. Waite

3
&copy=2생각만큼 큰 문제는 아닙니다. 속성 값 (예 : href속성)에서는의 &copy문자 참조로 간주되지 않습니다 ©. 속성 값 이외의 경우입니다.
Mathias Bynens

앰퍼샌드가 일반적으로 영어 텍스트의 앞뒤에 공백이 있기 때문에 내가 따르는 규칙을 기억하거나 생각하는 것은 어렵지 않습니다. 부호화. 그렇지 않으면 간단하게 인코딩하십시오.
Carl Smith

HTML5 규칙에 대한 참조를 추가 할 수 있습니까?
Ferrybig

17

나는 이것이 "브라우저가 신경 쓰지 않을 때 왜 스펙을 따르는가?"라는 질문에 더 많은 질문으로 바뀌 었다고 생각합니다. 다음은 일반적인 답변입니다.

표준은 "현재"가 아닙니다. 그들은 "미래"입니다. 개발자로서 웹 표준을 따르는 경우 브라우저 공급 업체가 해당 표준을 올바르게 구현할 가능성이 높으며 CSS 해킹, 기능 감지 및 브라우저 감지가 필요하지 않은 완전히 상호 운용 가능한 웹에 더 가까이 다가갑니다. 레이아웃이 특정 브라우저에서 깨지는 이유 또는 해결 방법을 알 필요가없는 곳.

특히 HTML5에 & amp; 특정 상황에서 HTML5 doctype을 사용하고 있으며 사용자가 HTML5 호환 브라우저를 사용하기를 기대하는 경우 그렇게 할 이유가 없습니다.


1
일반적으로 말하면, 대부분의 "표준"방식은 여전히 ​​드래프트 모드이며 앞으로 변경 될 수 있음을 기억해야합니다.
refaelio

6

글쎄, 그것이 사용자 입력에서 온다면 명백한 이유에서 절대적으로 그렇습니다. 이 웹 사이트가 그렇게하지 않았다고 생각하십시오.이 질문의 제목은 '&'를 '&'로 인코딩해야합니까?

그것이 echo '<title>Dolce & Gabbana</title>';엄밀히 말하면 꼭 할 필요는 없습니다. 더 나을 것이지만, 사용자가 없으면 차이를 알 수 있습니다.


5

당신의 title실제 모습을 보여 주 시겠습니까? 제출할 때

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

http://validator.w3.org/을 - 명시 적으로 실험 HTML 5 모드를 사용하도록 요구 - 그것은에 대한 불만이 없습니다 &들 ...


1
예, HTML5에는 이전 HTML 및 XHTML 파서와 다른 파서가 있으며 특정 상황에서 이스케이프 처리되지 않은 앰퍼샌드를 허용합니다.
kevinji

이 예제가 진행되는 한, 이것은 HTML5의 새로운 것은 아닙니다. 모두 <title>Dolce & Gabbana</title><p>Dolce & Gabbana</p>유효한 HTML 2.0입니다.
Mathias Bynens

4

HTML에서 a &문자 참조 또는 엔티티 참조 중 하나의 참조 시작을 나타냅니다 . 이 시점에서 구문 분석기는 #문자 참조를 나타내는 엔티티 참조 또는 엔티티 참조를 나타내는 엔티티 이름 모두 뒤에 a가 올 것으로 예상합니다 ;. 이것이 정상적인 행동입니다.

참조 이름 또는 단지 참조 개구하지만 &공백 또는 다른 구분 기호 뒤에 같은 ", ', <, >, &, 종료 ;, 심지어 참조 일반을 대표하는 것은 &생략 할 수 있습니다 :

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

이러한 경우에만 끝 ;또는 참조 자체를 생략 할 수 있습니다 (적어도 HTML 4에서는). HTML 5에는 끝이 필요하다고 생각합니다 ;.

그러나 사양에서는 혼동을 피하기 위해 항상 문자 참조 &#38;또는 엔티티 참조 와 같은 참조를 사용하는 것이 좋습니다&amp; .

작성자는 문자 참조 (엔티티 참조 열기 분리 문자)의 시작과 혼동을 피하기 위해 &amp;" &" 대신 " "(ASCII 10 진수 38)을 사용해야합니다 . &amp;CDATA 속성 값 내에서 문자 참조가 허용되므로 작성자는 속성 값에 " "를 사용해야 합니다.


1
그것이 여러분이 연결하는 HTML 4 사양입니다. (초안) HTML 5 사양을 읽었을 때 모호한 앰퍼샌드 만 허용되지 않습니다. 예를 들어 앰퍼샌드와 공백이 모호하지 않으므로 (내 독서로도) 허용해야합니다 .HTML 5 유효성 검사기가 허용하는 마크 업에 대한 내 대답을 참조하십시오.
AakashM

1
@AakashM : 확실하지 않습니다.
Gumbo

3

사용자가 귀하에게이를 전달하거나 URL에 들어 오면 이스케이프해야합니다.

페이지에 정적 텍스트로 표시되는 경우 모든 브라우저는이 방법 중 하나를 올바르게 사용할 수 있습니다. 작동하기 때문에 걱정하지 않아도됩니다.


3

업데이트 (2020 년 3 월) : W3C 유효성 검사기가 더 이상 URL 탈출에 대해 불평하지 않습니다.

이미지 URL이 탈출 해야하는 이유를 확인하고 있었으므로 https://validator.w3.org 에서 시도했습니다 . 설명이 꽤 좋습니다. URL조차도 이스케이프해야 함을 강조합니다. [PS : URL 필요 이후 사용했을 때 이스케이프 처리되지 않는 것 같습니다 &. 누구든지 명확히 할 수 있습니까?]

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

문서에서 엔티티 참조를 찾았지만 해당 이름으로 정의 된 참조가 없습니다. 참조 이름, 인코딩되지 않은 앰퍼샌드의 철자가 틀리거나 세미콜론 (;)을 생략하여 종종 발생합니다. 이 오류의 가장 일반적인 원인은 WDG에서 "URL의 앰퍼샌드"에 설명 된대로 URL의 인코딩되지 않은 앰퍼샌드입니다. 엔티티 참조는 앰퍼샌드 (&)로 시작하고 세미콜론 (;)으로 끝납니다. 문서에서 리터럴 앰퍼샌드를 사용하려면 "&"(URL 내부에서도)로 인코딩해야합니다. 세미콜론으로 엔티티 참조를 종료하지 않도록주의하십시오. 그렇지 않으면 다음 텍스트와 관련하여 엔티티 참조가 해석 될 수 있습니다. 또한 명명 된 엔터티 참조는 대 / 소문자를 구분합니다. & Aelig; 그리고 다른 문자입니다.


1
최고 투표 답변을 읽습니다. 속성은 #PCDATA이므로 구문 분석됩니다. 엔터티가 처리됩니다. 귀하의 예에서, &엔티티 참조를 시작합니다. 을 읽은 후 &qux구문 분석기는 최종 세미콜론 ( ;)을 찾지 않지만 =엔티티 이름의 일부가 될 수없는 등호 ( ) 로 실행됩니다 . 파서가 HTML4에 따라 파문을 엄격히 시도한 경우 파싱 오류 여야합니다. HTML 5에서 엔티티 구문 분석은 전반적으로 더 편안합니다.
Palec

1
나는 일반적으로 ;그 이유 때문에 (링크를 제어 할 때) 쿼리 문자열에서 구분 기호 로 사용하는 것이 가장 좋습니다 .
Demi

2

예, 가능하면 유효한 코드를 제공해야합니다.

대부분의 브라우저는이 오류를 자동으로 수정하지만 브라우저의 오류 처리에 의존하는 데 문제가 있습니다. 잘못된 코드를 처리하는 방법에 대한 표준은 없으므로 각 브라우저 공급 업체에 따라 각 오류로 수행 할 작업을 결정해야하며 결과는 다를 수 있습니다.

브라우저가 다르게 반응 할 수있는 몇 가지 예는 표 안에 있지만 표 셀 밖에있는 요소를 넣거나 서로 링크를 중첩하는 경우입니다.

특정 예제의 경우 문제가 발생하지 않지만 브라우저의 오류 수정으로 인해 브라우저가 표준 호환 모드에서 쿼크 모드로 변경되어 레이아웃이 완전히 손상 될 수 있습니다.

따라서 코드에서 이와 같은 오류를 수정해야합니다. 다른 경우가 아니라면 유효성 검사기의 오류 목록을 짧게 유지하여 더 심각한 문제를 발견 할 수 있습니다.


2

2 년 전, 웹 앱 중 하나가 Firefox에서 올바르게 표시되지 않았다는보고를 받았습니다. 페이지에 다음과 같은 태그가 포함되어있는 것으로 나타났습니다

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

반복되는 스타일 속성에 직면하면 IE는 두 스타일을 모두 결합하지만 Firefox는 그 중 하나만 사용하므로 다른 동작을합니다. 태그를

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

그리고 확실히, 그것은 문제를 해결했습니다! 이야기의 교훈은 브라우저가 유효하지 않은 HTML보다 유효한 HTML을보다 일관되게 처리한다는 것입니다. 따라서, 당신의 망할 마크 업을 이미 수정하십시오! 또는 HTML Tidy를 사용하여 수정하십시오.


1

경우 &에 사용되는 HTML 당신은 그것을 탈출한다

&자바 스크립트 문자열 (예 : alert('This & that');또는 document.href )에 사용되는 경우 에는 사용할 필요가 없습니다.

document.write를 사용하는 경우 다음과 같이 사용해야합니다. document.write(<p>this &amp; that</p>)



에 대한 좋은 지적 document.write(). 그러나 Alex는 스크립트 스탠드에서 문서에 대한 글을 작성하려고하는 모든 시점에서 imo입니다. +1
Patrick M

1

세미콜론이의 근처에서 끝나는 가능성에 따라 달라 지므로 &상당히 다른 결과가 표시됩니다.

예를 들어, 사용자의 입력을 처리 할 때 (예 : 제목 게시물에 사용자가 제공 한 포럼 게시물의 주제를 포함하는 경우) 사용자가 임의의 세미콜론을 넣을 위치를 알 수 없으며 이상한 엔티티가 무작위로 표시 될 수 있습니다. 따라서 항상 그 상황에서 탈출하십시오.

정적 HTML의 경우 반드시 건너 뛸 수는 있지만 적절한 이스케이프를 포함하는 것은 사소한 일이므로 피할 이유가 없습니다.


0

정적 텍스트에 대해 이야기하고 있다면

<title>Foo & Bar</title>

하드 디스크의 일부 파일에 저장되고 서버에서 직접 제공 한 다음 예 : 이스케이프 할 필요가 없습니다.

그러나 현재 완전히 정적 인 HTML 컨텐츠 는 거의 없기 때문에 HTML 컨텐츠가 다른 소스 (데이터베이스 컨텐츠, 사용자 입력, 웹 서비스 호출 결과, 레거시 API 결과 등)에서 생성되었다고 가정하는 다음 고지 사항을 추가합니다. ..) :

간단한 탈출하지 않는 경우 &, 다음 기회는 당신도 탈출하지 있습니다 &amp;또는 &nbsp;또는 <b>또는 <script src="http://attacker.com/evil.js">또는 기타 유효하지 않은 텍스트를. 즉, 컨텐츠를 잘못 표시하는 것이 가장 좋으며 XSS 공격에 취약 할 가능성이 높습니다 .

다시 말해서, 다른 문제가있는 다른 사례를 이미 확인하고 탈출 할 때, 완전히 깨지지는 않았지만 여전히 어설픈 독립형을 유지해야 할 이유는 거의 없습니다.


2
나는 downvote하지 않았지만, 내가 추측해야한다면, 당신의 대답 (지능적 인 반면)은 질문과 약간 일치하지 않기 때문에 당신은 downvoted되었다고 말할 것입니다. 그는 사용자 입력을 피하는 것에 대해 묻지 않았습니다. 그는 문자를 제어하고 기본적으로 "내가 원하는 것을하는 경우 문자에 대한 언어 사양을 따르는 것이 중요합니까?"라고 묻습니다. 즉, 그는 그것을 넣었 기 때문에 &가 있다는 것을 알고 있습니다.
Matt

@ 매트 : 알겠습니다, 그리고 그것은 합리적입니다. 나는 단지 더 이상 정적 HTML 페이지를 더 이상 작성하지 않으며 거의 ​​모든 내용이 적어도 약간 동적이라고 가정합니다 (보통 일부 데이터베이스 내용을 기반으로 함). 어쩌면 그 가정은 명백해야했을 것입니다.
Joachim Sauer

-1

이것이 누군가에게 유용한 지 확실하지 않습니다 ... 나는 이것을 잠시 동안 싸우고 있었다 ... 여기 당신이 당신의 모든 링크, 자바 스크립트, 내용을 수정하는 데 사용할 수있는 영광스러운 정규 표현식이 있습니다. 아무도 수정하고 싶지 않은 수많은 레거시 콘텐츠를 처리해야했습니다.

마스터 페이지 또는 컨트롤의 렌더 재정의에 이것을 추가하십시오.

이것을 잘못된 곳에 두는 것에 대해 화를 내지 마십시오.

// remove the & from href="blaw?a=b&b=c" and replace with &amp; 
//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);

-1

링크는 탈출해야 할 때 왜 상당히 좋은 예가 &에를&amp;

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

흥미롭게도, 나는 내 대답에서 올바르게 표현하기 위해 캐릭터를 탈출해야했습니다. (응답 패널에서) 내장 코드 샘플 옵션 을 사용하는 경우 입력 만하면 &amp;됩니다. 그러나 수동으로 <code></code>요소를 사용하려면 올바르게 표현하기 위해 탈출해야합니다. :)

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.