Unicode Collation Algorithm¶

Map Unicode strings, under a declared collation table and settings, into canonical-equivalence-safe multilevel weights or sort keys whose comparison yields the selected linguistic or application order.

Version: v1 · 2026-08-30 · History
Domain-specific #: 3028
Origin domain: computer science
Subdomain: internationalized text processing

Core Idea¶

The Unicode Collation Algorithm (UCA) is the Unicode Consortium's logical procedure for comparing Unicode strings according to a declared collation order rather than according to their encoded code-point values. It takes two pieces of governing context as seriously as it takes the text: a collation element table, which maps characters or character sequences to ordered tuples of weights, and a set of collation settings, which determine which levels and options participate in comparison. The default table, DUCET, supplies weights across the Unicode repertoire; language- and application-specific data can tailor that starting order. The result is a comparison relation—or an equivalent sort key—whose primary differences normally dominate secondary ones, secondary differences dominate tertiary ones, and so on.^[1]

The logical pipeline has four stages. First, the algorithm handles canonical equivalence as if each string had been transformed to Normalization Form D (NFD); a conformant implementation may avoid physically normalizing every string only when it preserves the same comparisons. Second, it scans the normalized string and finds the applicable mappings, including mappings for single characters, expansions in which one character yields several collation elements, and contractions in which a character sequence is treated as a unit. Third, it forms a multilevel key by collecting nonzero weights level by level. Finally, the two keys are compared lexicographically. For a fixed collation contract (C), the intended invariant is:

\[ A \leq_C B \quad\Longleftrightarrow\quad \operatorname{sortkey}(C,A) \leq_{\mathrm{binary}} \operatorname{sortkey}(C,B). \]

The qualification “for a fixed collation contract” is load-bearing. Keys produced with different locale tailorings, strength settings, UCA versions, or option sets are not licensed for comparison. The algorithm provides a framework for an order; the table and settings select which order is meant.^[1]

Multilevel comparison solves a problem that code-point order cannot solve. Languages sharing a script can order the same letters differently; within one language, a dictionary and a phonebook can use different conventions. In a typical Latin-script collation, primary weights encode base-letter distinctions, secondary weights accent distinctions, and tertiary weights case or other variants. Those glosses are not universal meanings for all writing systems, but they show the priority rule: a primary difference anywhere in the strings outranks every secondary or tertiary difference. Optional quaternary and identical levels can handle punctuation or final tie-breaking. Canonically equivalent sequences must collate identically, so the Angstrom sign, a precomposed A-with-ring, and an A followed by a combining ring cannot drift apart merely because their encodings differ.^[1]^[2]

UCA is customizable without being arbitrary. DUCET offers a complete default ordering, not a promise of correct local linguistic order. CLDR builds on the UCA default with root modifications and locale- or style-specific tailorings; implementations such as ICU instantiate collators from locale data or explicit rules. Tailoring can change relative weights, contractions, script grouping, strength, punctuation handling, case ordering, and related parameters while retaining the UCA comparison contract.^[3]^[4]

This makes UCA narrower than “sorting” and richer than “normalization.” It does not choose quicksort, mergesort, index layout, stability policy, or memory strategy, and it does not itself rearrange a list of records. It supplies the comparator or precomputed keys that such a sorting or indexing procedure consumes. Conversely, normalization only chooses a canonical representation for equivalent Unicode sequences; it does not decide whether Swedish ö comes after z, whether German phonebook ä behaves like ae, or whether punctuation is significant. UCA is the domain-specific closure that joins canonical-equivalence handling, Unicode-to-collation-element mapping, prioritized weights, customization, and comparison into one standardized text-ordering procedure.

Structural Signature¶

Sig role-phrases:

the Unicode input strings — the text values to be compared, potentially containing canonically equivalent but differently encoded sequences
the canonical-equivalence discipline — the requirement to behave as if input were in NFD, whether normalization is explicit or optimized away without changing results
the collation element table — DUCET or a well-formed tailored table mapping Unicode characters and character sequences to collation elements
the context-sensitive mapping pass — longest-match processing that recognizes simple mappings, expansions, contractions, and derived elements rather than assigning one fixed rank per code point
the ordered weight levels — primary, secondary, tertiary, and any supported later levels whose precedence makes stronger differences swamp weaker ones
the declared collation contract — locale or tailoring, strength, variable handling, case behavior, version, and other settings that fix which comparison relation is in force
the logical sort key — the level-ordered sequence of nonzero weights whose binary comparison reproduces the chosen string comparison
the comparison invariant — canonically equivalent strings compare alike, and keys are comparable only when generated under the same contract

