อนุญาตให้ใช้อักขระใดในที่อยู่อีเมล

ฉันไม่ได้ถามเกี่ยวกับการตรวจสอบอีเมลแบบเต็ม

ฉันแค่อยากรู้ว่าตัวละครที่ได้รับอนุญาตในuser-nameและserverบางส่วนของที่อยู่อีเมลคืออะไร นี่อาจเป็นเรื่องง่ายเกินไปบางทีที่อยู่อีเมลอาจมีรูปแบบอื่น แต่ฉันไม่สนใจ ฉันถามเกี่ยวกับรูปแบบง่าย ๆ นี้เท่านั้น: user-name@server(เช่น wild.wezyr@best-server-ever.com) และอักขระที่อนุญาตในทั้งสองส่วน

ดูRFC 5322: อินเทอร์เน็ตรูปแบบข้อความและในระดับที่น้อยกว่าRFC 5321: ธรรมดา Mail Transfer Protocol

RFC 822ยังครอบคลุมที่อยู่อีเมล แต่ส่วนใหญ่เกี่ยวข้องกับโครงสร้าง:

 addr-spec   =  local-part "@" domain        ; global address     
 local-part  =  word *("." word)             ; uninterpreted
                                             ; case-preserved

 domain      =  sub-domain *("." sub-domain)     
 sub-domain  =  domain-ref / domain-literal     
 domain-ref  =  atom                         ; symbolic reference

และตามปกติ Wikipedia มีบทความที่ดีเกี่ยวกับที่อยู่อีเมล :

ส่วนท้องถิ่นของที่อยู่อีเมลอาจใช้อักขระ ASCII ใด ๆ เหล่านี้:

• อักษรตัวพิมพ์ใหญ่และตัวพิมพ์เล็กละตินAไปZและaไปz;
• ตัวเลข0ถึง9;
• ตัวอักษรพิเศษ!#$%&'*+-/=?^_`{|}~;
• จุดที่.ระบุว่าไม่ใช่อักขระตัวแรกหรือตัวสุดท้ายเว้นแต่จะยกมาและให้ด้วยและจะไม่ปรากฏอย่างต่อเนื่องเว้นแต่จะยกมา (เช่นJohn..Doe@example.comไม่อนุญาต แต่"John..Doe"@example.comอนุญาต)
• "(),:;<>@[\]อนุญาตให้เว้นวรรคและอักขระได้ด้วยข้อ จำกัด (อนุญาตเฉพาะภายในสตริงที่ยกมาตามที่อธิบายไว้ในย่อหน้าด้านล่างและนอกจากนี้เครื่องหมายแบ็กสแลชหรือเครื่องหมายคำพูดคู่ต้องนำหน้าด้วยแบ็กสแลช)
• อนุญาตให้แสดงความคิดเห็นพร้อมวงเล็บที่ปลายด้านใดด้านหนึ่งของโลคัล เช่นjohn.smith(comment)@example.comและมีทั้งที่เทียบเท่ากับ(comment)john.smith@example.comjohn.smith@example.com

นอกเหนือไปจากอักขระ ASCII, เป็นของปี 2012คุณสามารถใช้ระหว่างประเทศตัวละครดังกล่าวข้างต้น U+007F , การเข้ารหัสเป็น UTF-8 ที่อธิบายไว้ในRFC 6532 ข้อมูลจำเพาะและอธิบายเกี่ยวกับวิกิพีเดีย โปรดทราบว่าในปี 2019 มาตรฐานเหล่านี้ยังคงถูกเสนอว่าเป็นข้อเสนอ แต่กำลังจะเปิดตัวช้า การเปลี่ยนแปลงในสเปคที่เพิ่มขึ้นนี้เป็นหลักอักขระสากลเป็นตัวอักษรและตัวเลขที่ถูกต้อง (aText) โดยไม่ส่งผลกระทบต่อกฎระเบียบเกี่ยวกับที่ได้รับอนุญาตและ จำกัด ตัวอักษรพิเศษเช่นและ!#@:

สำหรับการตรวจสอบดูการใช้นิพจน์ปกติในการตรวจสอบที่อยู่อีเมล

ชิ้นdomainส่วนถูกกำหนดดังนี้ :

มาตรฐานอินเทอร์เน็ต (ขอความคิดเห็น) สำหรับโปรโตคอลบังคับว่าฉลากชื่อโฮสต์ส่วนประกอบอาจมีเพียงตัวอักษร ASCII aผ่านz(ในกรณีที่ไม่คำนึงถึงตัวพิมพ์ใหญ่ - เล็ก) ตัวเลข0ผ่าน9และเครื่องหมายยัติภังค์ ( -) ข้อมูลจำเพาะดั้งเดิมของชื่อโฮสต์ในRFC 952ซึ่งได้รับคำสั่งว่าฉลากไม่สามารถเริ่มต้นด้วยตัวเลขหรือด้วยเครื่องหมายยัติภังค์และต้องไม่ลงท้ายด้วยเครื่องหมายขีดกลาง อย่างไรก็ตามข้อกำหนดที่ตามมา ( RFC 1123 ) อนุญาตให้ใช้ชื่อโฮสต์เพื่อเริ่มต้นด้วยตัวเลข ไม่อนุญาตให้ใช้สัญลักษณ์เครื่องหมายวรรคตอนหรือช่องว่างอื่น ๆ

