java中编码与解码分别指什么

一、java中编码与解码分别指什么

问题一：在java中读取文件时应该采用什么编码？

Java读取文件的方式总体可以分为两类：按字节读取和按字符读取。按字节读取就是采用InputStream.read()方法来读取字节，然后保存到一个byte[]数组中，最后经常用new String(byte[]);把字节数组转换成String。在最后一步隐藏了一个编码的细节，new String(byte[]);会使用操作系统默认的字符集来解码字节数组，中文操作系统就是GBK。而我们从输入流里读取的字节很可能就不是GBK编码的，因为从输入流里读取的字节编码取决于被读取的文件自身的编码。举个例子：我们在D:盘新建一个名为demo.txt的文件，写入”我们。”，并保存。此时demo.txt编码是ANSI，中文操作系统下就是GBK。此时我们用输入字节流读取该文件所得到的字节就是使用GBK方式编码的字节。那么我们最终new String(byte[]);时采用平台默认的GBK来编码成String也是没有问题的(字节编码和默认解码一致)。试想一下，如果在保存demo.txt文件时，我们选择UTF-8编码，那么该文件的编码就不在是ANSI了，而变成了UTF-8。仍然采用输入字节流来读取，那么此时读取的字节和上一次就不一样了，这次的字节是UTF-8编码的字节。两次的字节显然不一样，一个很明显的区别就是：GBK每个汉字两个字节，而UTF-8每个汉字三个字节。如何我们最后还使用new String(byte[]);来构造String对象，则会出现乱码，原因很简单，因为构造时采用的默认解码GBK，而我们的字节是UTF-8字节。正确的办法就是使用new String(byte[],”UTF-8”);来构造String对象。此时我们的字节编码和构造使用的解码是一致的，不会出现乱码问题了。

说完字节输入流，再来说说字节输出流。

我们知道如果采用字节输出流把字节输出到某个文件，我们是无法指定生成文件的编码的(假设文件以前不存在)，那么生成的文件是什么编码的呢？经过测试发现，其实这取决于写入的字节编码格式。比如以下代码：

OutputStream out= new FileOutputStream("d:\\demo.txt");

getBytes()会采用操作系统默认的字符集来编码字节，这里就是GBK，所以我们写入demo.txt文件的是GBK编码的字节。那么这个文件的编码就是GBK。如果稍微修改一下程序：out.write("我们".getBytes(“UTF-8”));此时我们写入的字节就是UTF-8的，那么demo.txt文件编码就是UTF-8。这里还有一点，如果把”我们”换成123或abc之类的ascii码字符，那么无论是采用getBytes()或者getBytes(“UTF-8”)那么生成的文件都将是GBK编码的。

这里可以总结一下，InputStream中的字节编码取决文件本身的编码，而OutputStream生成文件的编码取决于字节的编码。

下面说说采用字符输入流来读取文件。

首先，我们需要理解一下字符流。其实字符流可以看做是一种包装流，它的底层还是采用字节流来读取字节，然后它使用指定的编码方式将读取字节解码为字符。说起字符流，不得不提的就是InputStreamReader。以下是java api对它的说明： InputStreamReader是字节流通向字符流的桥梁：它使用指定的charset读取字节并将其解码为字符。它使用的字符集可以由名称指定或显式给定，否则可能接受平台默认的字符集。说到这里其实很明白了，InputStreamReader在底层还是采用字节流来读取字节，读取字节后它需要一个编码格式来解码读取的字节，如果我们在构造InputStreamReader没有传入编码方式，那么会采用操作系统默认的GBK来解码读取的字节。还用上面demo.txt的例子，假设demo.txt编码方式为GBK，我们使用如下代码来读取文件：

InputStreamReader in= new InputStreamReader(new FileInputStream(“demo.txt”));

那么我们读取不会产生乱码，因为文件采用GBK编码，所以读出的字节也是GBK编码的，而InputStreamReader默认采用解码也是GBK。如果把demo.txt编码方式换成UTF-8,那么我们采用这种方式读取就会产生乱码。这是因为字节编码(UTF-8)和我们的解码编码(GBK)造成的。解决办法如下：

InputStreamReader in= new InputStreamReader(new FileInputStream(“demo.txt”),”UTF-8”);

