PHP中字符串编码不一致会导致strtotime()解析失败，因其只按字节流处理且不识别编码，须先用mb_convert_encoding()统一转UTF-8再解析。
PHP中字符串编码不一致会导致strtotime()解析失败
是的，有影响。当日期字符串含中文（如“2024年5月1日”）或特殊符号且源字符串编码不是UTF-8时，strtotime()大概率返回false，因为该函数内部只按字节流处理，不识别编码。它不进行任何编码转换，直接读取原始字节——若传入GBK编码的“年”字（两字节：0xC4, 0xEA），会被当成两个非法ASCII字符，解析中断。
常见错误现象：
-
strtotime("2024年5月1日")在UTF-8文件里正常，在GBK文件里返回false - 从MySQL
latin1字段读出的日期字符串（如"2024-05-01"混有latin1空格或破折号）被误判为乱码，date_create()抛出DateTime::__construct(): Failed to parse time string
用mb_convert_encoding()统一转UTF-8再解析最稳妥
不要依赖setlocale()或iconv()隐式转换，它们对非标准格式（如含中文的日期）支持差。明确将输入字符串转为UTF-8是唯一可控路径。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 先用
mb_detect_encoding($str, ['UTF-8', 'GBK', 'BIG5', 'ISO-8859-1'], true)粗略判断源编码（注意：检测不可靠，仅作参考） - 若来源确定（如从GBK网页表单POST来），直接
$utf8_str = mb_convert_encoding($str, 'UTF-8', 'GBK') - 再传给
date_create($utf8_str)或strtotime($utf8_str) - 对MySQL结果，推荐在PDO连接时加
PDO::MYSQL_ATTR_INIT_COMMAND => "SET NAMES utf8mb4"，避免源头乱码
if (mb_detect_encoding($input, ['UTF-8', 'GBK'], true) !== 'UTF-8') {
$input = mb_convert_encoding($input, 'UTF-8', 'GBK');
}
$dt = date_create($input);
if (!$dt) {
throw new InvalidArgumentException('无法解析日期: ' . $input);
}
DateTime::createFromFormat()比strtotime()更可控但不解决编码问题
这个方法能指定格式（如'Y年m月d日'），跳过自然语言解析，但它**完全不关心编码**——传入GBK编码的字符串，仍会按字节匹配，导致格式匹配失败。必须确保输入已是UTF-8。
使用场景：
- 你明确知道字符串格式（如固定来自某API的
"2024/05/01"或"2024年05月01日"） - 需要严格校验格式而非容错解析
- 配合
mb_convert_encoding()预处理后使用
参数差异：
-
date_create()自动推断，宽松但不可控 -
DateTime::createFromFormat('Y年m月d日', $str)要求$str每个中文字符必须是UTF-8编码，否则m和d位置会错位
从数据库/文件读取时就该锁定编码，别留到解析阶段补救
很多问题其实发生在上游：MySQL字段用latin1存中文日期、CSV文件用ANSI保存、旧系统接口返回GBK JSON。此时在PHP里做mb_convert_encoding()只是打补丁，容易漏判或误转。
关键点：
- MySQL表结构中日期字段用
CHAR/VARCHAR时，务必设CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci - 读取CSV用
fgetcsv()前，先stream_filter_append($fp, 'convert.iconv.GBK/UTF-8') - 接收HTTP请求时，检查
$_SERVER['CONTENT_TYPE']是否含charset=gbk，并提前转换$_POST值
性能影响很小，但兼容性提升巨大——一旦编码在IO层就归一，后续所有date_*函数都无需额外处理。
最容易被忽略的是：JSON中的日期字符串（如{"date":"2024年5月1日"}）如果JSON本身是GBK编码，json_decode()不会报错，但返回的字符串仍是GBK字节，直接喂给date_create()就静默失败。这种隐性编码残留，比明面上的乱码更难排查。
