ควรบวกเข้ารหัสใน mailto: เชื่อมโยงหลายมิติ?

39

เมื่อวางที่อยู่อีเมลพร้อมกับแท็กที่อยู่ (หรือที่อยู่ย่อย) ในmailtoไฮเปอร์ลิงก์ ...

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

…เครื่องหมายบวกในอีเมลควรเป็น URL ที่เข้ารหัสหรือไม่

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

ฉันไม่สามารถเข้าใจได้และเอกสารมีความขัดแย้ง การทดสอบในโลกแห่งความเป็นจริงของเราได้สร้างผลลัพธ์ที่หลากหลายเช่นกันทำให้มีความสับสนมากยิ่งขึ้น

hyperlink url-encoding mailto

— Jeff Atwood
แหล่งที่มา

คุณจะเจาะจงมากขึ้นเกี่ยวกับวิธีการและผลลัพธ์ของการทดสอบจริงหรือไม่? ลูกค้า / บริการอีเมลบางรายปฏิบัติอย่างถูกต้องหรือไม่ คุณจะเจาะจงมากขึ้นได้ไหม?

— Bryson

1

@Bryson ฉันรู้ว่าส่วนขยาย chrome "ส่งโดยใช้ gmail" มีปัญหาเกี่ยวกับการไม่มีการเข้ารหัสและใน mailto: ตัวอย่างเช่น แต่อาจเป็นข้อผิดพลาด

— Jeff Atwood

2

แค่ใช้อันไหนก็ใช้ได้กับโครเมี่ยม

— Hardwareguy

21

เครื่องหมายบวกใช้เพื่อเข้ารหัสช่องว่างใน URL ไม่ใช่ใน HTML และไม่ใช่ใน SMTP (RFC2821) อย่างไรก็ตามเนื่องจากmailto:address@server.comเป็น URI (มันมีโปรโตคอลที่คั่นโปรโตคอลและที่อยู่โปรโตคอล) ก็ควรจะถือว่าเป็น URI และมันควรจะเป็นร้อยละเข้ารหัส

ดังนั้นจึงขึ้นอยู่กับลูกค้าที่จะแก้ไขการแสดงที่เข้ารหัสอย่างถูกต้องและถอดรหัสเท่าที่เหมาะสม นี่คือสิ่งที่ทาง Microsoft ใช้ในเรื่องนี้

คุณควรใช้การเข้ารหัส URL บน mailto: URL ที่ฝังอยู่ใน HTML หากอักขระในที่อยู่อีเมลถูกสงวนไว้ URI สิ่งนี้ทำให้มั่นใจได้ว่าคุณกำลังทำสิ่งที่ถูกต้อง มันขึ้นอยู่กับลูกค้าที่จะถอดรหัส URI อย่างเหมาะสมจากที่ได้รับ ใช่this+address@gmail.comเป็นอีเมลที่ถูกต้องมาก ใช่this%2Baddress@gmail.comก็ใช้ได้เช่นกัน ใช่ทั้งสองนั้นแตกต่างกัน แต่ไม่ว่าพวกเขาจะได้รับการปฏิบัติแตกต่างกันหรือไม่ก็ขึ้นอยู่กับลูกค้า ...

ดังที่คุณได้กล่าวไว้ก่อนหน้านี้ลูกค้าบางรายไม่สามารถแสดงได้อย่างถูกต้อง ฉันขอแนะนำให้ค้นหาลูกค้าที่มีแนวโน้มมากที่สุด (ลูกค้าที่ใช้เบราว์เซอร์ gmail? Outlook?) ที่ผู้ใช้ของคุณจะใช้ คุณบอกว่าคุณทดสอบกับ GMail หรือไม่ คุณทดสอบมันยังไง? ด้วย "mailto based เบราว์เซอร์: ไคลเอนต์ (เช่นส่วนเสริมของ firefox และข้อเสนอ gmail) URI มักจะไม่ถูกถอดรหัส (ตามที่ควรจะเป็น)

— Wez Furlong
แหล่งที่มา

ใครบ้างมีข้อมูลจริงเกี่ยวกับสิ่งที่ทำงานที่ไหน

— Wez Furlong