The recognition test is conjunctive. A system need not serialize keys exactly as UTS #10 illustrates, and it may compare incrementally rather than materializing whole keys: UCA is a logical specification, so an implementation may optimize any stage if it reproduces the specified comparisons.^[1] But a candidate is not UCA merely because it sorts Unicode strings. It must honor canonical equivalence; use UCA-compatible collation-element and level semantics; obtain a complete default or tailored order for the relevant repertoire; and preserve the same-contract relation between direct comparison and key comparison.

Several invariants sharpen the boundary. Canonically equivalent strings compare as equal at every ordinary strength. Stronger-level differences dominate weaker-level differences across the entire string, rather than comparison being decided character by character with all local features bundled together. Contractions and expansions allow the unit of collation to differ from the unit of encoding. A tailoring changes data and parameters within the common algorithmic contract; it does not license comparing a Swedish key to a German-phonebook key. A UCA version is part of the contract because DUCET can change between Unicode releases as characters and linguistic information change.^[1]

What It Is Not¶

Not raw Unicode code-point or binary order. Unicode code charts encode characters; they do not specify a universally correct sort order. The same repertoire must support conflicting linguistic orders, and multilevel distinctions cannot be made universally correct by rearranging code-point assignments. Raw binary comparison is only a final operation on keys produced under a collation contract, not a substitute for producing those keys.
Not a generic sorting algorithm. A sorting algorithm rearranges a collection and owns time, memory, stability, and adaptivity trade-offs. UCA defines how two Unicode strings compare, or how to derive comparable keys. A database may use UCA keys with quicksort, mergesort, a B-tree, or no bulk sorting at all. The comparator and the rearrangement procedure are separate roles.
Not Unicode normalization. NFD supplies the canonical-equivalence preprocessing contract, but normalization stops once equivalent representations have been reduced to a common form. It does not assign linguistic weights, define primary versus secondary differences, form contractions or expansions for collation, or tailor an order for a locale.^[2]
Not DUCET alone. DUCET is the default data table used by UCA. It is neither the whole algorithm nor a linguistically exact order for every language. The algorithm also specifies normalization behavior, mapping, level formation, comparison, conformance, and tailoring; correct language handling usually requires tailored data.^[1]
Not identical-string testing. At a chosen strength, distinct strings can legitimately compare equal because accent, case, punctuation, or another weaker difference is ignored. The optional identical level can supply a final normalized-code-point tie-break, but collation equality at primary or tertiary strength is an application relation, not proof of byte identity.
Not a guarantee of stable or deterministic record sorting. Stability and determinism are properties of the surrounding sort and its complete key fields. A collation comparator can declare two last names equal without fixing the order of their records. Adding a first-name or unique-ID key, or choosing a stable sort, addresses that separate requirement.^[1]

Scope of Application¶

UCA travels literally wherever software must compare, index, search, group, or present Unicode text under a declared linguistic or application collation. Its scope is Unicode text processing; uses outside that mechanism belong to the broader parents algorithm, order, comparison, and canonical_form.

Localized user-interface lists — contact names, menu labels, catalog entries, and other text lists can be ordered according to the user's locale rather than code-point sequence.
Database sorting and indexing — collations govern ORDER BY, index key construction, equality at a declared strength, and range endpoints; stored sort keys can amortize repeated comparisons.
Language-sensitive search and matching — the same strength hierarchy can define whether accents, case, punctuation, or variants matter when finding text, subject to UTS #10's separate matching requirements.
Index-header and grouping systems — CLDR collation data supports assigning strings to culturally appropriate alphabetic or script groupings as well as ordering within them.^[3]
Locale-tailored dictionaries, phonebooks, and book indexes — application styles can differ even within one language, so tailoring selects the contract rather than treating a language tag as a single inevitable order.
Multiscript and specialized orders — script reordering, phonetic or radical/stroke organization, numeric handling, punctuation policy, and custom rule sets fit when expressed through conformant data and settings.
Interoperable internationalization libraries — ICU exposes locale- and rule-based collators that implement the UCA/CLDR family while optimizing normalization, mapping, comparison, and key storage.^[5]

