憨厚生

【转】http://www.cnblogs.com/myssh/archive/2009/12/18/1627368.html

在《Pragmatic AJAX中文问题 A Web 2.0 Primer 》中偶然看到对readyStae状态的介绍，感觉这个介绍很实在，摘译如下：

 0: (Uninitialized) the send( ) method has not yet been invoked. 
 1: (Loading) the send( ) method has been invoked, request in progress. 
 2: (Loaded) the send( ) method has completed, entire response received.
 3: (Interactive) the response is being parsed. 
 4: (Completed) the response has been parsed, is ready for harvesting. 

 0 － （未初始化）还没有调用send()方法
 1 － （载入）已调用send()方法，正在发送请求
 2 － （载入完成）send()方法执行完成，已经接收到全部响应内容
 3 － （交互）正在解析响应内容
 4 － （完成）响应内容解析完成，可以在客户端调用了

对于readyState的这五种状态，其他书中大都语焉不详。像《Foundations of AJAX中文问题》中，只在书中的表2-2简单地列举了状态的“名称”－－The state of the request. The five possible values are 0 = uninitialized, 1 = loading, 2 = loaded, 3 = interactive, and 4 = complete。而《Ajax in Action》中好像根本就没有提到这5种状态的细节。《Professional AJAX中文问题》中虽不尽人意，但还是有可取之处：

There are five possible values for readyState: 
0 (Uninitialized): The object has been created but the open() method hasn’t been called. 
1 (Loading): The open() method has been called but the request hasn’t been sent. 
2 (Loaded): The request has been sent. 
3 (Interactive). A partial response has been received. 
4 (Complete): All data has been received and the connection has been closed. 

readyState有五种可能的值：
0 (未初始化)： (XMLHttpRequest)对象已经创建，但还没有调用open()方法。
1 (载入)：已经调用open() 方法，但尚未发送请求。
2 (载入完成)： 请求已经发送完成。
3 (交互)：可以接收到部分响应数据。
4 (完成)：已经接收到了全部数据，并且连接已经关闭。

在《Understanding AJAX中文问题: Using JavaScript to Create Rich Internet Applications》中，则用下表进行了说明：

readyState Status Code	Status of the XMLHttpRequest Object
(0) UNINITIALIZED 未初始化	The object has been created but not initialized. (The open method has not been called.) （XMLHttpRequest）对象已经创建，但尚未初始化（还没有调用open方法）。
(1) LOADING 载入	The object has been created, but the send method has not been called. （XMLHttpRequest）对象已经创建，但尚未调用send方法。
(2) LOADED 载入完成	The send method has been called, but the status and headers are not yet available. 已经调用send方法，（HTTP响应）状态及头部还不可用。
(3) INTERACTIVE 交互	Some data has been received. Calling the responseBody and responseText properties at this state to obtain partial results will return an error, because status and response headers are not fully available. 已经接收部分数据。但若在此时调用responseBody和responseText属性获取部分结果将会产生错误，因为状态和响应头部还不完全可用。
(4) COMPLETED 完成	All the data has been received, and the complete data is available in the responseBody and responseText properties. 已经接收到了全部数据，并且在responseBody和responseText属性中可以提取到完整的数据。

根据以上几本书中的关于readyState五种状态的介绍，我认为还是《Pragmatic AJAX中文问题 A Web 2.0 Primer 》比较到位，因为它提到了对接收到的数据的解析问题，其他书中都没有提到这一点，而这一点正是“(3)交互”阶段作为一个必要的转换过程存在于“(2)载入完成”到“(4)完成”之间的理由，也就是其任务是什么。归结起来，我觉得比较理想的解释方法应该以“状态：任务（目标）+过程+表现（或特征）”表达模式来对这几个状态进行定义比较准确，而且让人容易理解。现试总结如下：

readyState 状态	状态说明
(0)未初始化	此阶段确认XMLHttpRequest对象是否创建，并为调用open()方法进行未初始化作好准备。值为0表示对象已经存在，否则浏览器会报错－－对象不存在。
(1)载入	此阶段对XMLHttpRequest对象进行初始化，即调用open()方法，根据参数(method,url,true)完成对象状态的设置。并调用send()方法开始向服务端发送请求。值为1表示正在向服务端发送请求。
(2)载入完成	此阶段接收服务器端的响应数据。但获得的还只是服务端响应的原始数据，并不能直接在客户端使用。值为2表示已经接收完全部响应数据。并为下一阶段对数据解析作好准备。
(3)交互	此阶段解析接收到的服务器端响应数据。即根据服务器端响应头部返回的MIME类型把数据转换成能通过responseBody、responseText或responseXML属性存取的格式，为在客户端调用作好准备。状态3表示正在解析数据。
(4)完成	此阶段确认全部数据都已经解析为客户端可用的格式，解析已经完成。值为4表示数据解析完毕，可以通过XMLHttpRequest对象的相应属性取得数据。

概而括之，整个XMLHttpRequest对象的生命周期应该包含如下阶段：
创建－初始化请求－发送请求－接收数据－解析数据－完成

在具体应用中，明确了readyState的五个状态（XMLHttpRequest对象的生命周期各个阶段）的含义，就可以消除对Ajax核心的神秘感（语焉不详的背后要么是故弄玄虚，制造神秘感；要么就是“以其昏昏，使人昭昭”），迅速把握其实质，对减少学习中的挫折感和增强自信心都极其有益。

比如，通过如下示例：

//声明数组
var states ＝ [“正在初始化……”,
“正在初始化请求……成功！
正在发送请求……”,
“成功！
正在接收数据……”,
“完成！
正在解析数据……”,
“完成！
”];
//回调函数内部代码片段
if (xmlHttp.readyState==4)
{
var span = document.createElement(“span”);
span.innerHTML = states[xmlHttp.readyState];
document.body.appendChild(span);
if (xmlHttp.status == 200)
{
var xmldoc = xmlHttp.responseXML;
//其他代码
}
//别忘记销毁，防止内存泄漏
xmlHttp = null;
}else{
var span = document.createElement(“span”);
span.innerHTML = states[xmlHttp.readyState];
document.body.appendChild(span);
}

结果如下：

正在初始化请求……成功！
正在发送请求……成功！
正在接收数据……完成！
正在解析数据……完成！

我们很容易明白XMLHttpRequest对象在各个阶段都在做什么。因此，也就很容易对Ajax的核心部分有一个真正简单明了的理解。

本博PS：readyState一般用在异步请求时程序响应的判断，Iframe， javaScript脚本同样适用,参考另一篇文章：http://d-tune.javaeye.com/blog/506074

文章出处：http://www.cn-cuckoo.com/2007/07/16/the-details-for-five-states-of-readystate-9.html

历史 
    CVS 诞生于 1986 年，当时作为一组 shell 脚本而出现；1989年3月，Brian Berlinor用C语言重新设计并编写了CVS的代码；1993年前后，Jim Kingdon最终将CVS设计成基于网络的平台，开发者们能从Internet任何地方获得程序源代码。截至目前最新版本是2004年12月13日发布的1.12.11。 

功能介绍 
一、 代码统一管理，保存所有代码文件更改的历史记录。对代码进行集中统一管理，可以方便查看新增或删除的文件，能够跟踪所有代码改动痕迹。可以随意恢复到以前任意一个历史版本。并避免了因为版本不同引入的深层BUG。 
二、 完善的冲突解决方案，可以方便的解决文件冲突问题，而不需要借助其它的文件比较工具和手工的粘贴复制。 
三、 代码权限的管理。可以为不同的用户设置不同的权限。可以设置访问用户的密码、只读、修改等权限，而且通过CVS ROOT目录下的脚本，提供了相应功能扩充的接口，不但可以完成精细的权限控制，还能完成更加个性化的功能。 
四、 支持方便的版本发布和分支功能。

