Great question—this cuts straight to how Unicode handles the "user-perceived characters" we call grapheme clusters, which is critical for everything from text rendering to string length calculations. Let’s break down the exact mechanics step by step.

First, let’s clarify: a grapheme cluster is the single "character" you see on screen, which may be made up of one or more Unicode code points. Your examples illustrate this perfectly: U+0045 (Latin letter E) + U+0301 (acute accent) form one cluster (É), while U+0301 alone forms its own cluster (the standalone accent).

This isn’t about hardcoding "independent" vs "auxiliary" attributes for each code point—though code points do have categorizations that feed into the system. Instead, the behavior is defined by the Grapheme Cluster Boundary Algorithm from Unicode Standard Annex #29 (UAX #29). Here’s how it works:

1. Code Point Categories: Every Unicode code point is assigned a category (e.g., Lo for "Letter, Other"—like U+0045, Mn for "Mark, Non-Spacing"—like U+0301, Cc for "Control", etc.). You can look up these categories via tools or language APIs (like Python’s unicodedata.category()).

2. Boundary Rules: The algorithm uses a set of rules to decide whether a boundary exists between two adjacent code points. If no boundary exists, the code points are part of the same grapheme cluster. Key rules relevant to your question:

   • Rule GB9: Do NOT insert a boundary between a combining mark (like U+0301) and the character immediately before it—if that preceding character is a base character (like U+0045) or another combining mark. That’s why U+0045 + U+0301 counts as one cluster.
   • Standalone Combining Marks: If a combining mark is the first character in a string (or comes after a boundary-causing character like a control code), there’s no preceding character to attach to. The algorithm treats it as its own cluster because there’s no valid "base" to merge with—hence why U+0301 alone counts as one grapheme.

3. More Complex Cases: It’s not just "merge with the nearest base"—the algorithm handles edge cases like:

   • Multiple combining marks attached to a single base (e.g., U+0061 + U+0308 + U+0301 = ä́, which is one cluster).
   • ZWJ (Zero-Width Joiner) sequences (e.g., emoji family combinations like 👨‍👩‍👧, which uses multiple code points + ZWJ to form one cluster).
   • Spacing combining marks (common in Indic scripts) that interact with base characters in specific ways.

Most modern programming languages and text libraries include built-in support for UAX #29’s algorithm. For example:

• In Python 3.12+, you can use str.split_graphemes() to split a string into its grapheme clusters directly:

  # Example 1: Combined É
  combined = "\u0045\u0301"
  print(len(list(combined.split_graphemes())))  # Output: 1
  
  # Example 2: Standalone accent
  standalone_accent = "\u0301"
  print(len(list(standalone_accent.split_graphemes())))  # Output: 1
  

• For older Python versions, libraries like grapheme implement the full UAX #29 logic.
• Other languages like JavaScript (via libraries or ES2021+ Intl APIs) and Java (via java.text.BreakIterator) have similar tools.

It’s not about code points being "hardcoded as auxiliary". A combining mark like U+0301 doesn’t always merge—it only merges if the preceding character is eligible (per the boundary rules). If there’s no eligible preceding character, it becomes its own grapheme cluster.

内容的提问来源于stack exchange，提问作者AlanSTACK