더하기는 mailto : 하이퍼 링크로 인코딩해야합니까?

mailto 하이퍼 링크 에 주소 태그 (일명 하위 주소)가 포함 된 이메일 주소를 배치 할 때 …

<a href="mailto:username+foo@example.com">mail us now!</a>

… 이메일의 플러스는 URL로 인코딩되어야합니까?

<a href="mailto:username%2Bfoo@example.com">mail us now!</a>

나는 이것을 알 수 없으며 문서가 충돌합니다. 우리의 실제 테스트는 결과가 혼합되어 더욱 혼란스러워졌습니다.

플러스는 SMTP가 아닌 HTML이 아닌 URL로 공백을 인코딩하는 데 사용됩니다 (RFC2821). 그러나 mailto:address@server.comURI (프로토콜, 프로토콜 구분 기호 및 프로토콜 주소가 있음)이므로 URI 로 처리해야하며 백분율로 인코딩되어야합니다 .

따라서, 인코딩 된 표현을 정확하게 해석하고 적절하게 디코딩하는 것은 클라이언트의 몫이다. 다음은 Microsoft의 공식 문제 입니다.

이메일 주소의 문자가 URI 예약 된 경우 mailto : HTML에 포함 된 URL에 URL 인코딩을 적용해야합니다. 이렇게하면 올바른 작업을 수행 할 수 있습니다. URI를 수신 한 시점부터 적절하게 디코딩하는 것은 클라이언트의 책임입니다. 예, this+address@gmail.com매우 유효한 이메일입니다. 예 this%2Baddress@gmail.com도 유효합니다. 예,이 두 가지가 다르지만 다르게 취급 될지는 고객에게 달려 있습니다.

앞에서 언급했듯이 모든 클라이언트가이를 올바르게 렌더링하는 것은 아닙니다. 사용자가 사용할 가능성이 가장 높은 클라이언트 (gmail? 브라우저 기반 클라이언트? Outlook?)를 찾아 해당 클라이언트의 기능을 수행하는 것이 좋습니다. 당신은 당신이 GMail에서 테스트했다고 말했다? 어떻게 테스트 했습니까? "브라우저 기반 mailto : 클라이언트 (예 : firefox 및 gmail 제공에 대한 애드온)를 사용하면 URI가 디코딩되지 않을 가능성이 높습니다.

인코딩 +할 수도 있지만 반드시 할 필요는 없습니다.

먼저 RFC 2396에mailto 지정된 일반 URI의 예라는 것에 동의해야합니다 . (이것은 XHTML과 HTML 4가 사용하는 것입니다).

이제 RFC 2396에서 예약 문자 목록을 찾아 보겠습니다.

reserved    = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+" |
              "$" | ","

URI는 절대 및 상대로 분할됩니다.

URI-reference = [ absoluteURI | relativeURI ] [ "#" fragment ]

그리고 scheme mailto:이 지정되었으므로 이것은 절대 URI입니다.

absoluteURI   = scheme ":" ( hier_part | opaque_part )

그리고 모두 패턴부터 hier_part시작 /, mailto불투명 한 부분이다.

opaque_part   = uric_no_slash *uric

uric_no_slash = unreserved | escaped | ";" | "?" | ":" | "@" |
                "&" | "=" | "+" | "$" | ","

uric          = reserved | unreserved | escaped

따라서 /첫 번째 문자의 경우 이스케이프 해야하지만 이후에는 +and를 포함한 예약 문자를 넣을 수 있습니다 @.

이를 지원하기위한 다른 RFC가 있습니다. RFC 6068 이라는 2010 년에 게시 된 mailto 체계의 최신 RFC에서 다음과 같이 말합니다.