Clarity¶

UCA makes “alphabetical order” precise by replacing it with a fully specified contract. A reviewer can ask: Which UCA and Unicode versions? Which locale or custom rules? Which strength? Is punctuation variable? Is case ordered or ignored? Are the compared keys guaranteed to have been generated under the same settings? Without those answers, “sort alphabetically” is underspecified even when every string is valid Unicode.

The mechanism also separates three decisions that software frequently conflates. Encoding determines which characters a sequence of code points represents. Normalization determines whether canonically equivalent sequences receive a standard representation. Collation determines the order and comparison-equivalence appropriate to a locale or application. The first does not imply the second, and neither implies the third. A code point can be correctly encoded and normalized yet appear in the wrong place for Swedish users because the program selected German collation data.

Finally, the sort-key invariant clarifies an optimization boundary. A sort key is not a context-free fingerprint of a string. It is a compiled representation of that string under one collation contract. Once the contract is pinned, repeated comparisons can be reduced to binary key comparisons. If the contract changes, the key's meaning changes with it and ordinarily requires regeneration. That distinction prevents both accidental cross-locale comparisons and false confidence that a stored key remains valid across UCA-data upgrades.

Manages Complexity¶

Internationalized text ordering contains several interacting sources of complexity: multiple encodings of canonically equivalent text; scripts with different notions of a basic sortable unit; contractions and expansions; hierarchical distinctions among base letters, accents, case, punctuation, and other variants; locale disagreement; and the performance cost of comparing long strings repeatedly. UCA compresses that space into a stable sequence of roles—canonical-equivalence handling, mapping to collation elements, level-prioritized weights, tailoring, and comparison.

Collation element tables absorb irregular linguistic data so the comparison procedure does not need a new branch for each language. The level structure prevents weak distinctions from interfering with stronger ones: all primary weights are compared before any secondary weights, and so on. Contractions and expansions allow the algorithm to recognize that encoded characters and collation units need not align one-to-one. Tailoring changes the data and parameters rather than forking the entire algorithm. CLDR then distributes reviewed locale and style data on top of the shared UCA framework.^[1]^[3]

Sort keys manage repeated-comparison cost by compiling the contextual mapping and multilevel weights once per string. A database or index can then use ordinary binary comparison on keys generated by the same collator. This trades generation time and storage against faster repeated comparison; direct incremental comparison can be better when a string will be compared only a few times. The abstraction makes that trade visible while leaving the implementation free to compress keys, avoid unnecessary normalization, and use other optimizations that preserve comparison results.^[1]^[6]

Abstract Reasoning¶

The mechanism licenses concrete diagnoses and interventions:

If canonically equivalent spellings separate, the implementation has violated the canonical-equivalence contract. Normalize or enable equivalent UCA processing; changing the sort algorithm cannot repair a comparator that assigns different collation behavior to equivalent sequences.
If names look right in one locale and wrong in another, inspect the selected tailoring before changing Unicode data. Swedish and German can intentionally place the same letter differently. The symptom may be a contract mismatch, not corrupted text.
If accent-insensitive search is required, lower the comparison strength only after checking what else that strength collapses. A primary-strength match may intentionally treat several distinct spellings as equal; the broader candidate set is a designed consequence, not a bug.
If stored keys disagree after an upgrade, compare UCA/Unicode/CLDR versions and settings. DUCET can change between versions, and keys are not portable across unmatched contracts. Version-pinning or key regeneration is the appropriate intervention.^[1]
If repeated database comparisons are costly, precompute same-collator sort keys; if comparisons are rare, direct comparison can avoid full-key generation and storage. The break-even point is workload-dependent, so “always store keys” is not a theorem.^[6]
If a supposedly stable record order changes among collation-equal values, add a complete secondary field or use a stable surrounding sort. Changing from tertiary to identical strength may over-distinguish text and still does not, by itself, supply stable record sorting.
If two keys came from different locales or strengths, no ordering inference follows. Regenerate both under one declared contract rather than attempting to reconcile their byte values.