基本概念 
资源库（Repository） 
CVS的资源库存储全部的版本控制下的文件copy，通常不容许直接访问，只能通过cvs命令，获得一份本地copy，改动后再check in（commit）回资源库。而资源库通常为与工作目录分离的。CVS通过多种方式访问资源库。每种方法有不同目录表示形式。 
版本（Revision） 
每一个文件的各个版本都不相同，形如1.1, 1.2.1,一般1.1是该文件的第一个revision，后面的一个将自动增加最右面的一个整数，比如1.2, 1.3, 1.4...有时候会出现1.3.2.2，原因见后。revision总是偶数个数字。一般情况下将revision看作时CVS自己内部的一个编号，而tag则可以标志用户的特定信息。 
标签（Tag） 
用符号化的表示方法标志文件特定revision的信息。通常不需要对某一个孤立的文件作tag，而是对所有文件同时作一个tag，以后用户可以仅向特定tag的文件提交或者checkout。另外一个作用是在发布软件的时候表示哪些文件及其哪个版本是可用的；各文件不同revision可以包括在一个tag中。如果命名一个已存在的tag默认将不会覆盖原来的； 
分支（Branch） 
当用户修改一个branch时不会对另外的branch产生任何影响。可以在适当的时候通过合并的方法将两个版本合起来；branch总是在当前revision后面加上一个偶数整数（从2开始，到0结束），所以branch总是奇数个数字，比如1.2后面branch为1.2.2，该分支下revision可能为1.2.2.1,1.2.2.2,... 
冲突（Conflct） 
完全是纯文本的冲突，不包含逻辑上的矛盾。一般是一份文件，A做了改动，B在A提交之前也做了改动，这样最后谁commit就会出现冲突，需要手工解决冲突再提交。 

CVS与eclipse集成开发 
  前面对CVS的历史、功能、概论等理论知识做了介绍。下面我们将使用最流行的Java IDE Eclipse中内置的CVS工具，以一个完整开发流程，介绍实际环境中CVS的正确使用。关于CVS系统的安装，不是本文的内容，您可以从附录的链接中获取安装的介绍资料。 

常用的CVS控制命令 
Check Out（检出） 
把源文件从cvs源代码仓库中取出，缺省的版本是最新的版本，你也可以选择指定的版本。在每次更改源代码之前，需要Check Out最新的版本，再起基础之上对源代码进行修改。将代码目录checkout到指定目录下，所有文件都是read-write。 
Check In（检入） 
把源代码加入到cvs源代码仓库中，每一个添加进代码库中的文件的版本是 1.1。以后每次修改文件重新ci以后，此文件的版本递增为1.2 ，1.3.……。在每次对源代码修改之后，需要Check In，提交最新版本的源代码。 
Synchronize with Repository(与资源库同步，简称同步) 
使本地更改与资源库同步，它会列出本地和资源库之间不同的所有文件。 
Add to Version Control 
将新的文件加入到版本控制之中。 
Add to .cvsIgnore 
将文件设置到版本控制之外，这样该文件或目录中的文件的更改在CVS中不可见，即使同步也无法发现。

CVS正确使用步骤 
一、 同步（Synchronize） 
就是将本地更改与服务器同步，同步之后可以清晰的看到上一捡出（Check Out）版本之后本地、服务器上的最新改动。这是非常有用的，特别是敏捷开发，强调集体拥有代码。有了同步功能，你可以全局把握项目的代码，可以很方便的跟踪公共模块代码的任何改动。 
具体操作：在Eclipse的资源视图（Resource Perspective）或者Java视图（Java Perspective）中，选中要同步的目录，点击右键选择"Synchronize with Repository",之后它将显示同步的视图。如下图： 

(图一、CVS同步视图) 
同步之后，它有四种Mode可以选择，见上图绿色框框里按钮。从做到右分别为： 
Incoming Mode：表示修改是来自服务器，对应于更新（update）操作。 
Outgoing Mode：表示修改是来自本地，对应提交（commit）操作。 
Incoming/ Outgoing Mode：本地和服务器修改都在该模式（Mode）中显示。 
Conflicts Mode：显示本地和服务器修改的冲突文件。 
二、 更新（update） 
比较简单，选择Incoming Mode，再选中要更新的文件，右键选择update操作。 
三、 解决冲突并合并(solve conflct and merge) 
如果有冲突文件，冲突文件不能更新。你必须先解决冲突再操作。选中冲突的文件，再点右键选择"Open in Compare Editor"，用比较工具打开该文件。如下图： 

（图二、CVS比较器视图）

比较器（Compare）视图，左边版本底的是本地文件（Local File），右边是远程服务器文件（Remote File）。使用"Select Next Change"按钮（绿框中的第一箭头向下按钮），逐一查看不同点。如果不同点标识为黑色框框，则不用管它。如果是蓝色框框，则需要手工调整。如上图，不同点是蓝色框框，将鼠标放到两个不同点的中间小方框中，则凸出一个向右的按钮，并显示提示信息"Copy Current Change from Right to Left"，意思是将右边服务器的不同点覆盖到左边的本地文件。点中此按钮。重复这样的操作，将所有服务器上的更改拷贝到本地。 
如果有一行代码，本地和服务器都同时做了修改。这时，修改点则显示红色框框。这时，你就必须手工做正确的修改。全部修改完成，保存本地文件。 
此时，如果修改点没有了蓝色的框框，就可以开始做合并（merge）操作了。操作也很简单，选择该文件，点击右键，选择"Mark as merged"。 
注意：必须确保没有蓝色框框，即完全拷贝了服务器的修改才可以做合并（merge）操作，否则会覆盖服务器上的代码。 
四、 提交（commit） 
更新服务器代码，解决冲突之后，首先要查看本地文件修改之后是否有错误。如果有，当然首先解决错误，再提交。 

转  http://blog.cnw.com.cn/index.php/20937/viewspace-3418

HTTP头字段包括4类：
       general-header ;
     request-header ;
       response-header ;
     entity-header .
 
*******************************************************************************
 General Header Fields
=============================
   general header是request、response都可用的, 但是不能用于entity.
 
 
       －－ Cache-Control
       －－ Connection
       －－ Date
       －－ Pragma
       －－ Trailer
       －－ Transfer-Encoding
       －－ Upgrade
       －－ Via
       －－ Warning
 
*******************************************************************************
 Request Header Fields
======================
 
   request-header fields 允许客户端传递关于request和客户端的附加信息到服务端，
 
       －－ Accept
       －－ Accept-Charset
       －－ Accept-Encoding
       －－ Accept-Language
       －－ Authorization
       －－ Expect
       －－ From
       －－ Host
       －－ If-Match
       －－ If-Modified-Since
       －－ If-None-Match
       －－ If-Range
       －－ If-Unmodified-Since
       －－ Max-Forwards
       －－ Proxy-Authorization
       －－ Range
       －－ Referer
       －－ TE
       －－ User-Agent
 
*******************************************************************************
  Response Header Fields
===============================
 
   response-header fields 允许服务端传递关于response的、不能放到Status-Line的附加信息。
   这些头给出关于服务端的信息。 
 
      －－ Accept-Ranges
      －－ Age
      －－ ETag
      －－ Location
      －－ Proxy-Authenticate
      －－ Retry-After
      －－ Server
      －－ Vary
      －－ WWW-Authenticate
 
*******************************************************************************
 Entity Header Fields
========================
 
   Entity-header fields 定义关于entity-body的metainformation(标题字段数据),
   如果当前没有body, 则定义被request确定的资源信息.
   一些metainformation是可选的; 一些是必须的。
 
       －－ Allow
       －－ Content-Encoding
       －－ Content-Language
       －－ Content-Length
       －－ Content-Location
       －－ Content-MD5
       －－ Content-Range
       －－ Content-Type
       －－ Expires
       －－ Last-Modified
       －－ extension-header

【转自】http://www.x5dj.com/userforum/00100239/00305167.shtml