给InputStreamReader指定解码编码，这样二者统一就不会出现乱码了。

字符输出流的原理和字符输入流的原理一样，也可以看做是包装流，其底层还是采用字节输出流来写文件。只是字符输出流根据指定的编码将字符转换为字节的。字符输出流的主要类是：OutputStreamWriter。Java api解释如下：OutputStreamWriter是字符流通向字节流的桥梁：使用指定的 charset将要向其写入的字符编码为字节。它使用的字符集可以由名称指定或显式给定，否则可能接受平台默认的字符集。说的很明白了，它需要一个编码将写入的字符转换为字节，如果没有指定则采用GBK编码，那么输出的字节都将是GBK编码，生成的文件也是GBK编码的。如果采用以下方式构造OutputStreamWriter：

OutputStreamWriter out= new OutputStreamWriter(new FileOutputStream(“dd.txt”),”UTF-8”);

那么写入的字符将被编码为UTF-8的字节,生成的文件也将是UTF-8格式的。

问题二：既然读文件要使用和文件编码一致的编码，那么javac编译文件也需要读取文件，它使用什么编码呢？

这个问题从来就没想过，也从没当做是什么问题。正是因为问题一而引发的思考，其实这里还是有东西可以挖掘的。下面分三种情况来探讨，这三种情况也是我们常用的编译java源文件的方法。

1.javac在控制台编译java类文件。

通常我们手动建立一个java文件Demo.java，并保存。此时Demo.java文件的编码为ANSI,中文操作系统下就是GBK.然后使用javac命令来编译该源文件。”javac Demo.java”。Javac也需要读取java文件，那么javac是使用什么编码来解码我们读取的字节呢？其实javac采用了操作系统默认的GBK编码解码我们读取的字节，这个编码正好也是Demo.java文件的编码，二者一致，所以不会出现乱码情况。让我们来做点手脚，在保存Demo.java文件时，我们选择UTF-8保存。此时Demo.java文件编码就是UTF-8了。我们再使用”javac Demo.java”来编译，如果Demo.java里含有中文字符，此时控制台会出现警告信息，也出现了乱码。究其原因，就是因为javac采用了GBK编码解码我们读取的字节。因为我们的字节是UTF-8编码的，所以会出现乱码。如果不信的话你可以自己试试。那么解决办法呢？解决办法就是使用javac的encoding参数来制定我们的解码编码。如下：javac-encoding UTF-8 Demo.java。这里我们指定了使用UTF-8来解码读取的字节，由于这个编码和Demo.java文件编码一致，所以不会出现乱码情况了。

我习惯把Eclipse的编码设置成UTF-8。那么每个项目中的java源文件的编码就是UTF-8。这样编译也从没有问题，也没有出现过乱码。正是因为这样才掩盖了使用javac可能出现的乱码。那么Eclipse是如何正确编译文件编码为UTF-8的java源文件的呢？唯一的解释就是Eclipse自动识别了我们java源文件的文件编码，然后采取了正确的encoding参数来编译我们的java源文件。功劳都归功于IDE的强大了。

Ant也是我常用的编译java文件的工具。首先，必须知道Ant在后台其实也是采用javac来编译java源文件的，那么可想而知，1会出现的问题在Ant中也会存在。如果我们使用Ant来编译UTF-8编码的java源文件，并且不指定如何编码，那么也会出现乱码的情况。所以Ant的编译命令<javac>有一个属性” encoding”允许我们指定编码，如果我们要编译源文件编码为UTF-8的java文件，那么我们的命令应该如下：

<javac destdir="${classes}" target="1.4" source="1.4" deprecation="off" debug="on" debuglevel="lines,vars,source" optimize="off" encoding="UTF-8">

指定了编码也就相当于”javac–encoding”了，所以不会出现乱码了。

问题三：tomcat中编译jsp的情况。

这个话题也是由问题二引出的。既然javac编译java源文件需要采用正确的编码，那么tomcat编译jsp时也要读取文件，此时tomcat采用什么编码来读取文件？会出现乱码情况吗？下面我们来分析。

我们通常会在jsp开头写上如下代码：

<%@ page language="java" contentType="text/html; charset=utf-8" pageEncoding="utf-8"%>