ระวัง! มีความรู้มากมายในหัวข้อนี้ (สิ่งที่เคยเป็นจริงและตอนนี้ไม่ใช่)

เพื่อหลีกเลี่ยงการปฏิเสธที่อยู่อีเมลจริงในโลกปัจจุบันและอนาคตและจากที่ใดก็ได้ในโลกอย่างน้อยที่สุดคุณต้องรู้อย่างน้อยแนวคิดระดับสูงของRFC 3490 "Internationalizing Domain Names in Applications (IDNA)" ฉันรู้ว่าคนในสหรัฐอเมริกาและ A มักจะไม่ได้รับสิ่งนี้ แต่มันก็มีการใช้กันอย่างแพร่หลายและเพิ่มขึ้นอย่างรวดเร็วทั่วโลก (ส่วนใหญ่เป็นส่วนที่ไม่ใช่ภาษาอังกฤษ)

ส่วนสำคัญคือตอนนี้คุณสามารถใช้ที่อยู่เช่น mason @ 日本 .com และwildwezyr@fahrvergnügen.netได้แล้ว ไม่สิ่งนี้ยังไม่สามารถใช้งานได้กับทุกสิ่ง (มีหลายคนที่ยังไม่ได้กล่าวถึงแม้แต่ที่อยู่ qmail-style + ident ที่เรียบง่ายมักถูกปฏิเสธอย่างผิดพลาด) แต่มี RFC มีสเป็คตอนนี้ได้รับการสนับสนุนโดย IETF และ ICANN และที่สำคัญกว่านั้นมีการใช้งานจำนวนมากและมีจำนวนเพิ่มขึ้นเรื่อย ๆ ซึ่งสนับสนุนการปรับปรุงนี้ที่ให้บริการในปัจจุบัน

ฉันไม่รู้เกี่ยวกับการพัฒนานี้มากนักจนกระทั่งฉันย้ายกลับมาที่ญี่ปุ่นและเริ่มเห็นที่อยู่อีเมลเช่น hei @ やる .ca และ URL ของ Amazon เช่นนี้:

http://www.amazon.co.jp/ エレクトロニクス - デジタルカメラ? - ポータブルオーディオ / b / โทษ = topnav_storetab_e เช่น = UTF8 & โหนด = 3210981

ฉันรู้ว่าคุณไม่ต้องการลิงก์ไปยังข้อมูลจำเพาะ แต่ถ้าคุณพึ่งพาความรู้ที่ล้าสมัยของแฮกเกอร์ในฟอรัมอินเทอร์เน็ตตัวตรวจสอบอีเมลของคุณจะสิ้นสุดการปฏิเสธที่อยู่อีเมลที่ผู้ใช้ที่ไม่ใช้ภาษาอังกฤษคาดหวังมากขึ้น สำหรับผู้ใช้เหล่านั้นการตรวจสอบดังกล่าวจะน่ารำคาญเหมือนกับรูปแบบธรรมดา ๆ ที่คนเราไม่ชอบส่วนที่ไม่สามารถจัดการ + หรือชื่อโดเมนสามส่วนหรืออะไรก็ตาม

ดังนั้นฉันไม่ได้บอกว่ามันไม่ใช่เรื่องยุ่งยาก แต่รายการตัวอักษรทั้งหมด "อนุญาตภายใต้เงื่อนไขบาง / ไม่มี /" คือ (เกือบ) ตัวละครทั้งหมดในทุกภาษา หากคุณต้องการที่จะ "ยอมรับที่อยู่อีเมลที่ถูกต้องทั้งหมด (และไม่ถูกต้องมากเกินไป)" แล้วคุณจะต้องใช้เวลา IDN เข้าบัญชีซึ่งโดยทั่วไปจะทำให้วิธีการที่ตัวอักษรตามที่ไร้ประโยชน์ (ขออภัย) เว้นแต่คุณแรกแปลงที่อยู่อีเมลสากลเพื่อpunycode

หลังจากทำเช่นนั้นคุณสามารถทำตามคำแนะนำด้านบน

รูปแบบของที่อยู่อีเมลคือ: local-part@domain-part(สูงสุด 64 @ 255 อักขระรวมไม่เกิน 256)

local-partและdomain-partอาจมีการตั้งค่าที่แตกต่างกันของตัวละครที่ได้รับอนุญาต แต่ที่ไม่ได้ทั้งหมดที่มีกฎระเบียบมากขึ้นไป

โดยทั่วไปส่วนในท้องถิ่นสามารถมีอักขระ ASCII เหล่านี้:

