正文
java处理字符编码代码 java字符的编码方式是什么
小程序:扫一扫查出行
【扫一扫了解最新限行尾号】
复制小程序
【扫一扫了解最新限行尾号】
复制小程序
怎么读取java文件中字符编码格式
1:简单判断是UTF-8或不是UTF-8,因为一般除了UTF-8之外就是GBK,所以就设置默认为GBK。
按照给定java处理字符编码代码的字符集存储文件时,在文件java处理字符编码代码的最开头的三个字节中就有可能存储着编码信息,所以,基本的原理就是只要读出文件前三个字节,判定这些字节的值,就可以得知其编码的格式。其实,如果项目运行的平台就是中文操作系统,如果这些文本文件在项目内产生,即开发人员可以控制文本的编码格式,只要判定两种常见的编码就可以了:GBK和UTF-8。由于中文Windows默认的编码是GBK,所以一般只要判定UTF-8编码格式。
对于UTF-8编码格式的文本文件,其前3个字节的值就是-17、-69、-65,所以,判定是否是UTF-8编码格式的代码片段如下:
File file = new File(path);
InputStream in= new java.io.FileInputStream(file);
byte[] b = new byte[3];
in.read(b);
in.close();
if (b[0] == -17 b[1] == -69 b[2] == -65)
System.out.println(file.getName() + ":编码为UTF-8");
else
System.out.println(file.getName() + ":可能是GBK,也可能是其他编码");
2:若想实现更复杂的文件编码检测,可以使用一个开源项目cpdetector,它所在的网址是:。它的类库很小,只有500K左右,cpDetector是基于统计学原理的,不保证完全正确,利用该类库判定文本文件的代码如下:
读外部文件(先利用cpdetector检测文件的编码格式,然后用检测到的编码方式去读文件):
/**
* 利用第三方开源包cpdetector获取文件编码格式
*
* @param path
* 要判断文件编码格式的源文件的路径
* @author huanglei
* @version 2012-7-12 14:05
*/
public static String getFileEncode(String path) {
/*
* detector是探测器,它把探测任务交给具体的探测实现类的实例完成。
* cpDetector内置了一些常用的探测实现类,这些探测实现类的实例可以通过add方法 加进来,如ParsingDetector、
* JChardetFacade、ASCIIDetector、UnicodeDetector。
* detector按照“谁最先返回非空的探测结果,就以该结果为准”的原则返回探测到的
* 字符集编码。使用需要用到三个第三方JAR包:antlr.jar、chardet.jar和cpdetector.jar
* cpDetector是基于统计学原理的,不保证完全正确。
*/
CodepageDetectorProxy detector = CodepageDetectorProxy.getInstance();
/*
* ParsingDetector可用于检查HTML、XML等文件或字符流的编码,构造方法中的参数用于
* 指示是否显示探测过程的详细信息,为false不显示。
*/
detector.add(new ParsingDetector(false));
/*
* JChardetFacade封装了由Mozilla组织提供的JChardet,它可以完成大多数文件的编码
* 测定。所以,一般有了这个探测器就可满足大多数项目的要求,如果java处理字符编码代码你还不放心,可以
* 再多加几个探测器,比如下面的ASCIIDetector、UnicodeDetector等。
*/
detector.add(JChardetFacade.getInstance());// 用到antlr.jar、chardet.jar
// ASCIIDetector用于ASCII编码测定
detector.add(ASCIIDetector.getInstance());
// UnicodeDetector用于Unicode家族编码的测定
detector.add(UnicodeDetector.getInstance());
java.nio.charset.Charset charset = null;
File f = new File(path);
try {
charset = detector.detectCodepage(f.toURI().toURL());
} catch (Exception ex) {
ex.printStackTrace();
}
if (charset != null)
return charset.name();
else
return null;
}
String charsetName = getFileEncode(configFilePath);
System.out.println(charsetName);
inputStream = new FileInputStream(configFile);
BufferedReader in = new BufferedReader(new InputStreamReader(inputStream, charsetName));
读jar包内部资源文件(先利用cpdetector检测jar内部的资源文件的编码格式,然后以检测到的编码方式去读文件):
/**
* 利用第三方开源包cpdetector获取URL对应的文件编码
*
* @param path
* 要判断文件编码格式的源文件的URL
* @author huanglei
* @version 2012-7-12 14:05
*/
public static String getFileEncode(URL url) {
/*
* detector是探测器,它把探测任务交给具体的探测实现类的实例完成。
* cpDetector内置了一些常用的探测实现类,这些探测实现类的实例可以通过add方法 加进来,如ParsingDetector、
* JChardetFacade、ASCIIDetector、UnicodeDetector。
* detector按照“谁最先返回非空的探测结果,就以该结果为准”的原则返回探测到的
* 字符集编码。使用需要用到三个第三方JAR包:antlr.jar、chardet.jar和cpdetector.jar
* cpDetector是基于统计学原理的,不保证完全正确。
*/
CodepageDetectorProxy detector = CodepageDetectorProxy.getInstance();
/*
* ParsingDetector可用于检查HTML、XML等文件或字符流的编码,构造方法中的参数用于
* 指示是否显示探测过程的详细信息,为false不显示。
*/
detector.add(new ParsingDetector(false));
/*
* JChardetFacade封装了由Mozilla组织提供的JChardet,它可以完成大多数文件的编码
* 测定。所以,一般有了这个探测器就可满足大多数项目的要求,如果你还不放心,可以
* 再多加几个探测器,比如下面的ASCIIDetector、UnicodeDetector等。
*/
detector.add(JChardetFacade.getInstance());// 用到antlr.jar、chardet.jar
// ASCIIDetector用于ASCII编码测定
detector.add(ASCIIDetector.getInstance());
// UnicodeDetector用于Unicode家族编码的测定
detector.add(UnicodeDetector.getInstance());
java.nio.charset.Charset charset = null;
try {
charset = detector.detectCodepage(url);
} catch (Exception ex) {
ex.printStackTrace();
}
if (charset != null)
return charset.name();
else
return null;
}
URL url = CreateStationTreeModel.class.getResource("/resource/" + "配置文件");
URLConnection urlConnection = url.openConnection();
inputStream=urlConnection.getInputStream();
String charsetName = getFileEncode(url);
System.out.println(charsetName);
BufferedReader in = new BufferedReader(new InputStreamReader(inputStream, charsetName));
3:探测任意输入的文本流的编码,方法是调用其重载形式:
charset=detector.detectCodepage(待测的文本输入流,测量该流所需的读入字节数);
上面的字节数由程序员指定,字节数越多,判定越准确,当然时间也花得越长。要注意,字节数的指定不能超过文本流的最大长度。
4:判定文件编码的具体应用举例:
属性文件(.properties)是Java程序中的常用文本存储方式,象STRUTS框架就是利用属性文件存储程序中的字符串资源。它的内容如下所示:
#注释语句
属性名=属性值
读入属性文件的一般方法是:
FileInputStream ios=new FileInputStream(“属性文件名”);
Properties prop=new Properties();
prop.load(ios);
String value=prop.getProperty(“属性名”);
ios.close();
利用java.io.Properties的load方法读入属性文件虽然方便,但如果属性文件中有中文,在读入之后就会发现出现乱码现象。发生这个原因是load方法使用字节流读入文本,在读入后需要将字节流编码成为字符串,而它使用的编码是“iso-8859-1”,这个字符集是ASCII码字符集,不支持中文编码,
方法一:使用显式的转码:
String value=prop.getProperty(“属性名”);
String encValue=new String(value.getBytes(“iso-8859-1″),”属性文件的实际编码”);
方法二:象这种属性文件是项目内部的,java处理字符编码代码我们可以控制属性文件的编码格式,比如约定采用Windows内定的GBK,就直接利用”gbk”来转码, 如果约定采用UTF-8,就使用”UTF-8″直接转码。
方法三:如果想灵活一些,做到自动探测编码,就可利用上面介绍的方法测定属性文件的编码,从而方便开发人员的工作
补充:可以用下面代码获得Java支持编码集合:
Charset.availableCharsets().keySet();
可以用下面的代码获得系统默认编码:
Charset.defaultCharset();
java爬虫一段话里的部分字符乱码解决
1. 网络爬虫乱码的原因。
源网页的编码与抓取后的编码转换不一致。如果源网页是gbk编码的字节流,程序在我们抓取后直接用utf-8编码输出到存储文件,这必然会造成乱码,即当源网页编码与程序抓取后直接处理编码一致时,就不会出现乱码,然后统一字符编码后也就不会出现乱码。注意区分源网络代码A,程序B直接使用的代码,统一转换字符的代码C。
2. 是网页的服务器端代码。
B.捕获的数据原本是字节数组,由A编码,只有B=A才能保证不会出现乱码;否则,当字符集不兼容时,就会出现乱码字符。这一步常用于测试。
c、统一转码是指在获得网页的原始编码A后进行统一编码,主要是将每个网页的数据统一成一种编码,往往首选字符集较大的utf-8。
每个网页都有自己的代码,比如gbk,utf-8,iso8859-1,日本jp系统代码,西欧,俄语等等。爬行时,所有类型的代码都将被扩展。有的爬虫只是简单的识别网页,然后统一编码,有的则直接按照utf-8统一处理,不需要判断源网页,显然会造成乱码。
3. 乱码的解决方案。
根据原因找到解决办法很简单。
1) 确定源网页的代码a。
代码a通常位于网页的三个位置,即httpheader的内容、网页的元字符集和网页标题中的文档定义。获取源网页代码时,依次判断这三部分数据,从头到尾优先级相同。
理论上这是对的,但是国内有些网站不符合标准。比如写出来的gbk其实是utf-8,有的写出来是utf-8,其实是gbk。当然这是几个网站,但是确实存在。因此,在确定网页编码时,应该对这种特殊情况给予特殊处理,如中文检查、默认编码等策略。
在另一种情况下,如果以上三种都没有编码信息,一般使用第三方的网页编码智能识别工具,如cpdetector。原理是通过统计字节数组的特性来计算实际编码,有一定的准确率,但是我发现在实践中准确率还是很有限的。
但是综合以上三种编码确认方法后,中文乱码的问题几乎可以完全解决。在我的基于nutch1.6的网络爬虫系统中,经过统计,编码准确率可以达到99.99%,这也证明了上述方法和策略的可行性。
2) 程序通过代码b还原源网页数据。
显然,这里的B应该等于a,在java中,如果源网页的字节数组是source_byte_array,就会转换成stringstr=newstring(source_byte_array,B)。即这些字节数组对应的字符被正确编码显示在内存中,此时打印结果正常。此步骤通常用于调试或控制台输出测试。
3) 统一转码。
网络爬虫系统中有很多数据源。如果无法使用数据,它将被转换为其原始数据,如果这样做是浪费的。所以一般爬虫系统要对抓取的结果进行统一编码,做到一致,使用方便。此时,在(2)的基础上,可以进行统一的编码转换,在java中的实现如下。
源网页的字节数组是source_byte_array。
转换为普通字符串:stringnormal_source_str=newstring(source_byte_array,c)。这时候可以直接用javaapi存储,但是字符串往往不直接写。因为一般爬虫存储是将多个源网页存储在一个文件中,所以要记录字节偏移量,所以下一步。 再将得到的str转换为统一的编码C格式的字节数组,则byte[] new_byte_array=normal_source_str.getBytes(C)即可,此时即可用java io api将数组写入文件,并记录相应的字节数组偏移量等,待真正使用时,直接io读取即可。
爬虫过程不仅会存在乱码问题,还会存在网站爬取涉及法律、IP受限,爬取行为受限等等问题,这个时候就需要不断去解决这些问题。
请问java如何改变字符串的编码方式
byte[] b=string.getBytes("GB2312");//使用GB2312编码方式对字符串string进行编码
//这时要想将字节数组b的内容正确解码只能使用GB2312的编码方式进行解码,即
String str=new String(b,"GB2312");//这里若使用UTF-8编码方式来进行解码就会乱码
//将eclipse默认的编码方式改为UTF-8,只是用该编码方式对.java源文件进行编码保存
//这个对new String(string.getBytes("GB2312"),"UTF-8")没啥影响的
//因为从java源文件获取字符串string时,已经通过UTF-8编码方式进行解码了
//而string.getBytes("GB2312")是使用指定的编码方式对字符串string进行从新编码
//这两者之间没啥关系的
JAVA字符编码问题
这种编码问题真是很tricky的问题。说它tricky是因为这至少涉及到以下4种编码选取的排列组合(有时甚至更多),更有时乃至会发生错进错出,负负得正,中间过程错了但反而到不是乱码的情况。
(1)源代码的编码
(2)编译时告诉java编译器的源代码编码
(3)运行时jvm参数file.encoding
(4)输出终端对输出字节流的解码所采用的码组
在这简单情况下(1)和(2)一致,(3)和(4)一致就不会因为编解码映射错误(当然字符向终端字体映射的错误是另一回事,如字体缺失之类)。而(1)(2)和(3)(4)不必一致,这样就使得不必强求开发编译环境和运行应用环境的编码必须一致。
源代码的录入与编译若在在一个平台上时,大多数情况没有问题(反而用聪明的Idea IDE设置错误时会乱套,越是简陋的开发环境越不太会错)。但是如果你在中文GBK编码平台上的源代码在别人的unicode编码平台上编译,就有问题了。所以和别人,特别是和不同母语的人合作编程时,建议要么约定一律用unicode作为源文件编码;要么只用ASCII字符,反正其他编码一般都和ASCII兼容的,对于非ASCII字符,用Java的/uxxxx表示机制,比如"中国"就表示为"\u4e2d\u56fd"。4e2d和56fd分别是中国二字的unicode十六进制编码。
但我认为楼主在这里其实主要关心的是运行时的编码一致问题,即(3)和(4)。所以言归正传,让我们来检查它们是否一致。
由于正如上述,iso8859-1编码集其实是被其他所有公认的编码集所兼容的,也就是说它是所有公认编码集的公共子集。所以以iso8859-1为基础可以外延到任何一个公认编码集。事实上大多数情况也是这样做的。比如java System property里设定了encoding为iso8859-1,事实上不仅仅是一个Latin字母的映射,在非Latin区域按JVM宿主操作系统的编码扩展。即选iso8859-1其实是选择了宿主操作系统的默认编码。
假设楼主的操作系统编码是GBK,那么file.encoding=iso8859-1相当于选择了file.encoding=GBK。那么System.out.println(...)这个核心类方法会将china字符转换为file.encoding指定的编码(GBK)字节由out流输出给最终out所绑定的终端。比如console一般采用系统默认编码也是GBK的话,那就和file.encoding一致,能正常解码,不会乱码。
至于System.out.write()直接写字节流。由于该字节流是由china.getBytes()得到的,在不指定编码的时候使用file.encoding指定的默认值的(即GBK),因此Str-Byte的编码方法GBK和console采用的解码方法GBK又是一致的,所以也不是乱码。
但是这时候用toHexString打印出的两个字节串是不一样的。先直接把china逐字强行转换为int的情况,不涉及输出编码,总是unicode的。(JVM规范规定class里字串必须unicode编码)只要上述(1) (2)匹配,java编译器会自动从各种编码的源文件正确转成class文件里统一unicode编码的字串。相反,作为一个题外话提一下,当(1)(2)不匹配时会在特定的一种配合(1)(2)的(3)(4)也不匹配的情况下会负负得正输出正常,但这是绝对错误的做法,因为任何要求(1)(2)和(3)(4)有匹配关系的要求都是在应用中可能无法满足的。java编译器对这种情况也会报告warning,但不fail。
综上,一旦file.encoding设成宿主操作系统默认而系统consle也采用操作系统默认编解码的话,(3)(4)总是一致的,无论系统选择的是GBK还是utf-8等等。
那么如果file.encoding不选系统默认呢?比如utf-8。那就很可能出现乱码了。但是,慢着,试验的结果还是没有乱码。那是因为file.encoding是静态的JVM系统参数,在程序里像楼主那样设定是不起作用的(我不知道有没有办法发一个什么通知让这种程序改变生效的)。必须作为JVM参数直接传给java程序让它构造虚拟机的时候就得到这个参数,否则JVM会去拿宿主系统的默认值,就相当于又回到设file.encoding=iso8859-1了。
java -Dfile.encoding=utf-8 A
这下终于乱码了,而且两个都乱了。打印出的字节串一个还是unicode,另一个从GBK变到utf-8了。
如果你发现试验的现象和我上面说的正好相反,请注意检查console的编码设置,我们上面假设它也采用了宿主系统默认编码,但有些console很高级的嘞,可以设置成不通编码的(其实几乎所有的都可以)。那么分析的方法和上面一样,结果可能正好相反。
关于java处理字符编码代码和java字符的编码方式是什么的介绍到此就结束了,不知道你从中找到你需要的信息了吗 ?如果你还想了解更多这方面的信息,记得收藏关注本站。