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協議采用了請求/響應模型?？蛻舳讼蚍掌靼l送一個請求，請求頭包含請求的方法、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提?。℉TTP 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在服務器許可的等待時間內，客戶一直沒有發出任何請求?？蛻艨梢栽谝院笾貜屯徽埱蟆＃℉TTP 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請求頭中指定的一些前提條件失?。℉TTP 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版本

關于跨域名問題還是問題么，這方面的解決實踐非常多，今天我就舊話重提把我所知道的通過幾個應用場景來分別總結一下

先說明一點：我說的某某域名在您的控制下的意思是這個域名下的網頁由您來負責開發內部的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基礎哈，作用當然非常強大。

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

國家戰略是一個范軍事話題，并非只有軍事家才能成為戰略精英。在這一點上，美國培養未來的國家決策人才的經驗就值得中國反思。

前美國國防部長拉姆斯菲爾德

原文作者：于鐵軍（北京大學國際關系學院副教授）

美國的精英比較有活力，給人一種生機勃勃的感覺，因為他們更注重全面發展，更注重訓練。反觀國內精英，大多比較文弱，缺乏朝氣，口號、程式，大話、空話很多，行動力、執行力卻比較差。各種原因當然很多，其中重要之一是國內的精英培養機制有問題。在這方面，我們應該好好地研究一下美國培養精英的做法。如果我們對精英培養機制和培養內容不重視，中國要實現真正的崛起，難度是很大的。

什么是精英

精英，或者稱戰略性人才，是個很值得討論的題目。這里首先需要回答一個問題，什么是精英？精英，一定是有所擔當的人，有社會責任感的人，而絕不能是蠅營狗茍之輩。真正的精英，他身上一定帶有一些利他的東西，不是完全為了自己。這是精英的一個必備條件。

以美國外交和國家安全領域的情況為例來做具體的說明，哈爾伯斯坦的《出類拔萃之輩》、艾薩克森和托馬斯的《美國智囊六人傳》，以及詹姆斯·曼的《布什戰爭內閣史》等傳記作品。這些書中對艾奇遜、哈里曼、凱南、麥克羅伊、洛維特、邦迪兄弟、麥克納馬拉、羅斯托、拉姆斯菲爾德、鮑威爾、賴斯、沃爾福威茨、阿米蒂奇等美國外交和國家安全界精英的成長及活動，有惟妙惟肖的描寫，有助于增加我們對美國精英養成方式的感性認識。掩卷之余，你可以對書中人物做出或褒或貶的評價，但你一般不會否認，這是一批有理想、有追求、有能力并且關心公共事務的精英，美國這個國家的大政方針為他們所引領。

叱咤風云的美國前國務卿賴斯

美國培養精英的一個重要理念：尚武精神與體育運動

具體到精英的培養，大學里面的培養機制還是比較關鍵的。當然我們不否認有草根出身的英雄，而且國人還經常說，英雄莫問來路。但社會發展到現在這個階段，應該說大部分人才還是經過大學的正規教育訓練出來的。美國的高等教育制度十分復雜，不像我們那樣有一個統一的體制。從精英大學到普通大學，從研究性大學到小型的文理學院，從州立大學到私立大學，各種類型，應有盡有。不管是什么樣的大學，從學生錄取方面來看，美國比我們更重視學生的綜合素質和發展潛力。除了SAT、GRE和GMAT這樣的標準化考試之外，推薦信、研究計劃、習作、課外活動等也都是很重要的指標，這無疑有助于引導和鼓勵學生全面發展。

騎自行車的小布什，體育運動愛好在美國高官中相當普及

中國從小學就開始教育要德、智、體全面發展，但遺憾的是沒有落到實處。就拿體育來說，正如中國留美學者薛涌所觀察到的，美國精英層中運動員出身或者喜愛體育運動的人高得不成比例。他們在大學時代往往喜歡參加各種體育項目，如橄欖球、棒球、籃球、皮劃艇等。參加體育運動，在激烈的競爭中使你的體力達到極限，這有助于一系列優秀品質的培養，如全力以赴、堅忍不拔、公平競爭、團隊精神、尊重規則、強身健體，等等，而且還能找到一些志同道合者，為未來的事業編制人脈。在美國大學里，學生的領導能力常常是通過參加某某運動隊和某某社團的活動來體現的。光是悶頭學習，即使成績再好，可能也不為人看重。