'mailto'마찬가지로 URI를 생성하는 소프트웨어 는 사용 된 예약 문자를 인코딩 할 때주의해야합니다. HTML 양식은 'mailto'URI 를 생성하는 일종의 소프트웨어입니다 . 현재 구현은 공백을로 인코딩 '+'하지만 '+'공백에 대한 이러한 순위 '+'는 'mailto' URI 에서 실제와 구별 될 수 없기 때문에 문제가 발생 합니다. 'mailto'URI를 생성 할 때 모든 공백은로 인코딩해야 %20하고 '+'문자 는로 인코딩해야 합니다 (MAY) %2B. 주의하시기 바랍니다 '+' 문자가 자주 예를 들면 같은 하위 주소를 표시하기 위해 이메일 주소의 일부로서 사용된다 <bill+ietf@example.org>.

관련 RFC를 엄격히 읽으면 "+"를 인코딩해야합니다.

http://tools.ietf.org/html/rfc2368 의 섹션 2, 2 페이지 상단에 다음과 같이 나와 있습니다.

"to"의 모든 URL 예약 문자는 인코딩해야합니다. 특히 괄호, 쉼표 및 퍼센트 기호 ( "%")는 일반적으로 "mailbox"구문에서 발생합니다. "

URI 용 RFC (http://tools.ietf.org/html/rfc3986#section-2.2)에는 "+"가 예약 된 문자로 나열되어 있습니다.

즉, "올바른"것이 반드시 모든 브라우저에서 작동하는 것은 아닙니다. 일부 브라우저는 항상 옳고 그른 것처럼 올바른 것을 올바르게 처리합니다.

편집 : RFC6068과 "MAY"에 대해서는 문맥에 따라 다릅니다. 텍스트 읽기 용 URL을 작성하는 경우 "+"가 더 의미가 있지만 HTML로 작성하는 경우 RFC3986에 대한 엄격한 해석은 "유효한 HTML"아이디어와 더 밀접한 관계가 있으므로 값을 사용하는 모든 항목은 인코딩 될 것으로 기대하십시오.

새로운 RFC 당 http://tools.ietf.org/html/rfc6068#section-5

  ... '+' MAY BE encoded as %2B

그래서 대답은 그렇지 않다고 생각합니다.

인코딩 여부에 따라 큰 차이가 없을 것이라고 생각합니다. 문제는 메일 클라이언트입니다. 예를 들어 Yahoo Mail은 하위 주소 지정에 하이픈 만 사용하는 반면 gMail은 플러스를 사용합니다.

그건 내 2 센트 야 ...

편집 : 아래 응답에는 확실한 점이 있습니다.

RFC1738

3.5. MAILTO

mailto URL 체계는 개인 또는 서비스의 인터넷 우편 주소를 지정하는 데 사용됩니다. 인터넷 우편 주소 이외의 추가 정보는 존재하지 않습니다.

mailto URL의 형식은 다음과 같습니다.

    mailto:<rfc822-addr-spec>

RFC 822에 지정된 addr-spec의 인코딩은 어디 입니까 ? mailto URL에는 예약 문자가 없습니다.

퍼센트 부호 ( "%")는 RFC 822 주소 내에서 일반적으로 사용되며 인코딩되어야합니다.

많은 URL과 달리 mailto 체계는 직접 액세스 할 데이터 개체를 나타내지 않습니다. 객체를 지정한다는 의미는 없습니다. MIME의 메시지 / 외부 본문 유형과 다른 용도로 사용됩니다.

예약 된 문자가 없으므로 인코딩해야합니다.

당 RFC 6068 답변에서 언급 한 바와 같이, 당신은 더하기 기호를 인코딩 할 수있다 %2B.

혼란 거기에 이유가로 공간을 변환 플러스 실제로 표준 URL 인코딩의 일부가되지 않는 것입니다,의 그것의 일부 형태의 매개 변수 인코딩 (예 application/x-www-form-urlencoded)

PHP와의 차이점 rawurlencode()과 같습니다 urlencode().

따라서 RFC 6068의 말은 mailto:URL은 "원시"표준 URL 인코딩 ( RFC 3986에 따라 )을 사용해야하며 URL에 나타나는 더하기 부호는 항상 공백이 아니라 리터럴 더하기 부호로 취급해야합니다. 양식 인코딩되었습니다.

로컬 클라이언트가 플러스를 공백으로 변환하면 깨진 것입니다.