数据库中文字段是乱码,如何转码?

lashengcrh 2013-11-08 03:28:14
客户的数据库好像是使用了字符集是Latin1_General_BIN (即 ISO-8859-1),

英文和数字字段都可以正常读取,只有中文字段或中英文混合字段不行,有乱码。怎么办?
...全文
1179 20 打赏 收藏 转发到动态 举报
写回复
用AI写文章
20 条回复
切换为时间正序
请发表友善的回复…
发表回复
lashengcrh 2013-12-18
  • 打赏
  • 举报
回复
大家说的对,就是变态的客户信息科的人,安装数据库时,选的这个字符集,他们又懒得改,就麻烦我们这些做开发的人。
bcrun 2013-11-29
  • 打赏
  • 举报
回复
哈哈,大家说得都差不多了,我顺便问下,楼主你这是哪种数据库。不同数据库的处理方式稍有区别,原理相通。
  • 打赏
  • 举报
回复
str=new String(obj.getBytes("ISO-9958-1"),"GBK");
of123 2013-11-21
  • 打赏
  • 举报
回复
要分析用户的实际需求,为什么既要采用汉字,又要使用 ISO/IEC 8859-1 字库? 实际上在 TextBox 的属性中,就有 Font 可以选择字库。但有一个问题,如果选择了中文字库,那西文中对应于 A0 - FF 的编码就不能显示。老外也会认为“出了乱码”。因为大多数控制只能设置一种字体。 具体怎样做,要看同一个字段中是否需要兼容中文和编码大于 128 的西文。如果不需要,可以将用来显示不同字段的控件选不同的字体库。如果需要,就麻烦一些,需要通过分析 Unicode 识别出东西方文字,再像老马所说,利用 RichTextBox 的 SelectionFont 属性动态设置字体。
嗷嗷叫的老马 2013-11-21
  • 打赏
  • 举报
回复
那要是他换成RichTextBox应该就能显示了?
of123 2013-11-20
  • 打赏
  • 举报
回复
B3 C2 D3 D7 BE BB,用中文简体字库,显示出来就是 "陈幼净",无非是宋体、楷体之类的区别。 这个编码,用 ISO/IEC 8859-1 字库显示,就是 "³ÂÓ×¾»"。
of123 2013-11-20
  • 打赏
  • 举报
回复
打个比方,我们早先一个名牌产品叫“马戏扑克”,大小王是小丑,上海出产的。盒子上印的是 MAXIPUKE,汉语拼音。 出口到美国却无人问津,因为美国人看到的是 Maxi Puke,最大呕吐。
of123 2013-11-20
  • 打赏
  • 举报
回复
编码没有问题。在 ISO/IEC 8859-1 下显示 "³ÂÓ×¾»",说明其编码就是 B3 C2 D3 D7 BE BB。即汉字"陈幼净"的编码。 问题出在如何解释编码,也就是如何根据编码调用字库信息来显示文字图形。
TonyXQQ 2013-11-19
  • 打赏
  • 举报
回复
程序中调用iconv解码或者用MultiBytetoWideChar,WideChartoMultiByte来转码
lliai 2013-11-19
  • 打赏
  • 举报
回复
打开方式可以用 GBK:0xB0 0xA1,Unicode-16 LE:0x4A 0x55,Unicode-16 BE:0x55 0x4A,UTF-8:0xE5 0x95 0x8A来选择。
of123 2013-11-19
  • 打赏
  • 举报
回复
应该是你的控件字符集的问题。
of123 2013-11-19
  • 打赏
  • 举报
回复
ISO/IEC 8859-1 编码表如下

   0 1 2 3 4 5 6 7 8 9 A B C D E F 
