不打开文件转utf8

不打开文件转utf8,第1张

不打开文件转utf8方法:

选中需要转换编码的文件,右击选择“记事本”打开。打开以后,选择“文件”菜单下面的“另存为”。打开以后,选择“文件”菜单下面的“另存为”。选择文件保存路径,然后保存

1. 服务器指定字符集与客户字符集不同,而与加载数据字符集一致。

解决方法:对于这种情况,只需要设置客户端字符集与服务器端字符集一致就可以了,具体 *** 作如下:

* 查看当前字符集:

SQL>select * from sys.props$

2 WHERE NAME=‘NLS_CHARACTERSET’

NAME value$

NLS_CHARACTERSET ZHS16GBK

可以看出,现在服务器端Oracle数据库的字符集为‘ZHS16GBK’

* 根据服务器的字符集在客户端作相应的配置或者安装Oracle的客户端软件时指定:

如果还没安装客户端,那么在安装客户端时,指定与服务器相吻合的字符集即可;如果已经安装好了客户端,并且客户端为 sql*net 2.0 以下版本,进入Windows的系统目录,编辑oracle.ini文件,用US7ASCII替换原字符集,重新启动计算机,设置生效;否则,如果,客户端为 sql*net 2.0 以上版本,在Win98 下 运 行REGEDIT,第一步选HKEY_LOCAL_MACHINE,第二步选择SOFTWARE, 第三步选择 Oracle, 第四步选择 NLS_LANG, 键 入 与服 务 器 端 相 同 的 字 符 集

(本例为:HKEY_LOCAL_MACHINE/

SOFTWARE/ORACLE/NLS_LANG :AMERICAN _ AMERICA. ZHS16GBK)。

如果是UNIX客户端,则:

SQL>conn / as sysdba

Connected.

SQL>SQL>UPDATE sys.PROPS$ SET value$=‘SIMPLIFIED CHINESE’

2 WHERE NAME=‘NLS_LANGUAGE’

2. 服务器指定字符集与客户字符集相同,与加载数据字符集不一致。

解决方法:强制加载数据字符集与服务器端字符集一致。要做到这一点,可以通过重新创建数据库,并选择与原卸出数据一致的字符集,然后IMP数据,这种情况仅仅适用于空库和具有同一种字符集的数据。

解决这类问题,也可以先将数据加载到具有相同字符集的服务器上,然后用转换工具卸出为foxbase 格式或access格式数据库,再用转换工具转入到不同字符集的Oracle数据库中,这样就避免了Oracle字符集的困扰。目前数据库格式转换的工具很多,像power builder5.0以上版本提供的pipeline及Microsoft Access数据库提供的数据导入/导出功能等。

3. 服务器指定字符集与客户字符集不同,与输入数据字符集不一致。

对于这种情况,目前为止都还没有太好的解决方法。

通过上面的了解,我们知道,导致在后期使用数据库时出现种种关于字符集的问题,多半是由于在数据库设计、安装之初没有很好地考虑到以后的需要,所以,我们完全可以通过在服务器上和客户端使用相同的字符集来避免由此类问题引出的麻烦

怎样修改查看Oracle字符集

a.数据库服务器字符集select * from nls_database_parameters,其来源于props$,是表示数据库的字符集。

b.客户端字符集环境select * from nls_instance_parameters,其来源于v$parameter,

表示客户端的字符集的设置,可能是参数文件,环境变量或者是注册表

c.会话字符集环境 select * from nls_session_parameters,其来源于v$nls_parameters,表示会话自己的设置,可能是会话的环境变量或者是alter session完成,如果会话没有特殊的设置,将与nls_instance_parameters一致。

客户端的字符集要求与服务器一致,才能正确显示数据库的非Ascii字符。如果多个设置存在的时候,alter session>环境变量>注册表>参数文件

实际情况

我用select * from nls_database_parameters

PARAMETER VALUE

------------------------------ ------------------------------

NLS_LANGUAGE AMERICAN

NLS_TERRITORY AMERICA

NLS_CURRENCY $

NLS_ISO_CURRENCY AMERICA

NLS_NUMERIC_CHARACTERS .,

NLS_CHARACTERSET ZHS16GBK

NLS_CALENDAR GREGORIAN

NLS_DATE_FORMATDD-MON-RR

NLS_DATE_LANGUAGE AMERICAN

NLS_SORT BINARY

NLS_TIME_FORMATHH.MI.SSXFF AM

PARAMETER VALUE

------------------------------ ------------------------------

NLS_TIMESTAMP_FORMAT DD-MON-RR HH.MI.SSXFF AM

NLS_TIME_TZ_FORMAT HH.MI.SSXFF AM TZR

NLS_TIMESTAMP_TZ_FORMATDD-MON-RR HH.MI.SSXFF AM TZR