• อักษรละตินตัวพิมพ์เล็ก: abcdefghijklmnopqrstuvwxyz,
• ตัวอักษรละตินตัวพิมพ์ใหญ่: ABCDEFGHIJKLMNOPQRSTUVWXYZ,
• ตัวเลข: 0123456789,
• ตัวอักษรพิเศษ: !#$%&'*+-/=?^_`{|}~,
• จุด: .(ไม่ใช่อักขระตัวแรกหรือตัวอักษรสุดท้ายหรือทำซ้ำเว้นแต่จะยกมา)
• เครื่องหมายวรรคตอนพื้นที่เช่น: "(),:;<>@[\](มีข้อ จำกัด บางอย่าง),
• ความคิดเห็น: ()(ได้รับอนุญาตภายในวงเล็บเช่น(comment)john.smith@example.com)

ส่วนโดเมน:

• อักษรละตินตัวพิมพ์เล็ก: abcdefghijklmnopqrstuvwxyz,
• ตัวอักษรละตินตัวพิมพ์ใหญ่: ABCDEFGHIJKLMNOPQRSTUVWXYZ,
• ตัวเลข: 0123456789,
• ยัติภังค์: -(ไม่ใช่อักขระตัวแรกหรือตัวสุดท้าย)
• สามารถมีที่อยู่ IP ล้อมรอบด้วยวงเล็บ: หรือjsmith@[192.168.2.1]jsmith@[IPv6:2001:db8::1]

ที่อยู่อีเมลเหล่านี้ถูกต้อง:

• prettyandsimple@example.com
• very.common@example.com
• disposable.style.email.with+symbol@example.com
• other.email-with-dash@example.com
• x@example.com (ส่วนหนึ่งตัวอักษรท้องถิ่น)
• "much.more unusual"@example.com
• "very.unusual.@.unusual.com"@example.com
• "very.(),:;<>[]\".VERY.\"very@\ \"very\".unusual"@strange.example.com
• example-indeed@strange-example.com
• admin@mailserver1 (ชื่อโดเมนท้องถิ่นที่ไม่มีโดเมนระดับบนสุด)
• #!$%&'*+-/=?^_`{}|~@example.org
• "()<>[]:,;@\\"!#$%&'-/=?^_`{}| ~.a"@example.org
• " "@example.org (ช่องว่างระหว่างคำพูด)
• example@localhost (ส่งจาก localhost)
• example@s.solutions(ดูรายการโดเมนระดับบนสุดของอินเทอร์เน็ต )
• user@com
• user@localserver
• user@[IPv6:2001:db8::1]

และตัวอย่างที่ไม่ถูกต้องเหล่านี้:

• Abc.example.com(ไม่มี@ตัวอักษร)
• A@b@c@example.com( @อนุญาตเพียงหนึ่งอันนอกเครื่องหมายคำพูด)
• a"b(c)d,e:f;gi[j\k]l@example.com (ไม่อนุญาตให้ใช้อักขระพิเศษในส่วนท้องถิ่นนี้นอกเครื่องหมายคำพูด)
• just"not"right@example.com (สตริงที่ยกมาจะต้องเป็นจุดแยกหรือองค์ประกอบเดียวประกอบส่วนท้องถิ่น)
• this is"not\allowed@example.com (ช่องว่างเครื่องหมายคำพูดและแบ็กสแลชอาจมีอยู่เมื่อภายในสตริงที่ยกมาและนำหน้าด้วยแบ็กสแลชเท่านั้น)
• this\ still\"not\allowed@example.com (แม้ว่าจะหลบหนี (นำหน้าด้วยแบ็กสแลช), ช่องว่าง, เครื่องหมายคำพูดและแบ็กสแลชจะต้องอยู่ในเครื่องหมายคำพูด)
• john..doe@example.com(จุดคู่ก่อนหน้า@); (มีข้อแม้: Gmail ให้สิ่งนี้ผ่าน)
• john.doe@example..com(จุดสองจุดหลังจาก@)
• ที่อยู่ที่ถูกต้องพร้อมช่องว่างนำหน้า
• ที่อยู่ที่ถูกต้องพร้อมช่องว่างต่อท้าย

ที่มา: ที่อยู่อีเมลที่ Wikipedia

Perl's RFC2822 regexสำหรับการตรวจสอบอีเมล:

(?:(?:\r\n)?[ \t])*(?:(?:(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t]
)+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:
\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(
?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ 
\t]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\0
31]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\
](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+
(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:
(?:\r\n)?[ \t])*))*|(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z
|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)
?[ \t])*)*\<(?:(?:\r\n)?[ \t])*(?:@(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\
r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[
 \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)
?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t]
)*))*(?:,@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[
 \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*
)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t]
)+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*)
*:(?:(?:\r\n)?[ \t])*)?(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+
|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r
\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:
\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t
]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031
]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](
?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?
:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?
:\r\n)?[ \t])*))*\>(?:(?:\r\n)?[ \t])*)|(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?
:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?
[ \t]))*"(?:(?:\r\n)?[ \t])*)*:(?:(?:\r\n)?[ \t])*(?:(?:(?:[^()<>@,;:\\".\[\] 
\000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|
\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>
@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"
(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t]
)*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\
".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?
:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[
\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*|(?:[^()<>@,;:\\".\[\] \000-
\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(
?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)*\<(?:(?:\r\n)?[ \t])*(?:@(?:[^()<>@,;
:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([
^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\"
.\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\
]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*(?:,@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\
[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\
r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] 
\000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]
|\\.)*\](?:(?:\r\n)?[ \t])*))*)*:(?:(?:\r\n)?[ \t])*)?(?:[^()<>@,;:\\".\[\] \0
00-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\
.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,
;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?
:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t])*
(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".
\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[
^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]
]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*\>(?:(?:\r\n)?[ \t])*)(?:,\s*(
?:(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\
".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:(
?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[
\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t
])*))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t
])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?
:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|
\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*|(?:
[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\
]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)*\<(?:(?:\r\n)
?[ \t])*(?:@(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["
()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)
?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>
@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*(?:,@(?:(?:\r\n)?[
 \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,
;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t]
)*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\
".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*)*:(?:(?:\r\n)?[ \t])*)?
(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".
\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:(?:
\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\[
"()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])
*))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])
+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\
.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z
|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*\>(?:(
?:\r\n)?[ \t])*))*)?;\s*)

regexp แบบเต็มสำหรับที่อยู่ RFC2822 เป็นเพียง 3.7k

ดูเพิ่มเติม: RFC 822 อีเมล์ Parser อยู่ใน PHP

คำจำกัดความที่เป็นทางการของที่อยู่อีเมลมีดังนี้:

• RFC 5322 (ส่วน 3.2.3 และ 3.4.1, ล้าสมัย RFC 2822), RFC 5321, RFC 3696,
• RFC 6531 (อักขระที่อนุญาต)

ที่เกี่ยวข้อง:

• พลังที่แท้จริงของการแสดงออกปกติ

วิกิพีเดียมีบทความที่ดีเกี่ยวกับเรื่องนี้และข้อมูลจำเพาะอย่างเป็นทางการอยู่ที่นี่ จาก Wikipdia:

ส่วนท้องถิ่นของที่อยู่อีเมลอาจใช้อักขระ ASCII ใด ๆ เหล่านี้:

• ตัวอักษรภาษาอังกฤษตัวพิมพ์ใหญ่และตัวพิมพ์เล็ก (az, AZ)
• ตัวเลข 0 ถึง 9
• ตัวละคร! # $% & '* + - / =? ^ _ `{| } ~
• ตัวละคร (dot, period, full stop) โดยมีเงื่อนไขว่าไม่ใช่อักขระตัวแรกหรือตัวสุดท้ายและระบุด้วยว่าจะไม่ปรากฏอย่างน้อยสองครั้งติดต่อกัน

นอกจากนี้อนุญาตให้อ้างถึงสตริง (เช่น: "John Doe" @ example.com) ได้ดังนั้นจึงอนุญาตให้ใช้อักขระที่ห้ามมิฉะนั้นจะไม่ปรากฏในทางปฏิบัติทั่วไป RFC 5321 ยังเตือนว่า "โฮสต์ที่คาดว่าจะได้รับจดหมาย SHOULD หลีกเลี่ยงการกำหนดกล่องจดหมายที่ Local-part ต้องการ (หรือใช้) ฟอร์ม Quoted-string

Google ทำสิ่งที่น่าสนใจด้วยที่อยู่ gmail.com ที่อยู่ gmail.com อนุญาตเฉพาะตัวอักษร (az) ตัวเลขและจุด (ซึ่งถูกละเว้น)

เช่น pikachu@gmail.com เหมือนกับ pi.kachu@gmail.com และที่อยู่อีเมลทั้งสองจะถูกส่งไปยังกล่องจดหมายเดียวกัน PIKACHU@gmail.com จะถูกส่งไปยังกล่องจดหมายเดียวกัน

ดังนั้นในการตอบคำถามบางครั้งมันขึ้นอยู่กับผู้ดำเนินการตามจำนวน RFC มาตรฐานที่พวกเขาต้องการติดตาม รูปแบบที่อยู่ gmail.com ของ Google นั้นเข้ากันได้กับมาตรฐาน พวกเขาทำเช่นนั้นเพื่อหลีกเลี่ยงความสับสนว่าคนอื่นจะใช้ที่อยู่อีเมลที่คล้ายกันเช่น

*** gmail.com accepting rules ***
d.oy.smith@gmail.com   (accepted)
d_oy_smith@gmail.com   (bounce and account can never be created)
doysmith@gmail.com     (accepted)
D.Oy'Smith@gmail.com   (bounce and account can never be created)

ลิงค์วิกิพีเดียเป็นข้อมูลอ้างอิงที่ดีเกี่ยวกับที่อยู่อีเมลที่อนุญาตโดยทั่วไป http://en.wikipedia.org/wiki/Email_address

คุณสามารถเริ่มต้นจากบทความวิกิพีเดีย :