我常常不写pageEncoding这个属于，也不明白它的作用，但是不写也没出现过乱码情况。其实这个属性就是告诉tomcat采用什么编码来读取jsp文件的。它应该和jsp文件本身的编码一致。比如我们新建个jsp文件，设置文件编码为GBK,那么此时我们的pageEncoding应该设置为GBK,这样我们写入文件的字符就是GBK编码的，tomcat读取文件时采用也是GBK编码，所以能保证正确的解码读取的字节。不会出现乱码。如果把pageEncoding设置为UTF-8，那么读取jsp文件过程中转码就出现了乱码。上面说我常常不写pageEncoding这个属性，但是也没出现过乱码，这是怎么回事呢？那是因为如果没有pageEncoding属性，tomcat会采用contentType中charset编码来读取jsp文件，我的jsp文件编码通常设置为UTF-8,contentType的charset也设置为UTF-8,这样tomcat使用UTF-8编码来解码读取的jsp文件，二者编码一致也不会出现乱码。这只是contentType中charset的一个作用，它还有两个作用，后面再说。可能有人会问：如果我既不设置pageEncoding属性，也不设置contentType的charset属性，那么tomcat会采取什么编码来解码读取的jsp文件呢？答案是iso-8859-1，这是tomcat读取文件采用的默认编码，如果用这种编码来读取文件显然会出现乱码。

问题二和问题三分析的过程其实就是从源文件àclass文件过程中的转码情况。最终的class文件都是以unicode编码的，我们前面所做的工作就是把各种不同的编码转换为unicode编码，比如从GBK转换为unicode,从UTF-8转换为unicode。因为只有采用正确的编码来转码才能保证不出现乱码。Jvm在运行时其内部都是采用unicode编码的，其实在输出时，又会做一次编码的转换。让我们分两种情况来讨论。

1.java中采用Sysout.out.println输出。

比如：Sysout.out.println(“我们”)。经过正确的解码后”我们”是unicode保存在内存中的，但是在向标准输出(控制台)输出时，jvm又做了一次转码，它会采用操作系统默认编码(中文操作系统是GBK)，将内存中的unicode编码转换为GBK编码，然后输出到控制台。因为我们操作系统是中文系统，所以往终端显示设备上打印字符时使用的也是GBK编码。因为终端的编码无法手动改变，所以这个过程对我们来说是透明的，只要编译时能正确转码，最终的输出都将是正确的，不会出现乱码。在Eclipse中可以设置控制台的字符编码，具体位置在Run Configuration对话框的Common标签里,我们可以试着设置为UTF-8,此时的输出就是乱码了。因为输出时是采用GBK编码的，而显示却是使用UTF-8，编码不同，所以出现乱码。

2.jsp中使用out.println()输出到客户端浏览器。

Jsp编译成class后，如果输出到客户端，也有个转码的过程。Java会采用操作系统默认的编码来转码，那么tomcat采用什么编码来转码呢？其实tomcat是根据<%@ page language="java" contentType="text/html; charset=utf-8" pageEncoding="utf-8"%>中contentType的charset参数来转码的，contentType用来设置tomcat往浏览器发送HTML内容所使用的编码。Tomcat根据这个编码来转码内存中的unicode。经过转码后tomcat输出到客户端的字符编码就是utf-8了。那么浏览器怎么知道采取什么编码格式来显示接收到的内容呢？这就是contentType的charset属性的第三个作用了：这个编码会在HTTP响应头中指定以通知浏览器。浏览器使用http响应头的contentType的charset属性来显示接收到的内容。

总结一下contentType charset的三个作用：

1).在没有pageEncoding属性时，tomcat使用它来解码读取的jsp文件。

2).tomcat向客户端输出时，使用它来编码发送的内容。

3).通知浏览器，应该以什么编码来显示接收到的内容。

为了能更好的理解上面所说的解码和转码过程，我们举一个例子。

新建一个index.jsp文件，该文件编码为GBK,在jsp开头我们写上如下代码：

<%@ page language="java" contentType="text/html; charset=utf-8" pageEncoding="GBK"%>