The general reasoning pattern remains in-domain: locate the failure at the correct layer. Encoding failures change characters, normalization failures split canonical equivalents, tailoring failures select the wrong linguistic relation, strength failures collapse or expose the wrong differences, version failures invalidate stored comparison artifacts, and surrounding-sort failures reorder records that the collator correctly considered equal.

Knowledge Transfer¶

UCA transfers literally across internationalized computing practices because its roles retain the same meanings. A contact-list UI, a database index, a search engine, and a book-index generator may use different data structures, but each can bind a Unicode string to a collator, honor canonical equivalence, map text to collation elements, apply prioritized levels, and compare directly or through keys. Tailoring knowledge also transfers: a locale-specific rule changes a mapping or parameter within the same contract, and a strength decision controls which distinctions participate in both sorting and matching.

Implementation techniques transfer within the family. Normalization can be optimized away only when comparison equivalence is preserved. Sort keys can amortize repeated comparison. Contraction matching can be organized to avoid unnecessary context work. Versioned test data can verify that optimized implementations reproduce the logical algorithm. ICU and other conformant libraries may use different internal formats without changing the UCA identity because conformance is defined by results, not by one byte layout.^[1]^[5]

Outside Unicode text collation, the transfer is structural residue rather than UCA. “Map objects to multilevel weighted keys and compare lexicographically” is an instance of algorithm, order, and comparison; “reduce equivalent representations before comparison” belongs to canonical_form. A hiring rubric or product-ranking system may also have weighted levels, but it has no Unicode canonical equivalence, collation element table, DUCET, locale tailoring, or UCA conformance. Calling it “a collation algorithm” would be analogy-by-renaming. The portable skeleton belongs to the primes; the UCA name remains with the Unicode standard and its text-processing contract.

Examples¶

Canonical: equivalent encodings under one multilevel order¶

Consider three Unicode sequences representing the same visible A-with-ring: U+212B ANGSTROM SIGN, U+00C5 LATIN CAPITAL LETTER A WITH RING ABOVE, and U+0041 LATIN CAPITAL LETTER A followed by U+030A COMBINING RING ABOVE. UTS #10 requires canonically equivalent sequences to collate alike. Logically, NFD reduces them to the same canonical decomposition; the mapping pass therefore produces equivalent collation-element behavior, and the same contract yields equal keys at the ordinary comparison levels. A code-point comparison would distinguish the sequences immediately, so this case isolates why UCA cannot be replaced by binary order.^[1]^[2]

Now hold the algorithm fixed and change the tailoring. In Swedish, ö follows z; in German it precedes z as an accented form related to o. The encoding has not changed and neither string is malformed. The declared collation contract changed the weights, so the correct relative order changed with it.

Mapped back: The three encodings are the Unicode input strings; NFD behavior is the canonical-equivalence discipline; the locale-specific mapping is the collation element table under the declared collation contract; the equal-or-different outcome follows from the ordered weight levels and the comparison invariant.

Applied / In Practice: a locale-aware database index¶

A customer database repeatedly sorts and range-selects names. The application instantiates one collator for the requested locale and fixed settings, generates keys for each name under that collator, stores the collator version with the index contract, and lets the database compare the resulting key bytes. For a German collation, a range intended to cover names from O through P can include names beginning with Ö; selecting Swedish rules would place Ö after Z and produce a different, internally valid range. The operational error is therefore not “Unicode sorted incorrectly” but “the query and index used the wrong collation contract.” UTS #10 uses this kind of range-selection consequence to show why user-expected collation matters in databases.^[1]

When the system upgrades its UCA/CLDR data or changes locale, it rebuilds affected keys rather than comparing old and new keys. The surrounding database still chooses its own B-tree, sorting routine, tie-breaking fields, and stability behavior; UCA supplies only the text-comparison semantics.

Mapped back: Customer names are the Unicode input strings; the locale and version are the declared collation contract; key generation supplies the logical sort key; same-contract byte comparison realizes the comparison invariant; rebuilding on a contract change respects the boundary that keys from unmatched collations are not comparable.

Structural Tensions¶

