JavaSE6的特性

　　Java 語(yǔ)言從誕生的那天起，就非常注重網(wǎng)絡(luò )編程方面的應用。隨著(zhù)互聯(lián)網(wǎng)應用的飛速發(fā)展，Java 的基礎類(lèi)庫也不斷地對網(wǎng)絡(luò )相關(guān)的 API 進(jìn)行加強和擴展。在 Java SE 6 當中，圍繞著(zhù) HTTP 協(xié)議出現了很多實(shí)用的新特性：NTLM 認證提供了一種 Window 平臺下較為安全的認證機制;JDK 當中提供了一個(gè)輕量級的 HTTP 服務(wù)器;提供了較為完善的 HTTP Cookie 管理功能;更為實(shí)用的 NetworkInterface;DNS 域名的國際化支持等等。NTLM 認證不可避免，網(wǎng)絡(luò )中有很多資源是被安全域保護起來(lái)的。訪(fǎng)問(wèn)這些資源需要對用戶(hù)的身份進(jìn)行認證。下面是一個(gè)簡(jiǎn)單的例子：import java.net.*;import java.io.*;public class Test { public static void main(String[] args) throws Exception { URL url = new URL("http://PROTECTED.com"); URLConnection connection = url.openConnection(); InputStream in = connection.getInputStream(); byte[] data = new byte[1024]; while(in.read(data)>0) { //do something for data } in.close(); }}

　　當 Java 程序試圖從一個(gè)要求認證的網(wǎng)站讀取信息的時(shí)候，也就是說(shuō)，從聯(lián)系于 http://Protected.com 這個(gè) URLConnection 的 InputStream 中 read 數據時(shí)，會(huì )引發(fā) FileNotFoundException.盡管認為，這個(gè) Exception 的類(lèi)型與實(shí)際錯誤發(fā)生的原因實(shí)在是相去甚遠;但這個(gè)錯誤確實(shí)是由網(wǎng)絡(luò )認證失敗所導致的。要解決這個(gè)問(wèn)題，有兩種方法：其一，是給 URLConnection 設定一個(gè)“Authentication”屬性：String credit = USERNAME + "：" + PASSWORD;String encoding = new sun.misc.BASE64Encoder()。encode (credit.getBytes());connection.setRequestProperty ("Authorization"， "Basic " + encoding);

　　這里假設 http://PROTECTED.COM 使用了基本(Basic)認證類(lèi)型。從上面的例子，我們可以看出，設定 Authentication 屬性還是比較復雜的：用戶(hù)必須了解認證方式的細節，才能將用戶(hù)名/密碼以一定的規范給出，然后用特定的編碼方式加以編碼。Java 類(lèi)庫有沒(méi)有提供一個(gè)封裝了認證細節，只需要給出用戶(hù)名/密碼的工具呢?這就是我們要介紹的另一種方法，使用 java.net.Authentication 類(lèi)。每當遇到網(wǎng)站需要認證的時(shí)候，HttpURLConnection 都會(huì )向 Authentication 類(lèi)詢(xún)問(wèn)用戶(hù)名和密碼。Authentication 類(lèi)不會(huì )知道究竟用戶(hù)應該使用哪個(gè) username/password 那么用戶(hù)如何向 Authentication 類(lèi)提供自己的用戶(hù)名和密碼呢?提供一個(gè)繼承于 Authentication 的類(lèi)，實(shí)現 getPasswordAuthentication 方法，在 PasswordAuthentication 中給出用戶(hù)名和密碼：class DefaultAuthenticator extends Authenticator { public PasswordAuthentication getPasswordAuthentication () { return new PasswordAuthentication ("USER"， "PASSWORD".toCharArray()); }}

　　然后，將它設為默認的(全局)Authentication：Authenticator.setDefault (new DefaultAuthenticator());

　　那么，不同的網(wǎng)站需要不同的用戶(hù)名/密碼又怎么辦呢?Authentication 提供了關(guān)于認證發(fā)起者的足夠多的信息，讓繼承類(lèi)根據這些信息進(jìn)行判斷，在 getPasswordAuthentication 方法中給出了不同的認證信息：getRequestingHost()getRequestingPort()getRequestingPrompt()getRequestingProtocol()getRequestingScheme()getRequestingURL()getRequestingSite()getRequestorType()另一件關(guān)于 Authentication 的重要問(wèn)題是認證類(lèi)型。不同的認證類(lèi)型需要 Authentication 執行不同的協(xié)議。至 Java SE 6.0 為止，Authentication 支持的認證方式有：HTTP Basic authenticationHTTP Digest authenticationNTLMHttp SPNEGO NegotiateKerberosNTLM這里我們著(zhù)重介紹 NTLM.NTLM 是 NT LAN Manager 的縮寫(xiě)。早期的 SMB 協(xié)議在網(wǎng)絡(luò )上明文傳輸口令，這是很不安全的。微軟隨后提出了 WindowsNT 挑戰/響應驗證機制，即 NTLM.NTLM 協(xié)議是這樣的：客戶(hù)端首先將用戶(hù)的密碼加密成為密碼散列;客戶(hù)端向服務(wù)器發(fā)送自己的用戶(hù)名，這個(gè)用戶(hù)名是用明文直接傳輸的;服務(wù)器產(chǎn)生一個(gè) 16 位的隨機數字發(fā)送給客戶(hù)端，作為一個(gè) challenge(挑戰) ;客戶(hù)端用步驟1得到的密碼散列來(lái)加密這個(gè) challenge ，然后把這個(gè)返回給服務(wù)器;服務(wù)器把用戶(hù)名、給客戶(hù)端的 challenge 、客戶(hù)端返回的 response 這三個(gè)東西，發(fā)送域控制器 ;域控制器用這個(gè)用戶(hù)名在 SAM 密碼管理庫中找到這個(gè)用戶(hù)的密碼散列，然后使用這個(gè)密碼散列來(lái)加密 challenge;域控制器比較兩次加密的 challenge ，如果一樣，那么認證成功;Java 6 以前的版本，是不支持 NTLM 認證的。用戶(hù)若想使用 HttpConnection 連接到一個(gè)使用有 Windows 域保護的網(wǎng)站時(shí)，是無(wú)法通過(guò) NTLM 認證的。另一種方法，是用戶(hù)自己用 Socket 這樣的底層單元實(shí)現整個(gè)協(xié)議過(guò)程，這無(wú)疑是十分復雜的。終于，Java 6 的 Authentication 類(lèi)提供了對 NTLM 的支持。使用十分方便，就像其他的認證協(xié)議一樣：class DefaultAuthenticator extends Authenticator { private static String username = "username "; private static String domain = "domain "; private static String password = "password "; public PasswordAuthentication getPasswordAuthentication() { String usernamewithdomain = domain + "/ "+username; return (new PasswordAuthentication(usernamewithdomain， password.toCharArray())); }}

　　這里，根據 Windows 域賬戶(hù)的命名規范，賬戶(hù)名為域名+“/”+域用戶(hù)名。如果不想每生成 PasswordAuthentication 時(shí)，每次添加域名，可以設定一個(gè)系統變量名“http.auth.ntlm.domain”。Java 6 中 Authentication 的另一個(gè)特性是認證協(xié)商。目前的服務(wù)器一般同時(shí)提供幾種認證協(xié)議，根據客戶(hù)端的不同能力，協(xié)商出一種認證方式。比如，IIS 服務(wù)器會(huì )同時(shí)提供 NTLM with kerberos 和 NTLM 兩種認證方式，當客戶(hù)端不支持 NTLM with kerberos 時(shí)，執行 NTLM 認證。目前，Authentication 的默認協(xié)商次序是：GSS/SPNEGO -> Digest -> NTLM -> Basic

　　那么 kerberos 的位置究竟在哪里呢?事實(shí)上，GSS/SPNEGO 以 JAAS 為基石，而后者實(shí)際上就是使用 kerberos 的。輕量級 HTTP 服務(wù)器Java 6 還提供了一個(gè)輕量級的純 Java Http 服務(wù)器的實(shí)現。下面是一個(gè)簡(jiǎn)單的例子：public static void main(String[] args) throws Exception{ HttpServerProvider httpServerProvider = HttpServerProvider.provider(); InetSocketAddress addr = new InetSocketAddress(7778); HttpServer httpServer = httpServerProvider.createHttpServer(addr， 1); httpServer.createContext("/myapp/"， new MyHttpHandler()); httpServer.setExecutor(null); httpServer.start(); System.out.println("started");}static class MyHttpHandler implements HttpHandler{ public void handle(HttpExchange httpExchange) throws IOException { String response = "Hello world!"; httpExchange.sendResponseHeaders(200， response.length()); OutputStream out = httpExchange.getResponseBody(); out.write(response.getBytes()); out.close(); } }

　　首先，HttpServer 是從 HttpProvider 處得到的，這里我們使用了 JDK 6 提供的實(shí)現。用戶(hù)也可以自行實(shí)現一個(gè) HttpProvider 和相應的 HttpServer 實(shí)現。其次，HttpServer 是有上下文(context)的概念的。比如，http://localhost：7778/myapp/ 中“/myapp/”就是相對于 HttpServer Root 的上下文。對于每個(gè)上下文，都有一個(gè) HttpHandler 來(lái)接收 http 請求并給出回答。最后，在 HttpHandler 給出具體回答之前，一般先要返回一個(gè) Http head.這里使用 HttpExchange.sendResponseHeaders(int code， int length)。其中 code 是 Http 響應的返回值，比如那個(gè)著(zhù)名的 404.length 指的是 response 的長(cháng)度，以字節為單位。Cookie 管理特性Cookie 是 Web 應用當中非常常用的一種技術(shù)，用于儲存某些特定的用戶(hù)信息。雖然，我們不能把一些特別敏感的信息存放在 Cookie 里面，但是，Cookie 依然可以幫助我們儲存一些瑣碎的信息，幫助 Web 用戶(hù)在訪(fǎng)問(wèn)網(wǎng)頁(yè)時(shí)獲得更好的體驗，例如個(gè)人的搜索參數，顏色偏好以及上次的訪(fǎng)問(wèn)時(shí)間等等。網(wǎng)絡(luò )程序開(kāi)發(fā)者可以利用 Cookie 來(lái)創(chuàng )建有狀態(tài)的網(wǎng)絡(luò )會(huì )話(huà)(Stateful Session)。 Cookie 的應用越來(lái)越普遍。在 Windows 里面，我們可以在“Documents And Settings”文件夾里面找到IE使用的 Cookie，假設用戶(hù)名為 admin，那么在 admin 文件夾的 Cookies 文件夾里面，我們可以看到名為“admin@(domain)”的一些文件，其中的 domain 就是表示創(chuàng )建這些 Cookie 文件的網(wǎng)絡(luò )域，文件里面就儲存著(zhù)用戶(hù)的一些信息。JavaScript 等腳本語(yǔ)言對 Cookie 有著(zhù)很不錯的支持。 .NET 里面也有相關(guān)的類(lèi)來(lái)支持開(kāi)發(fā)者對 Cookie 的管理。不過(guò)，在 Java SE 6 之前， Java一直都沒(méi)有提供 Cookie 管理的功能。在 Java SE 5 里面， java.net 包里面有一個(gè) CookieHandler 抽象類(lèi)，不過(guò)并沒(méi)有提供其他具體的實(shí)現。到了Java SE 6，Cookie 相關(guān)的管理類(lèi)在 Java 類(lèi)庫里面才得到了實(shí)現。有了這些 Cookie 相關(guān)支持的類(lèi)，Java 開(kāi)發(fā)者可以在服務(wù)器端編程中很好的操作 Cookie，更好的支持 HTTP 相關(guān)應用，創(chuàng )建有狀態(tài)的 HTTP 會(huì )話(huà)。用 HttpCookie 代表 Cookiejava.net.HttpCookie 類(lèi)是 Java SE 6 新增的一個(gè)表示 HTTP Cookie 的新類(lèi)，其對象可以表示 Cookie 的內容， 可以支持所有三種 Cookie 規范：Netscape 草案RFC 2109 - http://www.ietf.org/rfc/rfc2109.txtRFC 2965 - http://www.ietf.org/rfc/rfc2965.txt這個(gè)類(lèi)儲存了Cookie 的名稱(chēng)，路徑，值，協(xié)議版本號，是否過(guò)期，網(wǎng)絡(luò )域，最大生命期等等信息。用CookiePolicy 規定 Cookie 接受策略java.net.CookiePolicy 接口可以規定Cookie 的接受策略。其中唯一的方法用來(lái)判斷某一特定的 Cookie 是否能被某一特定的地址所接受。 這個(gè)類(lèi)內置了 3 個(gè)實(shí)現的子類(lèi)。一個(gè)類(lèi)接受所有的 Cookie，另一個(gè)則拒絕所有，還有一個(gè)類(lèi)則接受所有來(lái)自原地址的 Cookie.用CookieStore 儲存Cookiejava.net.CookieStore 接口負責儲存和取出Cookie. 當有 HTTP 請求的時(shí)候，它便儲存那些被接受的 Cookie; 當有HTTP 回應的時(shí)候，它便取出相應的 Cookie. 另外，當一個(gè)Cookie 過(guò)期的時(shí)候，它還負責自動(dòng)刪去這個(gè)Cookie.用 CookieManger/CookieHandler 管理Cookiejava.net.CookieManager 是整個(gè) Cookie 管理機制的核心，它是 CookieHandler 的默認實(shí)現子類(lèi)。

　　一個(gè) CookieManager 里面有一個(gè) CookieStore 和一個(gè) CookiePolicy，分別負責儲存 Cookie 和規定策略。用戶(hù)可以指定兩者，也可以使用系統默認的 CookieManger.例子下面這個(gè)簡(jiǎn)單的例子說(shuō)明了 Cookie 相關(guān)的管理功能:// 創(chuàng )建一個(gè)默認的 CookieManagerCookieManager manager = new CookieManager();// 將規則改掉，接受所有的 Cookiemanager.setCookiePolicy(CookiePolicy.ACCEPT_ALL);// 保存這個(gè)定制的 CookieManagerCookieHandler.setDefault(manager); // 接受 HTTP 請求的時(shí)候，得到和保存新的 CookieHttpCookie cookie = new HttpCookie("……(name)……"，"……(value)……");manager.getCookieStore()。add(uri， cookie); // 使用 Cookie 的時(shí)候:// 取出 CookieStore CookieStore store = manager.getCookieStore();// 得到所有的 URI List uris = store.getURIs();for (URI uri ： uris) { // 篩選需要的 URI // 得到屬于這個(gè) URI 的所有 Cookie List cookies = store.get(uri); for (HttpCookie cookie ： cookies) { // 取出了 Cookie }} // 或者，取出這個(gè) CookieStore 里面的全部 Cookie// 過(guò)期的 Cookie 將會(huì )被自動(dòng)刪除List cookies = store.getCookies();for (HttpCookie cookie ： cookies) { // 取出了 Cookie}

　　其他新特性NetworkInterface 的增強從 Java SE 1.4 開(kāi)始，JDK 當中出現了一個(gè)網(wǎng)絡(luò )工具類(lèi) java.net.NetworkInterface，提供了一些網(wǎng)絡(luò )的實(shí)用功能。 在 Java SE 6 當中，這個(gè)工具類(lèi)得到了很大的加強，新增了很多實(shí)用的方法。例如：public boolean isUp()用來(lái)判斷網(wǎng)絡(luò )接口是否啟動(dòng)并運行public boolean isLoopback()用來(lái)判斷網(wǎng)絡(luò )接口是否是環(huán)回接口(loopback)public boolean isPointToPoint()用來(lái)判斷網(wǎng)絡(luò )接口是否是點(diǎn)對點(diǎn)(P2P)網(wǎng)絡(luò )public boolean supportsMulticast()用來(lái)判斷網(wǎng)絡(luò )接口是否支持多播public byte[] getHardwareAddress()用來(lái)得到硬件地址(MAC)public int getMTU()用來(lái)得到最大傳輸單位(MTU，Maximum Transmission Unit)public boolean isVirtual()用來(lái)判斷網(wǎng)絡(luò )接口是否是虛擬接口關(guān)于此工具類(lèi)的具體信息，請參考 Java SE 6 相應文檔(見(jiàn) 參考資源)。域名的國際化在最近的一些 RFC 文檔當中，規定 DNS 服務(wù)器可以解析除開(kāi) ASCII 以外的編碼字符。有一個(gè)算法可以在這種情況下做 Unicode 與 ASCII 碼之間的轉換，實(shí)現域名的國際化。java.net.IDN 就是實(shí)現這個(gè)國際化域名轉換的新類(lèi)，IDN 是“國際化域名”的縮寫(xiě)(internationalized domain names)。這個(gè)類(lèi)很簡(jiǎn)單，主要包括 4 個(gè)靜態(tài)函數，做字符的轉換。結語(yǔ)

　　Java SE 6 有著(zhù)很多 HTTP 相關(guān)的新特性，使得 Java SE 平臺本身對網(wǎng)絡(luò )編程，尤其是基于 HTTP 協(xié)議的因特網(wǎng)編程，有了更加強大的支持。

【JavaSE6的特性】相關(guān)文章：

Java認證考試知識點(diǎn)：JavaSE6的新功能03-16

色彩的基本特性03-12

項目管理特性03-18

項目管理有哪些特性-項目管理的6大特性11-14

去法國留學(xué)的特性03-24

色彩是特性有哪些03-12

污泥的分類(lèi)和特性04-10

網(wǎng)球比賽的幾大特性03-09

無(wú)線(xiàn)話(huà)筒有哪些特性-無(wú)線(xiàn)話(huà)筒的十大優(yōu)良特性03-27