Angular.js: validator email salah

Dibuat pada 20 Jan 2014  ·  26Komentar  ·  Sumber: angular/angular.js

Jika Anda memasukkan alamat email:
saya @ .example.com

Dikatakan bahwa email tersebut valid ..

Periksa ini di URL ini (dari dokumen):

http://docs.angularjs.org/api/ng.directive : input.email

moderate bug

Komentar yang paling membantu

Anda dapat dengan cepat memperbaiki ini menggunakan ng-pattern

<input type="email" ng-pattern="/^[_a-z0-9]+(\.[_a-z0-9]+)*@[a-z0-9-]+(\.[a-z0-9-]+)*(\.[a-z]{2,4})$/">

Semua 26 komentar

Ya, Anda benar, sepertinya EMAIL_REGEX salah.

Menurut http://dev.w3.org/html5/markup/input.email.html , kita bisa menggunakan

/^[a-zA-Z0-9.!#$%&’*+/=?^_`{|}~-]+@[a-zA-Z0-9-]+(?:\.[a-zA-Z0-9-]+)*$/

dan sepertinya itu akan bekerja lebih baik karena tidak menyertakan . mengikuti @

Saya akan mencoba mengirimkan tambalan cepat untuk ini.

... sebenarnya, ini sedikit lebih rumit dari yang saya kira, ini mungkin membutuhkan sedikit usaha. Sepertinya itu juga akan menerima ekspresi reguler yang dimulai dengan titik juga. Jadi, saya rasa ada sedikit pekerjaan yang harus dilakukan di sini.

Jika Anda dapat menyelesaikan masalah ini sebelum saya, jangan ragu untuk mengirimkan permintaan penarikan

Terima kasih atas laporan bugnya. Pada demo dokumen, Anda tidak akan melihat perbaikan ini hingga 1.2.10 turun, karena itu memuat skrip sudut 1.2.9 sepanjang waktu. Tetapi dalam beberapa hari Anda akan melihat ini diatasi di demo dokumen (kecuali jika komit dikembalikan, yang bisa terjadi O_O)

Hebat, 10x!

Pada Rabu, 22 Jan 2014 pukul 5:32 pagi, Caitlin Potter [email protected] :

Terima kasih atas laporan bugnya. Di demo dokumen, Anda tidak akan melihat perbaikan ini
hingga 1.2.10 turun, karena ia memuat skrip sudut 1.2.9 sepanjang waktu.
Tetapi dalam beberapa hari Anda akan melihat ini dibahas di demo dokumen

-
Balas email ini secara langsung atau lihat di Gi tHubhttps: //github.com/angular/angular.js/issues/5899#issuecomment -32990587
.

Apa ekspresi wajah saya ketika saya melihat bahwa " dummy @ ferferfe " (tanpa domain apa pun) dianggap sebagai email yang valid;)

@ mica16 tapi dummy@ferferfe adalah alamat email yang valid. Domain tidak perlu memiliki ekstensi, pikirkan saja localhost .

@Zequez benar, tapi siapa sih yang menggunakan alamat localhost untuk pendaftaran situs web misalnya?

@ Gunakan
ng-pattern = "/ ^ [a-z0-9! # $% & '* + / =? ^ _` {|} ~ .-] + @ [a-z0-9 -] +. [a-z0 -9 -] / "
Tidak ideal tapi berhasil.

@mbeckenbach ya, benar. Tetapi pertimbangkan bahwa nama domain tanpa titik adalah domain yang valid. ICANN tidak mengizinkan Anda mendaftarkan domain dengan MEREKA, bukan berarti nama domain tersebut tidak valid.

6 @ 6 bukan sebuah alamat email. Fakta bahwa ini bisa menjadi alamat email yang tepat dalam keadaan khusus, menurut pendapat saya, seharusnya tidak membuat kita mengizinkannya. Kemungkinan kesalahan melalui pola permisif ini adalah lipat lebih besar daripada kemungkinan bahwa kami akan mengecualikan seseorang dengan alamat email seperti itu.

1 untuk Jeff

@jeffmcmahan Maaf, tetapi sepertinya Anda harus mengajukan masalah dengan IETF atau WHATWG. Setelah definisi alamat email berubah, maka itu harus diubah di Angular, tetapi kita benar-benar perlu mengikuti apa yang dijelaskan dalam rekomendasi RFC dan WHATWG.

Sekarang, jika Anda ingin sedikit lebih ketat, Anda juga bisa menambahkan validator pola, itu bagus.

@ Caitp Anda bosnya.

Bagaimana kalau EMAIL_REGEXP dapat dikonfigurasi? Validasi sisi server kami lebih ketat daripada yang angularjs. Secara khusus, ini mensyaratkan, misalnya, bagian sebelum tanda @ tidak lebih dari 63 karakter. Sekarang kita harus membuat arahan khusus untuk semua masukan email atau ingat untuk menambahkan pola-ng ke setiap masukan email.