一、基础篇
HTTP（HyperTextTransferProtocol）是超文本传输协议的缩写，它用于传送WWW方式的数据，关于HTTP协议的详细内容请参考RFC2616。HTTP协议采用了请求/响应模型。客户端向服务器发送一个请求，请求头包含请求的方法、URI、协议版本、以及包含请求修饰符、客户信息和内容的类似于MIME的消息结构。服务器以一个状态行作为响应，相应的内容包括消息协议的版本，成功或者错误编码加上包含服务器信息、实体元信息以及可能的实体内容。
通常HTTP消息包括客户机向服务器的请求消息和服务器向客户机的响应消息。这两种类型的消息由一个起始行，一个或者多个头域，一个只是头域结束的空行和可选的消息体组成。HTTP的头域包括通用头，请求头，响应头和实体头四个部分。每个头域由一个域名，冒号（:）和域值三部分组成。域名是大小写无关的，域值前可以添加任何数量的空格符，头域可以被扩展为多行，在每行开始处，使用至少一个空格或制表符。
1、通用头域
通用头域包含请求和响应消息都支持的头域，通用头域包含Cache-Control、Connection、Date、Pragma、Transfer-Encoding、Upgrade、Via。对通用头域的扩展要求通讯双方都支持此扩展，如果存在不支持的通用头域，一般将会作为实体头域处理。下面简单介绍几个在UPnP消息中使用的通用头域。
Cache-Control头域
Cache-Control指定请求和响应遵循的缓存机制。在请求消息或响应消息中设置Cache-Control并不会修改另一个消息处理过程中的缓存处理过程。请求时的缓存指令包括no-cache、no- store、max-age、max-stale、min-fresh、only-if-cached，响应消息中的指令包括public、 private、no-cache、no-store、no-transform、must-revalidate、proxy-revalidate、 max-age。各个消息中的指令含义如下：
Public指示响应可被任何缓存区缓存。
Private指示对于单个用户的整个或部分响应消息，不能被共享缓存处理。这允许服务器仅仅描述当用户的部分响应消息，此响应消息对于其他用户的请求无效。
no-cache指示请求或响应消息不能缓存
no-store用于防止重要的信息被无意的发布。在请求消息中发送将使得请求和响应消息都不使用缓存。
max-age指示客户机可以接收生存期不大于指定时间（以秒为单位）的响应。
min-fresh指示客户机可以接收响应时间小于当前时间加上指定时间的响应。
max-stale指示客户机可以接收超出超时期间的响应消息。如果指定max-stale消息的值，那么客户机可以接收超出超时期指定值之内的响应消息。
Date头域
Date头域表示消息发送的时间，时间的描述格式由rfc822定义。例如，Date:Mon,31Dec200104:25:57GMT。Date描述的时间表示世界标准时，换算成本地时间，需要知道用户所在的时区。
Pragma头域
Pragma头域用来包含实现特定的指令，最常用的是Pragma:no-cache。在HTTP/1.1协议中，它的含义和Cache-Control:no-cache相同。
2、请求消息
请求消息的第一行为下面的格式：
Method　SP　Request-URI　SP　HTTP-Version　CRLF　
Method表示对于Request-URI完成的方法，这个字段是大小写敏感的，包括OPTIONS、GET、HEAD、POST、PUT、DELETE、TRACE。方法GET和HEAD应该被所有的通用WEB服务器支持，其他所有方法的实现是可选的。GET方法取回由Request-URI标识的信息。HEAD方法也是取回由Request-URI标识的信息，只是可以在响应时，不返回消息体。POST方法可以请求服务器接收包含在请求中的实体信息，可以用于提交表单，向新闻组、BBS、邮件群组和数据库发送消息。
SP表示空格。
Request-URI遵循URI格式，在此字段为星号（*）时，说明请求并不用于某个特定的资源地址，而是用于服务器本身。
HTTP-Version表示支持的HTTP版本，例如为HTTP/1.1。
CRLF表示换行回车符。
请求头域允许客户端向服务器传递关于请求或者关于客户机的附加信息。请求头域可能包含下列字段Accept、Accept-Charset、Accept- Encoding、Accept-Language、Authorization、From、Host、If-Modified-Since、If- Match、If-None-Match、If-Range、If-Range、If-Unmodified-Since、Max-Forwards、 Proxy-Authorization、Range、Referer、User-Agent。对请求头域的扩展要求通讯双方都支持，如果存在不支持的请求头域，一般将会作为实体头域处理。
典型的请求消息：
GEThttp://class/download.microtool.de:80/somedata.exe
Host:download.microtool.de
Accept:*/*
Pragma:no-cache
Cache-Control:no-cache
Referer:http://class/download.microtool.de/
User-Agent:Mozilla/4.04[en](Win95;I;Nav)
Range:bytes=554554-
上例第一行表示HTTP客户端（可能是浏览器、下载程序）通过GET方法获得指定URL下的文件。棕色的部分表示请求头域的信息，绿色的部分表示通用头部分。
Host头域
Host头域指定请求资源的Intenet主机和端口号，必须表示请求url的原始服务器或网关的位置。HTTP/1.1请求必须包含主机头域，否则系统会以400状态码返回。
Referer头域
Referer头域允许客户端指定请求uri的源资源地址，这可以允许服务器生成回退链表，可用来登陆、优化cache等。他也允许废除的或错误的连接由于维护的目的被追踪。如果请求的uri没有自己的uri地址，Referer不能被发送。如果指定的是部分uri地址，则此地址应该是一个相对地址。
Range头域
Range头域可以请求实体的一个或者多个子范围。例如，
表示头500个字节：bytes=0-499
表示第二个500字节：bytes=500-999
表示最后500个字节：bytes=-500
表示500字节以后的范围：bytes=500-
第一个和最后一个字节：bytes=0-0,-1
同时指定几个范围：bytes=500-600,601-999
但是服务器可以忽略此请求头，如果无条件GET包含Range请求头，响应会以状态码206（PartialContent）返回而不是以200（OK）。
User-Agent头域
User-Agent头域的内容包含发出请求的用户信息。

3、响应消息
响应消息的第一行为下面的格式：
HTTP-Version　SP　Status-Code　SP　Reason-Phrase　CRLF
HTTP-Version表示支持的HTTP版本，例如为HTTP/1.1。
Status-Code是一个三个数字的结果代码。
Reason-Phrase给Status-Code提供一个简单的文本描述。Status-Code主要用于机器自动识别，Reason-Phrase主要用于帮助用户理解。Status-Code的第一个数字定义响应的类别，后两个数字没有分类的作用。第一个数字可能取5个不同的值：
1xx:信息响应类，表示接收到请求并且继续处理
2xx:处理成功响应类，表示动作被成功接收、理解和接受
3xx:重定向响应类，为了完成指定的动作，必须接受进一步处理
4xx:客户端错误，客户请求包含语法错误或者是不能正确执行
5xx:服务端错误，服务器不能正确执行一个正确的请求
响应头域允许服务器传递不能放在状态行的附加信息，这些域主要描述服务器的信息和Request-URI进一步的信息。响应头域包含Age、 Location、Proxy-Authenticate、Public、Retry-After、Server、Vary、Warning、WWW- Authenticate。对响应头域的扩展要求通讯双方都支持，如果存在不支持的响应头域，一般将会作为实体头域处理。
典型的响应消息：
HTTP/1.0200OK
Date:Mon,31Dec200104:25:57GMT
Server:Apache/1.3.14(Unix)
Content-type:text/html
Last-modified:Tue,17Apr200106:46:28GMT
Etag:"a030f020ac7c01:1e9f"
Content-length:39725426
Content-range:bytes554554-40279979/40279980
上例第一行表示HTTP服务端响应一个GET方法。棕色的部分表示响应头域的信息，绿色的部分表示通用头部分，红色的部分表示实体头域的信息。
Location响应头
Location响应头用于重定向接收者到一个新URI地址。
Server响应头
Server响应头包含处理请求的原始服务器的软件信息。此域能包含多个产品标识和注释，产品标识一般按照重要性排序。
4、实体信息
请求消息和响应消息都可以包含实体信息，实体信息一般由实体头域和实体组成。实体头域包含关于实体的原信息，实体头包括Allow、Content-Base、Content-Encoding、Content-Language、 Content-Length、Content-Location、Content-MD5、Content-Range、Content-Type、 Etag、Expires、Last-Modified、extension-header。extension-header允许客户端定义新的实体头，但是这些域可能无法未接受方识别。实体可以是一个经过编码的字节流，它的编码方式由Content-Encoding或Content-Type定义，它的长度由Content-Length或Content-Range定义。
Content-Type实体头
Content-Type实体头用于向接收方指示实体的介质类型，指定HEAD方法送到接收方的实体介质类型，或GET方法发送的请求介质类型Content-Range实体头
Content-Range实体头
用于指定整个实体中的一部分的插入位置，他也指示了整个实体的长度。在服务器向客户返回一个部分响应，它必须描述响应覆盖的范围和整个实体长度。一般格式：
Content-Range:bytes-unit　SP　first-byte-pos - last-byte-pos/entity-legth
例如，传送头500个字节次字段的形式：Content-Range:bytes0-499/1234如果一个http消息包含此节（例如，对范围请求的响应或对一系列范围的重叠请求），Content-Range表示传送的范围，Content-Length表示实际传送的字节数。
Last-modified实体头
Last-modified实体头指定服务器上保存内容的最后修订时间。
5、 HTTP 头参考（microsoft）
HTTP 请求和 HTTP 响应都使用头发送有关 HTTP 消息的信息。头由一系列行组成，每行都包含名称，然后依次是冒号、空格、值。字段可按任何顺序排列。某些头字段既能用于请求头也能用于响应头，而另一些头字段只能用于其中之一。
许多请求头字段都允许客户端在值部分指定多个可接受的选项，有时甚至可以对这些选项的首选项进行排名。多个项以逗号分隔。例如，客户端可以发送包含 “Content-Encoding: gzip, compress,”的请求头，表示可以接受各种压缩类型。如果服务器的响应正文使用 gzip 编码，其响应头中将包含“Content-Encoding: gzip”。
有些字段可以在单个头中出现多次。例如，头可以有多个“Warning”字段。
下表列出了 HTTP 1.1 头字段。注意：有些头字段是 MIME 字段。MIME 字段在 Internet Engineering Task Force (IETF) 文档 RFC 2045 中进行了定义，但也可用于 HTTP 1.1 协议。有关 MIME 和 HTTP 1.1 规范的详细信息，请参阅 IEIF 页。
一般头字段
一般头字段可用于请求消息和响应消息。
　名称　　　　　　　　　　示例值
Cache-Control　 "max-age=10"
Connection　　　　"close"
Date　　　　　　　　　　"Tue, 11 Jul 2000 18:23:51 GMT"
Pragma　　　　　　　 "no-cache"
Trailer　　　　　　　　 "Date"
Transfer-Encoding"chunked"
Upgrade　　　　　　 "SHTTP/1.3"
Via　　　　　　　　　　　 "HTTP/1.1 Proxy1, HTTP/1.1 Proxy2"
Warning　　　　　　　"112 Disconnected Operation"
请求头字段
请求头字段仅用于请求消息。
　　 名称　　　　　　　　　　　　 示例值
Accept　　　　　　　　　　 "text/html, image/*"
Accept-Charset　　　"iso8859-5"
Accept-Encoding　"gzip, compress"
Accept-Language　"en, fr"
Authorization　　　　 [credentials]
Content-Encoding　"gzip"
Expect　　　　　　　　　　 "100-continue"
From　　　　　　　　　　　 "user@microsoft.com"
Host　　　　　　　　　　　　"www.microsoft.com"
If-Match　　　　　　　　　"entity_tag001"
If-Modified-Since"Tue, 11 Jul 2000 18:23:51 GMT"
If-None-Match　　　 "entity_tag001"
If-Range　　　　　　　　 "entity_tag001" or "Tue, 11 Jul 2000 18:23:51 GMT"
If-Unmodified-Since"Tue, 11 Jul 2000 18:23:51 GMT"
Max-Forwards　　　　"3"
Proxy-Authorization[credentials]
Range　　　　　　 "bytes=100-599"
Referer　　　　　 "http://www.microsoft.com/resources.asp"
TE　　　　　　　　　　"trailers"
User-Agent　　 "Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)"
 
>>请求头字段的具体含义
Accept：浏览器可接受的MIME类型。
Accept-Charset：浏览器可接受的字符集。
Accept-Encoding：浏览器能够进行解码的数据编码方式，比如gzip。
Accept-Language：浏览器所希望的语言种类，当服务器能够提供一种以上的语言版本时要用到。
Authorization：授权信息，通常出现在对服务器发送的WWW-Authenticate头的应答中。
Connection：表示是否需要持久连接。如果Servlet看到这里的值为“Keep-Alive”，或者看到请求使用的是HTTP 1.1（HTTP 1.1默认进行持久连接），它就可以利用持久连接的优点，当页面包含多个元素时（例如Applet，图片），显著地减少下载所需要的时间。要实现这一点， Servlet需要在应答中发送一个Content-Length头，最简单的实现方法是：先把内容写入ByteArrayOutputStream，然后在正式写出内容之前计算它的大小。
Content-Length：表示请求消息正文的长度。
Cookie：设置cookie,这是最重要的请求头信息之一
From：请求发送者的email地址，由一些特殊的Web客户程序使用，浏览器不会用到它。
Host：初始URL中的主机和端口。
If-Modified-Since：只有当所请求的内容在指定的日期之后又经过修改才返回它，否则返回304“Not Modified”应答。
Pragma：指定“no-cache”值表示服务器必须返回一个刷新后的文档，即使它是代理服务器而且已经有了页面的本地拷贝。
Referer：包含一个URL，用户从该URL代表的页面出发访问当前请求的页面。
User-Agent：浏览器类型，如果Servlet返回的内容与浏览器类型有关则该值非常有用。
UA-Pixels，UA-Color，UA-OS，UA-CPU：由某些版本的IE浏览器所发送的非标准的请求头，表示屏幕大小、颜色深度、操作系统和CPU类型。
响应头字段
响应头字段仅用于响应消息。
　 名称　　　　　　　　　 示例值
Accept-Ranges　　"none"
Age　　　　　　　　　　　　"2147483648(2^31)"
ETag　　　　　　　　　　　"b38b9-17dd-367c5dcd"
Last-Modified　　　 "Tue, 11 Jul 2000 18:23:51 GMT"
Location　　　　　　　　"http://localhost/redirecttarget.asp"
Proxy-Authenticate[challenge]
Retry-After　　　　　 "Tue, 11 Jul 2000 18:23:51 GMT" or "60"
Server　　　　　　　　　"Microsoft-IIS/5.0"
Vary　　　　　　　　　　　 "Date"
WWW-Authenticate[challenge]
实体头字段
实体头字段可以用于请求消息或响应消息。实体头字段中包含消息实体正文的有关信息，如使用的编码格式。
　　 名称　　　　　　　　　　　 示例值
Allow　　　　　　　　　　　　　　"GET, HEAD"
Content-Encoding　　 "gzip"
Content-Language　　"en"
Content-Length　　　　 "8445"
Content-Location　　　"http://localhost/page.asp"
Content-MD5　　　　　　 [md5-digest]
Content-Range　　　　 "bytes 2543-4532/7898"
Content-Type　　　　　　"text/html"
Expires　　　　　　　　　　　"Tue, 11 Jul 2000 18:23:51 GMT"
Last-Modified　　　　　 "Tue, 11 Jul 2000 18:23:51 GMT"
>>实体头字段的具体含义
Allow服务器支持哪些请求方法（如GET、POST等）。
Content-Encoding文档的编码（Encode）方法。只有在解码之后才可以得到Content-Type头指定的内容类型。利用gzip压缩文档能够显著地减少HTML文档的下载时间。Java的GZIPOutputStream可以很方便地进行gzip压缩，但只有Unix上的Netscape和Windows上的IE 4、IE 5才支持它。
Content-Length表示内容长度。只有当浏览器使用持久HTTP连接时才需要这个数据。
Content-Type表示后面的文档属于什么MIME类型。Servlet默认为text/plain，但通常需要显式地指定为text/html。
Date当前的GMT时间。你可以用setDateHeader来设置这个头以避免转换时间格式的麻烦。
Expires应该在什么时候认为文档已经过期，从而不再缓存它？
Last-Modified文档的最后改动时间。客户可以通过If-Modified-Since请求头提供一个日期，该请求将被视为一个条件GET，只有改动时间迟于指定时间的文档才会返回，否则返回一个304（Not Modified）状态。
Location表示客户应当到哪里去提取文档。Location通常不是直接设置的，而是通过HttpServletResponse的sendRedirect方法，该方法同时设置状态代码为302。
Refresh表示浏览器应该在多少时间之后刷新文档，以秒计。除了刷新当前文档之外，你还可以通过setHeader("Refresh", "5; URL=http://host/path")让浏览器读取指定的页面。
注意这种功能通常是通过设置HTML页面HEAD区的＜META. HTTP-EQUIV="Refresh" C＞实现，这是因为，自动刷新或重定向对于那些不能使用CGI或Servlet的HTML编写者十分重要。但是，对于Servlet来说，直接设置 Refresh头更加方便。
注意Refresh的意义是“N秒之后刷新本页面或访问指定页面”，而不是“每隔N秒刷新本页面或访问指定页面 ”。因此，连续刷新要求每次都发送一个Refresh头，而发送204状态代码则可以阻止浏览器继续刷新，不管是使用Refresh头还是＜META. HTTP-EQUIV="Refresh" ...＞。
注意Refresh头不属于HTTP 1.1正式规范的一部分，而是一个扩展，但Netscape和IE都支持它。
请求头示例
以下是 HTTP 请求的简单示例。
GET /articles/news/today.asp HTTP/1.1
Accept: */*
Accept-Language: en-us
Connection: Keep-Alive
Host: localhost
Referer:http://localhost/links.asp
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)
Accept-Encoding: gzip, deflate
该请求具有请求行，其中包括方法 (GET)、资源路径 (/articles/news/today.asp) 和 HTTP 版本 (HTTP/1.1)。由于该请求没有正文，故所有请求行后面的内容都是头的一部分。紧接着头之后是一个空行，表示头已结束。
响应头示例
Web 服务器可以通过多种方式响应前一个请求。假设文件是可以访问的，并且用户具有查看该文件的权限，则响应类似于：
HTTP/1.1 200 OK
Server: Microsoft-IIS/5.0
Date: Thu, 13 Jul 2000 05:46:53 GMT
Content-Length: 2291
Content-Type: text/html
Set-Cookie: ASPSESSIONIDQQGGGNCG=LKLDFFKCINFLDMFHCBCBMFLJ; path=/
Cache-control: private
...
响应的第一行称为状态行。它包含响应所用的 HTTP 版本、状态编码 (200) 和原因短语。示例中包含一个头，其中具有五个字段，接着是一个空行（回车和换行符），然后是响应正文的头两行。
有关HTTP头完整、详细的说明，请参见http://www.w3.org/Protocols/的HTTP规范。
 
