EmailAddress (Jodd API Documentation)

java.lang.Object
- jodd.mail.EmailAddress

```
public class EmailAddress
extends java.lang.Object
```
EmailAddress - a utility class to parse, clean up, and extract email addresses per RFC2822 syntax. This class can be trusted to only provide authenticated results.
This class has been successfully used on many billion real-world addresses, live in production environments, but it's not perfect yet, since the standard is quite complex.
Note: Unlike InternetAddress, this class will preserve any RFC-2047-encoding of international characters.

Field Summary

Fields
Modifier and Type	Field and Description
`static java.util.regex.Pattern`	`ADDR_SPEC_PATTERN` Java regex pattern for 2822 "addr-spec" token; Not necessarily useful, but available in case.
`static boolean`	`ALLOW_DOMAIN_LITERALS` This constant changes the behavior of the domain parsing.
`static boolean`	`ALLOW_DOT_IN_ATEXT` This constant allows ".
`static boolean`	`ALLOW_PARENS_IN_LOCALPART` This constant allows ")" or "(" to appear in quoted versions of the localpart (they are never allowed in unquoted versions) The default (2822) behavior is to allow this, i.e. boolean true.
`static boolean`	`ALLOW_QUOTED_IDENTIFIERS` This constant states that quoted identifiers are allowed (using quotes and angle brackets around the raw address) are allowed, e.g.: `"John Smith" <john.smith@somewhere.com>` The RFC says this is a valid mailbox.
`static boolean`	`ALLOW_SQUARE_BRACKETS_IN_ATEXT` This constant allows "[" or "]" to appear in atext.
`static java.util.regex.Pattern`	`COMMENT_PATTERN` Java regex pattern for 2822 "comment" token; Not necessarily useful, but available in case.
`protected java.lang.String`	`email`
`static boolean`	`EXTRACT_CFWS_PERSONAL_NAMES` This controls the behavior of getInternetAddress and extractHeaderAddresses.
`static java.util.regex.Pattern`	`MAILBOX_PATTERN` Java regex pattern for 2822 "mailbox" token; Not necessarily useful, but available in case.

Constructor Summary

Constructors
Constructor and Description

EmailAddress(java.lang.String email)
Creates new email address.

Constructors
Constructor and Description
`EmailAddress(java.lang.String email)` Creates new email address.

Method Summary

Methods
Modifier and Type	Method and Description
`java.lang.String`	`getDomain()` Returns domain part of the email address.
`javax.mail.internet.InternetAddress`	`getInternetAddress()` Given a 2822-valid single address string, returns an InternetAddress object holding that address, otherwise returns null.
`java.lang.String`	`getLocalPart()` Returns local part of the email address.
`java.lang.String`	`getPersonalName()` Returns personal name.
`java.lang.String`	`getReturnPathAddress()` Pull out the cleaned-up return path address.
`java.lang.String`	`getReturnPathBracketContents()` WARNING: You may want to use getReturnPathAddress() instead if you're looking for a clean version of the return path without CFWS, etc.
`boolean`	`isValid()` Returns `true`if email is valid.
`boolean`	`isValidReturnPath()` Returns `true` if the email represents a valid return path.

Methods inherited from class java.lang.Object
clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait

- Field Detail
  - ALLOW_DOMAIN_LITERALS
```
public static boolean ALLOW_DOMAIN_LITERALS
```
    This constant changes the behavior of the domain parsing. If true, the parser will allow 2822 domains, which include single-level domains (e.g. bob@localhost) as well as domain literals, e.g.:
    - someone@[192.168.1.100] or
    - john.doe@[23:33:A2:22:16:1F] or
    - me@[my computer]
    The RFC says these are valid email addresses, but most people don't like allowing them. If you don't want to allow them, and only want to allow valid domain names (RFC 1035, x.y.z.com, etc), and specifically only those with at least two levels ("example.com"), then change this constant to false.
  - ALLOW_QUOTED_IDENTIFIERS
```
public static boolean ALLOW_QUOTED_IDENTIFIERS
```
    This constant states that quoted identifiers are allowed (using quotes and angle brackets around the raw address) are allowed, e.g.:
    - "John Smith" <john.smith@somewhere.com>
    The RFC says this is a valid mailbox. If you don't want to allow this, because for example, you only want users to enter in a raw address (john.smith@somewhere.com - no quotes or angle brackets), then change this constant to false.
  - ALLOW_DOT_IN_ATEXT
```
public static boolean ALLOW_DOT_IN_ATEXT
```
    This constant allows "." to appear in atext (note: only atext which appears in the 2822 "name-addr" part of the address, not the other instances)
    The addresses:
    - Kayaks.org <kayaks@kayaks.org>
    - Bob K. Smith<bobksmith@bob.net>
    ...are not valid. They should be:
    - "Kayaks.org" <kayaks@kayaks.org>
    - "Bob K. Smith" <bobksmith@bob.net>
    If this boolean is set to false, the parser will act per 2822 and will require the quotes; if set to true, it will allow the use of "." without quotes.
  - EXTRACT_CFWS_PERSONAL_NAMES