T1: Complete default order versus linguistically correct local order. DUCET gives every supported Unicode character a place, including characters for which a locale has no explicit convention. That completeness makes a universal default usable, but UTS #10 warns that DUCET is not intended to be precisely correct for every language or script. Tailoring improves local expectations while reducing the fantasy of one universal “alphabetical” order. Diagnostic: Does this application need a reasonable repertoire-wide fallback, or an attested locale- or use-specific order whose differences justify tailored data?

T2: Canonical-equivalence safety versus normalization cost. Treating canonically equivalent sequences alike is non-negotiable for conformance, yet physically converting every string to NFD can add work. Optimized implementations may avoid full normalization when they can prove the same comparisons, but disabling normalization checks without controlling the input reopens equivalence failures. Diagnostic: Is the implementation preserving NFD-equivalent results by construction, or merely assuming normalized input without enforcing that precondition?

T3: Linguistic sensitivity versus comparison equality. Strength levels let applications ignore case, accents, punctuation, or other distinctions, enabling useful grouping and loose search. The same choice deliberately makes visibly or semantically distinct strings compare equal at that strength. More sensitivity improves discrimination but can frustrate search; less sensitivity improves recall but widens equality classes. Diagnostic: Which differences must determine order or matching here, and what distinct strings will intentionally collapse when the strength is lowered?

T4: Sort-key reuse versus storage and contract coupling. Precomputed keys accelerate repeated comparisons, database sorting, and indexing, but they cost generation time and space and are meaningful only under the collator that produced them. Direct comparison often stops at the first decisive difference and can be cheaper for one-off work. Diagnostic: Will each string participate in enough same-contract comparisons to repay key materialization, storage, and future regeneration?

T5: Stable results within a version versus evolution across versions. A fixed UCA version freezes its DUCET content, supporting reproducible comparison. Across versions, new assignments and improved linguistic information can change weights. Freezing forever preserves old order but misses corrections and repertoire growth; upgrading improves coverage but can invalidate indexes and persisted keys. Diagnostic: Has the system pinned and recorded its collation-data version, and does its upgrade plan include comparison tests and key/index regeneration?

T6: Shared algorithm versus local tailoring. The common UCA machinery enables interoperable implementations and reusable tooling, while language and application conventions require exceptions, contractions, expansions, and parameter changes. Too little tailoring harms users; unconstrained local rules fragment comparability. Diagnostic: Can the requested behavior be expressed as a well-formed UCA/CLDR tailoring with a declared scope, or does it silently create a private order whose keys and expectations cannot travel?

T7: Named autonomy versus reduction to parent structures. UCA can be decomposed into algorithmic procedure, canonicalization, ordered comparison, and key construction. Yet that decomposition does not tell an engineer how Unicode sequences map through contractions, expansions, DUCET, strength levels, locale data, and versioned conformance. The parents carry the cross-domain skeleton; UCA carries the retrievable intervention package inside internationalized text processing. Diagnostic: Is the question about a general algorithm/order/canonical-form pattern, or about the Unicode-specific contract whose exact roles and failure modes must remain assembled?

Structural–Framed Character¶

Unicode Collation Algorithm is mixed-structural: its algorithmic skeleton is highly formal and neutral, but the named abstraction is fixed to Unicode standards, maintained data, and linguistic or application conventions.

On evaluative weight, UCA is structural. It does not declare one language's ordering better than another; given a table and settings, it specifies comparison results and conformance obligations. On human-practice-bound, it is mixed. The key transformation and lexicographic comparison are mechanically executable, but the distinctions assigned primary, secondary, or weaker significance derive from writing systems and ordering practices. On institutional origin, it leans framed: UTS #10, Unicode versions, DUCET, and CLDR are maintained standards and datasets, even though they encode a formal procedure rather than a policy verdict. On vocabulary travels, it is domain-pinned: collation elements, NFD, DUCET, UCA strength, and locale tailoring are operative Unicode terms. On import versus recognize, exact recognition occurs across software only when those roles persist; outside Unicode text processing, a weighted lexicographic key is a co-instance of broader parents rather than UCA itself.

The portable skeleton is a deterministic algorithm that canonicalizes equivalent representations, maps them into prioritized comparison coordinates, and derives an order-preserving key. That skeleton belongs to algorithm, canonical_form, order, and comparison. UCA adds the Unicode repertoire, equivalence semantics, collation tables, standardized level behavior, locale data, and conformance/version contract that make the named technique useful.