附录:HTTP协议状态码的含义
　　状态代码 状态信息 含义
100 Continue初始的请求已经接受，客户应当继续发送请求的其余部分。（HTTP 1.1新）
101 Switching Protocols服务器将遵从客户的请求转换到另外一种协议（HTTP 1.1新
200 OK一切正常，对GET和POST请求的应答文档跟在后面。
201 Created服务器已经创建了文档，Location头给出了它的URL。
202 Accepted已经接受请求，但处理尚未完成。
203 Non-Authoritative Information文档已经正常地返回，但一些应答头可能不正确，因为使用的是文档的拷贝（HTTP 1.1新）。
204 No Content没有新文档，浏览器应该继续显示原来的文档。
205 Reset Content没有新的内容，但浏览器应该重置它所显示的内容。用来强制浏览器清除表单输入内容（HTTP 1.1新）。
206 Partial Content客户发送了一个带有Range头的GET请求，服务器完成了它（HTTP 1.1新）。
300 Multiple Choices客户请求的文档可以在多个位置找到，这些位置已经在返回的文档内列出。如果服务器要提出优先选择，则应该在Location应答头指明。
301 Moved Permanently客户请求的文档在其他地方，新的URL在Location头中给出，浏览器应该自动地访问新的URL。
302 Found类似于301，但新的URL应该被视为临时性的替代，而不是永久性的。注意，在HTTP1.0中对应的状态信息是“Moved Temporatily”，出现该状态代码时，浏览器能够自动访问新的URL，因此它是一个很有用的状态代码。注意这个状态代码有时候可以和301替换使用。例如，如果浏览器错误地请求http://host/~user（缺少了后面的斜杠），有的服务器返回301，有的则返回302。严格地说，我们只能假定只有当原来的请求是GET时浏览器才会自动重定向。请参见307。
303 See Other类似于301/302，不同之处在于，如果原来的请求是POST，Location头指定的重定向目标文档应该通过GET提取（HTTP 1.1新）。
304 Not Modified客户端有缓冲的文档并发出了一个条件性的请求（一般是提供If-Modified-Since头表示客户只想比指定日期更新的文档）。服务器告诉客户，原来缓冲的文档还可以继续使用。
305 Use Proxy客户请求的文档应该通过Location头所指明的代理服务器提取（HTTP 1.1新）。
307 Temporary Redirect和302（Found）相同。许多浏览器会错误地响应302应答进行重定向，即使原来的请求是POST，即使它实际上只能在POST请求的应答是303时才能重定向。由于这个原因，HTTP 1.1新增了307，以便更加清除地区分几个状态代码：当出现303应答时，浏览器可以跟随重定向的GET和POST请求；如果是307应答，则浏览器只能跟随对GET请求的重定向。（HTTP 1.1新）
400 Bad Request请求出现语法错误。
401 Unauthorized客户试图未经授权访问受密码保护的页面。应答中会包含一个WWW-Authenticate头，浏览器据此显示用户名字/密码对话框，然后在填写合适的Authorization头后再次发出请求。
403 Forbidden资源不可用。服务器理解客户的请求，但拒绝处理它。通常由于服务器上文件或目录的权限设置导致。
404 Not Found无法找到指定位置的资源。这也是一个常用的应答，
405 Method Not Allowed请求方法（GET、POST、HEAD、DELETE、PUT、TRACE等）对指定的资源不适用。（HTTP 1.1新）
406 Not Acceptable指定的资源已经找到，但它的MIME类型和客户在Accpet头中所指定的不兼容（HTTP 1.1新）。
407 Proxy Authentication Required类似于401，表示客户必须先经过代理服务器的授权。（HTTP 1.1新）
408 Request Timeout在服务器许可的等待时间内，客户一直没有发出任何请求。客户可以在以后重复同一请求。（HTTP 1.1新）
409 Conflict通常和PUT请求有关。由于请求和资源的当前状态相冲突，因此请求不能成功。（HTTP 1.1新）
410 Gone所请求的文档已经不再可用，而且服务器不知道应该重定向到哪一个地址。它和404的不同在于，返回407表示文档永久地离开了指定的位置，而404表示由于未知的原因文档不可用。（HTTP 1.1新）
411 Length Required服务器不能处理请求，除非客户发送一个Content-Length头。（HTTP 1.1新）
412 Precondition Failed请求头中指定的一些前提条件失败（HTTP 1.1新）。
413 Request Entity Too Large目标文档的大小超过服务器当前愿意处理的大小。如果服务器认为自己能够稍后再处理该请求，则应该提供一个Retry-After头（HTTP 1.1新）。
414 Request URI Too LongURI太长（HTTP 1.1新）。
416 Requested Range Not Satisfiable服务器不能满足客户在请求中指定的Range头。（HTTP 1.1新）
500 Internal Server Error服务器遇到了意料不到的情况，不能完成客户的请求。
501 Not Implemented服务器不支持实现请求所需要的功能。例如，客户发出了一个服务器不支持的PUT请求。
502 Bad Gateway服务器作为网关或者代理时，为了完成请求访问下一个服务器，但该服务器返回了非法的应答。
503 Service Unavailable服务器由于维护或者负载过重未能应答。
504 Gateway Timeout由作为代理或网关的服务器使用，表示不能及时地从远程服务器获得应答。（HTTP 1.1新）
505 HTTP Version Not Supported服务器不支持请求中所指明的HTTP版本

