Using mb_substr() is the correct way to solve the problem of Unicode string interception in PHP, because substr() cuts by bytes and causes multi-byte characters (such as emoji or Chinese) to be truncated into garbled code; while mb_substr() cuts by character, which can correctly process UTF-8-encoded strings, ensure complete characters are output and avoid data corruption. 1. Always use mb_substr() for strings containing non-ASCII characters; 2. explicitly specify the 'UTF-8' encoding parameters or set mb_internal_encoding('UTF-8'); 3. Use mb_strlen() instead of strlen() to get the correct number of characters; 4. Check whether the mbstring extension is enabled to ensure that the function is available; 5. Consider substr() only when processing pure ASCII or binary data. As long as user input, internationalization or web content is involved, mb_substr() must be used to ensure the security and correctness of string operations.

When working with multibyte strings—especially those containing non-ASCII characters like emojis, Chinese, Arabic, or even accented Latin letters—using PHP's standard substr() can lead to garbled output or even broken characters. This is the heart of the Unicode challenge in PHP string manipulation.

The issue arises because substr() operates on bytes , not characters . Since UTF-8 encodes some characters using 2, 3, or even 4 bytes, cutting a string in the middle of a byte sequence results in invalid or corrupted text.

That's where mb_substr() comes in.

Why substr() Fails with Unicode

Consider this string:

 $string = "Hello ?"; // The globe emoji is 4 bytes in UTF-8

If you try:

 echo substr($string, 0, 7); // Trying to get "Hello ?" (7 chars)

You might expect "Hello ?" , but depending on how the bytes align, you could end up with something like "Hello " — a mojibake or "garbage character" — because substr() sliced right through the middle of the 4-byte emoji.

This is not just an edge case — it's a real problem when dealing with user-generated content, internationalization, or APIs handling diverse text.

The Solution: mb_substr()

PHP's Multibyte String Functions , specifically mb_substr() , are designed to handle UTF-8 and other encodings correctly by operating on characters , not bytes.

Basic Syntax

 mb_substr(string $str, int $start, ?int $length = null, ?string $encoding = null)

To safely slice the earlier example:

 $safe = mb_substr($string, 0, 7, 'UTF-8');
echo $safe; // Output: "Hello ?" — intact and correct

Key points:

• The fourth parameter ( 'UTF-8' ) explicitly tells PHP the encoding.
• You can omit it if mb_internal_encoding() is set to UTF-8 (which it should be).
• Always specify the encoding when in doubt — don't rely on defaults.

Best Practices for Safe String Slicing

To avoid Unicode-related bugs, follow these guidelines:

• ? Always use mb_substr() for user-facing or international text
• ? Set internal encoding early:

   mb_internal_encoding('UTF-8');

• ? Use consistent encoding across your app — ensure databases, forms, and outputs are all UTF-8.
• ? Validate input encoding if uncertain:

   if (!mb_check_encoding($string, 'UTF-8')) {
      // Handle or convert
  }

• ? Never assume strlen() or substr() are safe with Unicode

Common Pitfalls to Avoid

• Mixing strlen and mb_substr :
  strlen() returns byte count. Use mb_strlen($string, 'UTF-8') instead.

   $text = "café"; // 5 bytes, 4 characters
  echo strlen($text); // 5
  echo mb_strlen($text); // 4 — correct character count

• Forgetting the encoding parameter :
  If omitted, mb_substr() uses the internal encoding — which might not be UTF-8. Be explicit.

• Assuming mbstring is always enabled :
  It's not part of the PHP core; it's an extension. Check with:

   if (!function_exists('mb_substr')) {
      die('Multibyte extension required.');
  }

  ---

  When You Might Still Use substr()

  There are rare cases where byte-level access is needed:

  • Binary data (eg, file headers)
  • Performance-critical code with ASCII-only strings
  • Working with encoded payloads (eg, base64)

  But for any human-readable text that might include Unicode, stick with mb_substr() .

  ---

  Using mb_substr() correctly isn't just about avoiding weird symbols — it's about building robust, internationalized applications. The Unicode challenge isn't exotic; it's everyday reality in modern web development.

  So whenever you slice a string, ask: Is this safe for ???? If you're not using mb_substr() , the answer is probably no.

  Basically, just use mb_substr() with 'UTF-8' — it's not much extra effort, and it saves a lot of headaches.

  The above is the detailed content of The Unicode Challenge: Safe String Slicing with `mb_substr()` in PHP. For more information, please follow other related articles on the PHP Chinese website!