编码java
Ⅰ java使用unicode为默认编码是什么意思
java初学者都会接触到一个概念，既java的默认编码是uincode，但书上也就出现这句话而已，究竟是什么意思就没再说。其实对于一个程序员来说，一个平台的编码方式是不用了解的，因为这是他内部处理字符的方式，和我们顶层设计程序是没有多大关系（如果真要说有关系的话，一个就是你对这个平台的熟悉程度，另一个就只能是你要处理的字符奇葩到要考虑编译器有没有包括这个字符）。但这并不是指我们在编程的时候完全不用考虑编码问题，恰恰相反，编码问题是跨系统交流的基本。
那java哪里会用到编码问题呢？最常见的是流，下面有两个例子。1.在linux下用java创建了一个文件（这里默认代码里没有指定编码），里面包括英文和中文，然后在windows下同样用java读取这个文件，并输出，结果中文出现了乱码；2.android手机和电脑的两个java程序进行类似qq的信息交流，中文都是乱码。疑惑来了，java不是跨平台吗，而且默认编码就是unicode，为什么会有编码？ 正如上面所说，java的系统编码是管理内部变量等信息的，是统一不能变的，但上面两个例子出现乱码的原因在于这些字符信息是从外界读取的，编码方式直接影响到字符的显示，比如gbk一个字符是1或2个字节，中文是2个，而utf8是1到4个字节不定，中文是3个，utf16是2个字节固定不变，所以很明显了，同样字节数的源信息可以每2个或者每3个字节表达一个中文，不同编码当然不同了，而且即使gbk和utf16都是两个字节表示一个中文，同样的二进制也对应不同的字符。所以从外部读取到这些byte信息后，就要指定编码，比如new
String(byte[],charset),当然，也可以在构建流的时候就指定，像new
InputStreamReader(InputStream,charset)等，但像BufferedReader等没有相应的构造函数，就只能把上面的InputStreamReader作为参数了。
总结：
1.String和流（包括控制台的输出输入）的默认编码是根据系统而定，即jvm假设这些信息是当前系统创建的，windows默认中文是gbk，linux和mac是utf8（这里又来了，utf8和unicode是什么意思，简单地说，unicode是把每个字符和一个唯一的二进制码对应的标准，而utf是unicode
transformation
format,即如何表示每个唯一的二进制码，utf8，utf16和utf32是不同的编码方式）；
2.IDE设置的编码方式用于存取java源文件，对于在不同系统平台上共享代码很重要；
3.java编译器采用utf8，即class文件的存储是用utf8，因为相对于utf16，utf8在处理英文占用内存小，而程序大部分都是英文；
4.jvm运行时的编码方式是utf16，即jvm用utf8从class文件读取程序后再转化为utf16编码的字符串，因为utf16是2个字节，统一的长度更方便jvm申请数组等操作；
5.网页大部分是用utf8编码的，在html头几行有charset的信息，在对下载下来的网页进行解析时，要注意编码，谷歌网络在对搜索结果的解析时也是用utf8的，所以在涉及到网络时编码问题非常重要，本人曾经栽得很惨，当然了，谁叫windows的编码不是utf8；
6.不知大家有没有经历过，如果编码弄错了，一般只有中文会出现乱码，而中文后面的英文是正确的，不合理啊，这不是类似多骨诺米牌吗，一个错了，后面不是全倒吗。所以别小看那些制定编码的专家，像utf8每个字节的前几位都用来表示一些信息，不同字节还不一样，而utf16也有，所以弄出了utf16le和utf16be
Ⅱ java中编码与解码分别指什么
java中编码：URLEncoder.encode(strUri,"utf-8");
java中解码码：URLDecoder.decode(strUri,"utf-8");
Ⅲ 编写JAVA程序输出中文字的unicode编码
我写的，你试试，你可以把它改写成循环的，可以一直把字符的Unicode输出，完善后发给我哈：
import java.io.*;
public class FindUnicode {
public static void main(String[] args) throws IOException{
InputStreamReader read = new InputStreamReader (System.in);
int ch = read.read();
System.out.print("\\u"+Integer.toHexString(ch));
read.close();
}
}
Ⅳ JAVA 编码 这是什么编码
编码就是对已有的数据进行安全重编译，比如说对于一个String字符串应用MD5加密 就会出现这种情况，比如字符串123456应用MD5加密编码就会变成gdyb21LQTcIANtvYMT7QVQ== 还有时候是为了程序前端和后端保持一致的对字符串的处理方式，因为同一个字符串，一旦前、后端处理编码不一致就会出现乱码，就会把汉子变成乱码输出。像你想把手机号编码成这种乱码 ，最好就是应用MD5加密
Ⅳ 各个JAVA编码的区别
Java的class文件采用utf8的编码方式，JVM运行时采用utf16。
Java的字符串是unicode编码的。
总之，Java采用了unicode字符集，使之易于国际化。
java对不同编码的处理：一个字节存8位，每位都有两中可能(0,1)共可以组合成表示2的8次方 256种可能，0~127存储空格、标点符号、数字、大小写字母，127~255存储其他国家语言的一些特殊字符还加入了很多画表格时需要用下到的横线、竖线、交叉等形状，一直把序号编到了最后一个状态255。
Java是一种可以撰写跨平台应用程序的面向对象的程序设计语言。Java技术具有卓越的通用性、高效性、平台移植性和安全性，广泛应用于PC、数据中心、游戏控制台、科学超级计算机、移动电话和互联网，同时拥有全球最大的开发者专业社群。
Java 编程语言的风格十分接近C、C++语言。Java是一个纯的面向对象的程序设计语言，它继承了 C++ 语言面向对象技术的核心，Java舍弃了C ++语言中容易引起错误的指针（以引用取代）、运算符重载（operator overloading）、多重继承（以接口取代）等特性，增加了垃圾回收器功能用于回收不再被引用的对象所占据的内存空间，使得程序员不用再为内存管理而担忧。在 Java SE 1.5 版本中，Java 又引入了泛型编程（Generic Programming）、类型安全的枚举、不定长参数和自动装/拆箱等语言特性。
Java 不同于一般的编译执行计算机语言和解释执行计算机语言。它首先将源代码编译成二进制字节码(bytecode)，然后依赖各种不同平台上的虚拟机来解释执行字节码，从而实现了“一次编译、到处执行”的跨平台特性。不过，每次的编译执行需要消耗一定的时间，这同时也在一定程度上降低了 Java 程序的运行效率。但在J2SE1.4.2 发布后，Java 的执行速度有了大幅提升。
Ⅵ Java几种常见的编码格式
ASCII 码
学过计算机的人都知道 ASCII 码，总共有 128 个，用一个字节的低 7 位表示，0~31 是控制字符如换行回车删除等；32~126 是打印字符，可以通过键盘输入并且能够显示出来。
ISO-8859-1
128 个字符显然是不够用的，于是 ISO 组织在 ASCII 码基础上又制定了一些列标准用来扩展 ASCII 编码，它们是 ISO-8859-1~ISO-8859-15，其中 ISO-8859-1 涵盖了大多数西欧语言字符，所有应用的最广泛。ISO-8859-1 仍然是单字节编码，它总共能表示 256 个字符。
GB2312
它的全称是《信息交换用汉字编码字符集 基本集》，它是双字节编码，总的编码范围是 A1-F7，其中从 A1-A9 是符号区，总共包含 682 个符号，从 B0-F7 是汉字区，包含 6763 个汉字。
GBK
全称叫《汉字内码扩展规范》，是国家技术监督局为 windows95 所制定的新的汉字内码规范，它的出现是为了扩展 GB2312，加入更多的汉字，它的编码范围是 8140~FEFE（去掉 XX7F）总共有 23940 个码位，它能表示 21003 个汉字，它的编码是和 GB2312 兼容的，也就是说用 GB2312 编码的汉字可以用 GBK 来解码，并且不会有乱码。
GB18030
全称是《信息交换用汉字编码字符集》，是我国的强制标准，它可能是单字节、双字节或者四字节编码，它的编码与 GB2312 编码兼容，这个虽然是国家标准，但是实际应用系统中使用的并不广泛。
UTF-16
说到 UTF 必须要提到 Unicode（Universal Code 统一码），ISO 试图想创建一个全新的超语言字典，世界上所有的语言都可以通过这本字典来相互翻译。可想而知这个字典是多么的复杂，关于 Unicode 的详细规范可以参考相应文档。Unicode 是 Java 和 XML 的基础，下面详细介绍 Unicode 在计算机中的存储形式。
UTF-16 具体定义了 Unicode 字符在计算机中存取方法。UTF-16 用两个字节来表示 Unicode 转化格式，这个是定长的表示方法，不论什么字符都可以用两个字节表示，两个字节是 16 个 bit，所以叫 UTF-16。UTF-16 表示字符非常方便，每两个字节表示一个字符，这个在字符串操作时就大大简化了操作，这也是 Java 以 UTF-16 作为内存的字符存储格式的一个很重要的原因。
UTF-8
UTF-16 统一采用两个字节表示一个字符，虽然在表示上非常简单方便，但是也有其缺点，有很大一部分字符用一个字节就可以表示的现在要两个字节表示，存储空间放大了一倍，在现在的网络带宽还非常有限的今天，这样会增大网络传输的流量，而且也没必要。而 UTF-8 采用了一种变长技术，每个编码区域有不同的字码长度。不同类型的字符可以是由 1~6 个字节组成。
UTF-8 有以下编码规则：
如果一个字节，最高位（第 8 位）为 0，表示这是一个 ASCII 字符（00 - 7F）。可见，所有 ASCII 编码已经是 UTF-8 了。
如果一个字节，以 11 开头，连续的 1 的个数暗示这个字符的字节数，例如：110xxxxx 代表它是双字节 UTF-8 字符的首字节。
如果一个字节，以 10 开始，表示它不是首字节，需要向前查找才能得到当前字符的首字节
Java 中需要编码的场景
前面描述了常见的几种编码格式，下面将介绍 Java 中如何处理对编码的支持，什么场合中需要编码。
I/O 操作中存在的编码
我们知道涉及到编码的地方一般都在字符到字节或者字节到字符的转换上，而需要这种转换的场景主要是在 I/O 的时候，这个 I/O 包括磁盘 I/O 和网络 I/O，关于网络 I/O 部分在后面将主要以 Web 应用为例介绍。
Ⅶ Java几种常见的编码方式
一般都用utf-8万国码
Ⅷ Java中如何设置编码格式
打开Eclipse，选择Window--〉Preferences--〉General---〉Workspace，然后在右边的界面就可以看见Other选项，选择即可设置编码格式。
Ⅸ 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很高级的嘞，可以设置成不通编码的(其实几乎所有的都可以)。那么分析的方法和上面一样，结果可能正好相反。