JQuery作者John Resig的讲座
http://v.youku.com/v_show/id_XMjQzMDY4NDQ=.html

转 http://blog.youmila.com/?p=513

关于跨域名问题还是问题么，这方面的解决实践非常多，今天我就旧话重提把我所知道的通过几个应用场景来分别总结一下

先说明一点：我说的某某域名在您的控制下的意思是这个域名下的网页由您来负责开发内部的JavaScript
场景一：将bbs.xxx.com的页面用iframe嵌入到www.xxx.com的中，如何在iframe内外使用js通信
一级域名都是xxx.com 这个域名一定是在您的控制下，所以你只要在两个页面中同时升级域名即可
在父窗口和iframe内部分别加上js语句：document.domain=”xxx.com”;
之后2个页面就等于在同一域名下，通过window.parent oIframe.contentDocument就可以相互访问，进行无障碍的JS通信
在新浪、淘宝等很多页面都能找到这样的语句。不过document.domain不可以随便指定，只能向上升级，从bbs.xxx.com升级到yyy.com肯定会出错

场景二：将www.yyy.com的页面用iframe嵌入到www.xxx.com的中，两个域名都在您的控制下，如何在iframe内外进行一定的数据交流
你可以通过相互改变hash值的方式来进行一些数据的通信

这里的实现基于如下技术要点：
1、父窗口通过改变子窗口的src中的hash值把一部分信息传入，如果src只有hash部分改变，那么子窗口是不会重新载入的。
2、子窗口可以重写父窗口的location.href，但是注意这里子窗口无法读取而只能重写location.href所以要求前提是您控制两个域名，知道当前父窗口的location.href是什么并写在子窗口内，这样通过parent.location.href = “已知的父窗口的href”+”#”+hash。这样父窗口只有hash改变也不会重载。
3、上面两步分别做到了两个窗口之间的无刷新数据通知，那么下面的来说如何感知数据变化。标准中没有相关规定，所以当前的任意浏览器遇到location.hash变化都不会触发任何javaScript事件，也就是说您要自己写监听函数来监视loaction.hash的值的变化。做法是通过setTimeout或者setInterval来写一个监听函数每20-100ms查看一下hash是否变化，如果变化了驱动js根据新的数据做想做的事情。

