Bir meslektaşım kısa süre önce beni bir blog gönderisine yönlendirdi: . Kısaltmak adına bu yazıda bundan olarak bahsedeceğim. E-posta Regex Doğrulamasının Boşluğu Üzerine Boşunalık Bir dizenin RFC 5322 İnternet Mesajı başlığı tanımına uyup uymadığını başarılı bir şekilde tanımlayabilen bir normal ifade yazmanın zorluğu eğlenceli bir zorluk olsa da, pratik programcılar için yararlı bir rehber olmadığını kabul ediyorum. Futility'nin Bunun nedeni RFC 5322 mesaj başlıklarını RFC 5321 adres değişmezleriyle birleştirmesidir; bu, basit bir dille, geçerli bir SMTP e-posta adresini oluşturan şeyin genel olarak geçerli bir mesaj başlığını oluşturan şeyden farklı olduğu anlamına gelir. Bunun nedeni aynı zamanda okuyucunun, standartlar açısından teorik olarak mümkün olan, ancak "vahşi doğada" meydana gelme olasılığının son derece küçük olduğunu göstereceğim uç durumlarla meşgul olmaya teşvik etmesidir. Bu makale, bu iddiaların her ikisini de genişletecek, e-posta normal ifadesine yönelik birkaç olası kullanım örneğini tartışacak ve pratik e-posta normal ifadesine ilişkin açıklamalı "yemek kitabı" örnekleriyle sonuçlanacaktır. RFC 5321, 5322'nin yerini alır E-posta iletimi için SMTP'nin evrenselliği, pratik bir konu olarak, 5321 olan ilgili IETF RFC'nin yakından okunması olmadan hiçbir e-posta adresi biçimlendirme incelemesinin tamamlanmadığı anlamına gelir. 5322, e-posta adreslerini, kendisine hiçbir özel durum kuralı uygulanmayan, yalnızca genel bir ileti başlığı olarak kabul eder. Bu, parantez içindeki yorumların alan adında bile geçerli olduğu anlamına gelir. atıfta bulunulan , yorumlar veya aksan veya Unicode karakterler içeren 10 test içerir ve bunlardan 8'inin geçerli e-posta adreslerini temsil ettiğini belirtir. Futility'de test paketi Bu yanlıştır çünkü RFC 5321, e-posta adreslerinin alan adı bölümlerinin " açıkça belirtir. SMTP amacıyla ASCII karakter kümesinden alınan bir dizi harf, rakam ve kısa çizgiden oluşacak şekilde sınırlandırıldığını" Düzenli bir ifade oluşturma bağlamında, özellikle aşırı dize uzunluğunun belirlenmesiyle ilgili olarak, bu kısıtlamanın meseleleri ne ölçüde basitleştirdiğini abartmak zordur. Örneklerin açıklamaları aşağıda bunu vurgulayacaktır. Bu aynı zamanda doğrulama bağlamında daha sonra inceleyeceğimiz diğer bazı pratik hususları da ima eder. Vahşi Ortamdaki Posta Kutusu Adları Her iki RFC'ye göre e-posta adresinin “@“ sembolünün solundaki kısmının teknik adı “posta kutusu”dur. Her iki RFC de posta kutusu bölümünde hangi karakterlere izin verileceği konusunda önemli bir serbestliğe izin verir. Tek önemli pratik kısıtlama, tırnakların veya parantezlerin dengelenmesi gerektiğidir; bu, vanilya normal ifadesinde doğrulamak için gerçek bir zorluktur. Ancak gerçek dünyadaki posta kutusu uygulamaları yine pratik programcının kullanması gereken önlemdir. Kural olarak, bize ödeme yapan insanlar, faturalandırılabilir saatlerimizin %90'ının, gerçek hayatta muhtemelen hiç var olmayabilecek teorik uç vakaların %10'unu çözmeye yönlendirilmesini hoş karşılamazlar. Baskın e-posta posta kutusu sağlayıcılarına, tüketicilere ve işletmelere bakalım ve ne tür e-posta adreslerine izin verdiklerini düşünelim. Tüketici e-postası için Twitter hesaplarından sızdırılan 5.280.739 e-posta adresinin listesini kullanarak bazı temel araştırmalar yaptım. 115 milyon Twitter hesabına dayanarak, bu bize Twitter'ın tüm nüfusu için %0,055 hata marjıyla %99'luk bir güven düzeyi veriyor; bu, tüm İnternet e-posta adreslerinin genel popülasyonunu oldukça iyi temsil ediyor. İşte öğrendiklerim: Adreslerin %82'si yalnızca ASCII alfasayısal karakterler içeriyordu, Tüm adreslerin %97'si için %15'i yalnızca ASCII alfanümerik ve noktalar (ASCII dönemleri) içeriyordu, %3'ü, e-posta adreslerinin nominal %100'ü için yalnızca ASCII alfanümerik, noktalar ve kısa çizgiler içeriyordu. Ancak bu %100 yuvarlanmış bir rakamdır. Trivia meraklıları için şunları da buldum: Toplamın %0,00072'sini oluşturan alt çizgi içeren 38 adres %0,00051 için artı işaretli 27 ve Toplamın %0,00002'sini temsil eden Unicode karakterli 1 adres. Bunun net etkisi, e-posta adresi posta kutularının yalnızca ASCII alfanümerik, noktalar ve kısa çizgiler içerdiğini varsaymanın, tüketici e-postaları için 5 9'dan daha iyi bir doğruluk sağlamasıdır. Datanyze, iş e-postaları için 6.771.269 şirketin 91 farklı e-posta barındırma çözümü kullandığını . Ancak Pareto dağıtımı geçerlidir ve bu posta kutularının %95,19'u yalnızca 10 hizmet sağlayıcı tarafından barındırılmaktadır. bildirdi Gmail İşletme Sürümü (%34,35 Pazar Payı) Google, posta kutusu oluştururken yalnızca ASCII harflerine, sayılarına ve noktalarına izin verir. Ancak artı işaretini kabul edecektir. e-posta alırken Microsoft Exchange Çevrimiçi (%33,60) Yalnızca ASCII harflerine, sayılarına ve noktalarına izin verir. GoDaddy E-posta Barındırma (%14,71) Microsoft 365'i kullanır ve yalnızca ASCII harflerine, sayılarına ve noktalarına izin verir. 7 Ek Sağlayıcı (%12,53) Belgelenmemiş. Ne yazık ki işletmelerin yalnızca %82'sinden emin olabiliyoruz ve bunun kaç tane posta kutusunu temsil ettiğini bilmiyoruz. Ancak Twitter e-posta adreslerinden 173.467 alan adından yalnızca 400'ünde 100'den fazla bireysel e-posta posta kutusunun temsil edildiğini biliyoruz. Kalan alan adlarının %99'unun çoğunun iş e-posta adresleri olduğuna inanıyorum. Sunucu veya etki alanı düzeyindeki posta kutusu adlandırma politikaları açısından, bu 237.592 e-posta adresini %99 güven düzeyi ve %0,25 hata payı ile 1 milyar iş e-posta adresinden oluşan bir popülasyonu temsil ediyor olarak almanın makul olduğunu düşünüyorum. Bir e-posta adresi posta kutusunun yalnızca ASCII alfanümerik, noktalar ve kısa çizgiler içerdiği varsayıldığında 3'e yakın 9'lar. Kullanım Durumları Yine, pratikliği ön planda tutarak, hangi koşullar altında programlı olarak geçerli bir e-posta adresini tanımlamamız gerekebileceğini düşünelim. Yeni Hesap Oluşturma/Kullanıcı Kayıtları Bu kullanım örneğinde, potansiyel yeni bir müşteri hesap oluşturmaya çalışmaktadır. Göz önünde bulundurabileceğimiz iki üst düzey strateji var. İlk durumda, yeni kullanıcının sağladığı e-posta adresinin geçerli olduğunu doğrulamaya ve eş zamanlı olarak hesap oluşturmaya devam etmeye çalışırız. Bu yaklaşımı benimsememenizin iki nedeni olabilir. Birincisi, e-posta adresinin geçerli bir forma sahip olduğunu doğrulayabilmenize rağmen, yine de mevcut olmayabilir. Diğer neden ise, her türlü ölçekte senkron kelimesinin kırmızı bayraklı bir kelime olması ve pragmatik programcının bunun yerine durum bilgisi olmayan bir web ön ucunun form bilgilerini bir mikro hizmete veya API'ye ilettiği bir ateşle ve unut modelini dikkate almasına neden olması gerekir. hesap oluşturma sürecinin tamamlanmasını tetikleyecek benzersiz bir bağlantı göndererek e-postayı eşzamansız olarak doğrulayın. İletişim Formları Teknik incelemeleri indirmek için sıklıkla kullanılan türden basit bir iletişim formu söz konusu olduğunda, geçerli bir e-posta gibi görünen ancak geçerli olmayan dizeleri kabul etmenin olası dezavantajı, e-postanın geçerli olup olmadığını doğrulamayarak pazarlama veritabanınızın kalitesini düşürmenizdir. e-posta adresi gerçekten var. Bir kez daha, ateşle ve unut modelinin, bir forma girilen dizenin programatik olarak doğrulanmasından daha iyi bir seçenek olduğunu belirtmek isteriz. Yönlendiren Günlüklerinin ve Diğer Büyük Hacimli Verilerin Ayrıştırılması. Bu bizi genel olarak programatik e-posta adresi tanımlamanın ve özel olarak da normal ifadenin gerçek kullanım durumuna götürür: büyük miktarda yapılandırılmamış metinlerin anonimleştirilmesi veya incelenmesi. Bu kullanım senaryosuyla ilk kez, yönlendiren günlüklerini bir sahtekarlık tespit veritabanına yüklemesi gereken bir güvenlik araştırmacısına yardım ederken karşılaştım. Yönlendiren günlükleri, şirketin duvarlarla çevrili bahçesinden ayrılmadan önce anonimleştirilmesi gereken e-posta adreslerini içeriyordu. Bunlar yüz milyonlarca satırdan oluşan dosyalardı ve günde yüzlerce dosya vardı. “Satırlar” bin karaktere yakın uzunlukta olabilir. Bir satırdaki karakterler arasında yineleme yapmak, döngüler ve standart dize işlevleri kullanarak karmaşık testler uygulamak (örneğin, bu satırda nin ilk kez görülmesi mi ve gibi bir dosya adının parçası mı?) inanılmaz derecede büyük bir zaman karmaşıklığı. @ imagefile@2x.png Aslında bu (çok büyük) şirketin şirket içi geliştirme ekibi bunun imkansız bir görev olduğunu ilan etmişti. Aşağıdaki derlenmiş regex'i yazdım: search_pattern = re.compile("[a-zA-Z0-9\!\#\$\%\'\*\+\-\^\_\`\{\|\}\~\.]+@|\%40(?!(\w+\.)**(jpg|png))(([\w\-]+\.)+([\w\-]+)))") Ve bunu aşağıdaki Python listesi anlayışına bıraktı: results = [(re.sub(search_pattern, "redacted@example.com", line)) for line in file] Ne kadar hızlı olduğunu hatırlamıyorum ama hızlıydı. Arkadaşım bunu bir dizüstü bilgisayarda çalıştırabilir ve birkaç dakika içinde tamamlayabilir. Doğruydu. Hem yanlış negatiflere hem de yanlış pozitiflere bakarak saati 5 9'da ölçtük. Yönlendiren günlükleri sayesinde işim biraz kolaylaştı; yalnızca URL'nin "yasal" karakterlerini içerebiliyorlardı, bu nedenle benioku belgelediğim tüm çarpışmaların haritasını çıkarabildim. deposunda Ayrıca, e-posta adresi analizini gerçekleştirseydim ve 5 9'un hedefine ulaşmak için gereken tek şeyin ASCII alfanümerik, noktalar ve çizgiler olduğunu öğrenseydim, bunu daha da basit (ve daha hızlı) yapabilirdim. Bununla birlikte, bu, pratikliğin ve çözümün, çözülmesi gereken gerçek soruna uyacak şekilde kapsamının belirlenmesinin iyi bir örneğidir. Programlama bilgisi ve tarihindeki en büyük alıntılardan biri, büyük Ward Cunningham'ın, tam olarak neyi başarmaya çalıştığınızı hatırlamak için bir saniye ayırmanız ve ardından kendinize "İşe yarayabilecek en basit şey nedir?" diye sormanız yönündeki . tavsiyesidir Büyük miktarda yapılandırılmamış metinden bir e-posta adresinin ayrıştırılması (ve isteğe bağlı olarak dönüştürülmesi) durumunda, bu çözüm kesinlikle aklıma gelen en basit şeydi. Açıklamalı Yemek Kitabı Başlangıçta söylediğim gibi, RFC 5322 uyumlu bir normal ifade oluşturma fikrini eğlenceli buldum, bu yüzden size standardın çeşitli yönleriyle başa çıkmak için düzenlenebilir normal ifade parçaları göstereceğim ve normal ifadenin bunu nasıl politikalarını açıklayacağım. Sonunda size her şeyin toplanmış halde nasıl göründüğünü göstereceğim. Bir e-posta adresinin yapısı şöyledir: Posta kutusu Yasal karakterler Tek noktalar (çift noktalar yasal değildir) Katlanmış Beyaz Alan (RFC 5322 çılgınlığı) (Tam bir normal ifade çözümü aynı zamanda dengeli parantez ve/veya tırnak işaretleri de içerir, ancak buna henüz sahip değilim. Ve büyük olasılıkla hiçbir zaman da sahip olmayacağım.) Sınırlayıcı (@) Alan adı Standart DNS ayrıştırılabilir alan adları IPv4 adres değişmezleri IPv6 adres değişmezleri IPv6-tam IPv6-comp (sıkıştırılmış için) 1. biçim (ortada 2+ 16 bitlik sıfır grupları) 2. biçim (başlangıçta 2+ 16 bitlik sıfır grupları) 3. form (sonunda 2 adet 16 bitlik sıfır grubu) 4. biçim (8 adet 16 bitlik sıfır grubu) IPv6v4-tam IPv6v4-comp (sıkıştırılmış) 1. form 2. biçim 3. biçim 4. form Şimdi regex'e geçelim. Posta kutusu ^(?<mailbox>(\[a-zA-Z0-9\\+\\!\\#\\$\\%\\&\\'\\\*\\-\\/\\=\\?\\+\\\_\\\{\\}\\|\\\~]|(?<singleDot>(?<!\\.)(?<!^)\\.(?!\\.))|(?<foldedWhiteSpace>\\s?\\&\\#13\\;\\&\\#10\\;.))\{1,64}) İlk olarak, dizenin başlangıcındaki ilk karakteri "sabitleyen" ye sahibiz. Bu, geçerli bir e-posta dışında hiçbir şey içermemesi gereken bir dizenin doğrulanması durumunda kullanılacaktır. İlk karakterin yasal olmasını sağlar. ^ Kullanım senaryosu bunun yerine daha uzun bir dizedeki bir e-postayı bulmaksa bağlantıyı çıkarın. Sonra, var. Bu, kolaylık olması açısından yakalama grubunu adlandırır. Yakalanan grubun içinde, sembolü ile ayrılmış üç normal ifade parçası bulunur; bu, bir karakterin, üç ifadeden herhangi biriyle eşleşebileceği anlamına gelir. (?<mailbox> alternatif eşleşme | İyi (performanslı ve öngörülebilir) normal ifade yazmanın bir kısmı, üç ifadenin birbirini dışladığından emin olmaktır. Yani, biriyle eşleşen bir alt dize, diğer ikisiyle kesinlikle eşleşmeyecektir. Bunu yapmak için, korkulan yerine belirli karakter sınıflarını kullanırız. .* Koşulsuz Yasal Karakterler [a-zA-Z0-9\+\!\#\$\%\&\'\*\-\/\=\?\+\_\{\}\|\~] İlk alternatif eşleşme, köşeli parantez içine alınmış bir karakter sınıfıdır ve nokta, "katlanmış beyaz boşluk", çift tırnak ve parantez bir e-posta posta kutusunda yasal olan tüm ASCII karakterlerini yakalar. dışında Bunları hariç tutmamızın nedeni, yalnızca yasal olmalarıdır; yani bunları nasıl kullanabileceğinize ilişkin doğrulanması gereken kurallar vardır. Önümüzdeki 2 alternatif maçta bunları halledeceğiz. şartlı olarak tek nokta (?<singleDot>(?<!\.)(?<!^)\.(?!\.)) Bu tür ilk kural nokta (nokta) ile ilgilidir. Bir posta kutusunda, noktaya yalnızca iki yasal karakter dizisi arasında ayırıcı olarak izin verilir, bu nedenle ardışık iki nokta yasal değildir. Ardışık iki nokta varsa eşleşmeyi önlemek için, bir sonraki karakterin (bir noktanın), kendisinden önce bir nokta varsa eşleşmeyeceğini belirten regex kullanırız. negatif geriye bakma (?<!\.) Regex görünümleri zincirlenebilir. Noktaya ulaşmadan önce, noktanın posta kutusunun ilk karakteri olamayacağı kuralını uygulayan başka bir olumsuz geriye bakış daha var. (?!^) Noktadan sonra negatif bir bakış_ahead_ vardır bir noktanın hemen ardından bir nokta geliyorsa eşleşmesini engeller. _(?!\.)_ ; bu, katlanmışWhiteSpace (?<foldedWhiteSpace>\s?\&\#13\;\&\#10\;.) Bu, iletilerde çok satırlı başlıklara izin verilmesiyle ilgili bazı RFC 5322 saçmalıklarıdır. E-posta adreslerinin tarihinde, çok satırlı bir posta kutusuyla ciddi bir adres oluşturan hiç kimsenin bulunmadığına bahse girmeye hazırım (bunu şaka olarak yapmış olabilirler). Ama ben 5322 oyununu oynuyorum, işte burada, alternatif bir eşleşme olarak oluşturan Unicode karakterleri dizisi. Katlanmış Beyaz Alanı Dengeli Çift Tırnak ve Parantez Her iki RFC de normalde yasa dışı olan karakterleri çevrelemenin (veya ) bir yolu olarak çift tırnak kullanımına izin verir. bunlardan kaçmanın Ayrıca, yorumların insanlar tarafından okunabilmesi için parantez içine alınmasına da izin verirler, ancak adres yorumlanırken posta aktarım aracısı (MTA) tarafından dikkate alınmazlar. Her iki durumda da karakterler yalnızca yasaldır. Bu, biri , diğeri bir çift karakterin olması gerektiği anlamına gelir. dengeliyse açılan kapanan Bir keşfettiğimi yazmak içimden geliyor, ancak bu muhtemelen yalnızca ölümden sonra işe yarar. Gerçek şu ki bu Vanilya regex'inde önemsiz değil. mucize gösterisi "Açgözlü" normal ifadenin özyinelemeli doğasından faydalanılabileceğine dair bir sezgim var, ancak önümüzdeki birkaç yıl boyunca bu soruna çözüm bulmak için gerekli zamanı ayırmam pek olası değil ve bu yüzden en iyi geleneğe göre, bunu bırakıyorum. okuyucu için bir alıştırma olarak. Posta Kutusu Uzunluğu {1,64} Aslında önemli bir posta kutusunun maksimum uzunluğudur: 64 karakter. olan Dolayısıyla, posta kutusu yakalama grubunu son bir kapanış paranteziyle kapattıktan sonra, alternatiflerimizden herhangi birini en az bir kez ve en fazla 64 kez eşleştirmemiz gerektiğini belirtmek için küme parantezleri arasında bir kullanırız. nicelik belirteci işaretini \s?(?<atSign>(?<!\-)(?<!\.)\@(?!\@)) Sınırlayıcı öbek çünkü göre sınırlayıcıdan hemen önce bir boşluk yasaldır ve ben sadece onların sözüne güveniyorum. özel durum \s? Futility'e Yakalama grubunun geri kalanı ile benzer bir modeli izler; önüne bir nokta veya çizgi gelirse veya hemen ardından başka bir gelirse eşleşmez. singleDot @ Alan adı Burada posta kutusunda olduğu gibi 3 alternatif maçımız var. Ve bunlardan sonuncusu, 4 alternatif maçı daha içine yerleştirdi. Standart DNS Ayrıştırılabilir (?<dns>[[:alnum:]]([[:alnum:]\-]{0,63}\.){1,24}[[:alnum:]\-]{1,63}[[:alnum:]]) Bu, ancak daha önce de belirtildiği gibi, son sözü söyleyen RFC 5321'e kesinlikle uygundur. Futility'deki testlerin birçoğunu geçmeyecektir, IPv4 (?<IPv4>\[((?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.){3}(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\]) Bu konuda söylenecek fazla bir şey yok. Bu, IPv4 adresleri için iyi bilinen ve kolayca kullanılabilen bir normal ifadedir. IPv6 (?<IPv6>(?<IPv6Full>(\[IPv6(\:[0-9a-fA-F]{1,4}){8}\]))|(?<IPv6Comp1>\[IPv6\:((([0-9a-fA-F]{1,4})\:){1,3}(\:([0-9a-fA-F]{1,4})){1,5}?\])|\[IPv6\:((([0-9a-fA-F]{1,4})\:){1,5}(\:([0-9a-fA-F]{1,4})){1,3}?\]))|(?<IPv6Comp2>(\[IPv6\:\:(\:[0-9a-fA-F]{1,4}){1,6}\]))|(?<IPv6Comp3>(\[IPv6\:([0-9a-fA-F]{1,4}\:){1,6}\:\]))|(?<IPv6Comp4>(\[IPv6\:\:\:)\])|(?<IPv6v4Full>(\[IPv6(\:[0-9a-fA-F]{1,4}){6}\:((?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.){3})(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\])|(?<IPv6v4Comp1>\[IPv6\:((([0-9a-fA-F]{1,4})\:){1,3}(\:([0-9a-fA-F]{1,4})){1,5}?(\:((?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.){3}(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?))\])|\[IPv6\:((([0-9a-fA-F]{1,4})\:){1,5}(\:([0-9a-fA-F]{1,4})){1,3}?(\:((?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.){3}(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?))\]))|(?<IPv6v4Comp2>(\[IPv6\:\:(\:[0-9a-fA-F]{1,4}){1,5}(\:((?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.){3}(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?))\]))|(?<IPv6v4Comp3>(\[IPv6\:([0-9a-fA-F]{1,4}\:){1,5}\:(((?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.){3}(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?))\]))|(?<IPv6v4Comp4>(\[IPv6\:\:\:((?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.){3})(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\])) IPv6 (ve IPv6v4) adresleri için iyi bir normal ifade bulamadım, bu yüzden RFC 5321'deki Backus/Naur notasyonlu kurallarını dikkatlice takip ederek kendi ifademi yazdım. IPv6 regex'inin her alt grubuna açıklama eklemeyeceğim, ancak her alt grubu birbirinden ayırmayı ve neler olduğunu görmeyi kolaylaştırmak için adlandırdım. IUPv6Comp1 yakalama grubunda "sol" taraftaki açgözlü eşleştirmeyi ve "sağ" taraftaki açgözlü olmayan eşleşmeyi birleştirme şeklim dışında gerçekten çok ilginç bir şey yok. Tam Monty Son regex'i Futility'den gelen test verileriyle birlikte kaydettim ve kendime ait bazı IPv6 test senaryolarıyla geliştirdim, . Umarım bu makale hoşunuza gitmiştir ve çoğunuz için yararlı ve zaman kazandırıcı olmuştur. Regex101'e AZW

Read the inside story of the failure of enterprise IT

Read My Stories

Bu ses hikayenin orijinal dilinde üretilmiştir!

Çok uzun; Okumak

Making security fun one episode at a time

E-posta Adresi İşleme için Regex'in Kullanışlılığı Hakkında

Çok uzun; Okumak

Adam Zachary Wasserman

About Author

ETİKETLERİ ASIN

Languages

BU YAZI...

E-posta Adresi İşleme için Regex'in Kullanışlılığı Hakkında

Çok uzun; Okumak

Adam Zachary Wasserman

About Author

ETİKETLERİ ASIN

Languages

BU YAZI...

İLGİLİ ÖYKÜLER