Exercise 3: Why substr() Is Dangerous for a Kanji Title — Possible Solution
====================================================================

HOW MULTI-BYTE UTF-8 CHARACTERS ARE ENCODED
------------------------------
Per this chapter, a character like 水 is encoded in UTF-8 as three real bytes, not one - a single visible "character" can span multiple bytes in the underlying string representation.

WHY substr() IS DANGEROUS
------------------------------
Per this chapter, PHP's plain substr() function operates on raw BYTES, with no awareness that some characters actually span several of them. Calling substr($title, 0, 10) cuts the string at exactly byte position 10, regardless of whether that position happens to fall in the middle of a multi-byte character's own byte sequence. If it does, the result is broken, invalid UTF-8 - a corrupted partial character that can't be correctly displayed or processed afterward.

WHY mb_substr() IS SAFE
------------------------------
Per this chapter, mb_substr() (and the other mb_-prefixed functions) are specifically built to operate on actual characters rather than raw bytes - mb_substr($title, 0, 10) correctly returns the first 10 real characters, never slicing through the middle of a multi-byte character's own byte sequence, regardless of how many bytes any individual character in that string actually occupies.

WHY THIS WORKS AS AN ANSWER
------------------------------
It correctly explains that a kanji character occupies multiple bytes in UTF-8, correctly explains that plain substr() operates on byte position without character awareness (risking a corrupted mid-character cut), and correctly explains that mb_substr() avoids this by operating on real character boundaries instead.