Its character: a formal, strongly structural procedure whose identity nevertheless remains framed by the Unicode text substrate and the institutional-linguistic data selecting a particular collation.

Structural Core vs. Domain Accent¶

This section decides why Unicode Collation Algorithm is a domain-specific abstraction and not a prime.

What is skeletal (could lift toward a cross-domain prime). Strip away Unicode terminology and a thin structure remains: normalize equivalent representations; map inputs or input fragments to ordered tuples; compare all strongest coordinates before any weaker coordinates; optionally compile the tuples into keys whose ordinary comparison preserves the intended relation. This is a real portable structure. Mathematical normal forms, database composite keys, staged ranking criteria, and canonical identifiers can instantiate parts of it. But the portable reasoning is already divided among existing primes. algorithm carries the finite effective procedure; canonical_form carries equivalence-safe reduction; order carries the precedence relation; and comparison carries the pairwise operation that reads off less, equal, or greater under a shared frame.

What is domain-bound. UCA's distinctive diagnostic and intervention vocabulary does not survive extraction: Unicode strings and code points; canonical equivalence as defined by the Unicode Standard; NFD; collation elements and their well-formed tables; DUCET and derived weights; contractions, expansions, and discontiguous matching under Unicode combining behavior; primary through identical levels; variable weighting; UCA/Unicode version conformance; and CLDR locale or style tailorings. Remove that machinery and there is no answer to the practical UCA questions: why U+212B and A-plus-ring must collate alike; why ö changes position between Swedish and German; why two sort keys from different collators say nothing about one another; or when a Unicode-data upgrade requires rebuilding an index.

The substrate is not just where a generic weighted ordering happens to be implemented. It determines the equivalence relation, mapping units, data tables, versioning, conformance tests, and user expectations. A weighted rubric for grant applications can copy the phrase “primary then secondary criteria,” but it has no canonical Unicode decomposition, contraction matching, DUCET, or locale tailoring. The analogy retains prioritized comparison and loses UCA.

Why this does not clear the prime bar. A prime's operative vocabulary and recognition tests must travel across multiple domains without being renamed beyond recognition. UCA's exact mechanism recurs broadly across user interfaces, databases, search, indexing, and libraries, but those are subdomains of internationalized computing using the same Unicode standard. Beyond them, transfer becomes decomposition: use algorithm for procedure, canonical_form for equivalence reduction, order for the resulting relation, or comparison for the pairwise judgment. The full UCA package does not operate in law, biology, logistics, or organizational design. Its reach is deep and important, but bounded. That is exactly the role of a domain-specific abstraction: preserve a mature named closure whose specialized diagnostics would be lost if it were flattened into its primes.

Unicode Collation Algorithm is a strict domain-specific instance of prime:algorithm. It takes Unicode strings plus a collation table and settings, executes a definite mapping-and-key procedure, and yields a comparison outcome. It adds a particular Unicode equivalence discipline, multilevel data model, tailoring system, and conformance contract. Removing the procedure removes the candidate's identity; the parent remains meaningful without any of those additions. This is the strongest taxonomic parent.

It presupposes and realizes prime:order. A collator establishes a total comparison order or, at strengths that intentionally collapse distinctions, a total preorder over strings. The level-prioritized weights and the table's well-formedness supply the relation; UCA is not merely an unordered transform. Order remains broader and already carries comparison as a prerequisite, so a separate direct parent edge to comparison would be redundant in a minimal placement even though comparison is an important related prime.

It contains an instance of prime:canonical_form through NFD-equivalent processing. Canonically equivalent Unicode sequences must receive the same comparison behavior, and the logical main algorithm begins by converting each string to the canonical-decomposition normal form. This is a constitutive operation rather than the taxonomic identity: canonical form alone does not supply linguistic weights, strength levels, tailoring, or sort keys.

The live domain_specific:sorting_algorithm is a strong neighbor, not a parent. UCA supplies a comparison/key function that a sorting algorithm may call; it does not itself rearrange a finite sequence or choose a stability, memory, adaptivity, or asymptotic-complexity strategy. Treating UCA as a species of Sorting Algorithm would collapse comparator semantics into the separate procedure that consumes them.