小布什的身體強壯，當總統時公務再繁忙，也要擠時間騎山地車和跑3英里。還有拉姆斯菲爾德，上大學時是普林斯頓摔跤隊的，要不是因為肩傷，本來可以入選美國的奧運代表隊。前總統福特，原來是密歇根大學橄欖球隊的，水平之高幾乎可以當職業運動員，但后來他選擇去了耶魯，畢業后開始從政。賴斯年輕的時候練花樣滑冰，據說具備專業水準。其他例子還有許多，美國精英對體育的重視由此可見一斑。

傳說中賴斯年輕時學習花樣滑冰的照片

體育運動、強健的體魄與尚武精神是密切聯系的。西方自古希臘以來便有一種尚武的傳統，當代美國也繼承了這一傳統，并成為其培養精英的一個重要理念。尚武精神在當代的一個重要表現就是重視體育。而在中國方面，長期以來則是尚文輕武的傳統占上風。歷史學家雷海宗先生早就提出過一種觀點，認為中國是“無兵的文化”。春秋戰國的時候，還是貴族在打仗。從那以后，兵的文化就日漸弱化，好男不當兵的觀念流傳甚廣，這與西方的情況大相徑庭。

美國戰略精英的培養機制

1.耶魯大學的大戰略研究：閱讀經典、海外游歷與現實關懷

耶魯大學的大戰略研究以歷史路徑為主。冷戰史名家約翰·加迪斯教授和曾撰寫過《大國的興衰》的名教授保羅·肯尼迪，都非常重視通過研究歷史來探究戰略。他們在耶魯大學設立的大戰略研究項目，大致分為閱讀經典、海外旅行和當代重大問題討論三個板塊。學生進入到這個項目后，春季學期被用來大量閱讀經典著作，讀修昔底德，讀孫子，讀馬基雅維利、伊麗莎白二世、美國的開國元勛、康德、梅特涅、克勞塞維茨、林肯、俾斯麥、威爾遜、丘吉爾、兩個羅斯福（西奧多·羅斯福和富蘭克林·羅斯福）、列寧、斯大林、毛澤東、凱南、基辛格等人的著作。培養戰略精英，不了解過去偉大的思想怎么行？不研究戰略思想發展史怎么行？

耶魯大戰略研究班的一次集體討論，未來的國家決策者們通過辯論與他人交流知識

夏季小學期學生們被安排到海外旅行。耶魯特別鼓勵學生到世界各地去游歷，主要不是看那些名勝古跡，而是到那些普通觀光者不怎么去的地方，比如說，你可以沿著古代的絲綢之路去看看今日的輸油管道；你可以先到圣彼得堡學一個月俄語，然后花兩個月時間途經西伯利亞回國；你可以到敘利亞、埃及去學阿拉伯語；你可以去中國那些外國人平常不怎么去的地方，了解一下中國的風土人情。這有點像田野調查。他們希望通過這種海外經歷，一方面使學生增加對不同文化、不同國家的了解，另一方面把他們置于一種自己不熟悉的、帶有挑戰性的環境中去磨練他們的意志，增加他們的自信心。

回來之后，在秋季學期開始時討論美國所面臨的當代重大問題。這時候學生要讀亨廷頓、福山、扎卡里亞這些人的著作，然后讓他們分組進行辯論，假定自己擔任國家公職，肩負著重要的職責，你要指出現在美國所面臨的主要問題是什么？美國的國家利益是什么？美國到底要維護什么？美國的最大威脅是什么？然后盡自己最大的努力去說服同學、說服教師來接受你的觀點?？梢韵胍姡@一年的讀萬卷書、行萬里路的訓練，對培育學生的戰略素養將是很有幫助的。

2.斯坦福大學國際安全與合作中心：走科學技術與跨學科研究之路

 

美國海軍預備役軍官團的一次課程，相當于中國的國防生制度，但是歷史更悠久，制度更健全

斯坦福大學集中搞戰略研究的地方，是國際安全與合作中心。該中心的突出特點是重視科技與戰略研究的關系，開展真正的跨學科研究。中心的研究人員分成兩大撥兒，一撥兒人是科學家和工程師，包括核物理學家、化學家、生物學家、研究導彈的等等；另一撥兒人則是搞人文社會科學的，包括政治學家、歷史學家、法學家、經濟學家、社會學家等。這兩撥兒人整天在一個屋檐下搞研究。在國家安全問題上，如果要提出一項政策，那么該政策在技術上的可行性如何，將是非常重要的一個問題。而對科學家和工程師們來說，他們在人文社科方面的知識、在政策的敏感性等方面可能就稍微欠缺一些。一項政策的歷史變遷、在法律上如何操作、如何將技術上的可能性轉化成政策，這些問題，他們不太擅長，因此也就需要由一些搞人文社科的來幫助，來協調。兩邊一搭伙兒就形成了一個良性循環。

