Email with Display Name
identity.person.email_displayEmail address with a display name (RFC 5322 mailbox format). Format: "Display Name" <local@domain> or Display Name <local@domain>. Commonly used in email headers and contact lists.
Worked samples
DuckDB 1.5.5 · finetype 0.6.64
| Value | As VARCHAR | display_name | email |
|---|---|---|---|
| "John Doe" <john@example.com> | "John Doe" <john@example.com> | John Doe | john@example.com |
| Jane Smith <jane@corp.com> | Jane Smith <jane@corp.com> | Jane Smith | jane@corp.com |
| "Alice B. Johnson" <alice.j@company.org> | "Alice B. Johnson" <alice.j@company.org> | Alice B. Johnson | alice.j@company.org |
| Support Team <support@example.com> | Support Team <support@example.com> | Support Team | support@example.com |
Shape
Length 10 to 300 characters.
^"?[^"<>]+"?\s*<[a-zA-Z0-9._%+\-]+@[a-zA-Z0-9.\-]+\.[a-zA-Z]{2,}>$| Value | Length | Shape |
|---|---|---|
| "John Doe" <john@example.com> | 29 | matches |
| Jane Smith <jane@corp.com> | 26 | matches |
| "Alice B. Johnson" <alice.j@company.org> | 40 | matches |
| Support Team <support@example.com> | 34 | matches |
| "John Doe" <john@example.com | 28 | rejected: one character short |
Background
Origin
RFC 2822, published in April 2001 under the title Internet Message Format, superseded RFC 822.[1] RFC 5322, also titled Internet Message Format, was published in October 2008 and obsoletes RFC 2822.[2] In its grammar, name-addr is an optional display-name followed by an angle-addr, and display-name is defined as a phrase.[2] A phrase is made of words, and each word is either an atom or a quoted-string.[2] The comma, the period and the double quote are among the specials, which cannot appear in an atom.[2] RFC 5322's obsolete syntax adds the period to the phrase because it is used in many messages in the display-name portion of addresses.[2] That is why a name with an initial, such as Alice B. Johnson, is safest written in quotes. (Meridian's view)
Use
RFC 2047, published in November 1996, lets an encoded-word replace a word within a phrase, for example one that precedes an address in a From, To, or Cc header.[3] An encoded-word has the form =?charset?encoding?encoded-text?=.[3] RFC 6532, Internationalized Email Headers, published in February 2012, extends the RFC 5322 syntax to allow UTF-8 content.[4] A display name exported straight from mail headers may therefore arrive either as raw UTF-8 or still wrapped in =?utf-8?...?= encoding, and it is worth decoding the second kind before you compare names. (Meridian's view)
Python's email.utils.parseaddr splits a value such as a To or Cc field into its realname and email address parts.[5] When the parse fails, parseaddr returns the 2-tuple ('', '').[5] Since Python 3.13, parseaddr and getaddresses take a strict parameter and reject malformed inputs by default.[5] The inverse, formataddr, takes a (realname, email_address) pair and returns a string suitable for a To or Cc header.[5] formataddr applies RFC 2047 encoding to the realname if it contains non-ASCII characters.[5] Prefer a tested address parser to a hand-written regular expression, and keep the rows it rejects for review rather than dropping them. (Meridian's view)
Sources
- [1]Internet Message Formatstandard
- [2]Internet Message Formatstandard
- [3]MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Textstandard
- [4]Internationalized Email Headersstandard
- [5]email.utils: Miscellaneous utilities — Python 3.15.0 documentationdocumentation
Detection notes
RFC 5322 mailbox format. Display name may be quoted or unquoted. Decompose extracts the display name and bare email address separately.
Use it
$ finetype infer -i ""John Doe" <john@example.com>" --mode column
→ identity.person.email_display
SELECT ft_infer('"John Doe" <john@example.com>');
-- → 'identity.person.email_display'CAST({col} AS VARCHAR)Schema
https://meridian.online/schemas/identity.person.email_display · Frictionless type string
finetype taxonomy identity.person.email_display -o json-schema