关于FireDAC的一点疑问，也可能是FireDAC的一个BUG.坛友们有何高见？

存贮过程返回特定某一条记录，这条记录的mobile字段数据我通过MySQL Workbench程序查询出来木有空格，况且VARCHAR(16)字段数据库本身也不容许插入超过16个字符。18这个数字估计正好是"木有手机会怎么样？”这9个汉字（问号也是全角输入的）x2得到的，猜测可能是FireDAC驱动或某数据组件对字段类型分析不适应UTF-8汉字编码或是其它。

存贮过程返回特定某一条记录，这条记录的mobile字段数据我通过MySQL Workbench程序查询出来木有空格，况且VARCHAR(16)字段数据库本身也不容许插入超过16个字符。18这个数字估计正好是"木有手机会怎么样？”这9个汉字（问号也是全角输入的）x2得到的，猜测可能是FireDAC驱动或某数据组件对字段类型分析不适应UTF-8汉字编码或是其它。

重新检查了一下数据库及表字符集设置情况，针对服务器也检查了MY.INI配置文件里确实有如下设置：
[mysql]
default-character-set=utf8
[mysqld]
character-set-server=utf8
collation-server=utf8_general_ci

　　数据库配置出错的可能性较小，另外说明一下就是同一个程序RAD STUDIO SEATTLE图形界面本身正确显示了数据（查询出来的），共用的数据库配置连接池，但不知道为什么通过TFDStoredProc调用存贮过程就抛异常。在网上查了一下存贮过程使用的是MySQL系统范围字符集设置，按说不应用有错，郁闷了。

UTF8对汉字编码最大三个字节，俺的上文已提出来了，从国际化的角度来说一个汉字就是一个字符（非专指ASCII字符），至于用什么编码则是另一回事。MYSQL的V4.1以上版本VARCHAR（１６）字段可以存贮最大１６个汉字，MYSQL会动态根据字符集编码调整存贮字节（UTF8编码对“木有手机会怎么样？”会提供3X9=27个字节（前文有计算错误））。你这个计算长度是没有问题，但不能说明MYSQL问题现象：１、数据库MySQL V5.1，WINDOWS平台，数据库引擎Innodb，缺省字符集从数据库到表和客户端全是UTF-8。
　　　　　２、某表一个字段mobile定义VARCHAR(16)，通过RAD STUDIO SEATTLE图形界面插入一条记录的值为“木有手机会怎么样？”。
　　　　　３、在上述表所在的数据库里有一个存贮过程，需要返回VARCHAR(16)这个mobile字段到客户端，调用存贮过程中返回参数类型同样设置为VARCHAR(16)。调用组件用的是TFDStoredProc配合TFDManager做的MySQL连接池。
　　　　　４、存贮过程调用一直没有问题，但某一个测试人员输入“木有手机会怎么样？”后灾难发生了，FireDAC抛异常提示16个字符空间放不了18个字符！

分析：１、MYSQL数据库官方文档４.１以上版本数据库对于VARCHAR(16)是可以放入不区分英文字符还是汉字字符的16的字符，数据已通过界面录入进表本身也说明了这一点。
　　　２、存贮过程是在数据库内执行，猜测MySQL数据库不至于出这样低级的问题，会不会是FireDAC设置有什么问题？或是干脆是一个BUG(相信不是)，有经验的坛友探讨一二，深度感谢。

更多 0 分享到：

的VARCHAR(16)可以存贮16个汉字，而FireDAC却不认这个怪事。


VARCHAR(16)是否可以存贮16个汉字(UTF8编码),这个直接用SQL提交，最好测试确认一下。
我也持怀疑态度。与编码无关,如果我用一种编码表示所有世上所有文字，每文字要4字节呢？ 16个汉字需要64字节了。这还给不给人扩展编码了。

而 FireDAC是否支持识别这种“变长度”的VARCHAR(16)字段，确实是个问题。

插入１６个汉字没有任何问题，不但用FireDAC测试了，而且用MySQL官方工具MySQL Workbench测试了，但MySQL Workbench调用存贮过程没有问题，FireDAC在超过８个汉字后调用存贮过程返回VARCHAR(16)数据开始出错。目前只能简单扩大，但录入界面检验和数据库校验失去一致性，小的遗憾。后续有什么进展再向同志们汇报。