Ayrıca mailto'da kodlanmalı mı: köprüler?

Bir mailto köprüsünde adres etiketli bir e-posta adresi (aka alt adresleme) …

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

… E-postadaki artı URL kodlu mu olmalı?

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

Bunu çözemiyorum ve belgeler çelişkili. Gerçek dünya testlerimiz de karışık sonuçlar üretti, bu da daha da kafa karıştırıcı oldu.

Artı, URL’lerde, HTML’de değil, SMTP’de (RFC2821) boşlukları kodlamak için kullanılır. Bununla birlikte, mailto:address@server.combir URI olduğu için (bir protokole, protokol ayırıcısına ve protokol adresine sahiptir), o zaman bir URI olarak ele alınmalı ve yüzde olarak kodlanmalıdır .

Bu nedenle, şifreli gösterimi doğru bir şekilde çözmek ve uygun bir şekilde kodunu çözmek müşteriye kalmıştır. İşte Microsoft'un resmi meselesi .

Mailto'da URL kodlaması uygulamanız gerekir: e-posta adresindeki karakterler URI'ye ayrılmışsa, HTML'ye gömülü URL'ler. Bu, doğru olanı yaptığınızı garanti eder. URI'nın alındığı yerden uygun şekilde kodunu çözmek müşteriye kalmıştır. Evet, this+address@gmail.comçok geçerli bir e-posta; evet this%2Baddress@gmail.comayrıca geçerlidir. Evet, bu ikisi farklı, ama farklı şekilde davranılıp davranılmayacakları müşteriye kalmış ...

Daha önce not ettiğiniz gibi, tüm müşteriler bunu doğru şekilde yapmaz. Kullanıcılarınızın kullanacağı en olası müşteriyi (gmail? Tarayıcı tabanlı istemcileri? Outlook?) Bulmanızı ve bu müşterinin yaptığı şeyi yapmasını öneririm. GMail'de test ettiğini söylemiştin? Nasıl test ettin? "Tarayıcı tabanlı mailto: client (firefox ve gmail teklifine eklentiler gibi) ile URI büyük olasılıkla çözülmemelidir (olması gerektiği gibi).

Şifreleyebilirsin +ama mecbur değilsin.

Öncelikle, RFC 2396mailto tarafından belirtilen genel bir URI örneği olduğunu kabul etmemiz gerekir . (XHTML ve HTML 4'ün kullandığı şey budur).

Şimdi ayrılmış karakterlerin listesini RFC 2396'da bulalım.

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

URI mutlak ve bağıl olarak ayrılır:

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

Ve şema mailto:belirtildiği için bu mutlak bir URI'dir:

absoluteURI   = scheme ":" ( hier_part | opaque_part )

Ve her iki modelde de hier_partbaşlangıç ​​için /, mailtoopak bir kısımdır.

opaque_part   = uric_no_slash *uric

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

uric          = reserved | unreserved | escaped

Bu nedenle kısıtlama, /ilk karaktere gelirse kaçmak zorunda olmanızdır , ancak bundan sonra +ve de dahil olmak üzere ayrılmış karakterleri girebilirsiniz @.

İşte bunu destekleyen başka bir RFC var. 2010 yılında yayınlanan ve en son RFC 6068 olarak adlandırılan mailto programının RFC'lerinde şöyle yazıyor:

'mailto'URI'leri oluşturan yazılımların da, kullanılan tüm ayrılmış karakterleri kodlamak için dikkatli olması gerekir. HTML formları, 'mailto'URI'ları oluşturan bir tür yazılımdır . Güncel uygulamaları olarak boşluk kodlamak '+', ama böyle çünkü bu sorun yaratır '+'bir alan için ayakta bir gerçek ayırt edilemeyen '+'bir de 'mailto' URI. 'mailto'URI'lar üretilirken tüm boşluklar olarak kodlanmalı %20ve '+'karakterler MAY olarak kodlanmalıdır %2B. Lütfen, '+' karakterlerin, örneğin bir alt adres belirtmek için bir e-posta adresinin parçası olarak kullanıldığını unutmayın <bill+ietf@example.org>.

İlgili RFC'nin katı bir şekilde okunması, "+" nın kodlanması gerektiğini söylüyor.

Bölüm 2, http://tools.ietf.org/html/rfc2368 adresindeki sayfa 2’nin en üstünde :

"" İle "deki tüm URL ayrılmış karakterlerin kodlanması gerektiğini unutmayın: özellikle, genellikle" posta kutusu "sözdiziminde" parantez, virgül ve yüzde işareti ("%").

URI'lar için RFC (http://tools.ietf.org/html/rfc3986#section-2.2) ayrılmış bir karakter olarak "+" listeler.

Bu, "doğru" olanın mutlaka tüm tarayıcılarda işe yarayacak olmadığını söyledi. Bazı tarayıcılar, her zaman doğru olanı, sanki hatalıymış gibi doğru olanları ve doğru oldukları gibi yanlış olarak ele alır.

Düzenleme: RFC6068 ve onun "MAY" olarak, bağlam bağımlı olarak okurdum. Metin okuma için URL'yi yazıyorsanız, "+" daha anlamlı olur, ancak HTML’de yazıyorsanız, RFC3986’nın daha katı yorumlanması "geçerli HTML" fikirleriyle daha satır içi olur ve bu nedenle değeri kullanan herhangi bir şey kodlanmasını bekle.

Her yeni RFC'ye göre http://tools.ietf.org/html/rfc6068#section-5

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

Yani cevabı değil sanırım, ama belki?

Bunu kodlamanın ya da kodlamanın gerçek bir fark yaratmayacağını düşünüyorum. Sorun posta istemcileri. İncelemek için, Yahoo Mail yalnızca alt adresleme için kısa çizgi kullanır, oysa gMail artı'yı kullanır.

Bu benim 2 sentim.

EDIT: Aşağıdaki cevap sağlam bir noktaya sahiptir.

RFC1738

3.5. MAILTO

Mailto URL şeması, bir bireyin veya hizmetin İnternet posta adresini belirlemek için kullanılır. İnternet posta adresi dışında hiçbir ek bilgi bulunmamakta veya ima edilmemektedir.

Bir mailto URL formu alır:

    mailto:<rfc822-addr-spec>

RFC 822'de belirtildiği gibi, addr-spec kodlaması . Mailto URL'leri içinde ayrılmış karakter yoktur.

Yüzde işaretinin ("%") RFC 822 adreslerinde yaygın olarak kullanıldığını ve kodlanması gerektiğini unutmayın.

Birçok URL'den farklı olarak, mailto şeması doğrudan erişilecek bir veri nesnesini temsil etmez; bir nesneyi tanımladığı bir anlam yoktur. MIME’deki mesajdan / dış gövde türünden farklı bir kullanımı vardır.

Ayrılmış karakter olmadığından kodlanmalıdır.

Cevaplarda belirtildiği gibi RFC 6068 uyarınca , artı işaretini olarak kodlayabilirsiniz %2B.

Karışıklık nedeni, bir boşluğu bir artıya dönüştürmenin aslında standart URL kodlamanın bir parçası olmamasıdır, form parametre kodlamasının bir parçası (yani application/x-www-form-urlencoded)

PHP rawurlencode()ve arasındaki fark gibi urlencode().

Öyleyse, RFC 6068’in söylediği şey bir mailto:URL’nin "raw" standart URL kodlaması kullanması gerektiğidir ( RFC 3986’ya göre ) ve URL’de görünen artı işareti her zaman değişmez artı işareti olarak değerlendirilmelidir, form kodlanmış.

Yerel istemci artıyı bir alana dönüştürürse bozulur.