개발자 도구 · URL 인코더 및 디코더
mailto 인코딩 방법: 제목, 본문 줄 바꿈 및 앰퍼샌드가 포함된 링크
· 그것이 중요한 이유
메일로 URL 인코딩 HTML
제목과 본문이 포함된 mailto: 링크는 URL이므로 공백, 줄 바꿈 및 &는 퍼센트 인코딩되어야 합니다. 이 게시물은 깨지지 않을 때 무엇이 깨지는지, 그리고 메일 클라이언트에서 올바르게 열리는 링크를 구축하는 방법을 보여줍니다.
제목이 첫 번째 공백에서 멈춘 연락처 링크 — 구체적인 깨진 mailto: 및 메일 클라이언트가 받은 내용
<a href="mailto:test@example.com?subject=Support Inquiry">보내기</a>와 같은 연락처 링크는 "지원 문의"의 공백이 메일 클라이언트의 링크를 종료하므로 중단됩니다. 많은 클라이언트가 "지원"만을 제목으로 받습니다. 이는 mailto: 링크가 RFC 6068을 따르며 쿼리 매개변수에 공백과 특수 문자에 백분율 인코딩이 필요함을 지정하기 때문에 발생합니다. 앰퍼샌드는 매개변수 구분 기호가 되지 않도록 %26 인코딩이 필요합니다.
깨진 mailto: 링크는 문제를 명확하게 보여줍니다. <a href="mailto:test@example.com?subject=Support Inquiry&body=Reply">연락처</a>와 같은 구성된 링크는 제목이 "지원"인 메시지만 표시합니다. 다양한 메일 클라이언트에서 테스트한 결과 다양한 허용 범위가 드러났습니다. Apple Mail은 링크를 부분적으로 처리하고 Gmail은 "지원"만 표시하며 Outlook은 완전히 실패합니다.
mailto:는 URL 구성표입니다 — RFC 6068 간단히 말하면 어떤 부분이 쿼리 문자열인가요?
RFC 6068는 구성 요소별 인코딩 규칙을 사용하여 mailto: URL 체계를 정의합니다. 일반 URL과 달리 mailto:에는 구성 요소별로 특정 규칙이 있습니다. 주소 부분(test@example.com)은 인코딩되지 않은 상태로 유지됩니다. @ 및 도메인은 구조적입니다. 쿼리 매개변수(제목, 본문, 참조, 숨은 참조)에는 인코딩이 필요합니다. RFC 6068은 규칙에 대해 RFC 3986를 참조하여 공백과 특수 문자에 대한 백분율 인코딩을 요구합니다. 값 내의 앰퍼샌드는 구분 기호가 아닌 데이터로 표시될 때 %26이 됩니다.
mailto 이해: 구성표 구조는 인코딩 실수를 방지합니다. 형식은 mailto:address?parameter1=value1¶meter2=value2입니다. 물음표는 쿼리 섹션을 소개합니다. 매개변수를 구분하는 앰퍼샌드가 인코딩되지 않은 상태로 유지됩니다. 값 내의 앰퍼샌드만 %26로 인코딩됩니다. 제목에 "Tom & Jerry"가 포함된 경우 Tom%20%26%20Jerry로 인코딩합니다. 제목과 본문 사이의 앰퍼샌드는 인코딩되지 않은 상태로 유지됩니다. 이 중첩 인코딩은 오류가 발생하기 쉽습니다.
제목과 본문 인코딩 — 공백은 %20, 줄바꿈은 %0D%0A, &는 값 내부의 %26
제목과 본문을 인코딩하려면 공백과 특수 문자를 주의 깊게 처리해야 합니다. mailto: 링크에서 공백은 HTML 형식과 달리 더하기 기호가 아닌 %20이 됩니다. 이 중요한 차이점은 웹 양식에 익숙한 개발자를 당황하게 합니다. 줄 바꿈은 %0D%0A(이메일의 CRLF 줄 끝)로 인코딩됩니다. 앰퍼샌드는 %26이 됩니다. 백분율 기호는 %25가 됩니다. 제목에는 일반적으로 공백, 악센트 및 괄호가 포함됩니다. 본문에는 공백, 악센트, 줄 바꿈이 포함되어 있습니다.
mailto: 링크의 일반적인 인코딩에는 공백 %20, 개행 %0D%0A, 앰퍼샌드 %26, 백분율 %25, 해시 %23, 질문 %3F가 포함됩니다. 악센트와 같은 비ASCII는 먼저 UTF-8 바이트로 변환된 다음 백분율로 인코딩됩니다. "우버 보고"는 %C3%9ber%20report가 됩니다. "안녕하세요! 안녕히 가세요'는 안녕하세요%21%0D%0A안녕하세요가 됩니다. 구조적이 아닌 값만 인코딩합니까? 그리고 & 문자.
작업 예: 제목, 두 줄 본문 및 참조로 링크 만들기 — 인코딩된 결과 및 메일 클라이언트에 표시되는 방식
작업 예: 제목 "회의 안건(9월)", 본문 "논의하자: 분기별 목표" 및 참조 "manager@example.com"은 완전한 인코딩을 보여줍니다. 제목에는 공백이 %20, 괄호가 %28 및 %29이 필요합니다. 본문에는 다음이 필요합니다. "논의하자:" 대부분 변경되지 않음(공백은 %20), 줄 바꿈은 %0D%0A로, "분기별 목표"는 대부분 변경되지 않았습니다. cc 필드에는 인코딩이 필요하지 않습니다.
결과 mailto:는 mailto:contact@example.com?subject=Meeting%20agenda%20%28Sept%29&body=Let%20us%20discuss%3A%0D%0AQuarterly%20goals&cc=manager@example.com입니다. 브라우저에서 테스트하면 메일 클라이언트 해석이 다르게 나타납니다. Gmail은 올바른 제목, 두 줄의 본문 및 참조가 포함된 작성 창을 엽니다. Outlook도 비슷한 결과를 보여줍니다. Apple Mail에는 권한이 필요합니다. 나이든 고객은 신체 지지력이 부족하여 실패합니다.
여기서 +가 잘못된 이유 — mailto: 형식 인코딩이 아닌 RFC 3986를 따르므로 +는 플러스로 유지됩니다.
더하기 기호가 잘못된 이유—mailto: 형식 인코딩이 아닌 RFC 3986를 따르므로 더하기는 그대로 유지됩니다. 중요한 차이점을 명확히 합니다. HTML 양식 인코딩은 쿼리 문자열의 공백에 플러스를 사용합니다. RFC 3986 및 RFC 6068는 모두 공백에 %20을 지정합니다. mailto: subject="Meeting+Agenda"를 사용하면 공백이 아닌 문자 그대로 더하기 기호가 있는 제목이 생성됩니다. 이 실수는 양식 인코딩 논리를 mailto: 생성에 복사할 때 발생합니다. Plus는 공백이 아니라 플러스를 의미합니다.
이것이 중요한 이유: 개발자가 양식 GET 제출 논리를 mailto: 세대 중단 링크에 복사합니다. 주제 "Meeting Agenda"는 형식상 "Meeting+Agenda"가 됩니다. mailto: 링크에서는 리터럴 플러스가 포함된 "Meeting+Agenda"를 생성합니다. 사용자는 제목 줄을 수동으로 수정합니다. mailto 테스트: 링크를 클릭하거나 생성된 링크를 검사해야 하며 양식 규칙을 분석해야 합니다.
일반적인 실수 — href에서 & 구분 기호를 HTML로 이스케이프하는 것을 잊고 주소에서 @를 퍼센트 인코딩하는 것을 잊어버렸습니다.
일반적인 mailto: 작성 실수에는 href 속성에서 HTML 앰퍼샌드와 이스케이프를 잊어버리는 것이 포함됩니다. HTML에서 유효한 XHTML의 경우 속성의 앰퍼샌드는 &여야 합니다. href="mailto:address?subject=Test&body=Test"는 잘못된 HTML입니다. href="mailto:address?subject=Test&body=Test"여야 합니다. 이는 URL 인코딩과 다른 인코딩을 나타냅니다. HTML 파서는 브라우저가 URL을 처리하기 전에 &를 &로 해석합니다.
이러한 실수를 테스트하려면 HTML 소스와 브라우저 콘솔을 검사해야 합니다. 실제 href 값을 보려면 마우스 오른쪽 버튼을 클릭하고 "요소 검사"를 선택하십시오. href 값을 주소 표시줄(mailto: 접두사 포함)에 복사하여 붙여넣고 메일 클라이언트를 확인하세요. 일부 이메일 링크는 특정 브라우저에서는 작동하지만 다른 브라우저에서는 작동하지 않습니다. mailto: 외부 클라이언트가 포함되어 수동 확인이 일반적이기 때문에 자동 테스트가 어렵습니다.
여기서 다루지 않는 내용 — 메일 클라이언트 지원 차이점 및 여러 수신자에 대한 심층적인 지원
여기서 다루지 않는 내용에는 메일 클라이언트 지원 차이점과 여러 수신자가 포함됩니다. 모든 클라이언트가 RFC 6068 매개변수를 동일하게 지원하는 것은 아닙니다. body 매개변수는 폭넓은 지원을 제공하지만 일부 오래된 클라이언트에서는 이를 무시합니다. cc 및 bcc 매개변수는 변수를 지원합니다. 여러 수신자에게는 쉼표로 구분된 이메일 주소가 필요하며 복잡한 주소의 경우 쉼표를 %2C로 인코딩합니다. 로케일에 따라 표시하려면 적절한 UTF-8 인코딩이 필요합니다.
메일 클라이언트의 발전은 플랫폼 전반에 걸친 mailto: 동작에 영향을 미칩니다. 최신 웹 메일 클라이언트(Gmail, Outlook.com)는 이전 데스크톱 클라이언트보다 RFC 6068 규정을 더 잘 준수합니다. 모바일 클라이언트는 때때로 더 엄격한 구문 분석을 수행합니다. 일부는 서식 있는 텍스트를 지원하지만 다른 일부는 일반 텍스트만 지원합니다. 개발자는 청중이 실제로 사용하는 메일 클라이언트로 테스트해야 합니다. 실제 구현은 RFC 6068 사양에도 불구하고 다양합니다.
요점: 각 값을 인코딩하고 구조를 유지합니다. URL 인코더 및 디코더의 단일 값 모드가 붙여넣을 인코딩된 제목과 본문을 제공하는 방법
요약: 각 값을 인코딩하고 구조를 유지합니다. URL 인코더 및 디코더 단일 값 모드는 링크에 붙여넣을 준비가 된 인코딩된 제목과 본문을 생성합니다. 이 도구는 "회의 안건(9월)"과 같은 인코딩되지 않은 값을 허용하고 "회의%20의제%20%28Sept%29"를 생성합니다. 출력을 mailto: href 속성에 직접 복사합니다. 여러 줄로 구성된 본문의 경우 줄바꿈이 포함된 일반 텍스트 버전을 붙여넣어 %0D%0A 인코딩 버전을 가져옵니다.
모범 사례에서는 수동 구성이 아닌 인코딩된 부분의 링크인 mailto를 조립합니다. JavaScript 또는 템플릿에서 HTML을 동적으로 작성하는 경우 & 구분 기호로 연결하기 전에 각 매개변수를 별도로 인코딩합니다. 정적 HTML의 경우 URL 인코더 및 디코더는 직접 작성하기 전에 인코딩을 안정적으로 테스트합니다. 코드 주석의 문서 인코딩 프로세스. 결과 mailto: 배포 전에 실제 메일 클라이언트를 클릭하여 링크를 테스트합니다.