这里的charset和pageEncoding不同，但是也不会出现乱码，我来解释一下。首先tomcat读取jsp内容，并根据pageEncoding指定的GBK编码将读取的GBK字节解码并转换为unicode字节码保存在class文件中。然后tomcat在输出时(out.println())使用charset属性将内存中的unicode转换为utf-8编码，并在响应头中通知浏览器，浏览器以utf-8显示接收到的内容。整个过程没有一次转码错误，所以就不会出现乱码情况。

问题五：Properties和ResourceBundle使用的解码编码。

以上两个是我们常用的类，他们在读取文件过程中并不允许我们指定解码编码，那么它们采取什么解码方式呢？查看源码后发现都是采用iso-8859-1编码来解码

的。这样的话我们也不难理解我们写的properties文件为什么都是iso-8859-1的了。因为采取任何一个别的编码都将产生乱码。因为iso-8859-1编码是没

有中文的，所以我们输入的中文要转换为unicode，通常我们使用插件来完成，也可以使用jdk自带的native2ascii工具。

二、如何使用java.util.regex包

在Sun的Java JDK 1.40版本中，Java自带了支持正则表达式的包，本文就抛砖引玉地介绍了如何使用java.util.regex包。

可粗略估计一下，除了偶尔用Linux的外，其他Linu x用户都会遇到正则表达式。正则表达式是个极端强大工具，而且在字符串模式-匹配和字符串模式-替换方面富有弹性。在Unix世界里，正则表达式几乎没有什么限制，可肯定的是，它应用非常之广泛。

正则表达式的引擎已被许多普通的Unix工具所实现，包括grep，awk，vi和Emacs等。此外，许多使用比较广泛的脚本语言也支持正则表达式，比如Python，Tcl，JavaScript，以及最著名的Perl。

我很早以前就是个Perl方面的黑客，如果你和我一样话，你也会非常依赖你手边的这些强大的text-munging工具。近几年来，像其他程序开发者一样，我也越来越关注Java的开发。

Java作为一种开发语言，有许多值得推荐的地方，但是它一直以来没有自带对正则表达式的支持。直到最近，借助于第三方的类库，Java开始支

持正则表达式，但这些第三方的类库都不一致、兼容性差，而且维护代码起来很糟糕。这个缺点，对我选择Java作为首要的开发工具来说，一直是个巨大的顾虑

你可以想象，当我知道Sun的Java JDK

1.40版本包含了java.util.regex(一个完全开放、自带的正则表达式包)时，是多么的高兴!很搞笑的说，我花好些时间去挖掘这个被隐藏起

来的宝石。我非常惊奇的是，Java这样的一个很大改进(自带了java.util.regex包)为什么不多公开一点呢?!

最近，Java双脚都跳进了正则表达式的世界。java.util.regex包在支持正则表达也有它的过人之处，另外Java也提供详细的相

关说明文档。使得朦朦胧胧的regex神秘景象也慢慢被拨开。有一些正则表达式的构成(可能最显著的是，在于糅合了字符类库)在Perl都找不到。

在regex包中，包括了两个类，Pattern(模式类)和Matcher(匹配器类)。Pattern类是用来表达和陈述所要搜索模式的对

象，Matcher类是真正影响搜索的对象。另加一个新的例外类，PatternSyntaxException，当遇到不合法的搜索模式时，会抛出例

即使对正则表达式很熟悉，你会发现，通过java使用正则表达式也相当简单。要说明的一点是，对那些被Perl的单行匹配所宠坏的Perl狂热爱好者来说，在使用java的regex包进行替换操作时，会比他们所以前常用的方法费事些。

本文的局限之处，它不是一篇正则表达式用法的完全教程。如果读者要对正则表达进一步了解的话，推荐阅读Jeffrey

Expressions，该书由O’Reilly出版社出版。我下面就举一些例子来教读者如何使用正则表达式，以及如何更简单地去使用它。

设计一个简单的表达式来匹配任何电话号码数字可能是比较复杂的事情，原因在于电话号码格式有很多种情况。所有必须选择一个比较有效的模式。比如:(212) 555-1212， 212-555-1212和212 555 1212，某些人会认为它们都是等价的。

首先让我们构成一个正则表达式。为简单起见，先构成一个正则表达式来识别下面格式的电话号码数字:(nnn)nnn-nnnn。

