1.java中编码与解码分别指什么？
2.如何解决java编译时编码问题造
3.idea编译java后中文乱码怎么解决
4.为什么我的源码java源代码是乱码？
5.java编码理解

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

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

       Java读取文件的方式总体可以分为两类：按字节读取和按字符读取。按字节读取就是编码采用InputStream.read()方法来读取字节，然后保存到一个byte[]数组中，源码最后经常用new String(byte[]);把字节数组转换成String。编码在最后一步隐藏了一个编码的源码细节，new String(byte[]);会使用操作系统默认的编码京东hydra 源码字符集来解码字节数组，中文操作系统就是源码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");

       out.write("我们".getBytes());

       getBytes()会采用操作系统默认的字符集来编码字节，这里就是GBK，所以我们写入demo.txt文件的是GBK编码的字节。那么这个文件的编码就是GBK。如果稍微修改一下程序：out.write("我们".getBytes(“UTF-8”));此时我们写入的字节就是UTF-8的，那么demo.txt文件编码就是UTF-8。这里还有一点，如果把”我们”换成或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，下载git源码教程并保存。此时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文件编码一致，所以不会出现乱码情况了。

        2.Eclipse中编译java文件。

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

        3.使用Ant来编译java文件。

        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--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响应头中指定以通知浏览器。浏览器使用/7e3ecdcffcf5dcdbaabba"target="_blank"title=""class="ikqb_img_alink">/iknow-pic.cdn.bcebos.com/7e3ecdcffcf5dcdbaabba?x-bce-process=image%2Fresize%2Cm_lfit%2Cw_%2Ch_%2Climit_1%2Fquality%2Cq_%2Fformat%2Cf_auto"esrc="/7e3ecdcffcf5dcdbaabba"/>

扩展资料：

       语言特点：

       1.简单性

       Java看起来设计得很像C++，但是为了使语言小和容易熟悉，设计者们把C++语言中许多可用的特征去掉了，这些特征是一般程序员很少使用的。例如，Java不支持goto语句，代之以提供break和continue语句以及异常处理。

       2.面向对象

       Java是一个面向对象的语言。对程序员来说，这意味着要注意应中的数据和操纵数据的方法（method），而不是严格地用过程来思考。Java还包括一个类的扩展集合，分别组成各种程序包（Package），用户可以在自己的程序中使用。

       3.分布性

       Java设计成支持在网络上应用，它是分布式语言。Java既支持各种层次的网络连接，又以Socket类支持可靠的流（stream）网络连接，所以用户可以产生分布式的客户机和服务器。

       4.编译和解释性

       Java编译程序生成字节码（byte-code），而不是通常的机器码。Java字节码提供对体系结构中性的目标文件格式，代码设计成可有效地传送程序到多个平台。Java程序可以在任何实现了Java解释程序和运行系统（run-timesystem）的系统上运行。

       5.稳健性

       Java原来是用作编写消费类家用电子产品软件的语言，所以它是被设计成写高可靠和稳健软件的。Java消除了某些编程错误，使得用它写可靠软件相当容易。

参考资料：

/baike.baidu.com/item/Java/?fr=aladdin"target="_blank"title="百度百科：Java">百度百科：Java

       /blog.csdn.net/shengzhu1/article/details/"target="_blank"title="CSDN：Java解释执行">CSDN：Java解释执行

java编码理解

        　　<%@ page contentType= text/ charset=utf pageEncoding= GBK %>

        　　jsp页面（pageEncoding）——根据pageEncoding的设定读取jsp——>翻译成统一的UTF JAVA源码（即 java）——由JAVAC的JAVA源码至java byteCode的编译——>

        　　编译成UTF encoding的二进制码（即 class）——Tomcat（或其的application container）载入和执行阶段二的来的JAVA二进制码——>输出contentType编码给浏览器

        　　 页面输入的参数用pageEncoding来编码

        　　 页面的默认编码是什么？

       

        　　ntentType的默认编码是什么？

        　　 编码和解码过程各种文件时什么编码

        　　response setContentType（ text/ charset=gb ） 是在页面显示时设置的字符格式request setCharacterEncoding（ gb ） 是servlet接受请求后对请求中的字符进行设置字符格式 因为默认通过网络传输的内容都被进行了iso 编码 如果想在后处理的时候不让中文成乱码 那就得对得到的内容进行gb 编码

        　　JSP pageEncoding和contentType属性

        　　JSP要经过两次的 编码 第一阶段会用pageEncoding 第二阶段会用utf 至utf 第三阶段就是由Tomcat出来的网页 用的是contentType

        　　关于JSP页面中的pageEncoding和contentType两种属性的区别

        　　pageEncoding是jsp文件本身的编码

        　　contentType的charset是指服务器发送给客户端时的内容编码

        　　JSP要经过两次的 编码 第一阶段会用pageEncoding 第二阶段会用utf 至utf 第三阶段就是由Tomcat出来的网页 用的是contentType

        　　第一阶段是jsp编译成 java 它会根据pageEncoding的设定读取jsp 结果是由指定的编码方案翻译成统一的UTF JAVA源码（即 java） 如果pageEncoding设定错了 或没有设定 出来的就是中文乱码

        　　第二阶段是由JAVAC的JAVA源码至java byteCode的编译 不论JSP编写时候用的是什么编码方案 经过这个阶段的结果全部是UTF 的encoding的java源码

        　　JAVAC用UTF 的encoding读取java源码 编译成UTF encoding的二进制码（即 class） 这是JVM对常数字串在二进制码（java encoding）内表达的规范

        　　第三阶段是Tomcat（或其的application container）载入和执行阶段二的来的JAVA二进制码 输出的结果 也就是在客户端见到的 这时隐藏在阶段一和阶段二的参数contentType就发挥了功效

        　　contentType的设定

        　　pageEncoding 和contentType的预设都是 ISO 而随便设定了其中一个 另一个就跟着一样了（TOMCAT 是如此） 但这不是绝对的 这要看各自JSPC的处理方式 而pageEncoding不等于contentType 更有利亚洲区的文字 CJKVç³»JSP网页的开发和展示 （例pageEncoding=GB 不等于 contentType=utf ）

        　　jsp文件不像 java java在被编译器读入的时候默认采用的是操作系统所设定的locale所对应的编码 一般我们不管是在记事本还是在ue中写代码 如果没有经过特别转码的话 写出来的都是本地编码格式的内容 所以编译器采用的方法刚好可以让虚拟机得到正确的资料

        　　但是jsp文件不是这样 它没有这个默认转码过程 但是指定了pageEncoding就可以实现正确转码了

        　　举个例子

        　　<%@ page contentType= text/ charset=utf %>大都会打印出乱码 因为我输入的 你好吗 是gbk的 但是服务器是否正确抓到 你好吗 不得而知

        　　但是如果更改为

lishixinzhi/Article/program/Java/hx//