中心的跨學科研究取向也體現在中心的教育功能上。中心為斯坦福大學的本科生開設的課程有“軍事技術與國家安全”、“核武器國際史”，以及通過模擬來解決國際危機的課程，走的都是技術與戰略研究的結合之路。中心還設立了一個本科生國際安全輔修項目，從斯坦福不同專業但都對國際安全問題感興趣的本科生中選拔優秀者參加，集中學習一年課程，包括實習和撰寫有政策意義的研究論文。另外，中心還設立獎學金，將全美名校中從事國際安全問題研究的有前途的年輕人吸收到中心的博士后和博士前項目中，讓他們與中心的研究人員密切互動，從而將研究和教學很好地結合起來。

斯坦福的這套做法，對國內的戰略研究來說很有借鑒意義。北大在國內也算是頂尖大學，但在國際問題研究領域幾乎看不到類似斯坦福那樣真正的跨自然和人文社會科學的研究機構。不同領域的專家很少有機會能坐下來一塊兒交流、討論、合作攻關。北大國際關系學院兩年多前成立了一個國際戰略研究中心，打算在這個方面做一點努力，但未來的路很長。無論是在觀念意識方面還是組織架構方面，中國的跨學科戰略研究與美國相比，都還有很大差距。

3.哈佛的戰略研究：重決策過程與案例研究

哈佛大學的國際事務研究中心

哈佛的戰略研究分好幾個單位，一個單位是哈佛國際事務研究中心，“文明沖突論”的提出者亨廷頓曾長期擔任這個中心的主任；基辛格出道之前也在這兒。后來在該中心下又成立一個奧林戰略研究所。在過去近20年中，奧林國家安全項目通過為美國國家安全領域優秀的年輕學者（包括博士待位人、博士后和高等院校的年輕教員，每年10人左右）提供獎學金的方式，為美國的國際戰略研究界培養了很多人才。這些人實際上形成了一個圈子。

哈佛的肯尼迪學院在戰略研究領域是后起之秀

目前來看，在哈佛的戰略研究中，更為活躍的是設立較晚的肯尼迪政府學院。從1960年代起，在政治學家諾伊斯塔特，外交史學家歐內斯特·梅，以及他們的學生、現任肯尼迪政府學院名譽院長格雷厄姆·艾利森的持續努力下，發展了一條從案例和決策過程入手來研究國際戰略的路徑。艾利森以古巴導彈危機為例所歸納出的三種決策模式，便是其中最為突出的一個范例。在長期關注決策和案例的基礎上，肯尼迪學院開設了各種高級別的戰略培訓班，與政府部門合作，培養各類戰略研究人才。

4.麻省理工學院的安全研究項目：與軍方密切合作

麻省理工學院(MIT)的安全研究項目（Security Studies Program，簡稱SSP項目）在美國大學的安全研究領域中是名列前茅的。該項目的前身是麻省理工學院國際問題研究所，在冷戰時期主要做宣傳戰、心理戰和第三世界的政治和經濟發展研究，后來研究重點轉向軍控和蘇聯軍事等領域。MIT是一個以工科為主的學校。給人印象特別深刻的是它跟軍方的關系特別密切，好多大實驗室的研發依靠的都是軍工項目。MIT安全項目的規模在美國大學中大概是數一數二的，為美國培養了不少高水平的戰略研究人才。在這里只簡單介紹一下它獨特的“軍事研究員”(military fellow)制度。

所謂軍事研究員制度，就是MIT跟美國軍方簽訂協議，接受來自美國陸軍、空軍、海軍和海軍陸戰隊的現役校級軍官到SSP項目做一年訪問學者。他們可以參加SSP項目的所有課程與活動，一年訪問結束后，從其所在軍種的院校取得學分。我們知道，軍事人員有自己的專業知識，他們到MIT來，可以給這里從事戰略問題研究的師生傳授很多軍事知識，彌補他們知識結構上的欠缺。另一方面，軍事研究員們也可以充分利用大學的智力資源，在開闊自己視野的同時，把那些他們在實際工作中遇到的難題提供給專家學者們研究討論，尋找答案。這對雙方都大有好處。搞戰略研究的，軍事是很重要的一個方面。如果對戰役、戰術這類東西完全不了解，上來就談戰略，其實是相當困難的。

