day09-数据库插入中文报错

本文详细介绍了如何在MySQL中解决中文乱码问题,通过修改数据库编码为UTF8或GBK,确保客户端、连接、数据库和服务器编码一致,实现中文正常存储。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

在向数据库表中插入中文时一直报错

MySQL的默认编码是Latin1,不支持中文,要支持中文需要把数据库的默认编码修改为gbk或者utf8。 
1、需要以root用户身份登陆才可以查看数据库编码方式(以root用户身份登陆的命令为:>mysql -u root –p,之后输入root用户的密码)。
查看数据库的编码方式命令为:

mysql> show variables where Variable_name like '%char%';
+--------------------------+----------------------------+
| Variable_name            | Value                      |
+--------------------------+----------------------------+
| character_set_client     | utf8                       |
| character_set_connection | utf8                       |
| character_set_database   | latin1                     |
| character_set_filesystem | binary                     |
| character_set_results    | utf8                       |
| character_set_server     | latin1                     |
| character_set_system     | utf8                       |
| character_sets_dir       | /usr/share/mysql/charsets/ |
+--------------------------+----------------------------+
8 rows in set (0.08 sec)

从以上信息可知数据库的编码为latin1,需要修改为gbk或者是utf8; 
其中,character_set_client为客户端编码方式;
character_set_connection为建立连接使用的编码;
character_set_database数据库的编码; 
character_set_results结果集的编码; 
character_set_server数据库服务器的编码; 
只要保证以上四个采用的编码方式一样,就不会出现乱码问题。 

mysql> set character_set_database=utf8;
Query OK, 0 rows affected, 1 warning (0.00 sec)
mysql> set character_set_server=utf8;
Query OK, 0 rows affected (0.00 sec)

mysql> show variables where Variable_name like '%char%';
+--------------------------+----------------------------+
| Variable_name            | Value                      |
+--------------------------+----------------------------+
| character_set_client     | utf8                       |
| character_set_connection | utf8                       |
| character_set_database   | utf8                       |
| character_set_filesystem | utf8                       |
| character_set_results    | utf8                       |
| character_set_server     | utf8                       |
| character_set_system     | utf8                       |
| character_sets_dir       | /usr/share/mysql/charsets/ |
+--------------------------+----------------------------+
8 rows in set (0.01 sec)

注意:需要将数据库删除后重新建立才可以生效

mysql> drop database test;
Query OK, 2 rows affected (0.04 sec)

mysql> create database test;
Query OK, 1 row affected (0.00 sec)

mysql> use test;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Database changed
插入数据库再查看就可以存入中文了 mysql
> select * from dataCenter; +--------------+----------------+-------------------+-------------------+---------------------+-----------------+ | dataCenterId | dataCenterName | dataCenterAddress | dataCenterLinkman | dataCenterTelephone | dataCenterEmail | +--------------+----------------+-------------------+-------------------+---------------------+-----------------+ | 1 || | | | | +--------------+----------------+-------------------+-------------------+---------------------+-----------------+ 1 row in set (0.00 sec)

 

转载于:https://www.cnblogs.com/dxnui119/p/10191458.html

Oracle数据库报错“无效的月份”(通常对应错误代码ORA-01843)是由于在插入或更新日期类型的字段时,系统无法正确解析提供的月份信息所导致的。该问题可能由多种因素引起,包括但不限于会话语言设置、日期格式不匹配、特定函数使用不当等。 ### 常见原因分析 #### 1. **NLS_LANGUAGE 设置不一致** 如果当前数据库会话的语言环境设置为中文(`SIMPLIFIED CHINESE`),但输入的日期字符串中月份部分使用英文缩写(如 `JAN`, `FEB` 等),则 Oracle 将无法识别这些月份名称,从而抛出“无效的月份”错误[^1]。例如,在以下语句中: ```sql INSERT INTO customers VALUES (1, 'John', 'Brown', '01-JAN-65', '800-555-1211'); ``` 如果当前会话的语言设置为中文,则 `'01-JAN-65'` 中的 `JAN` 将被视为无效月份名称。 #### 2. **日期格式与 NLS_DATE_FORMAT 不匹配** Oracle 使用 `NLS_DATE_FORMAT` 参数控制默认的日期显示和解析格式。如果插入的日期值格式与当前会话的 `NLS_DATE_FORMAT` 不一致,也可能导致此错误。例如,若 `NLS_DATE_FORMAT` 被设置为 `YYYY-MM-DD`,而插入的日期为 `'01-JAN-65'`,则可能导致解析失败。 #### 3. **使用 INTERVAL 函数导致非法日期** 当使用 `INTERVAL` 函数进行日期计算时,可能会生成不存在的日期。例如,从 `2023-08-31` 减去 11 个月得到 `2022-09-31`,而 9 月没有 31 号,因此触发 ORA-01839 错误,提示“指定月份的日期无效”[^2]。 #### 4. **AWR/ASH 报告调用中的 NLS 设置问题** 在调用 `dbms_workload_repository.ash_report_html` 等内置包生成报告时,如果会话的 `NLS_LANG` 或 `NLS_DATE_FORMAT` 设置不当,也可能引发 ORA-01843 错误。此时可以通过调整会话参数来规避问题[^3]。 --- ### 解决方案 #### 1. **修改会话语言设置** 可以临时更改当前会话的语言环境为英文,以支持英文月份缩写: ```sql ALTER SESSION SET NLS_LANGUAGE = AMERICAN; ``` 执行该语句后,再运行插入操作即可成功解析 `'01-JAN-65'` 这类日期值[^1]。 #### 2. **统一日期格式** 建议显式指定日期格式以避免歧义。可以使用 `TO_DATE` 函数明确转换字符串为日期,并指定格式模型: ```sql INSERT INTO customers VALUES (1, 'John', 'Brown', TO_DATE('01-JAN-65', 'DD-MON-YY'), '800-555-1211'); ``` 这种方式不受 `NLS_DATE_FORMAT` 和 `NLS_LANGUAGE` 的影响,确保日期解析的一致性。 #### 3. **处理 INTERVAL 导致的非法日期** 对于涉及 `INTERVAL` 的日期运算,应在执行前检查目标月份是否具有31天。例如,可以编写一个条件判断逻辑: ```sql SELECT CASE WHEN EXTRACT(DAY FROM SYSDATE) = 31 THEN ADD_MONTHS(SYSDATE, -11) - 1 ELSE ADD_MONTHS(SYSDATE, -11) END AS adjusted_date FROM dual; ``` 这样可以避免因生成非法日期而导致的错误。 #### 4. **配置 NLS_LANG 环境变量** 在操作系统级别设置 `NLS_LANG` 环境变量为英文格式,如: ``` NLS_LANG=AMERICAN_AMERICA.ZHS16GBK ``` 同时在会话中设置日期格式: ```sql ALTER SESSION SET NLS_DATE_FORMAT='MM-DD-YY'; ``` 这有助于解决 AWR/ASH 报告生成过程中出现的日期解析问题[^3]。 --- ### 最佳实践建议 - 在所有涉及日期的 SQL 操作中,始终使用 `TO_DATE()` 显式转换日期字符串,并提供格式模型。 - 避免依赖隐式的日期格式转换,特别是在多语言环境中。 - 定期检查数据库和会话级别的 NLS 设置,确保其与应用程序需求一致。 - 对于涉及时间间隔的操作,应考虑边界情况并添加必要的异常处理机制。 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值