NLS_DUAL_CURRENCY $

NLS_COMP BINARY

NLS_LENGTH_SEMANTICS BYTE

NLS_NCHAR_CONV_EXCPFALSE

NLS_NCHAR_CHARACTERSET AL16UTF16

NLS_RDBMS_VERSION 10.2.0.1.0

说明我在创建数据库时指定的字符集是ZHS16GBK,我用

update sys.props$ set value$='AL32UTF8' where name='NLS_CHARACTERSET'

修改了字符集,但插入中文时仍然有问题,这或许就如上面资料所说的通过修改SYS.PROPS$来修改主要是对应客户端的显示,与存储无关,

所以仍旧是乱码

然后我重新创建了个数据库,指定字符集为AL32UTF8,插入中文就没问题了。

可见我们如果要在数据库中显示中文,在创建数据库时一定哟指定好所用的字符集。

介绍

乱码是由于系统或软件缺乏对某种字符编码的支持,而产生的不能正常阅读的混乱字符。常见的内码错误有GB码和BIG5码冲突,日文,韩文显示问题等。

修正乱码,可以使用系统内码转换工具,如“南极星”等,将系统内码转换为对应内码,字符即可正确显示。

翻译为英文--messy code,unreadable code ,gibberish(推荐)

[编辑本段]

一般乱码的现象和解决方式

网页乱码是浏览器(如IE等)对HTML网页解释时形成的。如果在网页的代码中有形如:〈HTML〉〈HEAD〉〈META CONTENT=“text/html;charset=ISO-8859-1”〉〈/HEAD〉……〈/HTML〉的语句,浏览器在显示此页时,就会出现乱码。因为浏览器会将此页语种辨认为“欧洲语系”。解决的办法是将语种“ISO-8859-1”改为GB2312,如果是繁体网页则改为BIG5。

另一种解决办法是不修改网页代码,事先为浏览器安装多语言支持包(例如在安装IE时要安装多语言支持包),这样在浏览网页出现乱码时,就可以在浏览器中选择菜单栏下的“查看”/“编码”/“自动选择”/简体中文(GB2312),如为繁体中文则选择“查看”/“编码”/“自动选择”/繁体中文(BIG5),其它语言依此类推选择相应的语系,这样可消除网页乱码现象。

还有一种解决办法是利用多内码显示平台来转换内码。常用多内码显示平台有:

“南极星”:可自动识别GB码、BIG5码,用简体或繁体显示,并能做到同屏显示GB码和BIG5码,对日文、韩文亦能正确显示。下载地址:http:// www.njstar.com

“四通利方”:支持了包括GB、BIG5、HZ、日韩编码、UNICOD等17种汉字内码,也开始支持预览功能,并且增加了诸如“增删空格”、“插入禁排空格”等小而有用的功能,实在是网友的好帮手。下载地址:http:// www.srsnet.com

“MagicWin 98”:可真正的同屏显示不同内码,即GB码和BIG5码两者共存、都能正常显示。它支持GB、HZ、BIG5、JIS、EUC、SJIS、KSC、 UTF7和UTF8等格式;支持Netscape Communicator 4.X、Internet Explorer 和Office 等软件;支持在多个窗口中同时查看不同内码的文档的超级多内码显示平台。下载地址:http:// www.itwin.com.my/magicwin

网页无乱码保存的方法是:用浏览器打开网页时,在“查看”/“编码”中选择“自动选择”,存盘时保存类型选“web页”,编码选择“UNICOD”,这样保存过的网页再次打开时,在浏览器菜单“查看”、“编码”中不管选择简体中文(GB2312)、简体中文(HZ)还是UNICODE(UTF-8)或繁体中文(BIG5),最终显示都不会出现乱码。

文本、文档文件乱码,一般是繁体中文显示在简体中文系统下或者相反情况造成的。只要把原本是繁体的内码转换为简体内码(或者相反),就可消除乱码。

Word2000能胜任这类工作,例如要把繁体中文转换为简体中文,方法是:选择要转换内码的文件,在d出的对话框中(如图1),选择“其它编码”中的“繁体中文(BIG5)”一项,打开此文件时就不会出现乱码。无乱码保存方法:在保存时选择“文件”中的“另存为”,先存为“Word文档,存盘后打开再存为纯文本等其它格式;您也可以用Word2000的“中文简繁转换”工具实现无乱码保存,方法是在菜单栏中选择“工具/语言/中文简繁转换”,内码转换后再保存。

WPS2000也能转换内码,支持GB2312、BIG5、GBK等三种主要的汉字编码,并可在输出RTF、TXT、HTM格式文件时对内(乱码进行转换乱码常出现在‘记事本’里,尤其是下载文件)。

此外,金山乱码转换器(绿色版)也能修改乱码,下载地址:http://ishare.iask.sina.com.cn/cgi-bin/fileid.cgi?fileid=1367281