ดีฉันไม่ได้จดบันทึกที่เฉพาะเจาะจงของสิ่งที่ไมโครซอฟท์ยืนยันผลงานและ ...

— jcolebrand

นี่คือจุดที่ Gmail จัดการไม่ถูกต้อง แต่เนื่องจาก Google เพิกเฉยต่อรายงานข้อผิดพลาดของผู้ใช้คุณจึงไม่สามารถทำอะไรได้มากนัก

— Matthew อ่าน

5

หากคุณมีการเข้ารหัส+ใน URI @ก็จะต้องมีการเข้ารหัสเพราะมันเป็นตัวละครที่สงวนไว้ หากคุณอ่าน RFC อย่างระมัดระวังคุณจะพบว่าในส่วนที่ทึบแสงนั้น+ถูกกฎหมาย

— Eugene Yokota

ฉันอาจผิด แต่มันไม่ได้สงวนไว้ให้แยกชื่อผู้ใช้ออกจากโฮสต์ (เช่นในexample@example.com/path ) จากนั้นมันจะทำที่อยู่ในที่อยู่เพราะแยกชื่อผู้ใช้ออกจากโฮสต์

— Maciej Piechotka

7

คุณอาจเข้ารหัส+แต่คุณไม่จำเป็นต้อง

อันดับแรกเราต้องยอมรับว่าmailtoเป็นตัวอย่างของทั่วไป URI ที่ระบุโดยRFC 2396 (นี่คือสิ่งที่ใช้ XHTML และ HTML 4)

ตอนนี้ให้เราค้นหารายชื่อตัวละครที่สงวนไว้ใน RFC 2396

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

URI แยกเป็นสัมบูรณ์และสัมพัทธ์:

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

และเนื่องจาก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

ดังนั้นข้อ จำกัด คือการที่คุณจะต้องหลบหนี/ถ้ามันมาถึงตัวอักษรตัวแรก แต่หลังจากที่คุณสามารถใส่ในตัวละครรวมถึงสงวนและ+@

นี่คือ RFC อื่นเพื่อสนับสนุนสิ่งนี้ ใน RFCs ล่าสุดของชุดรูปแบบ mailto ที่เผยแพร่ในปี 2010 ชื่อRFC 6068กล่าวว่า:

ซอฟต์แวร์ที่สร้าง'mailto'URI จะต้องระมัดระวังในการเข้ารหัสอักขระที่สงวนไว้ที่ใช้ รูปแบบ HTML เป็นซอฟต์แวร์ประเภทหนึ่งที่สร้าง'mailto'URIs การใช้งานในปัจจุบันเข้ารหัสพื้นที่เป็น'+'แต่สิ่งนี้สร้างปัญหาได้เนื่องจาก'+'สถานะดังกล่าวสำหรับพื้นที่ไม่สามารถแยกความแตกต่างจากของจริง'+'ใน'mailto' URI เมื่อการผลิต'mailto'URI ของพื้นที่ทั้งหมดควรจะเข้ารหัสเป็น %20และตัวอักษรอาจจะเข้ารหัสเป็น'+' %2Bโปรดทราบว่า'+' ตัวละครมักใช้เป็นส่วนหนึ่งของที่อยู่อีเมลเพื่อระบุ subaddress <bill+ietf@example.org>เป็นเช่นใน

— ยูจีนโยโกตะ
แหล่งที่มา

ฉันไม่คุ้นเคยกับไวยากรณ์นั้นอย่างสิ้นเชิงอย่างไรก็ตามมันแสดงรายการอักขระที่แยกจากสระที่ไม่ได้จองซึ่งระบุว่า + เป็นอักขระที่สงวนไว้ ไม่ได้ระบุว่าจะต้องเข้ารหัส Microsoft บอกว่าจะเข้ารหัสมัน C'est la vie ฉันรอดู

— jcolebrand

1

เมื่อส่วนหนึ่งไม่ได้เริ่มต้นด้วย/, +ไม่กลายเป็นตัวละครที่สงวนไว้

— Eugene Yokota

ฉันไม่เห็นด้วย. "ที่อยู่อีเมล" มีการกำหนดไว้เป็นพิเศษและจะต้องได้รับการดูแลอย่างดีตั้งแต่แรก มาตรฐานนั้นทำให้สับสนมาก โชคดีที่เราไม่เห็นด้วยที่นี่

