使用 mb_split() 是处理多字节字符字符串分割的首选方法，因其能准确识别中文、日文等字符边界。该函数依赖 mb_internal_encoding() 和 mb_regex_encoding() 设置正确的字符编码，否则会导致乱码或分割错误。相比 explode() 和未加 u 修饰符的 preg_split()，mb_split() 能避免按字节分割导致的乱码问题，适用于 UTF-8、GBK 等多字节编码。实际使用中需确保编码设置与字符串编码一致，并注意正则表达式性能影响。PHP 7.4+ 可用 mb_str_split() 更高效地拆分为单字符数组。
当我们需要将包含中文、日文等多字节字符的字符串拆分成数组时，直接使用
explode()或不带
u修饰符的
preg_split()常常会遇到乱码或分割错误。PHP 提供了
mb_split()方法，它专门用于处理这类多字节字符集下的字符串分割，通过结合多字节字符串函数库（MBString）的编码设置，能够准确无误地完成任务。在我看来，这是处理这类问题的首选且最可靠的方式。
mb_split()方法是PHP中专门为多字节字符集设计的字符串分割利器，它能够根据正则表达式将一个多字节字符串拆分为数组。它的核心优势在于能够正确识别和处理单个多字节字符，而不是将其简单地当作字节序列。这意味着，无论你的字符串是UTF-8、GBK还是其他编码，只要MBString库配置得当，
mb_split()就能准确地按字符边界进行分割。
使用
mb_split()的基本语法是
mb_split(string $pattern, string $string, int $limit = -1)。
$pattern是一个正则表达式，
$string是要分割的源字符串，
$limit是可选的，用于限制返回的数组元素数量。
举个例子，假设我们有一个UTF-8编码的中文句子，想根据逗号或者空格来分割：
立即学习“PHP免费学习笔记（深入）”；
<?php
// 确保内部编码设置为字符串的实际编码，这对于mb_*系列函数至关重要
mb_internal_encoding("UTF-8");
mb_regex_encoding("UTF-8"); // mb_split 依赖 mb_regex_encoding
$text = "你好，世界！这是一个测试。";
// 使用mb_split按中文逗号或空格分割
$parts_mb_split = mb_split("[,，\s]+", $text);
print_r($parts_mb_split);
/* 预期输出示例（取决于具体文本和正则）：
Array
(
[0] => 你好
[1] => 世界！这是一个测试。
)
*/
$text2 = "苹果,香蕉 橘子";
$parts_mb_split_2 = mb_split("[,，\s]+", $text2);
print_r($parts_mb_split_2);
/* 预期输出:
Array
(
[0] => 苹果
[1] => 香蕉
[2] => 橘子
)
*/
?>这里需要特别强调的是，
mb_split()的行为很大程度上取决于
mb_internal_encoding()和
mb_regex_encoding()的设置。如果这些编码没有正确配置，即使使用了
mb_split()，也可能无法得到预期的结果。我个人在处理多语言项目时，总会把这两项设置放在脚本开头，以避免后续的各种字符编码问题。
为什么常规的 explode()
或 preg_split()
在处理多字节字符时会出问题？
这个问题，我相信很多初次接触多字节字符串处理的开发者都会遇到。简单来说，
explode()函数在设计之初，主要是针对单字节字符集（比如ASCII）来工作的。它在分割字符串时，是按字节流进行操作的。一个中文字符在UTF-8编码下可能占据3个字节，如果你尝试用
explode()去分割一个多字节字符串，并且分隔符本身也是多字节的，或者你试图通过一个单字节分隔符去“切开”一个多字节字符，那么结果往往是灾难性的——你会得到乱码，或者分割点完全不对。因为它不“理解”什么是“字符”，它只认识“字节”。
preg_split()呢？它比
explode()强大得多，因为它支持正则表达式。然而，默认情况下，
preg_split()同样是以字节为单位来处理字符串的，除非你明确告诉它要处理多字节字符。在PHP中，这意味着你需要为正则表达式添加
u(Unicode) 修饰符，例如
/pattern/u。但即使这样，也需要确保你的字符串本身是UTF-8编码的。如果字符串是其他多字节编码，或者你的PHP环境没有正确配置多字节支持，
preg_split()依然可能无法正确工作。
mb_split()的优势就在于，它天生就是为多字节环境而生，它会利用MBString的内部编码设置来确保正则表达式和字符串的匹配是基于字符而非字节的。这省去了我们手动添加
u修饰符的步骤，并且在处理非UTF-8的多字节编码时也更加灵活和可靠。在我看来，这种“开箱即用”的多字节感知能力是它最吸引人的地方。
mb_internal_encoding()
和 mb_regex_encoding()
如何影响 mb_split()
的行为？
理解这两个函数对
mb_split()的影响至关重要，它们是MBString库正确工作的基石。简单来说，
mb_internal_encoding()设定的是PHP脚本内部所有
mb_*函数（包括
mb_split()）默认操作的字符编码。当你调用
mb_split()时，它会假设你传入的字符串是这种编码格式的。如果你的字符串实际编码与
mb_internal_encoding()不符，那么即使
mb_split()自身功能再强大，也无法正确解析字符串，导致分割错误或乱码。
而
mb_regex_encoding()则更为具体，它专门设置
mb_ereg_*和
mb_split()等多字节正则表达式函数所使用的编码。
mb_split()内部实际上是调用了
mb_ereg_split()，因此它会严格遵循
mb_regex_encoding()的设置来解释你的正则表达式模式和目标字符串。如果
mb_regex_encoding()没有显式设置，它会默认使用
mb_internal_encoding()的值。
这意味着什么呢？这意味着如果你正在处理一个UTF-8编码的字符串，那么你的代码中至少应该有：
<?php
mb_internal_encoding("UTF-8");
mb_regex_encoding("UTF-8");
// ... 然后再调用 mb_split()
?>如果你的字符串是GBK编码，那么你就需要将它们设置为 "GBK"。我曾经遇到过一个非常头疼的问题，就是服务器环境的默认编码是ISO-8859-1，而我的PHP文件和数据库都是UTF-8。结果就是
mb_split()怎么都分割不对，排查了很久才发现是
mb_internal_encoding()没有显式设置，导致
mb_split()误以为我在处理单字节字符。所以，我的经验是，永远不要依赖服务器的默认设置，明确地在代码中指定编码，这是一个非常好的习惯。
使用 mb_split()
时有哪些常见的性能考量和潜在陷阱？
尽管
mb_split()在处理多字节字符串方面表现出色，但它并非没有自己的考量和潜在问题。
首先是性能。
mb_split()依赖于正则表达式引擎来工作，相比于简单的字符串查找（如
strpos或
explode针对固定字符串分隔符），正则表达式匹配通常会更消耗资源，尤其是在处理非常长的字符串或复杂的正则表达式模式时。如果你的应用对性能要求极高，并且分割需求非常简单（例如，仅仅是按单个多字节字符分割，且没有复杂的模式匹配），你可能需要权衡一下。不过，在大多数实际场景中，
mb_split()的性能损耗通常是可接受的，其带来的准确性远比微小的性能差异更重要。
其次，最大的陷阱，也是我反复强调的，就是编码不匹配。如果你的字符串实际编码是UTF-8，但
mb_internal_encoding()或
mb_regex_encoding()被设置成了GBK，那么
mb_split()就会把UTF-8的字节流当作GBK来解析，结果必然是乱码或错误的分割。这就像你给一个讲英语的人说中文，他当然听不懂。所以，务必确保MBString的编码设置与你处理的字符串编码保持一致。
还有一个小点，是关于空分隔符的处理。如果你尝试用一个空字符串作为分隔符传给
mb_split()，它会返回一个包含原始字符串的数组，而不是像
str_split()那样将字符串拆分成单个字符。如果你想将多字节字符串拆分成单个字符数组，PHP 7.4及以上版本提供了
mb_str_split()函数，这会更直接和高效。对于更早的版本，你可能需要结合
mb_substr()和循环来实现。
<?php
// PHP 7.4+ 拆分多字节字符串为单个字符数组
mb_internal_encoding("UTF-8");
$str = "你好世界";
$chars = mb_str_split($str);
print_r($chars);
/* 预期输出:
Array
(
[0] => 你
[1] => 好
[2] => 世
[3] => 界
)
*/
?>最后，关于正则表达式的复杂性。虽然
mb_split()接受正则表达式，但过度复杂的模式不仅会影响性能，还可能增加维护难度和引入难以发现的逻辑错误。尽量保持正则表达式的简洁和精确，这不仅对
mb_split()有益，对任何正则表达式的使用都是金科玉律。我发现，很多时候，简单的模式加上正确编码设置，就能解决90%的问题。