0x   
1x   
2x SP ! " # $ % & ' ( ) * + , - . / 
3x 0 1 2 3 4 5 6 7 8 9 : ; < = > ? 
4x @ A B C D E F G H I J K L M N O 
5x P Q R S T U V W X Y Z [ \ ] ^ _ 
6x ` a b c d e f g h i j k l m n o 
7x p q r s t u v w x y z { | } ~   
8x   
9x   
Ax NBSP ¡ ¢ £ ¤ ¥ ¦ § ¨ © ª « ¬ SHY ® ¯ 
Bx ° ± ² ³ ´ µ ¶ · ¸ ¹ º » ¼ ½ ¾ ¿ 
Cx À Á Â Ã Ä Å Æ Ç È É Ê Ë Ì Í Î Ï 
Dx Ð Ñ Ò Ó Ô Õ Ö × Ø Ù Ú Û Ü Ý Þ ß 
Ex à á â ã ä å æ ç è é ê ë ì í î ï 
Fx ð ñ ò ó ô õ ö ÷ ø ù ú û ü ý þ ÿ 
"陈幼净"编码 = B3 C2 D3 D7 BE BB,当然显示 "³ÂÓ×¾»"。
lashengcrh 2013-11-19
  • 打赏
  • 举报
回复
引用 7 楼 myjian 的回复:
这里关键要看你读的时候,是否需要把这个字段作为某些查询的条件,比如where [name]='嗷嗷叫的老马'这样的. 如果不需要,仅仅是作为数据存储的话,那就可以存的时候直接用BASE64编码一下....
我现在需要通过id读取病人姓名,怎么转码?
嗷嗷叫的老马 2013-11-14
  • 打赏
  • 举报
回复
这里关键要看你读的时候,是否需要把这个字段作为某些查询的条件,比如where [name]='嗷嗷叫的老马'这样的. 如果不需要,仅仅是作为数据存储的话,那就可以存的时候直接用BASE64编码一下....
舉杯邀明月 2013-11-14
  • 打赏
  • 举报
回复
你“存入”记录的代码是如何写的? 在那儿,会不会有“编码转换”造成的一些格式不兼容呢?
lashengcrh 2013-11-14
  • 打赏
  • 举报
回复
lashengcrh 2013-11-14
  • 打赏
  • 举报
回复
引用 1 楼 of123 的回复:
是在哪里看到乱码?试试,先不要用 String 类型,将数据放到 Byte 数组中,看编码有没有问题。

然后试试:

strData = StrConv(bytData, vbUnicode)


我测试了一下,例如,数据库中name字段内容“陈幼净”,读入byte数组中是

从查询分析器中看到的是“³ÂÓ×¾»”

strconv函数转不过来,请指教
贝隆 2013-11-08
  • 打赏
  • 举报
回复
引用 1 楼 of123 的回复:
是在哪里看到乱码?试试,先不要用 String 类型,将数据放到 Byte 数组中,看编码有没有问题。 然后试试: strData = StrConv(bytData, vbUnicode)
+10086
赵4老师 2013-11-08
  • 打赏
  • 举报
回复
对电脑而言没有乱码,只有二进制字节;对人脑才有乱码。啊 GBK:0xB0 0xA1,Unicode-16 LE:0x4A 0x55,Unicode-16 BE:0x55 0x4A,UTF-8:0xE5 0x95 0x8A
of123 2013-11-08
  • 打赏
  • 举报
回复
是在哪里看到乱码?试试,先不要用 String 类型,将数据放到 Byte 数组中,看编码有没有问题。 然后试试: strData = StrConv(bytData, vbUnicode)
数据库设计约定 ⼀、公共部分 ⼀、公共部分 1、存储引擎 、存储引擎 默认Innodb,⾮特殊要求⼀律使⽤此引擎 2、字符集 、字符集 Database Server 字符集统⼀默认UTF-8,table和column从server继承 ⼆、表设计约定 ⼆、表设计约定 1、主键 、主键 每张表必须包含物理⾃增主键,如主键字段不能满⾜业务需求,另建unique约束业务字段 2、外键 、外键 数据库表禁⽌主外键关联,需要在程序业务逻辑中维护。特殊情况如跟⽀付,财务模块相关,⽅可考虑主外键 3、表名,字段,索引命名规则 、表名,字段,索引命名规则 TABLE: 同⼀业务模块使⽤相同表前缀,如tb_pay_xxxx,字典表⽤dim_xxxx Column: XXXX_XXXX,中间以下划线隔开 4、公共字段 、公共字段 每张表包含2个公共字段,created_at,updated_at is_delete作为标识记录逻辑删除,⾮必须字段,枚举类型(tinyint(4)),0有效,1删除,默认为0(有效),如数据量增长过⼤可通过 归档,归档后在表中物理删除。 created_at,updated_at 字段作为DT增量拉取数据和数据回退等场景下使⽤,created_at 默认current_timestamp updated_at 默认current_timestamp,on update current_timestamp 5、字段冗余 、字段冗余 ⾮严格遵守3NF,通过业务字段冗余来减少表关联 6、字段类型长度选择 、字段类型长度选择 主键字段:bigint(20),int(11) 根据预估数据量选择,如果选择int(11)需要标注为unsigned 字符串:尽可能使⽤定长char类型,如姓名,⾝份证号码,如需要变长varchar,尽可能根据实际情况限制长度,如description等 枚举类型:统⼀tinyint(4),只占⼀个字节 ⽇期:date,datetime, timestamp,根据实际情况选择 ⾦额:使⽤decimel(xx,2) 7、字段不允许为空 、字段不允许为空 不允许可为空字段,必须有默认值 时间字段默认值建议: 1)date类型,默认值⾮current_date()下,默认值为'1970-01-01' 2)datetime类型,默认值⾮current_timestamp()下,设置为'1970-01-01 08:00:01' 3)timestamp类型,默认值⾮current_timestamp()下,设置成'1970-01-01 08:00:01' 8、注释 、注释 建表包含表注释,尤其枚举类型需要说明每⼀种含义 9、⼤字段 、⼤字段(text/blob) 原则上不允许这种字段,尽可能的拆分成⼩字段,如果特别需要,⽽⼜读写频繁,另外建⼀张表 三、索引约定 三、索引约定 1、命名 、命名 主键:pk_columnName (或者让数据库⾃动命名); 唯⼀键:uk_columnName; 普通索引:ix_columnName; 组合索引ix_column1_column2_column3; 如长度太长则截取部分,取义直观 2、必须包含索引 、必须包含索引 公共字段created_at和updated_at必须建⽴索引 军规适⽤场景:并发量⼤、数据量⼤的互联⽹业务 ⼀、基础规范 (1)必须使⽤InnoDB存储引擎 解读:⽀持事务、⾏级锁、并发性能更好、CPU及内存缓存页优化使得资源利⽤率更⾼ (2)必须使⽤UTF8字符集 解读:万国码,⽆需转码,⽆乱码风险,节省空间 (3)数据表、数据字段必须加⼊中⽂注释 解读:N年后谁tm知道这个r1,r2,r3字段是⼲嘛的 (4)禁⽌使⽤存储过程、视图、触发器、Event 解读:⾼并发⼤数据的互联⽹业务,架构设计思路是"解放数据库CPU,将计算转移到服务层",并发量⼤的情况下,这些功能很可能将数 据库拖死,业务逻辑放到服务层具备更好的扩展性,能够轻易实现"增机器就加性能"。数据库擅长存储与索引,CPU计算还是上移吧 (5)禁⽌存储⼤⽂件或者⼤照⽚ 解读:为何要让数据库做它不擅长的事情?⼤⽂件和照⽚存储在⽂件系统,数据库⾥存URI多好 ⼆、命名规范 (6)库名、表名、字段名:⼩写,下划线风格,不超过32个字符,必须见名知意,禁⽌拼⾳英⽂混⽤ (7)表名t_xxx,⾮唯⼀索引名idx_xxx,唯⼀索引名uniq_xxx 三、表设计规范 (8)单实例表数⽬必须⼩于500 (9)单表列数⽬必须⼩于30 (10)表必须有主键,例如⾃增主键 解读: a)主键递增,数据⾏写⼊可以提⾼插⼊性能,可以避免page分裂,减少表碎⽚提升空间和内存的使⽤ b)主键要选择较短的数据类型, Innodb
工欲善其事,必先利其器! 由于VFP数据库管理开发平台不支持unicode统一码,简体和繁体版VFP程序在不同华语地区呈现无法识别的乱码。当港台用户安装简体软件或大陆用户安装繁体软件时,即使尝试使用微软Applocle,设置区域,升级语言包,也可能无法正常显示。而改编简繁体软件工作量巨大。靠程序员逐字逐段转译海量代码里的中文字符,变量,字段,属性,注释,表单,类库,即使借助Convertz等工具仍然望而却步。 众里寻他千百度!VFP文件简繁体内码转换器全域整合Foxpro工程文件,轻松完成GBK与BIG5内码切换!批量快速地将VFP下所有源程序,库、表、类完整改编成对应的繁体或简体版。所见即所得,在当前窗口可直视转码结果并随时编缉修改。其中的剪贴板快译功能还可在用户任意复制抓取文档段落后,同步翻译并保存译本,方便取用。在处理DBF文件时,进程中不仅能重置中文数据库,还能自动更正中文字段名,告知出错文件名。 本工具简洁直观,功能强悍。只需菜单点选文件类型,设置文件位置,一键转换,即可实现批量文件极速转码。它支持VFP6,VFP7,VFP8,VFP9所有版本下的工程文件内码互换。完美封装和调度SCX,VCX,FRX,MNX,PJX,DBF,DBC,PRG,TXT所有文件。尽管对于源程序中极个别字符仍需人工校验,但已转码的VFP软件界面风格不变,编译成exe后运行顺畅与原版无异。 友情提示:转码前务必备份好原件,避免发生意外损坏。同时为便于调试,建议安装WINDOWS繁体和简体中文双系统。

7,763

社区成员

发帖
与我相关
我的任务
社区描述
VB 基础类
社区管理员
  • VB基础类社区
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
暂无公告

试试用AI创作助手写篇文章吧