• ตัวอักษรภาษาอังกฤษตัวพิมพ์ใหญ่และตัวพิมพ์เล็ก (az, AZ)
• ตัวเลข 0 ถึง 9
• ตัวละคร! # $% & '* + - / =? ^ _ `{| } ~
• ตัวละคร (dot, period, full stop) โดยมีเงื่อนไขว่าไม่ใช่อักขระตัวแรกหรือตัวสุดท้ายและระบุด้วยว่าจะไม่ปรากฏอย่างน้อยสองครั้งติดต่อกัน

ชื่อ:

abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789!#$%&'*+-/=?^_`{|}~.

เซิร์ฟเวอร์:

abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789-.

ตรวจสอบ @ และ จากนั้นส่งอีเมลเพื่อให้พวกเขายืนยัน

ฉันยังคงไม่สามารถใช้ที่อยู่อีเมล. name ของฉันใน 20% ของเว็บไซต์บนอินเทอร์เน็ตได้เพราะมีคนทำให้การยืนยันอีเมลของพวกเขาหมดไป

คำตอบสั้น ๆ คือมี 2 คำตอบ มีมาตรฐานเดียวสำหรับสิ่งที่คุณควรทำ พฤติกรรมที่ฉลาดและจะทำให้คุณหมดปัญหา มีอีกมาตรฐานหนึ่ง (กว้างกว่ามาก) สำหรับพฤติกรรมที่คุณควรยอมรับโดยไม่มีปัญหา ความเป็นคู่นี้ใช้สำหรับการส่งและรับอีเมล แต่มีแอปพลิเคชันในวงกว้างในชีวิต

สำหรับคำแนะนำที่ดีเกี่ยวกับที่อยู่ที่คุณสร้าง ดู: http://www.remote.org/jochen/mail/info/chars.html

หากต้องการกรองอีเมลที่ถูกต้องเพียงส่งผ่านสิ่งที่เข้าใจได้มากพอที่จะดูขั้นตอนต่อไป หรือเริ่มอ่าน RFC จำนวนมากอย่างระมัดระวังนี่คือมังกร

ดีอ่านบนเรื่อง

ข้อความที่ตัดตอนมา:

These are all valid email addresses!

"Abc\@def"@example.com
"Fred Bloggs"@example.com
"Joe\\Blow"@example.com
"Abc@def"@example.com
customer/department=shipping@example.com
\$A12345@example.com
!def!xyz%abc@example.com
_somename@example.com

คำตอบที่ได้รับการยอมรับหมายถึงบทความ Wikipedia เมื่อพูดถึงส่วนที่ถูกต้องในท้องถิ่นของที่อยู่อีเมล แต่ Wikipedia ไม่ได้เป็นผู้มีอำนาจในเรื่องนี้

IETF RFC 3696 เป็นหน่วยงานที่มีอำนาจในเรื่องนี้และควรได้รับการพิจารณาในส่วนที่3 ข้อ จำกัด เกี่ยวกับที่อยู่อีเมลในหน้า 5:

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

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

กฎที่แน่นอนคืออักขระ ASCII ใด ๆ รวมถึงอักขระควบคุมอาจปรากฏในเครื่องหมายคำพูดหรือในสตริงที่ยกมา เมื่อต้องการอ้างข้อความอักขระเครื่องหมายทับขวาจะถูกใช้เพื่ออ้างอิงอักขระต่อไปนี้ ตัวอย่างเช่น

  Abc\@def@example.com

เป็นรูปแบบที่ถูกต้องของที่อยู่อีเมล ช่องว่างอาจปรากฏขึ้นเช่นใน

  Fred\ Bloggs@example.com

อักขระแบ็กสแลชอาจถูกใช้เพื่ออ้างอิงตัวเองเช่น

  Joe.\\Blow@example.com

นอกเหนือจากการอ้างอิงโดยใช้อักขระเครื่องหมายแบ็กสแลชอักขระเครื่องหมายคำพูดคู่ทั่วไปอาจถูกใช้เพื่อล้อมรอบสตริง ตัวอย่างเช่น

  "Abc@def"@example.com

  "Fred Bloggs"@example.com

เป็นรูปแบบสำรองของสองตัวอย่างแรกด้านบน แบบฟอร์มที่ยกมาเหล่านี้ไม่ค่อยได้รับการแนะนำและเป็นเรื่องแปลกในทางปฏิบัติ แต่ตามที่กล่าวไว้ข้างต้นจะต้องได้รับการสนับสนุนโดยแอปพลิเคชันที่กำลังประมวลผลที่อยู่อีเมล โดยเฉพาะอย่างยิ่งรูปแบบที่ยกมามักจะปรากฏในบริบทของที่อยู่ที่เกี่ยวข้องกับการเปลี่ยนจากระบบและบริบทอื่น ๆ ; ข้อกำหนดเฉพาะกาลเหล่านั้นยังคงเกิดขึ้นและเนื่องจากระบบที่ยอมรับที่อยู่อีเมลที่ผู้ใช้ระบุไม่สามารถ "รู้" ว่าที่อยู่นั้นเชื่อมโยงกับระบบดั้งเดิมหรือไม่จึงต้องยอมรับและส่งแบบฟอร์มที่อยู่ในสภาพแวดล้อมอีเมล