第一步，创建一个pattern对象来匹配上面的子字符串。一旦程序运行后，如果需要的话，可以让这个对象一般化。匹配上面格式的正则表达可以

这样构成:(\d{3})\s\d{3}-\d{4}，其中\d单字符类型用来匹配从0到9的任何数字，另外{3}重复符号，是个简便的记号，用来表示有

3个连续的数字位，也等效于(\d\d\d)。\s也另外一个比较有用的单字符类型，用来匹配空格，比如Space键，tab键和换行符。

是不是很简单?但是，如果把这个正则表达式的模式用在java程序中，还要做两件事。对java的解释器来说，在反斜线字符

(\)前的字符有特殊的含义。在java中，与regex有关的包，并不都能理解和识别反斜线字符(\)，尽管可以试试看。但为避免这一点，即为了让反斜

线字符(\)在模式对象中被完全地传递，应该用双反斜线字符(\)。此外圆括号在正则表达中两层含义，如果想让它解释为字面上意思(即圆括号)，也需要在

它前面用双反斜线字符(\\)。也就是像下面的一样:

\\(\\d{3}\\)\\s\\d{3}-\\d{4}

现在介绍怎样在java代码中实现刚才所讲的正则表达式。要记住的事，在用正则表达式的包时，在你所定义的类前需要包含该包，也就是这样的一行:

下面的一段代码实现的功能是，从一个文本文件逐行读入，并逐行搜索电话号码数字，一旦找到所匹配的，然后输出在控制台。

Pattern pattern= Pattern.compile("\\(\\d{3}\\)\\s\\d{3}-\\d{4}");

in= new BufferedReader(new FileReader("phone"));

while((s= in.readLine())!= null)

Matcher matcher= pattern.matcher(s);

System.out.println(matcher.group());

对那些熟悉用Python或Javascript来实现正则表达式的人来说，这段代码很平常。在Python和Javascript这些语言

中，或者其他的语言，这些正则表达式一旦明确地编译过后，你想用到哪里都可以。与Perl的单步匹配相比，看起来多多做了些工作，但这并不很费事。

find()方法，就像你所想象的，用来搜索与正则表达式相匹配的任何目标字符串，group()方法，用来返回包含了所匹配文本的字符串。应

注意的是，上面的代码，仅用在每行只能含有一个匹配的电话号码数字字符串时。可以肯定的说，java的正则表达式包能用在一行含有多个匹配目标时的搜索。

本文的原意在于举一些简单的例子来激起读者进一步去学习java自带的正则表达式包，所以对此就没有进行深入的探讨。

这相当漂亮吧!但是很遗憾的是，这仅是个电话号码匹配器。很明显，还有两点可以改进。如果在电话号码的开头，即区位号和本地号码之间可能会有空格。我们也可匹配这些情况，则通过在正则表达式中加入\s?来实现，其中?元字符表示在模式可能有0或1个空格符。

第二点是，在本地号码位的前三位和后四位数字间有可能是空格符，而不是连字号，更有胜者，或根本就没有分隔符，就是7位数字连在一起。对这几种

情况，我们可以用(-|)?来解决。这个结构的正则表达式就是转换器，它能匹配上面所说的几种情况。在()能含有管道符|时，它能匹配是否含有空格符或连

字符，而尾部的?元字符表示是否根本没有分隔符的情况。

最后，区位号也可能没有包含在圆括号内，对此可以简单地在圆括号后附上?元字符，但这不是一个很好的解决方法。因为它也包含了不配对的圆括号，

"555)"。相反，我们可以通过另一种转换器来强迫让电话号码是否带有有圆括号:(\(\d{3}\)|\d{3})。如果我们把上面代码中的正则表达

式用这些改进后的来替换的话，上面的代码就成了一个非常有用的电话号码数字匹配器:

Pattern.compile("(\\(\\d{3}\\)|\\d{3})\\s?\\d{3}(-|)?\\d{4}");

可以确定的是，你可以自己试着进一步改进上面的代码。

现在看看第二个例子，它是从Friedl的中改编过来的。其功能是用来检查文本文件中是否有重复的单词，这在印刷排版中会经常遇到，同样也是个语法检查器的问题。

