编码解码

一、

文件:字节流,字符流。

字节流:直接将在JVM中处理的unicode的byte[]存入到文件,有数值和字符数据之分(即数值几个字节,字符是几个字节等);

字符流:会将unicode的byte[](包括数值和字符),转换成默认编码(utf-8)的byte[],然后存入到文件。

字符--》字节byte[]--》字符

二、

java.class类的编码为:unicode;

Java的class文件采用utf8的编码方式,JVM运行时采用utf16。Java的字符串是unicode编码。

windows 默认的编码为:中文:gb2312; 英文:iso8859;

"中文",unicode存储为"4e2d 6587",如果charset为"gbk",则被编码为"d6d0 cec4",然后返回字节"d6 d0 ce c4".如果charset为"utf8"则最后是"e4 b8 ad e6 96 87".如果是"iso8859-1",则由于无法编码,最后返回 "3f 3f"(两个问号)

1,文件,JVM,文件都是以字节码(byte[])进行处理的,我们看到字符是byte[]通过对应的编码方式映射的。

2,不同编码对byte[]的处理方式不同,对应的映射也不相同。体会由utf8的byte[]编码到unicode的byte[],再由unicode的byte[]解码到utf8的byte[]

3,两层管理,一层:不同编码的byte[],不同编码的byte[]可以通过unicode的byte[]进行转换;二层:每种编码的byte[]怎么对应我们看到的字符

Java采用的编码:unicode,JVM平台默认字符集和外部资源的编码:

文件:utf8的byte[]

JVM:utf8的byte[]转化为unicode的byte[]

文件:需要将unicode的byte[]以哪种编码的byte[]进行存储到文件中

当没有明确指定需要使用的字符编码方案时,Java程序通过“java.nio.charset.Charset.defaultCharset().name()”语句来获取默认的字符编码方案,该语句返回的值跟运行Java程序的操作系统的设置有关,在有些操作系统上,该语句返回值可能是UTF8;在有些操作系统上,该语句返回值可能是GBK;在有些操作系统上,该语句返回值可能是除了UTF8和GBK以外的其他字符编码方案。这样子,程序的可移植性大大降低。

两层结构:由字节流,到编码的字节流,编码映射字符

JVM里面的任何字符串资源都是Unicode,就是说,任何String类型的数据都是Unicode编码。没有例外。既然只有一种编码,那么,我们可以这么说,JVM里面的String是不带编码的。String相当于char[]。

JVM里面的 byte[] 数据是带编码的。比如,Big5,GBK,GB2312,UTF-8之类的。

一个GBK编码的byte[] 转换成 String,其实就是从GBK编码向Unicode编码转换。

一个String转换成一个Big5编码的byte[],其实就是从Unicode编码向Big5编码转换。

所以,Unicode是所有编码转换的中间介质。所有的编码都有一个转换器可以转换到Unicode,而Unicode也可以转换到其他所有的编码。这样构成了一个总线结构。

byte是字节,字符串在网络传输或存储前需要转换为byte数组。在从网络接收或从存储设备读取后需要将byte数组转换成String。String是字符串,可以看成是由char组成的数组。String和char为内存形式,byte是网络传输或存储的序列化形式。

String序列化成byte数组或byte反序列化为String时需要选择正确的编码方式。如果编码方式不正确,就会得到一些0x3F的值。常用的字符编码方式有ISO8859_1、GB2312、GBK、UTF-8/UTF-16/UTF-32。

所有文件的储存是都是字节(byte)的储存,在磁盘上保留的并不是文件的字符而是先把字符编码成字节,再储存这些字节到磁盘。在读取文件(特别是文本文件)时,也是一个字节一个字节地读取以形成字节序列字节流可用于任何类型的对象,包括二进制对象,而字符流只能处理字符或者字符串;

字节流提供了处理任何类型的IO操作的功能,但它不能直接处理Unicode字符,而字符流就可以。

字节流是最基本的,所有的InputStrem和OutputStream的子类都是,主要用在处理二进制数据,它是按字节来处理的,但实际中很多的数据是文本,又提出了字符流的概念,它是按虚拟机的encode来处理,也就是要进行字符集的转化这两个之间通过InputStreamReader,OutputStreamWriter来关联,实际上是通过byte[]和String来关联 在实际开发中出现的汉字问题实际上都是在字符流和字节流之间转化不统一而造成的

时间: 2024-08-10 03:54:21

编码解码的相关文章

[C语言]Base64编码解码

Base64编码解码 一,Base64编码原理 Base64编码的字符数组如下所示 : ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/ 字符串转Base64编码:取3字节的字符串转换为四字节的字符串,依次往后转换.得到Base64编码字符串.具体原理如下: 1,如果需要编码的原串字节数刚好为3的倍数,那么转换规则如下: 以中文字符'严'为例,'严'字的UTF-8编码为:0xE4B8A5 = 11100100  10

