Separate telephone-number display from storage

What it is

Phone-number canonicalization and presentation separates a comparable, routable identity from the string shown to people. For a public number that can be fully internationalized, engineering systems commonly use a plus-prefixed E.164 text representation: + is the international-prefix symbol used by E.123, RFC 3966, and software conventions, followed by E.164's country-calling-code and national-significant-number digit structure without visual separators. The interface can render that identity in national or international notation according to the number's numbering plan. Canonicalization is not “delete every non-digit”: region context, significant leading zeroes, extensions, and local-only scope can all affect meaning.

Why it happens

One number may appear in national notation, plus-prefixed international notation, an origin-specific access-prefix form, or a tel: URI. Spaces and parentheses aid reading, while dialing prefixes route from an origin; neither is a stable sole identity. Storing display text makes region changes, numbering-plan updates, and deduplication depend on brittle string comparison. Storing only scrubbed digits loses structure needed to interpret the number. Libphonenumber advises neutral storage in its structured PhoneNumber representation and can render E164, INTERNATIONAL, NATIONAL, and RFC3966 forms. The canonical record supports matching and communication; purpose, the number's plan, and dialing origin determine its presentation.

Studying it

Test parsing, canonicalization, matching, and deduplication with paired samples in which several real notations denote the same number and similar suffixes denote different numbers. Retain input region, number class, extension, and metadata version for each record. Parse–format–parse round trips should preserve identity and attached semantics. Presentation studies should cover scanning a contact list, spoken confirmation, copy and paste, click-to-call, and calling across borders, measuring grouping recognition, transcription errors, and whether the dial string works from the actual origin. Audit canonical-value diffs after metadata upgrades instead of silently rewriting all history.

Where it stops holding

E.164 fits complete international public numbers, not every short code, PBX extension, private-network number, or local-only number; an extension is a separate component. Localized phone display follows the number's numbering plan, not arbitrary regrouping by interface language. A dialable string additionally depends on call origin, carrier, and device. A telephone number is also not a permanent person identifier: it can be ported, disconnected, and reassigned. Raw input can matter for audit, user confirmation, or lossless handling of unresolved data, but it should remain source data rather than overwrite the canonical record.

Applying it

• After successful parsing, store structured country calling code, national significant number, and a separate extension. For a fully internationalizable public number, also derive plus-prefixed E.164 text for indexing, duplicate candidates, and interchange.
• Keep raw input, parsing region, canonical record, and metadata version in separate fields. Scope unresolved short codes, extensions, and local numbers explicitly instead of inventing a country code.
• Render NATIONAL or INTERNATIONAL forms through maintained metadata for the number's plan. Choose E.164 or RFC3966 as appropriate for copy, export, and click-to-call channels; never reconstruct identity from display text.
• Test round-trip stability, idempotence, and metadata upgrades. Do not merge accounts or contacts on string equality alone: ask for confirmation, and test dialing on target devices from the intended origin.

Related

• Same group: S2.07.1 Relating country calling codes to national formats · S2.07.2 Phone-number length and grouping vary by country · S2.07.3 Strict validation rejects legitimate numbers
• Adjacent: S2.01 Date and Time Formats · S2.09 Regional Differences in Input Validation
• Search terms: E.164 canonicalization · PhoneNumberFormat · RFC 3966 tel URI