Exercise 1: UTF-16 Code Units vs. Code Points, Verified Directly — Possible Solution ==================================================================== THE RARE ASTRAL-PLANE CHARACTER ('𠀋', U+2000B) ------------------------------ '𠀋'.length reports 2 - not 1 - because this character lives outside the Basic Multilingual Plane and needs a surrogate pair (two 16-bit UTF-16 code units) to represent one real character. [...'𠀋'].length correctly reports 1 - the spread operator uses the string's own iterator, which is defined in terms of Unicode code points, not raw code units, so it correctly treats the surrogate pair as a single character. '𠀋'.slice(0, 1) produces a genuinely corrupted result - a lone, invalid surrogate half. It isn't a smaller valid character; it's broken data, since a surrogate half has no valid meaning on its own. THE COMMON KANJI ('水') ------------------------------ '水'.length reports 1, [...'水'].length also reports 1, and '水'.slice(0, 1) correctly returns the full character '水' unchanged. All three checks agree because '水' lives within the Basic Multilingual Plane and needs only one UTF-16 code unit to represent. WHY THE RESULTS DIFFER ------------------------------ The difference isn't about kanji as a category - it's about which specific character, and which Unicode plane it lives in. Common, everyday kanji (the overwhelming majority, including everything actually used as content on this site) live in the BMP and behave exactly like any other single-code-unit character. Only the rare, historical, or highly specialized kanji living in the Supplementary Ideographic Plane (U+20000 and above) actually trigger the surrogate- pair behavior this chapter describes. WHY THIS WORKS AS AN ANSWER ------------------------------ It correctly reproduces all three checks for both characters, correctly identifies that .length itself already disagrees for the rare character (2 vs. the array-spread's 1, unlike the common kanji where both agree at 1) as the earliest sign something is different about it, and correctly attributes the difference to the specific Unicode plane the character lives in rather than to "kanji" as an undifferentiated category.