服务器端获取表单数据的编码解码问题(servlet)

首先需要明确指出的是,这里的服务器是指tomcat. 在页面没有明确指定编码的情况下,客户端通过input标签和字符串向服务器传递两个值param1和param2.如果直接使用request.getParameter()方法来获取值的话,得到的肯定都是乱码,我们需要对其重新进行编码解码,就像下面的代码所示的那样: new String(req.getParameter("param1").getBytes("iso-8859-1"), "gbk"

百度移动版的url编码解码代码

1 var decode = function(m) { 2 try { 3 m = decodeURIComponent(m); 4 } catch(e) {} 5 var s = m.split("%"); 6 if (s.length > 1) { 7 s.shift(); 8 for(var i = 0; i < s.length; i++) { 9 var t = s[i]; 10 t = parseInt(t, 16); 11 t = t + 256; 12 t

Atitit.&#160;二进制数据ascii表示法,与base64编码解码api&#160;设计标准化总结java&#160;php&#160;c#.net

Atitit. 二进制数据ascii表示法,与base64编码解码api 设计标准化总结java php c#.net 1. Base64编码,1 1.1. 子模式 urlsafe Or  url unsafe2 1.2. 其他的二进制数据表示法  bin2hex() ,Quoted-printable ,UUencode2 2. Base64常用api2 2.1. ------------解码api2 2.2. decode(String s, OutputStream out)2 2.3. 

使用多字节字符集的跨平台(PC、Android、IOS、WP)编码/解码方法

随着移动端的发展,跨平台已成为通讯架构设计的重要考虑因素,PC.Android.IOS.WP等跨多平台间的数据通讯,必然要解决字符编码/解码的问题. 多字节字符集MBCS不是跨平台的首选字符集,面向跨平台.国际化的推荐字符集肯定是UNICODE. 写VC的人都知道,在以前VC++6.0中默认的字符集是多字节字符集,而VS2005及以后默认的字符集是Unicode,VS2013中默认不再对多字节字符串进行支持. 但对很多较早的服务端项目,依然使用的是多字节字符集,不过使用多字节字符集依然可以实现跨

常见编码解码脚本

在平时我们会遇到各种各样的编码,在这里,我总结了一些常见的编码,并不是很全 尝试着做了个编码解码的汇总,并且写了个脚本出来,由于python功底不是很强,所以可能会有不到之处,还望各位多多指正 附上脚本: 1 #-*-coding:utf-8-*- 2 #author:hell0_w 3 #本人博客:http://hell0w.cnblogs.com/ 4 5 import base64 6 import bubblepy 7 import urllib 8 import quopri 9 im

网络编程 -- RPC实现原理 -- Netty -- 迭代版本V3 -- 编码解码

网络编程 -- RPC实现原理 -- 目录 啦啦啦 V2--Netty -- pipeline.addLast(io.netty.handler.codec.MessageToMessageCodec<INBOUND_IN, OUTBOUND_IN>) 覆写编码解码方法. pipeline相当于拦截器.在pipeline中添加MessageToMessageCodec接口的实现类,该接口的实现类中的encode()方法自动将发送的Object对象转换为ByteBuf,decode()方法自动将

JavaEE细节问题03——关于服务器和浏览器的编码解码

Request--对于接受请求: 获取请求中的编码解码问题 : 对于post请求,浏览器会根据当前页面的编码来对字符进行编码, 所以我们 直接采用:  request.setCharacterEncoding("UTF-8"); 对于get请求,浏览器自动对字符进行iso-8859-1编码 所以我们拿到以后就要对其进行iso-8859-1解码,使其成为原本的字节数组,然后再进行utf-8编码          Enumeration<String> enums = requ

自定义协议的编码解码

2015.4.1 wqchen. 转载请注明出处 http://www.cnblogs.com/wqchen/p/4385798.html 本文介绍的是一个自定义协议的编码解码工具的实现. 游戏开发中,前端后端协议一般都会协商定制通信协议的格式,统一格式后用程序脚本对应前端和后端的编程语言,分别生成一份协议的编码和解码方案,便于协议的一致性. 这样的工具有很多,比较出名的是google的protobuf,它可以支持很多种编程语言.我也曾试用过protobuf,看过一点它的实现,protobuf完

C# 对JS编码/解码进行转换

public static class Extension { #region [编码/解码统一转换] /// <summary> /// /// </summary> /// <param name="str"></param> /// <param name="isEscape">True为Encode;False为Decode</param> /// <returns><