Excel导出CSV含Alt+Enter换行符（\r\n）导致PHP fgetcsv()误判行尾，引发字段错位；应预处理流识别引号状态剔除内部换行，或改用str_getcsv($line, ',', '"', '"')并确保MySQL字段足够长且无截断。
Excel导出的CSV含\r\n换行符导致PHP导入时字段错位
班级通信录从Excel另存为CSV后，单元格内若含手动换行（Alt+Enter），会生成\r\n嵌入字段中；PHP用fgetcsv()读取时，它把\r\n当成本行结束符，导致后续字段整体偏移、姓名/电话错乱。
这不是编码问题，也不是BOM干扰，是CSV解析器对“内部换行”的默认处理逻辑所致。
- 确认是否真有内部换行：用
hexdump -C file.csv | head -20查是否有0d 0a出现在双引号字段中间 - 避免用
str_replace("\n", "", $line)粗暴处理——会破坏合法行尾，且\r\n和\n混用时不可靠 - 优先在导出源头控制：Excel中替换所有
Alt+Enter为空格，或改用“文本导出向导”→选择“{LF}”为行分隔符（但非所有版本支持）
用fgetcsv()前预处理CSV流，安全剥离字段内换行
不能直接file_get_contents()再explode("\n")，那样会切碎本应属于同一行的双引号包裹内容。正确做法是边读边识别引号配对状态，只在引号闭合后才认同行结束。
以下代码片段可作为fgetcsv()调用前的流预处理器：
立即学习“PHP免费学习笔记（深入）”；
function clean_csv_linebreaks($file_path) {
$fp = fopen($file_path, 'r');
$buffer = '';
$in_quotes = false;
$clean_lines = [];
while (($char = fgetc($fp)) !== false) {
if ($char === '"') {
$in_quotes = !$in_quotes;
}
if ($char === "\n" && !$in_quotes) {
$clean_lines[] = rtrim($buffer) . "\n";
$buffer = '';
} else {
$buffer .= $char;
}
}
if ($buffer !== '') {
$clean_lines[] = $buffer;
}
fclose($fp);
return $clean_lines;
}
返回的是已剔除字段内\n和\r\n的干净行数组，每项可安全传给str_getcsv()或写入临时文件再用fgetcsv()。
用str_getcsv()替代fgetcsv()并指定引号转义规则
str_getcsv()比fgetcsv()更可控，尤其配合$escape参数能更好处理带引号的换行字段。关键点在于：Excel CSV默认用双引号包裹含逗号/换行的字段，且内部双引号会重复（"abc""def"），必须显式声明。
- 务必传入
'"'作为$enclosure，否则无法识别字段边界 - 设
$escape = '"'（不是反斜杠），才能正确解析"line1\r\nline2"为单字段 - 示例：
str_getcsv($line, ',', '"', '"')—— 第四个参数是$escape，PHP 5.3+ - 若原始CSV用
\转义双引号（少见），则$escape = '\\'，但班级通信录几乎不会这么导出
导入后仍显示异常？检查MySQL字段类型与客户端截断
即使PHP层解析正确，若MySQL列定义为VARCHAR(50)而姓名字段含换行后实际长度超限，插入时会被静默截断——看起来像“换行丢失”，实则是存储层丢弃了后半部分。
排查步骤：
- 执行
SHOW CREATE TABLE student_contact;确认相关字段是TEXT或足够长的VARCHAR - 用
SELECT HEX(name) FROM student_contact LIMIT 1;看是否含0A（\n）或0D0A（\r\n）字节 -
phpMyAdmin等界面可能不渲染换行，改用
SELECT CONCAT('[', name, ']') ...肉眼验证 - 插入前加
mb_strlen($name, 'UTF-8')日志，确认PHP传入长度与预期一致
真正麻烦的从来不是怎么读进来，而是谁在哪个环节悄悄吞掉了你没看见的\r——它可能藏在Excel单元格里，也可能死在MySQL的strict mode警告里，还可能被PDO预处理语句的默认strip_tags式过滤顺手清掉。动手前先var_dump(bin2hex($first_char))看一眼。