这种实现的一些分析：
1、信息通道是双向的，当然会兼容单向，如果只是父窗口向子窗口通知数据，只需要子窗口写hash监听，反之亦然。
2、局限性也是颇大，因为这种通信的前提是双方知道对方的location.href。如果父窗口带有动态的location.search也就是查询参数，那么子窗口的处理上就比较困难，需要把父窗口的location.search作为传递信息的一部分告知子窗口。
3、另外的困扰会有浏览器带给你，IE之外的浏览器遇到hash的改变会记录历史，这样你在处理前进后退的时候会非常头疼

场景三：将www.yyy.com的页面用iframe嵌入到www.xxx.com的中，只有被嵌入的yyy.com在您的控制下，如何在iframe内外进行一定的交流
真实场景：google adsence的一个需求，你希望google发现您的页面不能匹配出相关性非常好的按点击付费广告时，你希望google的广告iframe能够隐藏。
google的广告iframe在google域下显然不能把自己隐藏掉，那么怎么办呢？
1、google会提供给你一个html页面
2、您将这个页面放置在您的域名下，并告诉google它的位置
3、当google发现没有很好的广告时，会将子窗口的loaction重定向到您的那个页面下，这样您的页面因为同域名就可以访问父页面来隐藏自己了
是不是很巧的方法？

场景四：您是内容发布商，如何改造接口，让其他域名下的页面可以从浏览器端出发获得您的数据
我们知道ajax的xmlHttpRequest()说到底是一个无刷新请求服务器数据的辅助工具，但是xmlHttpRequest并不能跨域名请求数据，在某些情况下成了极大的限制。
但是我们如果通过其他方式完成无刷新请求数据不也可以么，我们用Dom方法操作动态JS脚本请求来做这件事。
    //创建一个脚本节点
    var oScript = document.createElement(’script’);
    //指定脚本src src可以指向任意域名
    //注意src不再指向静态js，而是带着查询参数指向一个动态脚本广播服务。
    oScript.src = “http://yyy.com/query.php?”+yourQueryString;   
    //如果指定了charset 同时还可以解决xmlHttpRequest另一大困扰 乱码问题                                                                                                                           
    //oScript.charset = “utf-8″;
    //通过Dom操作把这个新的节点加入到文档当中                                 
    document.getElementsByTagName(”head”)[0].appendChild(oScript);

这样只要query.php的输出是可执行的javaScript脚本，比如：djsCallBack（{jsondata}）;
当他从服务器返回后就会自动执行,你可以方便的用json方式来做数据传递了。
要注意，您的脚本请求最好带上时间戳，避免浏览器缓存造成取回数据实时性下降。

如果您是数据提供者，您可以要求数据索取者在查询参数中提供回调函数名，比如query.php?callback=myDataHandler&key=…?
这样您就可以根据参数来提供给他myDataHandler({jsondata}),这样不同的数据索取者都会得到自定义的正确的异步回调。

场景五：通过后端程序语言，为了跨域名而做各自的后台数据抓取转化服务，比如php curl，YAHOO  CHINA NCP就是用这种方案。

场景六：通过flash proxy，因为flash的跨域调用可以通过crossdomain.xml和security.allowdomain(’*')文件实现，而js又可以和flash进行通信，所以js完全可以借用flash

               实现js跨域通信。

 
总结总结：
第一种场景，相应的处理办法有这非常好的效果，可以说完全解决了问题。
第二种场景，相应的处理办法具有一定的跨域数据交流功效，具有相当大的局限，并不适合在复杂业务流程中应用，实际上我也确实也没看到过基于此的大规模应用。
第三种场景，相应的处理办法比较巧妙，虽然redirect之后就不干你什么事了，但如果你是google一样面向众多域名的内容提供商，也是个不错的解决思路。
第四种场景，相应的处理办法非常强大，对比Ajax可以看到，跨域名没问题，无刷新没问题，本身又是异步的，JSON比xml快的多，同时解决乱码问题，只是请求都是Get方式的，不能做Post方式的请求。多一种武器自然可以从容选择了。

第五种场景，处理很方便，也很实用。

第六种场景，需要一定的flash基础哈，作用当然非常强大。

The Java Community Process(SM) Program

转 http://blog.csdn.net/sergeycao/archive/2009/02/04/3861560.aspx

J2ME 配置规范
=========
JSR 30 --- Connected Limited Device Configuration 1.0
http://jcp.org/en/jsr/detail?id=30

JSR 139 --- Connected Limited Device Configuration 1.1
http://jcp.org/en/jsr/detail?id=139

JSR 36 --- Connected Device Configuration 1.0
http://jcp.org/en/jsr/detail?id=36

JSR 218 --- Connected Device Configuration 1.1
http://jcp.org/en/jsr/detail?id=218

========================================
1、JSR 30、JSR139 简介 及它们之间的关系
CLDC全称为Connected Limited Device Configuration(有限连接设备配置)，
分别对应了JSR 30和JSR 139两个JSR。

CLDC专门针对移动电话、阅读器和主流的PDA（个人数字助理）定义了一组基础的应用程序编程接口和虚拟机标准，
和简表文件一起配合，就构成了一套实用的Java平台，可以为内存不多、处理器性能有限、图形能力一般的设备开发应用程序。

JSR 30 CLDC 1.0 提供了基本的语言类库,主要是定义了JAVA编程语言的一套子集，包括虚拟机的功能上，网络支持，安全安装以及其他核心API上都是子集和全集的关系，主要目标是某类嵌入式的消费类产品。由于不支持浮点运算,可以用CLDC1.1替代CLDC1.0;

JSR 139 CLDC 1.1是CLDC 1.0技术标准的修订版本，包含了一些新的特性比如浮点运算和弱引用等方面的支持，和CLDC-1.0是完全向后兼容的;

2、JSR 36、JSR218 简介 及 它们之间的关系
JSR 36 CDC (Connected Device Configuration，连接设备配置)。CDC的目标设备较CLDC具有更大的内存、更快速的处理器、更稳定的电源，以及更出色的网络连接能力。
CDC主要应用在工业控制器、高端PDA、电视机顶盒及车载娱乐与导航系统上。

JSR 218 是在JSR 36基础上进行补充，并兼容JSR 36.

J2ME 简表规范
=========
CDC 简表规范
------------------
JSR 46 --- Foundation Profile
http://jcp.org/en/jsr/detail?id=46

JSR 129 --- Personal Basis Profile Specification
http://jcp.org/en/jsr/detail?id=129

JSR 62 --- Personal Profile Specification
http://jcp.org/en/jsr/detail?id=62

JSR 219 --- Foundation Profile 1.1
http://jcp.org/en/jsr/detail?id=219

JSR 217 --- Personal Basis Profile 1.1
http://jcp.org/en/jsr/detail?id=217

JSR 216 --- Personal Profile 1.1
http://jcp.org/en/jsr/detail?id=216

CLDC 简表规范
--------------------
JSR 37 --- Mobile Information Device Profile 1.0
http://jcp.org/en/jsr/detail?id=37

JSR 118 --- Mobile Information Device Profile 2.0
http://jcp.org/en/jsr/detail?id=118

JSR 195 --- Information Module Profile
http://jcp.org/en/jsr/detail?id=195

JSR 228 --- Information Module Profile 2.0)
http://jcp.org/en/jsr/detail?id=228