Relationships to Other Abstractions¶

Current abstraction Unicode Collation Algorithm Domain-specific

Parents (3) — more general patterns this builds on

Unicode Collation Algorithm is a kind of Algorithm Prime

Unicode Collation Algorithm is a strict domain-specific instance of prime:algorithm.
Unicode Collation Algorithm is part of Canonical Form Prime

Unicode Collation Algorithm is a strict domain-specific instance of prime:algorithm.
Unicode Collation Algorithm is part of Order Prime

Unicode Collation Algorithm is a strict domain-specific instance of prime:algorithm.

Hierarchy paths (6) — routes to 6 parentless roots

Unicode Collation Algorithm → Algorithm → Function (Mapping)

Show alternative paths (5)

Neighborhood in Abstraction Space¶

Unicode Collation Algorithm sits in a sparse region of the domain-specific corpus (82^nd percentile for distinctiveness): few abstractions share its structure, so a faithful description tends to retrieve it precisely.

Family — Unclustered & Miscellaneous (1565 abstractions)

Nearest neighbors

Computed from structural-signature embeddings · 2026-09-08

Not to Be Confused With¶

Unicode code-point order. This orders code points by numeric value and can be implemented as a binary string comparison, but it cannot satisfy conflicting language conventions or multilevel comparison. Tell: Is the order read directly from encoded values, or from collation elements under a declared contract?
Unicode normalization. NFC/NFD/NFKC/NFKD reduce representational variation according to canonical or compatibility equivalence. UCA uses canonical-equivalence handling but adds collation mappings, prioritized weights, locale data, and comparison. Tell: Does the procedure merely standardize representation, or decide which of two normalized strings sorts first?
Sorting Algorithm. A sorting algorithm rearranges a collection and is evaluated by complexity, stability, memory, and adaptivity. UCA supplies the comparator or key semantics that one sorting algorithm can consume. Tell: Is the disputed behavior about record rearrangement and resource costs, or about how two Unicode strings compare?
Default Unicode Collation Element Table (DUCET). DUCET is versioned default mapping data for UCA and deliberately not a perfect order for every language. Tell: Are you inspecting the mapping weights, or the entire normalization–mapping–level–key–comparison procedure?
CLDR locale tailoring. CLDR supplies root modifications and language/style-specific data and rule syntax on top of UCA. A tailored German-phonebook order is an instance configured by those data, not a different foundational algorithm. Tell: Is the question about how tailoring data changes weights, or about the common logical comparison contract that interprets them?
Collation equality versus string identity. Two strings may compare equal when the selected strength ignores their accent, case, or punctuation difference. That does not make their code points or bytes identical. Tell: Equal under which collator and strength, or identical as encoded strings?
Stable or deterministic sorting. UCA can provide an identical-level tie-break, but it does not make a surrounding unstable sort stable or supply missing secondary record fields. Tell: Did the comparator fail to distinguish the strings, or did the sorting procedure reorder records that were correctly equal under its key?

References¶

[1] Unicode Consortium, Unicode Technical Standard #10: Unicode Collation Algorithm, Version 17.0.0, Revision 53 (2025-09-03), https://www.unicode.org/reports/tr10/. registry ↩a ↩b ↩c ↩d ↩e ↩f ↩g ↩h ↩i ↩j ↩k ↩l ↩m ↩n

[2] Unicode Consortium, Unicode Standard Annex #15: Unicode Normalization Forms, https://www.unicode.org/reports/tr15/. registry ↩a ↩b ↩c ↩d

[3] Unicode Consortium, Unicode Locale Data Markup Language (LDML), Part 5: Collation, https://www.unicode.org/reports/tr35/tr35-collation.html. registry ↩a ↩b ↩c ↩d

[4] Unicode ICU, Collation Customization, https://unicode-org.github.io/icu/userguide/collation/customization/. registry ↩a ↩b

[5] Unicode ICU, Collation Service Architecture, https://unicode-org.github.io/icu/userguide/collation/architecture.html. registry ↩a ↩b ↩c

[6] Unicode ICU, Collation Concepts, https://unicode-org.github.io/icu/userguide/collation/concepts.html. registry ↩a ↩b ↩c