5.哥倫比亞大學的軍事行動與戰略分析研討班

哥倫比亞大學的戰略研究與教學也非常重視軍事。哥倫比亞大學有個戰爭與和平研究所，它主辦的一個名為“軍事行動與戰略分析”的暑期研討班（Summer Workshopon Analysis of Military Operations and Strategy，簡稱SWAMOS)每年夏季開班，主要講授和討論軍事及戰略問題。暑期班的學員，一部分是研究安全問題的博士生，另一部分是在大學中從事國際安全教學與研究的年輕教員，每期學員大約有20人，時間大概是三個星期左右。研討班的講師基本上是全美這個領域中最好的專家，有大學教授，有智庫中的研究人員，還有政府部門中的相關人士。講授的內容包括戰略思想、陸?？哲姷幕局R、軍事預算、常規戰爭、反叛亂戰爭、核戰略等。每天上午上三個小時的課，中間休息15分鐘，下午分組討論兩小時，然后是師生自由交流和體育活動，晚上再安排看戰爭片，看完之后還要討論各種戰略戰術和戰爭倫理問題。去參加研究班之前，已經被要求先完成1000頁左右的閱讀量，材料寄到家。研討班開班后，每天要看個七八十頁材料。這樣三個星期下來，等于上了一門本科生、一門研究生的課程。

哥倫比亞大學的“軍事行動與戰略分析”暑期研討班課堂

通過考察上述這幾所大學的戰略精英培養機制，可以使我們認識到美國在培養自己的戰略精英方面是多么地不遺余力而又行之有道。相比之下，中國的精英培養機制卻存在著種種不足。許多口號都飄在空中，落不到實處，形不成真正的生產力。最重要的是，人的精氣神，無論是在精英層次還是民眾層次，都做得遠遠不如歐美。 (本文來源：網易軍事 )

說起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

  這樣的錯誤以前我也犯過，也見過不少人這樣的寫法！下面我也舉個例子：
  

 public void writeFile(File f) {
  String content = null;
  try {
   byte[] b = new byte[1024];
   FileInputStream in = new FileInputStream(f);
   in.read(b);
   content = new String(b);
  } catch (Exception e) {
   System.out.println(e.getMessage());
  }

  if (content.indexOf("hello") > -1) {
   System.out.println("yes");
  } else {
   System.out.println("no");
  }
 }

 上面是個簡單的方法,代碼中有個隱藏的bug。我在維護一個系統的時候就遇到類似的代碼，實際中類似的BUG隱藏
的更深！在對系統業務和代碼不是很很熟悉的情況下，我推薦如下寫法：

 1 public void writeFile(File f) {
 2  String content = null;
 3  try {
 4   byte[] b = new byte[1024];
 5   FileInputStream in = new FileInputStream(f);
 6   in.read(b);
 7   content = new String(b);
 8  } catch (Exception e) {
 9   content="";
10   //如果異常發生的話,content可能為空
11   //下面對content的操作就有可能發生NullPointerException異常
12   System.out.println(e.getMessage());
13  }
14  //下面操作有可能發生NullPointerException異常
15  if (content.indexOf("hello") > -1) {
16   System.out.println("yes");
17  } else {
18   System.out.println("no");
19  }
20 }

 一般來說異常處理不推薦直接system.out.println打印出來！
 幾條建議：
 如果無法處理某個異常，那就不要捕獲它。
　　☆ 如果捕獲了一個異常，請不要胡亂處理它。
　　☆ 盡量在靠近異常被拋出的地方捕獲異常。
　　☆ 在捕獲異常的地方將它記錄到日志中，除非您打算將它重新拋出。
　　☆ 按照您的異常處理必須多精細來構造您的方法。
　　☆ 需要用幾種類型的異常就用幾種，尤其是對于應用程序異常。
　　☆ 把低層次的異常封裝成層次較高程序員較容易理解的異常。
　　☆ 盡量輸出造成異常的完整數據
　　☆ 盡量捕獲具有特定含義的異常：比如SqlException，而不是簡單地捕獲一個Exception

  希望對大家有幫助！

參考：
http://www.tkk7.com/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

     and  datediff(day, date1,'2009-2-03')>=0 

     and  date1<='2009-2-03' 

