php判断用户输入字符串长度_php表单输入长度校验【教程】

必须用 m

b_strlen() 而非 strlen() 校验中文字符串长度，因 strlen() 按字节计算导致“你好”返回6，而用户感知为2个字符；需显式指定 'UTF-8' 编码、启用 mbstring 扩展，并配合前端 JS 的 Array.from().length 及后端清洗（trim、去零宽字符）确保准确。

用 strlen() 还是 mb_strlen()？中文输入必须分清

PHP 判断用户输入字符串长度，最常踩的坑就是用 strlen() 量中文——它按字节算，一个 UTF-8 中文占 3 字节，strlen("你好") 返回 6，但用户眼里是 2 个字符。表单校验要的是“用户感知的长度”，不是字节长度。

正确做法：统一用 mb_strlen($str, 'UTF-8')，并确保 PHP 已启用 mbstring 扩展（绝大多数现代环境默认开启）。如果不确定，先检查：extension_loaded('mbstring')。

• 表单接收后立即用 mb_strlen($_POST['username'], 'UTF-8') 校验
• 若前端传了非 UTF-8 编码（极少见），需先 mb_convert_encoding() 转换，否则结果不可靠
• mb_strlen() 第二个参数不写可能 fallback 到 mb_internal_encoding()，建议显式传 'UTF-8'

表单提交前 JS 校验和 PHP 后端校验必须都做

前端用 JavaScript 的 input.length 或 new Blob([input]).size 都不准——JS 的 String.prototype.length 对 UTF-16 代理对处理不一致，比如 emoji ?（U+1F30D）在 JS 中算 2，但用户只当 1 个字符。所以 JS 层建议用 Array.from(input).length 或 input.codePointAt() 循环计数，更稳妥。

但无论 JS 多准，PHP 后端校验绝不能省。用户可禁用 JS、绕过前端、用 curl 直接 POST 脏数据。

• JS 示例（兼容 emoji）：Array.from(document.getElementById('title').value).length > 20
• PHP 示例：if (mb_strlen($_POST['title'] ?? '', 'UTF-8') > 20) { die('标题不能超过20个字符'); }
• 注意空值：用 $_POST['field'] ?? '' 避免未定义索引警告

max_length 和 maxlength 不是一回事，别指望 HTML 属性保平安

是浏览器原生限制，仅防误操作，完全可被绕过（删掉属性、改 DOM、用 Postman 提交）。而数据库字段的 max_length（如 MySQL 的 VARCHAR(50)）是存储层约束，触发时抛出 SQL 错误，不是友好的用户提示。

真正可控、可定制提示、可统一处理的，只有 PHP 层的逻辑校验。把它当成唯一可信防线。

• HTML 的 maxlength 可以留着提升体验，但绝不依赖
• 数据库字段长度应 ≥ PHP 校验上限（例如 PHP 限制 30，DB 设 VARCHAR(32)），留点余量防编码转换或 BOM 等意外
• 若用 Laravel / Symfony 等框架，优先走 Validation 规则（如 'title' => 'required|string|max:20'），底层仍是 mb_strlen

特殊字符、空格、不可见符容易让长度“偷偷超标”

用户复制粘贴时可能带全角空格、零宽空格（\u200B）、BOM、换行符等。这些字符 mb_strlen() 全部计入，但肉眼难察觉，导致“明明没输满却提示超长”。

建议在 PHP 校验前做轻量清洗：

• 用 trim() 去首尾空白（含全角空格、\r\n\t 等）
• 用 preg_replace('/[\x{200B}-\x{200D}\x{FEFF}]/u', '', $str) 清零宽字符（正则需 /u 修饰符）
• 若业务允许，可额外加 mb_ereg_replace('^\s+|\s+$', '', $str) 更彻底去空格
• 清洗后再用 mb_strlen() 校验，避免用户困惑

字符边界永远比看起来复杂——emoji、中日韩标点、组合字符（如带声调的拉丁字母）、双向文本控制符……只要涉及用户自由输入，就得默认它们存在。校验逻辑里多一行清洗，比上线后收一堆“为什么我只打了5个字就报错”的工单划算得多。