有道面试题:若一张表中只有一个字段VARCHAR(N)类型,utf8编码,则N最大值为多少?先明白计算的一些规则限制 4.0版本以下,varchar(20),指的是20字节,如果存放UTF8汉字时,只能存6个(每个汉字3字节) 5.0版本以上,varchar(20),指的是20字符,无论存放的是数字.字母还是UTF8汉字(每个汉字3字节),都可以存放20个,最大大小是65532字节 ① 存储限制    需要额外地在长度列表上存放实际的字符长度:小于255为1个字节,大于255则要2个字节② 编码

几个平常用的mysql函数,MySql判断汉字.日期.数字的具体函数分享给大家,具体内容如下 1.判断字符串是否为汉字 返回值:1-汉字 0-非汉字 ? 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 DROP FUNCTION IF EXISTS fc_is_hanzi;   CREATE FUNCTION fc_is_hanzi( p_str VARCHAR(1024) )

项目中有时候需要按照汉字的拼音排序,比如联系人列表.矿物分类等,有的还需要按拼音字母从A到Z分类显示. 如果存储汉字的字段编码使用的是GBK字符集,因为GBK内码编码时本身就采用了拼音排序的方法(常用一级汉字3755个采用拼音排序,二级汉字就不是了,但考虑到人名等都是常用汉字,因此只是针对一级汉字能正确排序也够用了),直接在查询语句后面添加ORDER BY name ASC,查询结果将按照姓氏的升序排序:如果存储姓名的字段采用的是utf8字符集,需要在排序的时候对字段进行转码,对应的代码是ORD

DROP TABLE test_string; ), col_varchar )); INSERT INTO `test_string` VALUES ('mysql', 'mysql'); 在创建数据库表时,为了给一个string类型的数据定义一个数据库中的数据类型,一般参考的都是char或varchar,但这两者的选择有时候让人很纠结,现总结一下两者的区别: (1)CHAR的长度是固定的,而VARCHAR的长度是可以变化的. 比如,存储字符串“mysql＂,对于CHAR(10),表示你存储的

