憨厚生

【轉】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 不合適的地方,請大家指出來!希望對你有用! ...  閱讀全文