厂商可选包(Optional Packages)
-----------------------------------------

CDC设备厂商可选包
...........................
JSR 66 --- RMI Optional Package Specification Version 1.0
http://jcp.org/en/jsr/detail?id=66

JSR 80 --- Java USB API
http://jcp.org/en/jsr/detail?id=80

JSR 113 --- Java Speech API 2.0
http://jcp.org/en/jsr/detail?id=113

JSR 169 --- JDBC Optional Package for CDC/Foundation Profile
http://jcp.org/en/jsr/detail?id=169

JSR 209 --- Advanced Graphics and User Interface Optional Package for the J2ME Platform
http://jcp.org/en/jsr/detail?id=209

CLDC设备厂商可选包
...........................
JSR 75 --- PDA Optional Packages for the J2ME Platform
http://jcp.org/en/jsr/detail?id=75

JSR 82 --- Java APIs for Bluetooth
http://jcp.org/en/jsr/detail?id=82

JSR 120 --- Wireless Messaging API
http://jcp.org/en/jsr/detail?id=120

JSR 135 --- Mobile Media API
http://jcp.org/en/jsr/detail?id=135

JSR 172 --- J2ME Web Services Specification
http://jcp.org/en/jsr/detail?id=172

JSR 177 --- Security and Trust Services API for J2ME
http://jcp.org/en/jsr/detail?id=177

JSR 179 --- Location API for J2ME
http://jcp.org/en/jsr/detail?id=179

JSR 180 --- SIP API for J2ME
http://jcp.org/en/jsr/detail?id=180

JSR 184 --- Mobile 3D Graphics API for J2ME
http://jcp.org/en/jsr/detail?id=184

JSR 190 --- Event Tracking API for J2ME
http://jcp.org/en/jsr/detail?id=190

JSR 205 --- Wireless Messaging API 2.0
http://jcp.org/en/jsr/detail?id=205

JSR 211 --- Content Handler API
http://jcp.org/en/jsr/detail?id=211

JSR 226 --- Scalable 2D Vector Graphics API for J2ME
http://jcp.org/en/jsr/detail?id=226

JSR 229 --- Payment API
http://jcp.org/en/jsr/detail?id=229

JSR 230 --- Data Sync API
http://jcp.org/en/jsr/detail?id=230

运行环境规范
..................
JSR 185 --- JavaTM Technology for the Wireless Industry
http://jcp.org/en/jsr/detail?id=185

 

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/sergeycao/archive/2009/02/04/3861560.aspx

     摘要: 我google一下,已有人翻译了此文.比我翻译的要好!是译言站翻译的 见url: http://www.yeeyan.com/articles/view/92135/47626/dz 原文见:http://code.google.com/intl/zh-CN/speed/articles/optimizing-javascript.html 不合适的地方,请大家指出来!希望对你有用! ...  阅读全文

转 http://war.news.163.com/09/1211/18/5Q98H5TU00011232.html

国家战略是一个范军事话题，并非只有军事家才能成为战略精英。在这一点上，美国培养未来的国家决策人才的经验就值得中国反思。

说起Google，可谓无人不知无人不晓。作为世界第一的搜索引擎，其强大的搜索功能，可以让你在瞬间找到你想要的一切。不过对于普通的计算机用户而言，Google是一个强大的搜索引擎；而对于黑客而言，则可能是一款绝佳的黑客工具。正因为google的检索能力强大，黑客可以构造特殊的关键字，使用Google搜索互联网上的相关隐私信息。通过Google，黑客甚至可以在几秒种内黑掉一个网站。这种利用Google搜索相关信息并进行入侵的过程就叫做Google Hack。

搜索也是一门艺术

         在我们平时使用搜索引擎的过程中，通常是将需要搜索的关键字输入搜索引擎，然后就开始了漫长的信息提取过程。其实Google对于搜索的关键字提供了多种语法，合理使用这些语法，将使我们得到的搜索结果更加精确。当然，Google允许用户使用这些语法的目的是为了获得更加精确的结果，但是黑客却可以利用这些语法构造出特殊的关键字，使搜索的结果中绝大部分都是存在漏洞的网站。
下面我们先来看看Google的部分语法：
         intitle：搜索网页标题中包含有特定字符的网页。例如输入“intitle: cbi”，这样网页标题中带有cbi的网页都会被搜索出来。
         inurl：搜索包含有特定字符的URL。例如输入“inurl:cbi”，则可以找到带有cbi字符的URL。
         intext:搜索网页正文内容中的指定字符，例如输入“intext:cbi”。这个语法类似我们平时在某些网站中使用的“文章内容搜索”功能。
         Filetype:搜索指定类型的文件。例如输入“filetype:cbi”，将返回所有以cbi结尾的文件URL。
         Site：找到与指定网站有联系的URL。例如输入“Site：family.chinaok.com”。所有和这个网站有联系的URL都会被显示。
         这些就是Google的常用语法，也是Google Hack的必用语法。虽然这只是Google语法中很小的部分，但是合理使用这些语法将产生意想不到的效果。

语法在Google Hack中的作用

         了解了Google的基本语法后，我们来看一下黑客是如何使用这些语法进行Google Hack的，这些语法在入侵的过程中又会起到怎样的作用呢？
         intitle
         intitle语法通常被用来搜索网站的后台、特殊页面和文件，通过在Google中搜索“intitle:登录”、“intitle:管理”就可以找到很多网站的后台登录页面。此外，intitle语法还可以被用在搜索文件上，例如搜索“intitle:"indexof"etc/shadow”就可以找到Linux中因为配置不合理而泄露出来的用户密码文件。
         inurl
         Google Hack中，inurl发挥的作用的最大，主要可以分为以下两个方面:寻找网站后台登录地址，搜索特殊URL。
         寻找网站后台登录地址：和intitle不同的是，inurl可以指定URL中的关键字，我们都知道网站的后台URL都是类似login.asp、admin.asp为结尾的，那么我们只要以“inurl:login.asp”、“inurl:admin.asp”为关键字进行搜索，同样可以找到很多网站的后台。此外，我们还可以搜索一下网站的数据库地址，以“inurl:data”、“inurl:db”为关键字进行搜索即可。

1.寻找网站的后台登录页面
         搜索特殊URL：通过inurl语法搜索特殊URL，我们可以找到很多网站程序的漏洞，例如最早IIS中的Uncode目录遍历漏洞，我们可以构造“inurl:／winnt／system32／cmd exe?／c+dir”这样的关键字进行搜索，不过目前要搜索到存在这种古董漏洞的网站是比较困难的。再比如前段日子很火的上传漏洞，我们使用““inurl:upload.asp”或“inurl:upload_soft.asp”即可找到很多上传页面，此时再用工具进行木马上传就可以完成入侵。

         intext
         intext的作用是搜索网页中的指定字符，这貌似在Google Hack中没有什么作用，不过在以“intext:to parent directory”为关键字进行搜索后，我们会很惊奇的发现，无数网站的目录暴露在我们眼前。我们可以在其中随意切换目录，浏览文件，就像拥有了一个简单的Webshell。形成这种现象的原因是由于IIS的配置疏忽。同样，中文IIS配置疏忽也可能出现类似的漏洞，我们用“intext:转到父目录”就可以找到很多有漏洞的中文网站。