SQL Server 中對已經定義的變量賦值的方式用兩種，分別是 SET 和 SELECT。
對于這兩種方式的區別，SQL Server 聯機叢書中已經有詳細的說明，但很多時候我們
并沒有注意，其實這兩種方式還是有很多差別的。

SQL Server推薦使用 SET 而不是 SELECT 對變量進行賦值。
當表達式返回一個值并對一個變量進行賦值時，推薦使用 SET 方法。

下表列出 SET 與 SELECT 的區別。請特別注意紅色部分。

	set	select
同時對多個變量同時賦值	不支持	支持
表達式返回多個值時	出錯	將返回的最后一個值賦給變量
表達式未返回值	變量被賦null值	變量保持原值

下面以具體示例來說明問題：

create table chinadba1(
userid int ,
addr varchar(128)
)
go
insert into chinadba1(userid,addr) values(1,'addr1')
insert into chinadba1(userid,addr) values(2,'addr2')
insert into chinadba1(userid,addr) values(3,'addr3')
go

表達式返回多個值時，使用 SET 賦值

declare @addr varchar(128)
set @addr = (select addr from chinadba1)
/*
--出錯信息為
服務器: 消息 512，級別 16，狀態 1，行 2
子查詢返回的值多于一個。當子查詢跟隨在 =、!=、<、<=、>、>= 之后，或子查詢用作表達式時，這種情況是不允許的。
*/
go

表達式返回多個值時，使用 SELECT 賦值

declare @addr varchar(128)
select @addr = addr from chinadba1
print @addr --結果集中最后一個 addr 列的值
--結果: addr3
go

表達式未返回值時，使用 SET 賦值

declare @addr varchar(128)
set @addr = '初始值'
set @addr = (select addr from chinadba1 where userid = 4 )
print @addr --null值
go

表達式未返回值時，使用 SELECT 賦值

declare @addr varchar(128)
set @addr = '初始值'
select @addr = addr from chinadba1 where userid = 4
print @addr --保持原值
go

需要注意的是，SELECT 也可以將標量子查詢的值賦給變量，如果標量子查詢不返回值，則變量被置為 null 值。
此時與 使用 SET 賦值是完全相同的
對標量子查詢的概念大家應該都覺得陌生，舉個例子就能說明

declare @addr varchar(128)
set @addr = '初始值'
--select addr from chinadba1 where userid = 4 為標量子查詢語句
select @addr = (select addr from chinadba1 where userid = 4)
print @addr --null值
go

轉自：http://blog.csdn.net/shouyenet1/archive/2008/12/13/3511818.aspx

管理下屬方面有三個人對我影響比較大。

第一個人是金山前任CEO的雷軍先生，他說過一句話我印象很深，他說”什么是執行力，執行力就是Double Check！”

第二個人是阿里巴巴的前COO李琪先生，他有個著名的‘16字真言’，一直被我奉為與下屬共同成長的寶典。

第三個人是臺灣的星云大師，他說過“最高明的管理，就是不管理”，他在《包容的智慧》一書中講過這樣一個故事。

“有一年，臺灣陷入經濟恐慌，大家為了年終獎金、加薪，游行示威，社會動蕩不安。我們佛光山也有退伍老兵在這里服務，我跟他們開玩笑說，你們也拿個小旗子，到我們的門口搖旗，要求加薪。一位老兵說，我們不要。我問為什么？他說：比金錢更寶貴的東西，就是尊重。我們在這里服務，法師們每天見到我們，合掌、點頭，跟我們講老伯早、老伯好，我們在精神上就很富有了。我們不要加薪，我們要人尊重。”

最后，星云大師說這個世界上人與人相處，最好的管理就是尊重他，愛護他，善用他。

本文來自CSDN博客，轉載請標明出處：http://blog.csdn.net/rjchen/archive/2009/11/19/4835865.aspx

在查詢的時候，有這樣的一個需求
數據庫內容如下：
iD  description

1     TableClassA.getName()
2     TableClassB.getName(),exception
3     TableClassC,getName()
4     TableClassD,getName().null

我想查詢輸入以下結果：
iD  description

1     TableClassA
2     TableClassB
3     TableClassC
4     TableClassD
及查詢的結果是.號或,前的內容
SQL如下

