Unicode kararlılık politikası

What is the Unicode Stability Policy?

The Unicode Stability Policy is a set of formal commitments by the Unicode Consortium guaranteeing that certain properties and assignments in the Unicode Standard will not change in ways that would break existing implementations. These policies protect developers who build software on Unicode: you can rely on the behavior of characters you support today remaining consistent in future Unicode versions.

Stability policies are published on unicode.org and are considered binding. They were formalized over several Unicode versions and have become more comprehensive as the standard matured.

Core Stability Guarantees

Character Assignment Stability

Once a code point is assigned to a character, that assignment is permanent: - No character is ever unassigned from its code point - No code point is ever reassigned to a different character - A Unicode 1.0 file can be decoded correctly by a Unicode 16.0 implementation

Character Name Stability

Normative character names are immutable. If a name was published with a typo or error (e.g., U+FE18's name has a documented misspelling "BRAKCET" instead of "BRACKET"), the wrong name cannot be changed. Instead, a formal alias is added via NameAliases.txt, and applications are expected to use both the name and its aliases.

Normalization Stability (since Unicode 4.1)

The canonical decomposition of any character assigned before Unicode 4.1 is fixed permanently. This means: - NFC/NFD results for pre-4.1 characters will never change - Software can normalize text and store it without re-normalizing after Unicode updates - New characters (post-4.1) may have decompositions, but once published they are also stable

import unicodedata
# This NFC result will be the same in all future Unicode versions
# for characters assigned before Unicode 4.1
print(unicodedata.normalize("NFC", "caf\u0065\u0301"))  # "café"

Identifier Stability (since Unicode 5.1)

Code points in ID_Start and ID_Continue properties do not lose those properties. This ensures that identifiers valid in one Unicode version remain valid in future versions.

Case Mapping Stability (partial)

Simple case mappings (uppercase, lowercase, titlecase) do not change for existing characters. Special case mappings (context-dependent) may be updated, but simple cases are stable.

Bidi Stability (Unicode 6.3+)

The bidi class of assigned characters does not change in ways that would alter the visual presentation of existing text.

What Is NOT Stable

The Unicode Stability Policy does not guarantee everything:

Practical Impact for Developers

Text storage: Because character assignments and normalization are stable, you can safely store Unicode text in databases. A code point stored today will mean the same character forever.

Identifier parsing: Programming languages using ID_Start/ID_Continue for identifier validation (Python, JavaScript, Rust) benefit from identifier stability — valid identifiers remain valid.

Emoji rendering: Emoji properties are not fully stable — an emoji can gain or lose a Emoji_Presentation flag, changing its default rendering. This is why platform emoji updates sometimes appear unexpected.

Normalization in indexes: Because NFC/NFD results are stable for assigned characters, you can normalize text before indexing it and rely on those indexes remaining valid after Unicode updates.

Quick Facts