2.随意浏览网站中的文件
         Filetype
         Filetype的作用是搜索指定文件。假如我们要搜索网站的数据库文件，那么可以以“filetype:mdb”为关键字进行搜索，很快就可以下载到不少网站的数据库文件。当然，Filetype语法的作用不仅于此，在和其他语法配合使用的时候更能显示出其强大作用。
         Site
         黑客使用Site，通常都是做入侵前的信息刺探。Site语法可以显示所有和目标网站有联系的页面，从中或多或少存在一些关于目标网站的资料，这对于黑客而言就是入侵的突破口，是关于目标网站的一份详尽的报告。

语法组合，威力加倍

         虽然上文中介绍的这几个语法能各自完成入侵中的一些步骤，但是只使用一个语法进行入侵，其效率是很低下的。Google Hack的威力在于能将多个语法组合起来，这样就可以快速地找到我们需要的东西。下面我们来模拟黑客是如何使用Google语法组合来入侵一个网站的。

    信息刺探
         黑客想入侵一个网站，通常第一步都是对目标网站进行信息刺探。这时可以使用“Site:目标网站”来获取相关网页，从中提取有用的资料。

3.搜索相关页面
         下载网站的数据库
         搜索“Site:目标网站 Filetype:mdb”就可以寻找目标网站的数据库，其中的Site语法限定搜索范围，Filetype决定搜索目标。用这种方法有一个缺点，就是下载到数据库的成功率较低。在这里我们还可以采用另一种语法组合，前提是目标网站存在IIS配置缺陷，即可以随意浏览站点文件夹，我们搜索“Site:目标网站 intext:to parent directory”来确定其是否存在此漏洞。在确定漏洞存在后，可以使用“Site:目标网站 intext:to parent directory+intext.mdb”进行数据库的搜索。

4.找到网站数据库

    登录后台管理
         下载到数据库后，我们就可以从中找到网站的管理员帐户和密码，并登录网站的后台。对于网站后台的查找，可以使用语法组合“Site:目标网站 intitle:管理”或者“Site:目标网站 inurl:login.asp”进行搜索，当然我们可以在这里进行联想，以不同的字符进行搜索，这样就有很大的概率可以找到网站的后台管理地址。接下去黑客就可以在后台上传Webshll，进一步提升权限，在此不再阐述。

    利用其他漏洞
         如果下载数据库不成功，我们还可以尝试其他的入侵方法。例如寻找上传漏洞，搜索“Site:目标网站 inurl:upload.asp”。此外，我们还可以根据一些程序漏洞的特征，定制出Google Hack的语句。
         Google Hack可以灵活地组合法语，合理的语法组合将使入侵显得易如反掌，再加入自己的搜索字符，Google完全可以成为你独一无二的黑客工具。

合理设置，防范Google Hack
   
5. 合理设置网站
         Google Hack貌似无孔不入，实则无非是利用了我们配置网站时的疏忽。例如上文中搜索“intext:to parent directory”即可找到很多可以浏览目录文件的网站，这都是由于没有设置好网站权限所造成的。在IIS中，设置用户访问网站权限时有一个选项，叫做“目录浏览”，如果你不小心选中了该项，那么其结果就如上文所述，可以让黑客肆意浏览你网站中的文件。
         这种漏洞的防范方法十分简单，在设置用户权限时不要选中“目录浏览”选项即可。

6.不要选中该项
         编写robots.txt文件
         robot.txt是专门针对搜索引擎机器人robot编写的一个纯文本文件。我们可以在这个文件中说明网站中不想被robot访问的部分，这样，我们网站的部分或全部内容就可以不被搜索引擎收录了，或者让搜索引擎只收录指定的内容。因此我们可以利用robots.txt让Google的机器人访问不了我们网站上的重要文件，Google Hack的威胁也就不存在了。

         编写的robots.txt文件内容如下：
User-agent: *
Disallow: /data/
Disallow: /db/

         其中“Disallow”参数后面的是禁止robot收录部分的路径，例如我们要让robot禁止收录网站目录下的“data”文件夹，只需要在Disallow参数后面加上“/data/”即可。如果想增加其他目录，只需按此格式继续添加。文件编写完成后将其上传到网站的根目录，就可以让网站远离Google Hack了

 

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/chaosa/archive/2007/10/16/1828301.aspx

  这样的错误以前我也犯过，也见过不少人这样的写法！下面我也举个例子：
  

 上面是个简单的方法,代码中有个隐藏的bug。我在维护一个系统的时候就遇到类似的代码，实际中类似的BUG隐藏
的更深！在对系统业务和代码不是很很熟悉的情况下，我推荐如下写法：

 一般来说异常处理不推荐直接system.out.println打印出来！
 几条建议：
 如果无法处理某个异常，那就不要捕获它。
　　☆ 如果捕获了一个异常，请不要胡乱处理它。
　　☆ 尽量在靠近异常被抛出的地方捕获异常。
　　☆ 在捕获异常的地方将它记录到日志中，除非您打算将它重新抛出。
　　☆ 按照您的异常处理必须多精细来构造您的方法。
　　☆ 需要用几种类型的异常就用几种，尤其是对于应用程序异常。
　　☆ 把低层次的异常封装成层次较高程序员较容易理解的异常。
　　☆ 尽量输出造成异常的完整数据
　　☆ 尽量捕获具有特定含义的异常：比如SqlException，而不是简单地捕获一个Exception

  希望对大家有帮助！

参考：
http://www.blogjava.net/usherlight/archive/2006/10/23/76782.html

        cookie在web开发中应用的比较多!浏览器默认的接受cookie的,但是如果浏览器禁止了cookie,会出现什么情况了?
        在此我测试了如下系统:gmail,163邮箱,126邮箱,tom邮箱
        我在浏览器禁用cookie的情况下,登陆上述4邮箱!
        Gmail:
        正确输入用户名密码后,系统给出如下提示:
        

    163邮箱:

 正确输入用户名密码后,系统给出如下提示:让我搞不清楚是用户名密码错误还是其它错误!



    126邮箱
    
    正确输入用户名密码后,系统给出如下提示:让我搞不清楚是用户名密码错误还是其它错误!

    
    tom邮箱

    正确输入用户名密码后,系统给出如下提示:居然提示我是"非法请求"

 

        从上面测试中感受到不同的用户体验.对大多数做web开发的人来说,判断浏览器是否支持Cookie并不是什么难事!难的是对细节的处理!
        也许我们与优秀的产品差距最大的是对细节的处理!
        
        附: 我测试用的是IE6.0

 关于沟通，大家都知道其重要性！但是，在实际工作中有不少人做的不够好，也包括我自己！
 客户提出的问题，原因大概有一下几种！
 一、客户对软件系统不熟悉，把属正常情况的现象误以为是问题
     这时候就需要我们听清楚客户的描述，然后根据客户的描述一步步的确认其操作等！
     确保用户的操作的正确性。
 二、系统的bug
   一般要了解如下情况！
   2.1 who:谁操作系统的时候出问题了！一般记录系统的登陆名
   2.2 when:在什么时候操作出问题了！
   2.3 how:怎么操作的！这个比较重要，一般记录的是操作步骤！
   2.4 contact：客户的联系方式，邮件还是电话等。
   2.4 feedback：给客户的反馈，答复什么时候解决此问题！
   2.5 follow:既跟踪，确保客户已经解决此问题！而不能简单告诉用户怎么做，在此之后最后跟用户确认一下此问题是否解决！
   
   我的感受：听客户的意见，然后确认！反复之！
   

        在Ｗeb开发中常用到Cookie，所以有时需要判断客户端浏览器是否禁用Cookie！我看了一个gmail的页面原码！它是这样写的，如下：

var c="jscookietest=valid";
document.cookie=c;
if(document.cookie.indexOf(c)==-1)
location="html/zh-CN/nocookies.html";
//不支持Cookie

原理是：先对Cookie赋值，然后再读取
希望对大家有用！