ชิ้นส่วนท้องถิ่นอาจประกอบด้วย
ตัวอักษรผสมตัวเลขหรืออักขระพิเศษใด ๆ

  ! # $ % & ' * + - / = ?  ^ _ ` . { | } ~

period (".") อาจปรากฏขึ้นเช่นกัน แต่ไม่สามารถใช้เพื่อเริ่มต้นหรือสิ้นสุดส่วนในท้องถิ่นและอาจไม่ปรากฏจุดต่อเนื่องสองช่วงขึ้นไป ระบุไว้อย่างชัดเจนอักขระ ASCII กราฟิก (การพิมพ์) อื่นที่ไม่ใช่เครื่องหมาย ("@") เครื่องหมายแบ็กสแลชเครื่องหมายคำพูดคู่เครื่องหมายจุลภาคหรือวงเล็บเหลี่ยมอาจปรากฏขึ้นโดยไม่มีการอ้างอิง หากรายการใด ๆ ของอักขระที่แยกออกมานั้นปรากฏขึ้นพวกเขาจะต้องเสนอราคา แบบฟอร์มเช่น

  user+mailbox@example.com

  customer/department=shipping@example.com

  $A12345@example.com

  !def!xyz%abc@example.com

  _somename@example.com

มีความถูกต้องและเห็นได้อย่างสม่ำเสมอ แต่ตัวอักษรที่ปรากฏด้านบนได้รับอนุญาต

ตามที่คนอื่นทำฉันส่ง regex ที่ใช้งานได้ทั้ง PHP และ JavaScript เพื่อตรวจสอบที่อยู่อีเมล:

/^[a-z0-9!'#$%&*+\/=?^_`{|}~-]+(?:\.[a-z0-9!'#$%&*+\/=?^_`{|}~-]+)*@(?:[a-z0-9](?:[a-z0-9-]*[a-z0-9])?\.)+[a-zA-Z]{2,}$/i

สามารถพบได้ในลิงค์ Wikipedia นี้

ส่วนท้องถิ่นของที่อยู่อีเมลอาจใช้อักขระ ASCII ใด ๆ เหล่านี้:

• อักษรตัวพิมพ์ใหญ่และตัวพิมพ์เล็กละตินAไปZและaไปz;

• ตัวเลข0ถึง9;

• ตัวอักษรพิเศษ!#$%&'*+-/=?^_`{|}~;

• จุดที่.ระบุว่าไม่ใช่อักขระตัวแรกหรือตัวสุดท้ายเว้นแต่จะยกมาและให้ด้วยและจะไม่ปรากฏอย่างต่อเนื่องเว้นแต่จะยกมา (เช่นJohn..Doe@example.comไม่อนุญาต แต่"John..Doe"@example.comอนุญาต)

• "(),:;<>@[\]อนุญาตให้เว้นวรรคและอักขระได้ด้วยข้อ จำกัด (อนุญาตเฉพาะภายในสตริงที่ยกมาตามที่อธิบายไว้ในย่อหน้าด้านล่างและนอกจากนี้เครื่องหมายแบ็กสแลชหรือเครื่องหมายคำพูดคู่ต้องนำหน้าด้วยแบ็กสแลช)

• อนุญาตให้แสดงความคิดเห็นพร้อมวงเล็บที่ปลายด้านใดด้านหนึ่งของโลคัล เช่นjohn.smith(comment)@example.comและมีทั้งที่เทียบเท่ากับ(comment)john.smith@example.comjohn.smith@example.com

นอกเหนือจากอักขระ ASCII ข้างต้นอักขระสากลที่อยู่เหนือ U + 007F ซึ่งเข้ารหัสเป็น UTF-8 ได้รับอนุญาตจากRFC 6531แม้ว่าระบบอีเมลอาจ จำกัด อักขระที่จะใช้เมื่อกำหนดส่วนภายใน

สตริงที่ยกมาอาจมีอยู่เป็นนิติบุคคลที่คั่นด้วยจุดภายในส่วนท้องถิ่นหรือมันอาจมีอยู่เมื่ออัญประกาศนอกสุดเป็นตัวละครนอกสุดของส่วนท้องถิ่น (เช่นabc."defghi".xyz@example.comหรือ"abcdefghixyz"@example.comได้รับอนุญาตในทางกลับกันabc"defghi"xyz@example.comไม่ได้; ไม่เป็นabc\"def\"ghi@example.com) สตริงและอักขระที่อ้างถึงอย่างไรก็ตามไม่ได้ใช้กันโดยทั่วไป RFC 5321ยังเตือนว่า "โฮสต์ที่คาดว่าจะได้รับจดหมาย SHOULD หลีกเลี่ยงการกำหนดกล่องจดหมายที่ Local-part ต้องการ (หรือใช้) ฟอร์ม Quoted-string ที่อ้างถึง

ส่วนในพื้นที่postmasterได้รับการปฏิบัติเป็นพิเศษโดยไม่คำนึงถึงตัวพิมพ์เล็กและใหญ่และควรส่งต่อไปยังผู้ดูแลระบบอีเมลของโดเมน ในทางเทคนิคทุกชิ้นส่วนในประเทศอื่น ๆ เป็นกรณี ๆ ดังนั้นjsmith@example.comและ JSmith@example.comระบุกล่องจดหมายที่แตกต่างกัน อย่างไรก็ตามหลายองค์กรปฏิบัติต่อตัวอักษรตัวพิมพ์ใหญ่และตัวพิมพ์เล็กเท่ากัน

แม้จะมีความหลากหลายของตัวละครพิเศษที่ใช้ได้จริงในทางเทคนิค องค์กร, บริการอีเมล, เซิร์ฟเวอร์อีเมลและไคลเอนต์ในทางปฏิบัติมักจะไม่ยอมรับพวกเขาทั้งหมด ตัวอย่างเช่น Windows Live Hotmail อนุญาตเฉพาะการสร้างที่อยู่อีเมลโดยใช้ตัวอักษรและตัวเลขจุด ( .), ขีดล่าง ( _) และยัติภังค์ ( -) คำแนะนำทั่วไปคือการหลีกเลี่ยงการใช้อักขระพิเศษเพื่อหลีกเลี่ยงความเสี่ยงของอีเมลที่ถูกปฏิเสธ

คำตอบคือ (เกือบ) ALL(ASCII 7 บิต)
หากกฎการรวมเป็น "... อนุญาตภายใต้เงื่อนไขบาง / ไม่มี / ... "

เพียงแค่ดูกฎการรวมที่เป็นไปได้หลายข้อสำหรับข้อความที่ได้รับอนุญาตในส่วน "ข้อความโดเมน" ในRFC 5322ที่ด้านบนของหน้า 17 เราพบ:

dtext          =   %d33-90 /          ; Printable US-ASCII
                   %d94-126 /         ;  characters not including
                   obs-dtext          ;  "[", "]", or "\"

ตัวอักษรที่ขาดหายไปเพียงสามตัวในคำอธิบายนี้ใช้ในโดเมนตัวอักษร[]เพื่อสร้างคู่ที่ยกมา\และตัวอักษรช่องว่าง(% d32) เมื่อใช้ช่วงทั้ง 32-126 (ทศนิยม) ข้อกำหนดที่คล้ายกันปรากฏเป็น "qtext" และ "ctext" อนุญาตให้ใช้อักขระควบคุมจำนวนมาก / หนึ่งรายการของตัวควบคุมดังกล่าวจะปรากฏในหน้า 31 ส่วน 4.1 ของ RFC 5322เป็น obs-NO-WS-CTL

obs-NO-WS-CTL  =   %d1-8 /            ; US-ASCII control
                   %d11 /             ;  characters that do not
                   %d12 /             ;  include the carriage
                   %d14-31 /          ;  return, line feed, and
                   %d127              ;  white space characters

อนุญาตให้ใช้อักขระควบคุมทั้งหมดตามที่ระบุไว้ในตอนต้นของส่วน 3.5:

.... MAY be used, the use of US-ASCII control characters (values
     1 through 8, 11, 12, and 14 through 31) is discouraged ....

และกฎการรวมดังกล่าวจึง "กว้างเกินไป" หรืออีกนัยหนึ่งกฎที่คาดไว้คือ "ง่ายเกินไป"

เพื่อประโยชน์ของความเรียบง่ายฉันฆ่าเชื้อการส่งโดยการลบข้อความทั้งหมดภายในเครื่องหมายคำพูดคู่และคำพูดรอบข้างที่เกี่ยวข้องก่อนการตรวจสอบวาง kibosh ในการส่งที่อยู่อีเมลตามสิ่งที่ไม่ได้รับอนุญาต เพียงเพราะใครบางคนสามารถมีจอห์น .. "ที่อยู่ * $ hizzle * Bizzle" .. ที่อยู่ Doe@whething.com ไม่ได้หมายความว่าฉันจะต้องอนุญาตในระบบของฉัน เรากำลังอยู่ในอนาคตซึ่งอาจใช้เวลาน้อยกว่าในการได้รับที่อยู่อีเมลฟรีกว่าที่จะทำความสะอาดก้นของคุณ และมันก็ไม่เหมือนกับว่าเกณฑ์อีเมลไม่ได้ถูกฉาบไว้ข้างๆอินพุตที่ระบุว่าอะไรคืออะไรและไม่ได้รับอนุญาต

ฉันยังทำให้บริสุทธิ์สิ่งที่ไม่ได้รับอนุญาตโดยเฉพาะจาก RFCs ต่าง ๆ หลังจากลบเนื้อหาที่ยกมา รายการอักขระและรูปแบบที่ไม่อนุญาตเป็นพิเศษนั้นเป็นรายการที่สั้นกว่ามากสำหรับการทดสอบ

ไม่อนุญาตให้ใช้:

    local part starts with a period ( .account@host.com )
    local part ends with a period   ( account.@host.com )
    two or more periods in series   ( lots..of...dots@host.com )
    &’`*|/                          ( some&thing`bad@host.com )
    more than one @                 ( which@one@host.com )
    :%                              ( mo:characters%mo:problems@host.com )

ในตัวอย่างที่กำหนด:

John.."The*$hizzle*Bizzle"..Doe@whatever.com --> John..Doe@whatever.com

John..Doe@whatever.com --> John.Doe@whatever.com

การส่งข้อความอีเมลยืนยันไปยังผลลัพธ์ที่เหลือเมื่อพยายามเพิ่มหรือเปลี่ยนที่อยู่อีเมลเป็นวิธีที่ดีในการดูว่ารหัสของคุณสามารถจัดการกับที่อยู่อีเมลที่ส่ง หากอีเมลผ่านการตรวจสอบความถูกต้องหลังจากผ่านการฆ่าเชื้อเป็นจำนวนมากตามที่ต้องการแล้วให้ปิดการยืนยันนั้น หากคำขอกลับมาจากลิงก์การยืนยันอีเมลใหม่สามารถย้ายจากสถานะการถือครอง || ชั่วคราว | | สถานะชำระล้างหรือการจัดเก็บเพื่อให้กลายเป็นอีเมลที่ถูกเก็บไว้อย่างแท้จริงชั้นเฟิสต์คลาส

การแจ้งเตือนการเปลี่ยนที่อยู่อีเมลล้มเหลวหรือสำเร็จสามารถส่งไปยังที่อยู่อีเมลเก่าได้หากคุณต้องการพิจารณา การตั้งค่าบัญชีที่ไม่ได้รับการยืนยันอาจหลุดออกจากระบบเนื่องจากความพยายามที่ล้มเหลวทั้งหมดหลังจากระยะเวลาที่เหมาะสม

ฉันไม่อนุญาตอีเมลที่มีกลิ่นเหม็นในระบบของฉันบางทีนั่นอาจเป็นเพียงการทิ้งเงิน แต่ 99.9% ของเวลาที่ผู้คนทำสิ่งที่ถูกต้องและมีอีเมลที่ไม่ส่งข้อ จำกัด ตามข้อกำหนดไปที่ขอบใช้สถานการณ์ความเข้ากันได้ของกรณีขอบ ระวัง regex DDoS นี่คือสถานที่ที่คุณจะมีปัญหา และสิ่งนี้เกี่ยวข้องกับสิ่งที่สามที่ฉันทำฉันกำหนดขีด จำกัด ว่าฉันยินดีดำเนินการอีเมลฉบับใดนานแค่ไหน หากจำเป็นต้องทำให้เครื่องของฉันทำงานช้าลงเพื่อให้ได้รับการตรวจสอบ - จะไม่ผ่านตรรกะจุดสิ้นสุด API ข้อมูลขาเข้าของฉัน

แก้ไข: คำตอบนี้ยังคงเป็นเพราะ "ไม่ดี" และอาจสมควรได้รับ อาจจะยังคงไม่ดีอาจจะไม่

ใน PHP ของฉันฉันใช้เช็คนี้

<?php
if (preg_match(
'/^(?:[\w\!\#\$\%\&\'\*\+\-\/\=\?\^\`\{\|\}\~]+\.)*[\w\!\#\$\%\&\'\*\+\-\/\=\?\^\`\{\|\}\~]+@(?:(?:(?:[a-zA-Z0-9_](?:[a-zA-Z0-9_\-](?!\.)){0,61}[a-zA-Z0-9_-]?\.)+[a-zA-Z0-9_](?:[a-zA-Z0-9_\-](?!$)){0,61}[a-zA-Z0-9_]?)|(?:\[(?:(?:[01]?\d{1,2}|2[0-4]\d|25[0-5])\.){3}(?:[01]?\d{1,2}|2[0-4]\d|25[0-5])\]))$/',
"tim'qqq@gmail.com"        
)){
    echo "legit email";
} else {
    echo "NOT legit email";
}
?>

ลองด้วยตัวคุณเองhttp://phpfiddle.org/main/code/9av6-d10r

ฉันสร้าง regex นี้ตามแนวทาง RFC:

^[\\w\\.\\!_\\%#\\$\\&\\'=\\?\\*\\+\\-\\/\\^\\`\\{\\|\\}\\~]+@(?:\\w+\\.(?:\\w+\\-?)*)+$

Gmail จะอนุญาตให้ + เครื่องหมายเป็นอักขระพิเศษและในบางกรณี (.) แต่ไม่อนุญาตให้ใช้อักขระพิเศษอื่นใดใน Gmail RFC บอกว่าคุณสามารถใช้อักขระพิเศษ แต่คุณควรหลีกเลี่ยงการส่งจดหมายไปยัง Gmail ด้วยอักขระพิเศษ