select id,
     case
    when (CHARINDEX(',',description)>0) and (CHARINDEX('.',description)>0)
     then --在這個做了判斷,如同時包含.和,則判斷.和,那個在前
      case 
       when CHARINDEX(',',description)>CHARINDEX('.',description) then left(description,CHARINDEX('.',description)-1)
       when CHARINDEX(',',description)<CHARINDEX('.',description) then left(description,CHARINDEX(',',description)-1)
      end
    when (CHARINDEX(',',description)>0) then left(description,CHARINDEX(',',description)-1)
    when (CHARINDEX('.',description)>0) then left(description,CHARINDEX('.',description)-1)
    else description
   end
   as description
  from  tablename

從Jao的Programming Musing 看到的：Babar Kazar 整理了一堆經典論文。Jao強烈建議每個嚴肅的程序員讀每篇論文，說它們都或多或少有意思。粗粗掃了一下，很多論文都沒讀過。挑了些俺多少知道一點的介紹。

· An axiomatic basis for computer programming C. A. R. Hoare
Tony Hoare名下的公理化語義（Axiomatic Semantics）。著名的Hoare Triples, P{C}Q, 就是從這里來的。論文不長，雙列6頁。前輩們就是這樣的，6頁紙就能開宗立派。不像俺，6頁紙連介紹部分都寫不周全。哪位老大想知道怎么證明程序正確。前置條件，不變條件，后置條件的妙用，可以用這篇論文開牙。
· Communicating Sequential Processes (CSP) C. A. R. Hoare
Hoare, 又見Hoare。其實也正常。牛人之牛，就在于成就深廣。鏈接的文檔應該不算論文，而算專著。260頁。從1985年推出到現在20多年過去，這本書的引用率在CS歷史上排名第三，可見其影響之深。對并發編程有強烈興趣的老大可以去鉆研一把。我沒讀過。
· Call-by-name, call-by-value, and the lambda calculus Gordon Plotkin
沒讀過。只見LtU介紹過。Gordon老大這篇論文的要點之一是要想順利地對程序進行推導，就需要有合適的lambda理論。想深入理解call-by-name，call-by-value，和lambda算子的老大們可以上了。
· Towards a theory of type structure John C. Reynolds
號稱經典中的經典。不過也沒讀過。類型系統一直是編程語言研發的熱點，也是非常有趣的方向――類型系統的編程好比讓機器證明一系列定理。Reynolds在論文里討論了什么才是正確的類型結構，和句法正確必須獨立于任何具體的類型表達形式，并且給出了帶類型的lambda算子的一種擴展，允許他描述用戶自定義類型和多態函數。滿篇公式，有勇氣去讀的老大要有心理準備。
· Structured Programming with go to Statements Donald E. Knuth
這篇論文詳細結構化編程時討論了什么時候用goto，什么時候不用goto。高爺爺精細務實的態度非常值得學習。高老太爺用了一輩子goto(MIX和MMIX程序里沒了Goto怎么玩兒得轉囁？)，豈能輕易被Dijkstra對goto的批評嚇退？他仔細探討了幾種不同的程序，考察goto用在那些程序里的利弊。最后得出結論，goto在某些程序里仍然高效實用。雖然論文是30年前的，但里面的分析手法和利用goto的優化技術至今可用。
· Definitional interpreters for higher-order programming languages John C. Reynolds
這篇文章俺喜歡。”Metacircular”這個性感的概念就是在這篇論文里首次提出的。想深入了解用一門語言寫出的解釋器定義這門語言自身的神奇理念，這篇論文是必讀材料。有興趣的老大可以先讀SICP的第四章。
· An APL Machine 1970 Philip S. Abrams
只知道APL是門有歷史意義的語言。順便說一句，APL這個名字太土了。A Programming Language ＝＝APL。象什么話嘛。