字符与字节的区别 一个字符由于所使用的字符集的不同,会并存储在一个或多个字节中,所以一个字符占用多少个字节取决于所使用的字符集 注意:char与varchar后面接的数据大小为存储的字符数,而不是字节数   char与varchar的差异   为方便说明,我们下面定义一个表: CREATE TABLE `t_users` ( `name` CHAR(10) NOT NULL, `subject` VARCHAR(10) NOT NULL, `description` CHAR(10) NOT N

Unicode/UCS总结: UCS和Unicode使用最大32bit来表示字符(它的范围很大,但不一定全使用,常使的是UCS-2),它用2~4个字节的空间描述了已知的接近全部的字符(并且仍在更新,还会把笑脸之类的字符也放入其中), 而通常使用的plane 0也就是UCS-2,使用2个字节描述了比较常用的字符,包括大量的CJK文字,所以大家平常能用到的字符大体都在UCS-2中包括了. 需要注意的是,Unicode只是一个符号集,它只规定了符号的二进制代码,却没有规定这个二进制代码应该如何存储.

数据库建表  字符串字段类型的选择 char与varchar的区别: char      长度固定,char(M)类型的数据列里,每个值都占用M个字节,如果某个长度小于M,MySQL就会在它的右边用空格字符补足．(在检索操作中那些填补出来的空格字符将 被去掉) varchar  长度可变,在varchar(M)类型的数据列里,每个值只占用刚好够用的字节再加上一个用来记录其长度的字节(即总长度为L+1字节)． 比如char(255)和varchar(255)存储字符串"hello world&qu

一.char 和 varchar 的区别: 1)取值范围: char:取值范围:0~255 varchar:取值范围:0~65535 2)空间占用与速度: char: 定长字符串,占用空间大,速度快,一般用于固定长度的表单提交数据存储,例如:身份账号.电话号码.密码等 varchar:变长字符串,占用空间小,速度慢 3)存储与检索数据: char:存储的数据是否达到了给定值的字节,都要占用给定值大小的空间,不足的自动用空格填充,在检索时后面的空格会被自动去裁剪掉. 如:定义  tel char(

-- 创建汉字拼音对照临时表 CREATE TABLE IF NOT EXISTS `t_base_pinyin` ( `pin_yin_` varchar(255) CHARACTER SET gbk NOT NULL, `code_` int(11) NOT NULL, PRIMARY KEY (`code_`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1; 二.插入对照数据 复制代码 代码如下: -- 插入数据 INSERT INTO t_base_pin

写在前面 面试的时候突然有一位面试官问,说说CHAR和VARCHAR的区别,懵逼了,想自己平常使用的时候直接把VARCHAR拿来就用,真没注意到其中的不同. 反思,为什么没有注意到他们的不同 对于mysql知识体系建立的不完备,借用<如何高效学习>里面提到的观点是: mysql这座城市里,建立的高速公路不够完备,所有的知识体系之间没有建立关联关系.这也是问到其中的知识一脸懵逼的原因. 平常使用时候,没有多问"为什么",为什么我们使用VARCHAR而不是使用CHAR,使用VA

摘自:http://dev.mysql.com/doc/refman/5.6/en/char.html In contrast to CHAR, VARCHAR values are stored as a 1-byte or 2-byte length prefix plus data. The length prefix indicates the number of bytes in the value. A column uses one length byte if values re

按照汉字的拼音排序,用的比较多是在人名的排序中,按照姓氏的拼音字母,从A到Z排序: 如果存储姓名的字段采用的是GBK字符集,那就好办了,因为GBK内码编码时本身就采用了拼音排序的方法(常用一级汉字3755个采用拼音排序,二级汉字就不是了,但考虑到人名等都是常用汉字,因此只是针对一级汉字能正确排序也够用了). 直接在查询语句后面 添加 order by name asc; 查询结果按照姓氏的升序排序: 如果存储姓名的字段采用的是 utf8字符集,需要在排序的时候对字段进行转码:对于的代码是  or

按照汉字的拼音排序,用的比较多是在人名的排序中,按照姓氏的拼音字母,从A到Z排序: 如果存储姓名的字段采用的是GBK字符集,那就好办了,因为GBK内码编码时本身就采用了拼音排序的方法(常用一级汉字3755个采用拼音排序,二级汉字就不是了,但考虑到人名等都是常用汉字,因此只是针对一级汉字能正确排序也够用了). 直接在查询语句后面 添加 order by name asc; 查询结果按照姓氏的升序排序: 如果存储姓名的字段采用的是 utf8字符集,需要在排序的时候对字段进行转码:对于的代码是  or

mysql中文显示乱码或者问号是因为选用的编码不对或者编码不一致造成的,最简单的方法就是修改mysql的配置文件my.cnf.在[mydqld]和[client]段加入 default-character-set=utf8 (有的版本不支持default-character-set=utf8,用character_set_server=utf8来取代 default-character-set=utf8即可) 注:如果没有[client]就手工加入[client]段 ( 5.0以上版本修改方法:

今天使用mysql出现 Incorrect string value: '\xE8\xA7\x84\xE5\x88\x99' for column 'name' 异常 通过查找问题,发现是字段编码不支持中文.于是把表的编码设置支持中文即可. 第一次的表: "create table  friendsList (id varchar(7) primary key,name varchar(20)) ;" 第二次修改后的表 "create table  friendsList (

按照汉字的拼音排序,用的比较多是在人名的排序中,按照姓氏的拼音字母,从A到Z排序: 如果存储姓名的字段采用的是GBK字符集,那就好办了,因为GBK内码编码时本身就采用了拼音排序的方法(常用一级汉字3755个采用拼音排序,二级汉字就不是了,但考虑到人名等都是常用汉字,因此只是针对一级汉字能正确排序也够用了). 直接在查询语句后面 添加 order by name asc; 查询结果按照姓氏的升序排序: 如果存储姓名的字段采用的是 utf8字符集,需要在排序的时候对字段进行转码:对于的代码是  or

之前在网上查找了很多方法,排在前排的都是修改配置文件my.ini的,没有成功,后来找到了一个解决方法: 在建表的时候,在语句后面加上段"engine = innodb default charset = gbk",这样所建的表就可以完整的存储汉字而不会乱码了. 比如: 新建了一张test表,插入汉字值: 此时数据库中的值会乱码.然后删除该test表: 删除之后再重新建表,在建表语句后面加上一句: 然后再插入汉字值: 此时数据库的值查询出来就能正常的显示了.

按照汉字的拼音排序,用的比较多是在人名的排序中,按照姓氏的拼音字母,从A到Z排序: 如果存储姓名的字段采用的是GBK字符集,那就好办了,因为GBK内码编码时本身就采用了拼音排序的方法(常用一级汉字3755个采用拼音排序,二级汉字就不是了,但考虑到人名等都是常用汉字,因此只是针对一级汉字能正确排序也够用了). 直接在查询语句后面 添加 order by name asc; 查询结果按照姓氏的升序排序: 如果存储姓名的字段采用的是 utf8字符集,需要在排序的时候对字段进行转码:对应的代码是 ord

Incorrect string value: '\xE6\x9B\xB9\xE5\x86\xAC...' for column 'realname' at row 1 该情况一般是由数据库设计时的编码错误导致的. show variables like 'character%'   查看数据库编码,为latin1. 如果项目正在测试当中,数据不重要的话,一劳永逸的解决办法是,使用 alert database tuanplus character set utf8 更改数据库的编码格式,再重新

因为数据库中可以设定表的编码格式,不同编码格式下,中文的排序有区别,下面分别介绍常用编码下的排序方法. 1.如果数据表的某字段的字符编码是 utf8_general_ci,排序写法: ORDER BY CONVERT(表别名.字段名 USING gbk) COLLATE gbk_chinese_ci ASC; 例子 SELECT * FROM mg_clinic mc ORDER BY CONVERT(mc.`CLNAME` USING gbk) COLLATE gbk_chinese_ci A

一.差异 1.占用存储空间上 char 初始化时占固定空间,varchar依据插入内容大小使用空间. 2.char最大字符长度255个(约0.1KB),varchar则是65535(约192KB). 3.存储时,char只保留前空格,varchar保留前后空格. 4.相同长度定义下,在管理上,varchar 比 char 多占用一个字节来存储长度信息. 二.相同 char(M) 和 varchar(M) 都是只能存储M个字符,无论中英文,超出自动截断.