— jcolebrand

7

การอ่านอย่างเข้มงวดของ RFC ที่เกี่ยวข้องบอกว่าควรจะเข้ารหัส "+"

ส่วนที่ 2 ด้านบนของหน้า 2 ในhttp://tools.ietf.org/html/rfc2368พูดว่า:

"โปรดทราบว่าตัวอักษร URL ที่สงวนไว้ทั้งหมดใน" ถึง "ต้องได้รับการเข้ารหัส: โดยเฉพาะอย่างยิ่งวงเล็บ, เครื่องหมายจุลภาคและเครื่องหมายเปอร์เซ็นต์ ("% ") ซึ่งโดยทั่วไปจะเกิดขึ้นในไวยากรณ์" กล่องจดหมาย "

RFC สำหรับ URIs (http://tools.ietf.org/html/rfc3986#section-2.2) แสดงรายการ "+" เป็นอักขระที่สงวนไว้

ดังที่กล่าวไว้สิ่งที่ "ถูกต้อง" ไม่จำเป็นต้องทำงานในเบราว์เซอร์ทั้งหมด เห็นได้ชัดว่าเบราว์เซอร์บางตัวจะจัดการกับสิ่งที่ถูกต้องอยู่เสมอราวกับว่ามันผิดและไม่ถูกต้องราวกับว่ามันถูก

แก้ไข: สำหรับ RFC6068 และ "MAY" ของมันฉันจะอ่านว่าขึ้นอยู่กับบริบท หากคุณกำลังเขียน URL สำหรับการอ่านข้อความ "+" จะสมเหตุสมผลมากกว่าแต่ถ้าคุณเขียนเป็น HTML การตีความที่เข้มงวดยิ่งขึ้นของ RFC3986 จะสอดคล้องกับแนวคิด "HTML ที่ถูกต้อง" มากกว่าดังนั้นทุกอย่างที่ใช้ค่าควรเป็น คาดหวังให้เข้ารหัส

— IBBoard
แหล่งที่มา

2

ใน RFC 3986, mailtoจะได้รับการปฏิบัติpath-rootlessซึ่งจะช่วยให้ลำดับของที่กำหนดโดยpchar เป็นส่วนหนึ่งของ ดังนั้นการอ่านอย่างเข้มงวดกล่าวว่าไม่จำเป็นต้องมีการเข้ารหัสเปอร์เซ็นต์ (unreserved / pct-encoded / sub-delims / ":" / "@")+sub-delims+

— Eugene Yokota

6

ต่อ RFC ใหม่http://tools.ietf.org/html/rfc6068#section-5

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

ดังนั้นฉันเดาคำตอบไม่ได้ แต่อาจจะ?

— yuriismaster
แหล่งที่มา

3

ฉันคิดว่าการเข้ารหัสมันจะไม่สร้างความแตกต่างอย่างแท้จริง ปัญหาคือไคลเอนต์จดหมาย สำหรับการตรวจสอบ Yahoo Mail จะใช้ยัติภังค์สำหรับที่อยู่ย่อยเท่านั้นในขณะที่ gMail ใช้เครื่องหมายบวก

นั่นคือ 2 เซ็นต์ของฉัน ...

แก้ไข: การตอบสนองด้านล่างมีจุดแข็ง

— บรูโน่
แหล่งที่มา

จริงจุดดีว่ามีความแตกต่างบางอย่างเกี่ยวกับที่อยู่อีเมลย่อย - แต่อีเมลในกรณีนี้เป็นโฮสต์ Gmail ดังนั้นฉันรู้ว่าบวกถูกต้องและจะทำงานเมื่อได้รับจากเซิร์ฟเวอร์สมมติว่าอีเมลที่ได้รับผ่านลูกค้า

— Jeff Atwood

ปัญหาคือแอปพลิเคชันแยกวิเคราะห์คำขอ URI หากคาดว่าจะได้รับข้อมูล URLEncoded มันจะทำการถอดรหัสข้อมูล แต่นั่นไม่ยุติธรรมสำหรับคุณ (เพื่อเข้ารหัสเท็จ) หรือต่อลูกค้า (เพื่อทำการตั้งสมมติฐาน) โพรโทคอลไม่ได้กำหนดการเข้ารหัสที่คาดไว้ไคลเอนต์ทำ ดูการแก้ไขเพิ่มเติมที่ฉันทำกับ A โดย @Wez

— jcolebrand

3

RFC1738

3.5 MAILTO

ชุดรูปแบบ mailto URL ใช้เพื่อกำหนดที่อยู่ทางไปรษณีย์อินเทอร์เน็ตของแต่ละบุคคลหรือบริการ ไม่มีข้อมูลเพิ่มเติมใด ๆ นอกเหนือจากที่อยู่ทางไปรษณีย์อินเทอร์เน็ต

mailto URL ใช้แบบฟอร์ม:
    mailto:<rfc822-addr-spec>
อยู่ที่ไหน (การเข้ารหัสของ) ที่ addr สเปคตามที่ระบุไว้ในRFC 822 ภายใน mailto URL ไม่มีตัวอักษรที่สงวนไว้

โปรดทราบว่าโดยทั่วไปจะใช้เครื่องหมายเปอร์เซ็นต์ ("%") ภายในที่อยู่ RFC 822 และต้องเข้ารหัส

แตกต่างจาก URL จำนวนมากชุดรูปแบบ mailto ไม่ได้แสดงวัตถุข้อมูลที่จะเข้าถึงโดยตรง ไม่มีความหมายในการกำหนดวัตถุ มันมีการใช้งานที่แตกต่างจากข้อความ / ประเภทร่างกายภายนอกใน MIME

เนื่องจากไม่มีอักขระที่สงวนไว้จึงควรเข้ารหัส

— S.Skov
แหล่งที่มา

และต่อtools.ietf.org/html/rfc6068 "เมื่อสร้าง 'mailto' URIs ช่องว่างทั้งหมดควรเข้ารหัสเป็น% 20 และอักขระ '+' อาจเข้ารหัสเป็น% 2B"

— Jeff Atwood

1

Since there are no reserved characters it should be encoded.อืมมมที่ไม่สมเหตุสมผล

— jcolebrand

@jcolebrand '+' เป็นอักขระพิเศษในชุดรูปแบบ URL จึงต้องเข้ารหัสเมื่อไม่มีบทบาทพิเศษ - เช่น เมื่อไม่ได้จองไว้

— S.Skov

@ เจฟฟ์แน่นอน - ฉันไม่ดีสำหรับการใช้ชีวิตในโลก RFC ที่มีอายุมากกว่า จากนั้นtools.ietf.org/html/rfc2119โดยทั่วไปบอกให้คุณทำในสิ่งที่คุณรู้สึกว่าเหมาะกับคุณที่สุด

— S.Skov

ดูเหมือนว่า .... ย้อนกลับไปในจิตวิญญาณต่อวิธีที่ฉันอ่านคำแนะนำในตอนแรก

— jcolebrand

3

ต่อRFC 6068%2Bตามที่กล่าวไว้ในคำตอบคุณอาจเข้ารหัสที่เครื่องหมายบวกเป็น

เหตุผลที่ทำให้เกิดความสับสนคือการแปลงช่องว่างเป็นเครื่องหมายบวกไม่ใช่ส่วนหนึ่งของการเข้ารหัส URL มาตรฐาน แต่เป็นส่วนหนึ่งของการเข้ารหัสพารามิเตอร์ของฟอร์ม (เช่นapplication/x-www-form-urlencoded)

มันเหมือนความแตกต่างระหว่าง PHP ฯและrawurlencode()urlencode()

ดังนั้นสิ่งที่ RFC 6068 กำลังพูดคือmailto:URL ควรใช้การเข้ารหัส URL มาตรฐาน "ดิบ" (ต่อRFC 3986 ) และเครื่องหมายบวกที่ปรากฏใน URL ควรถือว่าเป็นเครื่องหมายบวกตามตัวอักษรเสมอและไม่เป็นพื้นที่ที่มี ได้รับการเข้ารหัสรูปแบบ

หากไคลเอ็นต์โลคัลแปลงเครื่องหมายบวกเป็นช่องว่างมันจะเสียหาย

— Alnitak
แหล่งที่มา