Anda dapat menggunakan ng-pattern selain type = email, @rjokelai - juga, perubahan pipeline validasi @matsko akan memudahkan penambahan validasi email kustom

"Sekarang, jika Anda ingin sedikit lebih ketat, Anda juga bisa menambahkan validator pola, itu bagus."

bagaimana dengan validator default hanya menerima email normal dengan titik di dalamnya, dan jika seseorang dalam minoritas kecil ingin tidak terlalu ketat, mereka dapat membuat validatornya sendiri. Mengapa sebagian besar developer harus membuat pola mereka sendiri agar minoritas kecil tidak perlu melakukannya? Ini adalah standar purisme yang konyol

karena ini pada dasarnya adalah polyfill untuk validasi batasan html5, itulah alasannya. Minggu depan mudah-mudahan kami akan mengirimkan fitur yang akan mempermudah penyesuaian ini

Apakah email tanpa zona domain valid? Saya menguji kolom input sederhana dengan type = "email" dan Angular memvalidasi

Oh, sudah ada masalah tertutup - https://github.com/angular/angular.js/issues/9463

Apakah email tanpa zona domain valid? Saya menguji kolom input sederhana dengan type = "email" dan Angular memvalidasi email foo @ bar dengan sukses. (Angular v1.3.0)

Mereka adalah email yang valid, sesuai spesifikasi. Pertanyaan ini telah dijawab berkali-kali pada pelacak masalah ini, tidak ada yang tidak valid tentang email tanpa TLD.

Gunakan validator khusus untuk meminta TLD spesifik yang Anda inginkan

@caitp , saya menyadari kami telah mengganggu Anda tentang ini, tetapi saya pikir itu bisa membantu jika Anda menjelaskan mengapa menjaga spesifikasi itu penting. Kita semua menyadari bahwa pengembang yang masuk akal dan kompeten tidak akan menganggap bahwa validator email mengizinkan _0 @ 0_. Artinya, ini akan digunakan untuk situasi pendaftaran formulir standar, dan itu akan menyebabkan masalah dalam banyak situasi seperti itu. Dan kami diberi tahu bahwa pentingnya menjaga spesifikasi lebih besar daripada masalah itu. Oke --- keren. Tapi kenapa?

Karena akan sangat aneh ketika browser Anda mengatakan itu valid dan sudut mengatakan itu tidak valid

Anda tidak mencari validasi email, Anda mencari validasi pola di atas validasi email --- Anda ingin alamat email yang valid (ditangani oleh sudut) yang cocok dengan pola tertentu (berisi TLD)

  1. Akankah aneh jika Anda menambahkan validasi pola dan kemudian "browser Anda mengatakan itu valid dan [A] ngular mengatakan tidak"? Tidak. Jadi mengapa aneh jika validasi pola itu dibangun?
  2. Kami semua menyadari bahwa apa yang lolos untuk email yang valid dalam kasus penggunaan yang kami minati lebih sempit daripada spesifikasinya.

_Saya hanya ingin tahu mengapa Angular tidak melayani kasus penggunaan yang saya minati, karena ini kasus umum._

Jadi mengapa aneh jika validasi pola itu dibangun?

Sebenarnya, Anda mendapatkan perilaku yang sama dari browser. http://jsfiddle.net/t6rdmngo/ Jika Anda menjalankan ini di browser modern, Anda tidak akan dapat mengirimkan formulir teratas karena ketidakcocokan pola jika Anda tidak menyertakan TLD.

Dalam versi sudut, Anda mendapatkan perilaku yang sama. Ini bagus. Ini adalah apa yang kita inginkan. Perilaku identik antara perilaku asli dan perilaku kerangka kerja. Kerangka seharusnya tidak memiliki ketidaksepakatan dengan platform

Sekarang saya mengerti. Terima kasih telah bersabar dengan saya!

Anda dapat dengan cepat memperbaiki ini menggunakan ng-pattern

<input type="email" ng-pattern="/^[_a-z0-9]+(\.[_a-z0-9]+)*@[a-z0-9-]+(\.[a-z0-9-]+)*(\.[a-z]{2,4})$/">

Jika Anda mengubah * terakhir menjadi + di regex, ini berfungsi seperti yang diharapkan

http://w3c.github.io/html-reference/input.email.html

/^[a-zA-Z0-9.!#$%&'*+/=?^_`{]}~-]+@[a-zA-Z0-9-]+(?:.[a -zA-Z0-9 -] +) + $ /

Apakah halaman ini membantu?
0 / 5 - 0 peringkat