MySQL的使用:
中国人使用软件最大的问题是编码问题,或者说是如何显示、保存汉字。到了网络时代更是如此。MySQL是普遍使用的数据库之一,在使用MYSQL的时候,如何存储汉字也是一个问题。
由于数据库是C/S模式的,所以该问题的解决方案必然包含客户、服务器双方的设置。
通行的解决方案一般有两种:
方案1,客户、服务器双方都采用GBK编码。
方案2,客户、服务器双方都采用UTF-8编码。
方案1的优点是,采用这种设置,无论采用什么样的客户端,都能够显示正确的汉字。但是,在网络程序设计的时候会有些麻烦——因为网页之间的数据传递往往采用ISO-8859-1编码,所以必然存在编码转换的麻烦。具体细节可以参照网络上的多种解释。
如果采用方案2,在进行网络编程的时候问题会少很多,一般不会有编码转换的问题(这只是经验)。但是,当使用命令行的客户端时,不能正确显示汉字。
EMS SQL Manager的一个Bug:不能正确处理汉字!
按照上述原理在使用MySQL的时候,如果创建数据库时采用UTF-8编码,创建字段的时候采用缺省(因为数据库的缺省编码就是UTF-8,所以缺省就是UTF-8),则表中的列应该能够正确的存储并显示汉字。但是,EMS SQL Manager4.5.1.3在多数情况下不能正确地存储汉字;通过其他客户端存储的汉字,也不能正确显示。
中国人使用软件最大的问题是编码问题,或者说是如何显示、保存汉字。到了网络时代更是如此。MySQL是普遍使用的数据库之一,在使用MYSQL的时候,如何存储汉字也是一个问题。
由于数据库是C/S模式的,所以该问题的解决方案必然包含客户、服务器双方的设置。
通行的解决方案一般有两种:
方案1,客户、服务器双方都采用GBK编码。
方案2,客户、服务器双方都采用UTF-8编码。
方案1的优点是,采用这种设置,无论采用什么样的客户端,都能够显示正确的汉字。但是,在网络程序设计的时候会有些麻烦——因为网页之间的数据传递往往采用ISO-8859-1编码,所以必然存在编码转换的麻烦。具体细节可以参照网络上的多种解释。
如果采用方案2,在进行网络编程的时候问题会少很多,一般不会有编码转换的问题(这只是经验)。但是,当使用命令行的客户端时,不能正确显示汉字。
EMS SQL Manager的一个Bug:不能正确处理汉字!
按照上述原理在使用MySQL的时候,如果创建数据库时采用UTF-8编码,创建字段的时候采用缺省(因为数据库的缺省编码就是UTF-8,所以缺省就是UTF-8),则表中的列应该能够正确的存储并显示汉字。但是,EMS SQL Manager4.5.1.3在多数情况下不能正确地存储汉字;通过其他客户端存储的汉字,也不能正确显示。