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

Bir meslektaşım kısa süre önce beni bir blog gönderisine yönlendirdi: E-posta Regex Doğrulamasının Boşluğu Üzerine . Kısaltmak adına bu yazıda bundan Boşunalık olarak bahsedeceğim.

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, Futility'nin pratik programcılar için yararlı bir rehber olmadığını kabul ediyorum.

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.

Futility'de atıfta bulunulan test paketi , 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.

Bu yanlıştır çünkü RFC 5321, e-posta adreslerinin alan adı bölümlerinin " 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ı" açıkça belirtir.

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ı bildirdi . 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.

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 e-posta alırken artı işaretini kabul edecektir.

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 [email protected] gibi bir dosya adının parçası mı?) inanılmaz derecede büyük bir zaman karmaşıklığı.

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, "[email protected]", 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 deposunda belgelediğim tüm çarpışmaların haritasını çıkarabildim.

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:

1. Posta kutusu
2. Yasal karakterler
3. Tek noktalar (çift noktalar yasal değildir)
4. Katlanmış Beyaz Alan (RFC 5322 çılgınlığı)
5. (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.)
6. Sınırlayıcı (@)
7. Alan adı
8. Standart DNS ayrıştırılabilir alan adları
9. IPv4 adres değişmezleri
10. IPv6 adres değişmezleri
11. IPv6-tam
12. IPv6-comp (sıkıştırılmış için)
13. 1. biçim (ortada 2+ 16 bitlik sıfır grupları)
14. 2. biçim (başlangıçta 2+ 16 bitlik sıfır grupları)
15. 3. form (sonunda 2 adet 16 bitlik sıfır grubu)
16. 4. biçim (8 adet 16 bitlik sıfır grubu)
17. IPv6v4-tam
18. IPv6v4-comp (sıkıştırılmış)
19. 1. form
20. 2. biçim
21. 3. biçim
22. 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, (?<mailbox> var. Bu, kolaylık olması açısından yakalama grubunu adlandırır. Yakalanan grubun içinde, alternatif eşleşme sembolü | ile ayrılmış üç normal ifade parçası bulunur; bu, bir karakterin, üç ifadeden herhangi biriyle eşleşebileceği anlamına gelir.

İ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 dışında bir e-posta posta kutusunda yasal olan tüm ASCII karakterlerini yakalar.

Bunları hariç tutmamızın nedeni, yalnızca şartlı olarak 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.

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 negatif geriye bakma (?<!\.) kullanırız.

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 ; bu, bir noktanın hemen ardından bir nokta geliyorsa eşleşmesini engeller.

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 Katlanmış Beyaz Alanı oluşturan Unicode karakterleri dizisi.

Dengeli Çift Tırnak ve Parantez

Her iki RFC de normalde yasa dışı olan karakterleri çevrelemenin (veya bunlardan kaçmanın ) bir yolu olarak çift tırnak kullanımına izin verir.

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 dengeliyse yasaldır. Bu, biri açılan , diğeri kapanan bir çift karakterin olması gerektiği anlamına gelir.

Bir mucize gösterisi 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.

"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 olan bir posta kutusunun maksimum uzunluğudur: 64 karakter.

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 nicelik belirteci kullanırız.

işaretini

\s?(?<atSign>(?<!\-)(?<!\.)\@(?!\@))

Sınırlayıcı öbek özel durum \s? çünkü Futility'e göre sınırlayıcıdan hemen önce bir boşluk yasaldır ve ben sadece onların sözüne güveniyorum.

Yakalama grubunun geri kalanı singleDot ile benzer bir modeli izler; önüne bir nokta veya çizgi gelirse veya hemen ardından başka bir @ gelirse eşleşmez.

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, Futility'deki testlerin birçoğunu geçmeyecektir, ancak daha önce de belirtildiği gibi, son sözü söyleyen RFC 5321'e kesinlikle uygundur.

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, Regex101'e . Umarım bu makale hoşunuza gitmiştir ve çoğunuz için yararlı ve zaman kazandırıcı olmuştur.

AZW