编辑手记:很多人在进行数据库导入导出操作的时候会遇到字符集的问题,今日拣选了 《循序渐进Oracle》一书中的相关章节,希望对初学Oracle的朋友有所帮助。 在传统的EXP导出文件中,记录着导出使用
在部署重构版测试环境时,需要创建Oracle数据库,使用dbca创建数据库之后没有注意数据库本身的字符集,导致后续所有的数据库脚本执行后中文乱码。最后的解决办法是清掉全库数据,再修改字符集,重启数据库。
[ ] 中的关键字可以选择不加,IF NOT EXISTS 的意思是如果不存在才创建 数据库
在显示 utf8中文数据时会乱码,但是你用cmd告诉MySQL服务器器我使用的是GBK,你要给我返回GBK数据就可以正常显示了,如下图。这也是为什么PHP,Java,Python等编程连接数据库时都要指定数据库的结果集。
1.数据库字符集:数据库需要存储多国语言选择AL32UTF8,只有中英文选择ZHS16GBK
【 CleverCode发表在csdn博客中的原创作品,请勿转载,原创地址:http://blog.csdn.net/clevercode/article/details/46377577】
很多刚接触的朋友经常会搞混这两个字符集,数据库字符集是在创建数据库时进行指定的,不建议更改!而客户端字符集是可以随时更改的!
这个系列的文章是根据《MySQL是怎样运行的:从根儿上理解MySQL》这本书的个人笔记总结专栏,这里十分推荐大家精读一下这本书,也是目前市面上个人所知的讲述Mysql原理的为数不多的好书之一,好了废话不多说我们下面进入正题。
上一篇呢,从理论上介绍了MYSQL字符集和校对规则是什么以及如何正确的使用字符集;关于第一部分的内容可参考:深入理解MySQL字符集及校对规则(一)
最近业务中需要用 Python 写一些脚本。尽管脚本的交互只是命令行 + 日志输出,但是为了让界面友好些,我还是决定用中文输出日志信息。
这里要注意字符集应和校对规则名称相对应,不可一边UTF8 一边GBK, 如若没有指定字符集和校对规则名字,则会按照默认MySQL默认方式(MySQL目录 my.ini配置文件)创建数据库,下面给出一些常用的字符集以及校对规则名称。
NLS(National Language Support,国家语言支持)是数据库的一个非常强大的特性,控制着数据的许多方面,最重要的两个方面包括:1、文本数据采用何种编码存储在磁盘上。2、透明地将数据从一个字符集转换到另一个字符集。Oracle字符集可以分为数据库字符集和客户端字符集。客户端字符集定义了客户端字符数据的编码方式,任何发自或发往客户端的字符数据均使用客户端定义的字符集编码,客户端可以看作是能与数据库直接连接的各种应用,例如SQL*Plus、exp/imp等。客户端字符集是通过设置NLS_LANG参数来设定的。
在开发中常常碰到,需要导入dmp文件到现有数据库。这里的dmp文件可能来自于其它系统,所以,一般情况下是不知道导出程序(exp)的版本、导出时间或者导出模式等信息的。那么如何从现有的dmp文件中获取到这些信息呢?下面作者将一一讲解。
mysql -uroot -poldboy -S /data/3306/mysql.sock
以下配置项是Linux系统的本地化(localization)设置,用于控制系统在不同方面如何呈现和处理数据。下面是每个配置项的解释:
Q:什么是存储引擎? A:比如一个视频文件可以转成mp4,avi,wmv,而存储进磁盘中也会存在不同类型的文件系统中如linux中的ext3,ext4,xfs等.(直观区别就是占用系统的空间大小与清晰程度可能不一样);
现象说明:在windows下编辑的内容,上传到linux平台下出现中文乱码。如下: 在windows平台编写haha.txt文件,内容如下: 上传到linux平台,出现中文乱码,如下: 基本上面出现的
1 字符集 字符集就是编码的集合,例如unicode、GBK、GB2312等都属于字符集。
今天有客户向我咨询:数据库由ZHS16GBK字符集修改为AL32UTF8字符集,发现中文的数据中小部分出现乱码,客户认为AL32UTF8明明可以支持更多的文字,不应该出现这样的情况才对。 从现象看,基本可以确认故障是字符集转换导致的,Oracle也强烈不建议做这种字符集转换的操作,幸好该客户的操作只是在一个测试环境中操作的。不过,之前也一直有个误区,我们都知道AL32UTF8是可以支持多国语言的字符集,对于中文字节存储占用空间比ZHS16GBK多,然后第一反应就认为AL32UTF8应该是ZHS16GBK的
在使用MySQL时要注意6个需要编码的地方:系统的编码、客户端、服务端、库、表、列。字符集编码不仅影响数据存储,还影响client程序和数据库之间的交互.在mysql中输入命令show session variables like '%char%'能够看到例如以下一些字符集(下面是以win10为例,生产中多数时linux,在linux里面除了latin1之外都是utf8的字符集):
最近业务中需要用 Python 写一些脚本。尽管脚本的交互只是命令行 + 日志输出,但是为了让界面友好些,我还是决定用中文输出日志信息。 很快,我就遇到了异常: UnicodeEncodeError: 'ascii' codec can't encode characters in position 0-3: ordinal not in range(128) 为了解决问题,我花时间去研究了一下 Python 的字符编码处理。网上也有不少文章讲 Python 的字符编码,但是我看过一遍,觉得自己可以讲得
字符(Character)是各种文字和符号的总称,包括各国家文字、标点符号、图形符号、数字等。 字符集(Character set)是多个字符的集合,字符集种类较多,每个字符集包含的字符个数不同,常见字符集名称:ASCII字符集、GB2312字符集、BIG5字符集、 GB18030字符集、Unicode字符集等。计算机要准确的处理各种字符集文字,需要进行字符编码,以便计算机能够识别和存储各种文字。 字符编码(Character encoding)是把字符集中的某个字符编码为指定字符集中字符,以便文本在计算机中存储和通过通信网络的传递。常见的例子包括将拉丁字母表编码成ASCII,ASCII将字母、数字和其它符号编号,并用7比特的二进制来表示。 字符序(collation)是指同一个字符集内字符之间的比较规则。只有确定字符序后,才能在一个字符集上定义什么是等价的字符,以及字符之间的大小关系。一个字符可以包含多种字符序。MySQL字符序命名规则是:以字符序对应的字符集名称开头,以国家名居中(或以general居中),以ci、cs、或bin结尾。以ci结尾的字符序表示大小写不敏感,以cs结尾的字符序表示大小写敏感,以bin结尾的字符序表示按二进制编码值比较。
Oracle创建数据库时指定字符集,一般不能修改,整个数据库都是一个字符集。虽然还支持指定国家字符集,用于nvarchar2类型,不过很少用到。常用的字符集:AL32UTF8和ZHS16GBK,其中AL32UTF8与UTF8几乎是等价的。一个汉字在AL32UTF8中占三个字节,而在ZHS16GBK中占用两个字节。
3、字符无需区分大小写时,采用默认的xx_ci校验集可以,否则选择xx_bin校验集(生产环境中,尽量不要修改校验集)
查看数据库编码: show create database db_name; 查看表编码: show create table tbl_name; 查看字段编码: show full columns from tbl_name; show full fields from tbl_name;
上篇我们介绍了mysql字符集的种类,主要windows用gbk,mac默认utf8,还有字符集的服务器级别,数据库级别,表级别,连行都有级别,每一行都可以有不同的字符集:
何剑敏 Oracle ACS华南区售后团队,首席技术工程师 曾供职于中国联通信息计费部、卓望数码,系统支撑部首席DBA,负责中国移动全网梦网业务和移动应用商城数据库维护。后供职于IBM,负责米其林项目和澳洲电信(Telstra)项目数据库管理。现供职于Oracle ACS华南区售后团队,首席技术工程师。多年从事第一线的数据库运维工作,有丰富项目经验、维护经验和调优经验,专注于数据库的整体运维。 编辑手记:字符集是数据库中很复杂的一个问题,通常设定后不做改变,但因生产的需要,也提供通过导入导出或命令修改的
MySQL数据库具有跨平台性,不仅可以在Windows上运行,还可以在UNIX,Linux和Mac OS等操作系统上运行
在MySQL中,最常见的字符集有ASCII字符集、latin字符集、GB2312字符集、GBK字符集、UTF8字符集等,下面我们简单介绍下这些字符集:
http://www.eygle.com/special/NLS_CHARACTER_SET_03.htm
在文章开始前,大家可以先考虑几个问题,这样方便更快理解文章的知识点,下面的问题都会在文章中找到答案哦!
今天在写一个StringIO.write(int)示例时思维那么一发散就拐到了字符集的问题上,顺手搜索一发,除了极少数以外,绝大多数中文博客都解释的惨不忍睹,再鉴于被此问题在oracle的字符集体系中蹂躏过,因此在过往笔记的基础上增删了几个示例贴出来。
当我们创建数据没有指定字符集和校验规则时,系统使用默认字符集:utf8,校验规则:utf_general_ci;
上篇文章我们说了mysql客户端到服务端会不同的字符集不断转换,其中服务端有三个重点的系统变量,1.处理客户端发来的字节串:character_set_client。2.吧请求的字节串从character_Set_cliect转成character_set_connection。3.吧字节串返回给客户端:character_Set_result。
重新登录之后生效。 现在查看一下当前设置: [plain] view plain copy
PostgreSQL 中的字符集支持允许以各种字符集(也称为编码)存储文本,包括单字节字符集,如 ISO 8859系列和多字节字符集,如 EUC (EUC)、 UTF-8和 Mule 内部代码。所有支持的字符集都可以由客户机透明地使用,但是有一些字符集不支持在服务器中使用(即作为服务器端编码)。使用 initdb 初始化 PostgreSQL 数据库集群时选择了默认字符集。在创建数据库时可以重写它,因此可以使用多个数据库,每个数据库具有不同的字符集。
当向 MySQL 数据库插入一条带有中文的数据形如 insert into employee values(null,'小明','female','2018-03-28','2018-03-29','Sales',2018,'从事互联网工作!'); 出现乱码时,可以使用语句 show variables like 'character%'; 来查看当前数据库的相关编码集。
ORA-02374: conversion error loading table "QBJMES"."PROJECT"
con = cx_Oracle.connect("pythondemo","welcome","192.168.188.11:1521/std1")
说明系统已安装中文语言包,无需再安装。重要提示,如果按照下面的步骤你的系统仍然无法使用中文,那么请一个一个尝试上面的编码方式。比如把LANG="zh_CN"修改为LANG="zh_CN.gb18030"。
set character_set_client = gbk; -- 来自客户端的语句的字符集。服务器使用character_set_client变量作为客户端发送的查询中使用的字符集。
数据库是mysql 向数据库insert数据的时候,一直显示这个错误,在网上查找了许多相关,大致的问题是: 1:所存储的数据与数据库表的字段类型定义不相匹配. 2:字段类型是否正确, 是否越界, 有无把一种类型的数据存储到另一种数据类型中. 3:写的SQL语句里列的数目和后面的值的数目不一致。 经过检查后并不是以上问题产生, 而是字符集问题,导致insert发生错误了, 后来试过设置数据库编码和项目编码统一为utf-8,仍然解决不了问题 。 最后发现,假设数据库的默认字符集是GBK,假设创建了表 table,那么table的字符集是GBK, 之后再设置数据库的字符集为utf-8,如图下显示:
答:taskctl安装后默认的用户名密码都是admin,后期的用户、密码都是通过Admin程序来管理。
文章目录 MySQL_字符集及数据类型 1.字符集 2.校对集 3.MySQL的数据类型--值的类型 (1)整型 (2)unsigned(无符号) (3)显示宽度(zerofill) (4)浮点型 (
背景:目前正在进行业务重构,需要对使用MySQL的业务库表进行重新设计,在迁移时,遇到了中文字符乱码问题(源库表的默认编码是LATIN1,新库表的默认编码为UTF8),故重新学习了下MySQL编码和解码相关知识,并整理了在遭遇乱码时的一些常用技巧。(本文发布于云+社区:https://cloud.tencent.com/developer/article/1370123)
对于MySQL自带的客户端来说,这个编码过程使用的字符集和我们使用的操作系统的默认字符集是一样的,类Unix系统的默认字符集就是utf8,Windows系统的默认字符集就是gbk。
最近在工作中遇到了一个说大不大说小不小的问题,就是当我解析一个xml文件的时候,抛出了一个"Invalid byte 2 of 2-byte UTF-8 sequence"的异常,这个异常会导致解析直接退出,显然不能容忍。查阅相关资料稍微定位了一下,大概知道是字符集的问题,仔细一看,xml文件中的确有中文字符,而且当我把这些中文字符删了之后的确又能解析成功。不过我还是不能理解这当中的缘由,不过由于时间原因,当时只是把中文字符删了就草草完工。现在回头想想这个坑还是不能留,顺便趁机补下字符集相关的知识。
看到题目,你也许会说,“又是这种月经帖,这问题我早弄清楚了”. 但如果有人问你,“Unicode,GBK和UTF-8有什么区别?”, 你能自信地给他一句简短清晰的回答吗? 如果不能的话, 那还是看一下
最近的SQL优化工作中经常遇到因字符集或校验规则不一致导致索引使用不了的问题,修改表的字符集或校验规则相当于把表重构,表中数据量大时,处理起来费时费力,希望应用开发者在设计之初时注意到此问题,让后期接手运维的小伙伴少一些负担。GreatSQL的字符集和校验规则种类繁多,提供灵活性的同时,也带来使用混乱的烦恼。本文对字符集做一个总结,让读者对GreatSQL的字符集有一个全面的了解。
领取专属 10元无门槛券
手把手带您无忧上云