· The Anatomy of a Large-Scale Hypertextual Web Search Engine Sergey Brin and Lawrence Page
網絡是個大的矩陣(transition probability matrix of Markov Chain)。網頁的聲譽(page rank)就是這個巨大矩陣的principle eigenvector的某個元素。嗯，反正我只有佩服的份兒。
· No Silver Bullet: Essence and Accidents of Software Engineering Frederic P. Brooks, Jr.
地球銀都知道。不用俺多嘴了。
· A Mathematical Theory of Communication Claude Shannon
Bell實驗室當年輝煌一時。出了名的叫人做A，結果發明了B。香農老大就是其中杰出代表。香農進了Bell實驗室后，居然沒人吩咐他干嘛。香農老大轉念一想，自己喜歡數學，Bell的生意盡在通訊，干嘛不看看把數學應用到通訊上有什么結果呢？于是1948年這篇論文問世樂。搞通訊的人崩潰樂?，F代信息理論就誕生樂。
· Bayesian Networks without Tears
貝葉斯理論熱了好幾年了。估計還會繼續熱下去?，F在信息越來越多，我們已經審美疲勞。大家渴望的不是信息，而是知識。靠個人的力量把信息提煉成知識太慢，我們需要機器的幫忙。機器學習不熱都難，而貝葉斯理論在機器學習里有很好的應用。這篇文章行為淺顯，可以輕松讀完。對了，那個人人喝罵的微軟回形針的智能引擎就是用貝葉斯網絡實現的。
· A Universal Algorithm for Sequential Data Compression
沒讀過。無恥地找個借口：我們系開信息理論課的時候，俺剛好畢業。
· A Relational Model of Data for Large Shared Data Banks 1970 Edgar F. Codd
沒有關系代數，人類將會怎樣？Codd劃時代的論文奠定了現代數據庫的基礎。嘿嘿，其實俺也沒有讀過這篇論文。順便說一句，現在的ORM試圖把data schema和對象系統映射起來。問題是，data schema只是對關系的一種表達方式而已，還和具體的系統實現有關。也許把對象間的結構和關系映射起來才是正道。
· Let's Build a Compiler 1988-1995
教你一步一步寫出一坨編譯器。不算論文吧。一篇相當不錯的指南。
· Gauging Similarity via N-Grams: Language-Independent Sorting... Marc Damashek
第一次聽說
· Worse Is Better Richard P. Gabriel
網上膾炙人口的文章。很有教育意義。簡單說，worse is better包括下面幾點：
-- 簡單：設計要簡單。但如果接口和實現不能兩全，追求實現的簡單。文章里給出的Unix vs Multics的例子非常有意思。
-- 正確：程序必須在所有可見的方面正確。其它地方，如果簡單和正確不能兩全，追求簡單。
-- 一致性：程序不能太不一致。但為了簡單，可以在少數地方不一致。
-- 完備性：程序應該盡可能照顧到重要的地方，但是不能犧牲簡潔。
強烈推薦。
· Hints on Programming Language Design C.A.R. Hoare
Hoare對設計語言的經驗總結。這些經驗至今有效。文章很容易讀，讀后絕對增長程序設計的功力。
· Why Functional Programming Matters John Hughes
為普通程序員準備的大餐，所以寫得通俗。沒有公式，也沒有拗口的術語。著重展示了Fold和Map的強大抽象能力。不由想到我在大學里修的一門課，編程語言。課是好課，老師是一流老師。課上我們學習了淺顯的程序語言理論，重點學習了函數編程（用Common Lisp）和邏輯編程（用Prolog）。這門課徹底改變我對編程的理解，明白了imperative programming和OO programming外還有精彩世界。至今想來都覺得幸運。那門課的作業也很有意思，實現一個駐留內存的數據庫，支持關系代數里的常見操作。
· On the Expressive Power of Programming Languages Matthias Felleisen
沒讀過。待讀。
· The Early History Of Smalltalk Alan Kay
還有什么好說的呢？Alan Kay這個名字說明一切。30年前Alan Kay就做出來Smalltalk，現在想來仍然讓人驚嘆。引一段文章Alan Kay評述Smalltalk的話：In computer terms, Smalltalk is a recursion on the notion of computer itself. Instead of dividing "computer stuff" into things each less strong than the whole--like data structures, procedures, and functions which are the usual paraphernalia of programming languages--each Smalltalk object is a recursion on the entire possibilities of the computer. Thus its semantics are a bit like having thousands and thousands of computer all hooked together by a very fast network. Questions of concrete representation can thus be postponed almost indefinitely because we are mainly concerned that the computers behave appropriately, and are interested in particular strategies only if the results are off or come back too slowly.
· Computer Programming as an Art Donald E. Knuth
高老太爺在1974年圖靈獎儀式上的致詞。真是頂尖geek的風范啊。高太爺在文章里解釋了問什么他的書取名為《編程的藝術》。明顯他對人們談到編程時把科學置于藝術之上很不了然。高爺爺追溯“藝術”的詞源，說藝術的本意就是技能，也是技術和技巧兩次的起源。從這里開始，他開始討論藝術和科學的關聯，討論藝術在編程里的表現形式和意義。用他的話說，他作為教育者和作者的畢生目標就是叫人寫美妙的程序。讀起來讓人心潮彭湃的說。
· The next 700 programming languages Peter J. Landin
42年前的論文，影響深遠。Peter在論文里描述的函數語言ISWIM（If You See What I Mean）現在沒有幾個人知道了。但他對lambda算子的推崇和對函數語言的論述影響了后來的函數語言設計。
· Recursive Functions of Symbolic Expressions and their Computation by Machine (Part I) 1960 John McCarthy
47年前提出LISP的那篇著名論文。沒讀過。動態類型檢查，Garbage Collection, 遞歸函數，S-expression, 程序及數據。。?？芍^貢獻輝煌。