匹配单词，像其他的一样，也可以通过好几种的正则表达式来完成。可能最直接的是\b\w+\b，其优点在于只需用少量的regex元字符。其中

\w元字符用来匹配从字母a到u的任何字符。+元字符表示匹配匹配一次或多次字符，\b元字符是用来说明匹配单词的边界，它可以是空格或任何一种不同的标

现在，我们怎样来检查一个给定的单词是否被重复了三次?为完成这个任务，需充分利用正则表达式中的所熟知的向后扫描。如前面提到的，圆括号在正

则表达式中有几种不同的用法，一个就是能提供组合类型，组合类型用来保存所匹配的结果或部分匹配的结果(以便后面能用到)，即使遇到有相同的模式。在同样

的正则表达中，可能(也通常期望)不止有一个组合类型。在第n个组合类型中匹配结果可以通过向后扫描来获取到。向后扫描使得搜索重复的单词非常简

单:\b(\w+)\s+\1\b。

圆括号形成了一个组合类型，在这个正则表示中它是第一组合类型(也是仅有的一个)。向后扫描\1，指的是任何被\w+所匹配的单词。我们的正则

表达式因此能匹配这样的单词，它有一个或多个空格符，后面还跟有一个与此相同的单词。注意的是，尾部的定位类型(\b)必不可少，它可以防止发生错误。如

果我们想匹配"Paris in the the spring"，而不是匹配"Java's regex package is the theme

of this article"。根据java现在的格式，则上面的正则表达式就是:Pattern pattern

=Pattern.compile("\\b(\\w+)\\s+\\1\\b");

最后进一步的修改是让我们的匹配器对大小写敏感。比如，下面的情况:"The the theme of this article is

package."，这一点在regex中能非常简单地实现，即通过使用在Pattern类中预定义的静态标志CASE_INSENSITIVE:

Pattern pattern=Pattern.compile("\\b(\\w+)\\s+\\1\\b",

有关正则表达式的话题是非常丰富，而且复杂的，用Java来实现也非常广泛，则需要对regex包进行的彻底研究，我们在这里所讲的只是冰山一

角。即使你对正则表达式比较陌生，使用regex包后会很快发现它强大功能和可伸缩性。如果你是个来自Perl或其他语言王国的老练的正则表达式的黑客，

使用过regex包后，你将会安心地投入到java的世界，而放弃其他的工具，并把java的regex包看成是手边必备的利器。

三、总想问java女生学怎么样

1、女生学java是一个很好的选择，因为女性比男性有着独特的优势，就这个行业而言：

2、一是女性在细心和耐力方面比男性表现得更为突出;

3、二是在技术管理方面女性更有优势。

4、现在的研发项目中很少是个人独立去做一件事情。多数是需要团队合作的。通常那些技术非常好的人，在对团队的管理及项目管理方面却是表现很一般。因为在管理中，沟通和协调是要素，这正是女性的特长。“这些看似琐碎的管理，往往是决定最后任务能否成功的关键要素。”

5、谈到出路，男性程序员面临着这个问题，女性程序员更面临着这个问题。我认为比较好的有两条途径：

6、一是永远走技术这条路走到底，最后做到技术最高(好像不通)。“可是，IT这个行业技术更新很快，永远没有最高。”

7、另一是发挥女性自身的优势，去转管理方面，比如说做team leader，做project manager之类的职业。“不过，从技术转为技术管理也是件不容易的事情，需要自身不断的学习、积累和提高。

8、不会的，不要被江湖传闻吓到。学习java编程确实需要一定的逻辑思维能力，但是正常人都具备这个能力，没有想象的那么难。再者，Java说到底是一门技术，符合孰能生巧的规律，只要肯下功夫，勤勤恳恳敲代码，都能学会，纸上谈兵是不靠谱的，只会增长你自以为是的能力，不会提高工作落地的能力。

9、至于所谓的学Java的女生少，只是因为敲代码的工作相对比较枯燥，并且互联网时代前期，码农加班情况严重，所以没有女生原意选择这个行业。但是今时不同往日了，现在互联网越来越成熟，加班的情况也是少之又少了，程序媛的数量也在增多。而且现在的老板为了员工内部和谐，提高工作效率，更喜欢招程序媛，都是重点保护对象，吃香都来不及呢。