编码

在XX项目中解决android webkit处理汉字编码问题的总结 问题： 服务器通过302重定向方式发送给客户端重定向地址，地址中的汉字采用原数据方式发送，没有经过任何编码。因为其中存在汉字，所以在android端经过webkit解码编码之后，最终无法正常在服务器端请求正确数据。Android中默认使用utf-8编码。 Android在framework中解析http信息，Request.java的函数readResponse通过AndroidHttpClientConnection.java的函数parseResponseHeader解析response的header部分。 存储数据使用的是org.apache.http.util.CharArrayBuffer中的CharArrayBuffer。使用SessionInputBuffer的readline来读取一行，进行解析。 我们主要关心的是Location部分，因为重定向主要是通过Location的值重新去请求url。Android中也是这么做的，不会去html的body中解析标记A的herf。 读取的每一行都会被传入到Headers.java中进行解析。Location地址被转换为String存储到mHeaders[IDX_LOCATION]中。 在从CharArrayBuffer变成String的时候，有个值得注意的地方

让我们从一个故事开始说起。话说北大是很有哲学传统的，当你准备踏进北大校门时，连门卫都会连问你三个终极哲学问题： 你是谁？你从哪里来？你要到哪里去？ 那么这与我们的问题又有何关系呢？我觉得理解内存中的编码的关键在于理解String类型，因此我们也来探讨一下String的前世今生：String是谁（什么）？String从哪里来？String到哪里去？ 当我们能够清晰地回答这三个终极问题时，对文本在内存中的编码也算理解得差不多了。 注：文中将用Java平台为例来探讨这些问题。 String是什么？ 要回答这个问题，源码当然是最好的参考。 字符序列(CharSequence) 如果看String类型的声明： public final class String implements java.io.Serializable, Comparable<String>, CharSequence { private final char value[]; // ... } 可以看到它实现了所谓的CharSequence接口，所以它是一个char序列，内部实质是一个char数组。 也即上述代码中的”char value[]“，（也许你觉得”char[] value“的写法更习惯一些，两者是等价的） 如果再看String的length方法，事实就更清楚了，实际上取的是char数组的长度： public

ContentType 属性指定响应的 HTTP 内容类型。如果未指定 ContentType，默认为 text/HTML。 　　语法　　Response.ContentType [= ContentType ] 　　参数 　　ContentType pageEncoding是jsp文件本身的编码 contentType的charset是指服务器发送给客户端时的内容编码 JSP要经过两次的“编码”，第一阶段会用pageEncoding，第二阶段会用utf-8至utf-8，第三阶段就是由Tomcat出来的网页， 用的是contentType。 第一阶段是jsp编译成.java，它会根据pageEncoding的设定读取jsp，结果是由指定的编码方案翻译成统一的UTF-8 JAVA源码（即.java），如果pageEncoding设定错了，或没有设定，出来的就是中文乱码。 第二阶段是由JAVAC的JAVA源码至java byteCode的编译，不论JSP编写时候用的是什么编码方案，经过这个阶段的结果全部是UTF-8的encoding的java源码。 也就是说： pageEncoding：设置JSP源文件和响应正文中的字符集编码。 contentType：设置JSP源文件和响应正文的字符集编码及MIME类型。 可见

关键术语解释(下) 一、第1层 抽象字符表ACR (Abstract Character Repertoire抽象字符清单)：明确字符的范围(即确定支持哪些字符) 1. 抽象字符表ACR 是一个编码系统支持的所有抽象字符的集合，可以简单理解为无序的字符集合，用于确定字符的范围，即要支持哪些字符。 抽象字符表ACR的一个重要特点是字符的无序性，即其中的字符并没有编排数字顺序，当然也就没有数字编号。 2. “ 抽象 ”字符不具有某种特定的字形，不应与具有某种特定字形的“ 具体 ”字符混淆。 3. 字符表可以是 封闭的(即字符范围是固定的) ，即除非创建一个新的标准，否则 不允许 添加新的字符，比如ASCII字符表和ISO/IEC 8859系列都是这样的例子；字符表也可以是 开放的(即字符范围是不固定的) ，即 允许 不断添加新的字符，比如Unicode字符表和一定程度上Code Page代码页(代码页后文会有详细解释)是这方面的例子。 二、第2层 编号字符集CCS(Coded Character Set)：用数字编号表示字符(即用数字给字符编号) 【注： 一般将“ Coded Character Set ”翻译为“编码字符集”或“已编码字符集”，但这里的“编码”二字容易导致与后文的“编码方式”及“编码模式 ” 中的“编码”二字混淆，带来理解上的困扰，因此觉得翻译为“编号字符集”为宜。】

转自 http://www.ruanyifeng.com/blog/2007/10/ascii_unicode_and_utf-8.html 今天中午，我突然想搞清楚Unicode和UTF-8之间的关系，于是就开始在网上 查资料。 结果，这个问题比我想象的复杂，从午饭后一直看到晚上9点，才算初步搞清楚。 下面就是我的笔记，主要用来整理自己的思路。但是，我尽量试图写得通俗易懂，希望能对其他朋友有用。毕竟，字符编码是计算机技术的基石，想要熟练使 用计算机，就必须懂得一点字符编码的知识。 1. ASCII码 我们知道，在计算机内部，所有的信息最终都表示为一个二进制的字符串。每一个二进制位（bit）有0和1两种状态，因此八个二进制位就可以组合出 256种状态，这被称为一个字节（byte）。也就是说，一个字节一共可以用来表示256种不同的状态，每一个状态对应一个符号，就是256个符号，从 0000000到11111111。 上个世纪60年代，美国制定了一套字符编码，对英语字符与二进制位之间的关系，做了统一规定。这被称为ASCII码，一直沿用至今。 ASCII码一共规定了128个字符的编码，比如空格“SPACE”是32（二进制00100000），大写的字母A是65（二进制 01000001）。这128个符号（包括32个不能打印出来的控制符号），只占用了一个字节的后面7位

以下内容源于对 PEP-0263 的翻译和解读，同时给出了一些网上网友的说法。 ======== 我是分割线 ======== 原文地址： PEP 0263 -- Defining Python Source Code Encodings 【摘要】 给出声明 Python 源文件编码的语法。该编码信息后续会被 Python 解析器用于解析源文件。 这种方式增强了对源文件中 Unicode 编码字的处理。 【问题】 Python 2.1 时代，Unicode 字符只能采用基于 Latin-1 字符进行“Unicode 转义”的方式来表示（也就是说当时只支持 Latin-1 字符编码，所以 Unicode 字符编码只能使用 Latin-1 字符来进行转义表示）。这对广大亚洲人民是很坑爹的。 【解决方案】 通过在 Python 脚本文件的头部增加 显式的 、 可按文件随时改变的 特殊注释，来声明编码方式。 【编码定义】 Python 默认使用 ASCII 编码。 若要自定义 Python 源码的编码方式，需要在脚本文件的 第一 或者 第二 行的位置上添加如下定义： 1. 方式一（第一行） # coding=<encoding name> 2. 方式二（第二行） #!/usr/bin/python # -*- coding: <encoding name> -*- 3. 方式三（第二行）