```
public static boolean EXTRACT_CFWS_PERSONAL_NAMES
```
    This controls the behavior of getInternetAddress and extractHeaderAddresses. If true, it allows the real world practice of:
    - <bob@example.com> (Bob Smith)
    In this case, "Bob Smith" is not technically the personal name, just a comment. If this is set to true, the methods will convert this into:
    - Bob Smith <bob@example.com>
    This also happens somewhat more often and appropriately with mailer-daemon@blah.com (Mail Delivery System).
    If a personal name appears to the left and CFWS appears to the right of an address, the methods will favor the personal name to the left. If the methods need to use the CFWS following the address, they will take the first comment token they find.
  - ALLOW_SQUARE_BRACKETS_IN_ATEXT
```
public static boolean ALLOW_SQUARE_BRACKETS_IN_ATEXT
```
    This constant allows "[" or "]" to appear in atext. The address:
    - [Kayaks] <kayaks@kayaks.org>
    ...is not valid. It should be:
    - "[Kayaks]" <kayaks@kayaks.org>
    If this boolean is set to false, the parser will act per 2822 and will require the quotes; if set to true, it will allow them to be missing.
    Use at your own risk. There may be some issue with enabling this feature in conjunction with ALLOW_DOMAIN_LITERALS.
  - ALLOW_PARENS_IN_LOCALPART
```
public static boolean ALLOW_PARENS_IN_LOCALPART
```
    This constant allows ")" or "(" to appear in quoted versions of the localpart (they are never allowed in unquoted versions) The default (2822) behavior is to allow this, i.e. boolean true. You can disallow it, but better to leave it true.
  - email
```
protected final java.lang.String email
```
  - MAILBOX_PATTERN
```
public static final java.util.regex.Pattern MAILBOX_PATTERN
```
    Java regex pattern for 2822 "mailbox" token; Not necessarily useful, but available in case.
  - ADDR_SPEC_PATTERN
```
public static final java.util.regex.Pattern ADDR_SPEC_PATTERN
```
    Java regex pattern for 2822 "addr-spec" token; Not necessarily useful, but available in case.
  - COMMENT_PATTERN
```
public static final java.util.regex.Pattern COMMENT_PATTERN
```
    Java regex pattern for 2822 "comment" token; Not necessarily useful, but available in case.
- Constructor Detail
  - EmailAddress
```
public EmailAddress(java.lang.String email)
```
    Creates new email address. Nothing is parsed yet.
- Method Detail
  - isValid
```
public boolean isValid()
```
    Returns trueif email is valid.
  - isValidReturnPath
```
public boolean isValidReturnPath()
```
    Returns true if the email represents a valid return path.
  - getReturnPathBracketContents
```
public java.lang.String getReturnPathBracketContents()
```
    WARNING: You may want to use getReturnPathAddress() instead if you're looking for a clean version of the return path without CFWS, etc. See that documentation first!
    Pull whatever's inside the angle brackets out, without alteration or cleaning. This is more secure than a simple substring() since paths like:
    <(my > path) >
    ...are legal return-paths and may throw a simpler parser off. However this method will return all CFWS (comments, whitespace) that may be between the brackets as well. So the example above will return:
    (my > path)_
    (where the _ is the trailing space from the original string)
  - getReturnPathAddress
```
public java.lang.String getReturnPathAddress()
```
    Pull out the cleaned-up return path address. May return an empty string. Will require two parsings due to an inefficiency.
    
    Returns:
    null if there are any syntax issues or other weirdness, otherwise the valid, trimmed return path email address without CFWS, surrounding angle brackets, with quotes stripped where possible, etc. (may return an empty string).
  - getInternetAddress
```
public javax.mail.internet.InternetAddress getInternetAddress()
```
    Given a 2822-valid single address string, returns an InternetAddress object holding that address, otherwise returns null. The email address that comes back from the resulting InternetAddress object's getAddress() call will have comments and unnecessary quotation marks or whitespace removed.
  - getPersonalName
```
public java.lang.String getPersonalName()
```
    Returns personal name. The Strings returned by this method will not reflect any decoding of RFC-2047 encoded personal names.
  - getLocalPart
```
public java.lang.String getLocalPart()
```
    Returns local part of the email address.
  - getDomain
```
public java.lang.String getDomain()
```
    Returns domain part of the email address.

Class EmailAddress

Field Summary

Constructor Summary

Method Summary

Methods inherited from class java.lang.Object

Field Detail

ALLOW_DOMAIN_LITERALS

ALLOW_QUOTED_IDENTIFIERS

ALLOW_DOT_IN_ATEXT

EXTRACT_CFWS_PERSONAL_NAMES

ALLOW_SQUARE_BRACKETS_IN_ATEXT

ALLOW_PARENS_IN_LOCALPART

email

MAILBOX_PATTERN

ADDR_SPEC_PATTERN

COMMENT_PATTERN

Constructor Detail

EmailAddress

Method Detail

isValid

isValidReturnPath

getReturnPathBracketContents

getReturnPathAddress

getInternetAddress

getPersonalName

getLocalPart

getDomain