使用方法:打开要改的文件,使用金山乱码转换器,在列表中找到要修改的文件,选中,再点击“大五码”,确定,就好了。

[编辑本段]

乱码的例子:

64 0 obj<</Length 1090/Filter/FlateDecode/I 2762/L 2746/O 2730/S 2636>>stream

x赽```b``朿`2z?@桤Y8凒? � ?i??lj

??槂?鴁2V8hò??埳0=8~€s�偧髊?

?腾

???(蟀,c楽 撇 鲉?幽?甝峾R佩s莸鹞e曳p 鄿蝡荛??念鲺屷:oX?L?v厜鞞??其vGXl@泷劈ⅰ`嚚3撯?燹嵅?L&78?Y缺0绦?L`i??蝡q! sC#穪?扬僰?F?*1�?x藂?

n帱设钲驼uE肂Iζ?\??8黗mi8x?摋儍?唎?琜?H龇~t郺?埔 5l逧?xc樚?告2lsP�裂蠽磳必�???櫕[吵甿]珱um胧珏亴-[伳诽Y樊n]6$?B琐?扯仈l輮?泆砉ivt哉倒柏Q<皱霛?!?ヮ�%!`喕搀猲瘑焿刉硕罍凊?.PVd里B?墏?睸€\?蜏L�檶?梈Y\X簈)绫fN飀/醊.垭怠@Sr?M6EMtU郦牞tD1?ㄞ菐璝+AFE-嘫?l D?l2腁 + ?Q錬q?蠮u)U?e槂�祦缘v狭鈖↘炼A?给X奱

宣~3vMv蔃#?h跼 胞挒 ! 哶??碈?q蒴栗 彀暼?x屼?p�r?瓾�胆-厕臦dka刮堌彡膼际Gz囆??垘瀀?茆赝雺蟼�lJ襰|n亚笱s&?陡亟2溓:€�?凯 殎丵,d b3[€帕LS?%泚. a?俌 `Q? 膁襽崩姇写渹扒?$Qc?d7卋u)D1?讏0h.?jp=LJ`g?yb1[探?B貋=坔纃馌?T?C?&Jt� 祪剑觐剢?z?3堡HL冟:?�?榳?x铿 澡??T??磅0?箌

?? \翛h?臽淅致S冞扐蹃7�?I?`S硖A愈m?C兟H髣褌侊辳 ??o� |?2€[癅#鴡?)? \^W

vti_cachedhasborder:BR|false vti_error0:SX|FrontPage 淇濆瓨缁撴灉缁勪欢璇曞浘浠庢枃浠垛€渇pweb:///_private/form_results.csv钬濊�鍙栨垨鍐椤叆锛屼絾姝ゆ枃浠舵垨 URL 绂佹�璁块棶锛屽洜涓哄畠浣崭簬镞犳晥镄勫瓙鏂囦欢澶逛笅锛屼笉鏄�绣绔欑殑涓€閮ㄤ唤锛屾垨钥呯�鐞嗗憳绂佹�璁块棶銆? vti_error1:SX|FrontPage 淇濆瓨缁撴灉缁勪欢璇曞浘浠庢枃浠垛€渇pweb:///_private/form_results.csv钬濊�鍙栨垨鍐椤叆锛屼絾姝ゆ枃浠舵垨 URL 绂佹�璁块棶锛屽洜涓哄畠浣崭簬镞犳晥镄勫瓙鏂囦欢澶逛笅锛屼笉鏄�绣绔欑殑涓€閮ㄤ唤锛屾垨钥呯�鐞嗗憳绂佹�璁块棶銆? vti_error:IX|2 vti_metatags:VR|HTTP-EQUIV=Content-Language zh-cn HTTP-EQUIV=Content-Type text/html\\ charset=gb2312 vti_charset:SR|gb2312 vti_language:SR|zh-cn vti_title:SR|瀛欎粫璞�殑缃戠珯

这些都是乱码!

[编辑本段]

数据库乱码的原因

1 数据正确,但数据库配置错误,使用了错误的字符集。一般是数据库移植,还原时DBA的错误造成的。

2 数据正确,但拿到的数据错误。

一般是客户端使用了默认的字符集,比如在GBK的机器上开发,但换到Linux下面就出现读取的数据为乱码了。

解决方法是,在连接参数里面明确指定数据传输用的字符集,而不是使用 *** 作系统默认的。

3 数据错误。一般是客户端发来的数据编码问题。比如页面发送数据是UTF-8,可是后台处理程序是GBK的,结果造成保存到数据库的数据为乱码。

解决方法:所有字符集编码都采用统一的编码。比如全部用GBK的。


欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/sjk/9628364.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2023-04-30
下一篇 2023-04-30

发表评论

登录后才能评论

评论列表(0条)

保存