· FORTH - A Language for Interactive Computing Charles H.Moore
只知道Forth是一門stack oriented的編程語言，影響了后來的一些語言，比如CAT。其它的就不知道了。
· Teach Yourself Programming in Ten Years 2001 Peter Norvig
大牛之所以為大牛，原因之一就是目光深遠。這篇文章批評那些《24秒學會C＋＋》之類教材的無稽，討論了學習編程，從菜鳥變成鯤鵬的方法。中文版已經傳得滿世界都是，趕快找來看吧。Peter Norvig的網站上還有很多高質量的文章。強烈推薦一讀。
· The Definition and Implementation of a Computer Language based on constraints Guy Lewis Steele Jr.
好像是Guy Steels的碩士論文。沒讀過。
· Growing a Language Guy Lewis Steele Jr.
好文！G老大在OOPSLA 98上的主題演講。G老大主張應該采取漸進的方式設計一門可以被自由擴展的語言（LISP圈子里的牛人們多半都持這種觀點吧？）。這篇演講稿針對該觀點做了精練地論述。說起進化的觀點，可以參看另外一篇好文章，SICP作者之一，Jay Sussman的近作。
· Epigrams on Programming Alan J. Perlis
A老大發表的一系列關于編程的格言。幽默而深刻。每讀必笑。笑后必哭。嗯嗯嗯，夸張一下。不要當真。
· The Complexity of Theorem Proving Procedures Stephen A. Cook
仙風道骨的庫克爺爺的成名作。這篇文章一出，好比有人在加州荒漠里發現第一塊狗頭金，立刻掀起開發加州的狂潮。計算復雜性理論迅速遍地開花。相比這篇論文開創性的貢獻，庫克因此得到圖靈獎不過小小點綴。NP-Complete在這篇論文里被嚴格定義。更重要的是，庫克證明了第一個NP-Complete的問題，SAT(Boolean Satisfiability Problem)。有了SAT，再加上折磨了無數學生的Polynomial Reducibility，無數的NPC問題就出現樂。。。別看俺在這里唾沫橫飛，當年做有關計算理論的證明題還是相當吃力的，沒有少熬夜。奇怪的是，某一天我給同學講解我的解法，NPC的相關定義突然變得清晰起來。當初讓我絞盡腦汁的證明竟然變得相當機械。后來知道，給人講解（包括寫作）是非常有效地學習方法。懷著備課的目標讀文章，假設自己給別人講解正在讀的文章，有助快速理解所讀內容。SAT的證明相當復雜，我反正沒有耐心讀完。
· Steps Toward Artificial Intelligence Marvin Minsky
AI的奠基論文。不過我沒讀過。
· The Original 'Lambda Papers' Guy Steele and Gerald Sussman
一系列講解lambda算子和scheme設計的經典論文。學scheme時讀過，對理解scheme的設計理念很有幫助。

· The UNIX Time-Sharing System Dennis Ritchie and Ken Thompson
作者不用介紹了吧？這篇文章里介紹的Unix特性早為人熟知。不過第八部分(VIII Perspective)討論了作者的設計理念，仍然值得一讀。

本文來自CSDN博客，轉載請標明出處：http://blog.csdn.net/g9yuayon/archive/2007/02/23/1512851.aspx

耦合異步腳本

var script = document.createElement('script');

script.src = "sorttable-async.js";

script.text = "sorttable.init()"; // 這會在下面解釋

document.getElementsByTagName('head')[0].appendChild(script);

<script src="jquery.js">

jQuery("p").addClass("pretty");

</script>

var scripts = document.getElementsByTagName("script");

var cntr = scripts.length;

while ( cntr ) {

var curScript = scripts[cntr-1];

if ( -1 != curScript.src.indexOf('sorttable-async.js') ) {

eval( curScript.innerHTML );

break;

}

cntr--;

}

window.onload = function() {

var script = document.createElement('script');

script.src = "sorttable-async.js";

script.text = "sorttable.init()";

document.getElementsByTagName('head')[0].appendChild(script);

}