phpEnv解决MySQL 1366错误 phpEnv插入特殊字符报错-php教程-PHP中文网

必须修改phpenv的my.ini全局启用utf8mb4，仅php中set names utf8mb4无效；需在client[mysqld]三节配置default-character-set或character-set-server，并重启mysql服务，再配合php连接声明及表字段utf8mb4化。

phpenv解决mysql 1366错误 phpenv插入特殊字符报错

phpEnv 下 MySQL 1366 错误必须改 my.ini，只在 PHP 里 SET NAMES utf8mb4 没用——因为 phpEnv 的 MySQL 默认没启用 utf8mb4 支持，连接层和服务器层全卡在 utf8（即 utf8mb3）上。

phpEnv 的 `my.ini` 必须全局启用 `utf8mb4`

phpEnv 封装的是 Windows 版 MySQL，其默认配置几乎全是 utf8，但 MySQL 的 utf8 不支持 emoji 和部分生僻汉字。不改配置文件，PHP 层再怎么设字符集都只是“表面握手”，底层仍拒收四字节 UTF-8 序列。

打开 phpEnv\MySQL\my.ini（路径可能含版本号，如 phpEnv\MySQL\5.7.31\my.ini）

在 [client]、[mysql]、[mysqld] 三节下分别添加或修改以下行：

[client]
default-character-set = utf8mb4

[mysql]
default-character-set = utf8mb4

[mysqld]
character-set-server = utf8mb4
collation-server = utf8mb4_unicode_ci

保存后**必须重启 phpEnv 的 MySQL 服务**（不是重启面板，是进 Windows 服务管理器重启 MySQL_phpEnv 类似名称的服务）
验证是否生效：mysql -u root -p -e "SHOW VARIABLES LIKE 'character_set%';"，确认 character_set_client、character_set_server、character_set_database 全为 utf8mb4

PHP 连接时仍要显式声明 `utf8mb4`，但仅限连接初始化阶段

即使 my.ini 已改，PHP 的 MySQL 扩展（mysqli 或 PDO）默认仍按旧协议协商字符集。不主动声明，就可能回落到 latin1 或 utf8。

btpanel phpsite 宝塔面板PHP网站

宝塔面板 PHP 网站管理：站点创建、删除、启停、PHP 版本切换、域名管理、SSL证书管理、伪静态管理、数据库管理

下载

mysqli 方式：创建连接后立即执行 $mysqli->query("SET NAMES utf8mb4");
PDO 方式：DSN 中加 ;charset=utf8mb4，例如：new PDO("mysql:host=127.0.0.1;dbname=test;charset=utf8mb4", $user, $pass);
不要用 mysql_query("SET NAMES utf8") —— utf8 在 MySQL 里就是 utf8mb3，对 emoji 无效
如果用 ThinkPHP 等框架，确保配置项 'charset' => 'utf8mb4'，且数据库连接建立后无二次覆盖

表和字段也得是 `utf8mb4`，不能只靠建库时指定

phpEnv 新建数据库时若未指定字符集，默认仍是 latin1 或 utf8。已有表更不会自动升级——ALTER DATABASE 只改默认值，不影响已有表结构。

查当前表编码：SHOW CREATE TABLE `your_table`;，确认字段定义含 CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci
批量转表：ALTER TABLE `your_table` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

新建表务必显式声明：

CREATE TABLE `test` (
  `id` INT PRIMARY KEY,
  `name` VARCHAR(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

注意：utf8mb4_unicode_ci 比 utf8mb4_general_ci 更准，推荐优先用前者

导入 CSV 或 SQL 文件前，必须检查真实编码而非文件声明

phpEnv 常用于本地开发，数据多来自 Excel 导出、微信后台或爬虫，这些来源常带 BOM、GBK 编码却标称 UTF-8、或混入 Windows-1252 引号——此时直接 source xxx.sql 必报 1366。

先用命令看真实编码：file -i your_file.sql（Windows 可用 PowerShell Get-Content your_file.sql -Encoding Byte | Select-Object -First 10 查 BOM）
若为 GBK，先转码：iconv -f GBK -t UTF-8//IGNORE your_file.sql > cleaned.sql
若含 BOM，用编辑器另存为“UTF-8 无 BOM”格式，或用 sed -i '1s/^\xEF\xBB\xBF//' cleaned.sql（Linux/macOS）
绝对别信 Excel 导出的 CSV 声称是 UTF-8——它大概率是 ANSI（即 GBK），强转会把中文变乱码

最易被忽略的是：phpEnv 的 MySQL 配置文件有多个层级（my.ini、my.cnf、甚至注册表加载路径），改错文件等于白改；还有人改了 my.ini 却没重启服务，或者重启了面板但没重启 MySQL 进程——这两处卡住，后面所有 PHP 层操作都是徒劳。