本文地址: http://www.vxxp.com/archives/2.html
中文名稱 | psp版豆瓣電臺 (2011年6月24日 更新) |
---|---|
原文名稱 | psp版豆瓣電臺 |
發行版本 開發人員 |
1.1.5 LonLeung |
游戲類型 | 多媒體 |
發行廠商 | 豆瓣 © 2005-2012 douban.com, all rights reserved |
容量大小 | 103 KB |
語言 | 中文 |
其他 | 京ICP證090015號 京ICP備09113438 網絡視聽許可證0110418號 文網文[2009]267號 |
1.0.0
2010-6-18 新建PSP豆瓣電臺項目
1.0.1
2010-7-20 第一個Demo
1.0.2
2010-8-8 在1.0.1版本上增加了官方UI
1.0.3
2011-5-15 PSP豆瓣電臺發布
1.0.4
2011-5-17 新增加20個豆瓣頻道,用搖桿光標選擇下拉框的頻道后自動播放相應頻道的歌曲
1.0.5
2011-5-22 新增豆瓣私人頻道
1.0.6
2011-5-23 新增加紅心、去紅心、刪除歌曲功能
1.1.0
2011-5-24 新增Lee MHz 頻道、優化UI
1.1.1
2011-5-25 修正歌曲還差0.5秒未播放完就開始跳歌問題
1.1.2
2011-5-27 修正Skip歌曲時延時問題,增加短報告處理方法,刪除UI中多余的控件讓界面更清爽
1.1.3
2011-6-1 增加長報告處理方法,使后臺的歌曲喜好計算更加準確
1.1.4
2011-6-10 新增一臺服務器,今后開始采取自動腳本更新方式,方便同學們升級。
1.1.5
2011-6-24 作者 Saoirse Ronan 對豆瓣電臺圖標進行了美化修復
thunder://QUFodHRwOi8vMTI3LjAuMC4xLzExMDUxNjE4NDlmODdkN2EyOTNhZGRjNWVhLnJhcj9maWQ9ZnVTVnFDTTFNcDVkSlp1eGhMRjlKMjRSNGtwR1JRSUFBQUFBQUs2YldpMGo3SThjK2FRZzdkQ1pyandzWUxXcCZtaWQ9NjY2JnRocmVzaG9sZD0xNTAmdGlkPTRGMjJFOUUyQjkxMjhEN0UxRUNGNTUwMUE4NDNFOTRBJnNyY2lkPTZaWg==
115網盤:http://u.115.com/file/e61dk1rk
(2012-3-28 更新: 公共頻道)
dbank網盤: http://dl.dbank.com/c0gdv0aj9c
<audio>
tag usage.
It uses native <audio>
where available and falls back to an invisible flash player to emulate it for other browsers.
The player can be completely styled with CSS to provide a consistent user interface.
audio.js can only play mp3 files and can be extended in any way like playing a single file or a list of songs.
Special Downloads:
Ajaxed Add-To-Basket Scenarios With jQuery And PHP
Free Admin Template For Web Applications
jQuery Dynamic Drag’n Drop
ScheduledTweets
Advertisements:
Professional XHTML Admin Template ($15 Discount With The Code: WRD.)
Psd to Xhtml
SSLmatic – Cheap SSL Certificates (from $19.99/year)
我們不是最好的,但是我們會努力做的更好,我們愿意傾聽和接受所有用戶的心聲。最后,大家在使用過程中若發現任何的問題,或者有比較好的創意和想法,可以隨時向我們反饋(yanis.wang@gmail.com),我們會隨時傾聽大家的意見,xhEditor的發展離不開大家的支持。
查看最新版演示:http://xheditor.com/demo
更多官方在線演示:
1. 默認模式:http://xheditor.com/demos/demo01.html
2. 自定義按鈕:http://xheditor.com/demos/demo02.html
3. 皮膚選擇:http://xheditor.com/demos/demo03.html
4. 其它選項:http://xheditor.com/demos/demo04.html
5. Javascript交互:http://xheditor.com/demos/demo05.html
6. 非utf-8編碼網頁調用:http://xheditor.com/demos/demo06.html
7. UBB可視化編輯:http://xheditor.com/demos/demo07.html
8. Ajax文件上傳:http://xheditor.com/demos/demo08.html
9. 插件擴展:http://xheditor.com/demos/demo09.html
10.iframe調用文件上傳:http://xheditor.com/demos/demo10.html
11.異步加載:http://xheditor.com/demos/demo11.html
v1.1.3 Change (2011-1-1)
11) Grunge Textures
[via]
國內類似的資源網站也很多,這里就不一一列出啦,Just Google It!
轉載請注明:
轉載自:http://www.fisherv.com
xhEditor是一個基于jQuery開發的簡單迷你并且高效的可視化XHTML編輯器,基于網絡訪問并且兼容IE 6.0+,Firefox 3.0+,Opera 9.6+,Chrome 1.0+,Safari 3.22+。
在眾多用戶不斷的問題回饋和意見反饋下,經過長達1年零3 個月的不斷完善后,v1系列的正式版本v1.0.0 Final終于正式對外發布。經過這么久的不斷開發修正和完善,v1.0.0 Final的BUG數量相對已經非常少,我們有自信可以給大家交上一份滿意的答卷。
我們不是最好的,但是我們會努力做的更好,我們愿意傾聽和接受所有用戶的心聲。最后,大家在使用過程中若發現任何的問題,或者有比較好的創意和想法,可以隨時向我們反饋(yanis.wang@gmail.com),我們會隨時傾聽大家的意見,xhEditor的發展離不開大家的支持。
查看最新版演示:http://xheditor.com/demo
更多官方在線演示:
1. 默認模式:http://xheditor.com/demos/demo01.html
2. 自定義按鈕:http://xheditor.com/demos/demo02.html
3. 皮膚選擇:http://xheditor.com/demos/demo03.html
4. 其它選項:http://xheditor.com/demos/demo04.html
5. Javascript交互:http://xheditor.com/demos/demo05.html
6. 非utf-8編碼網頁調用:http://xheditor.com/demos/demo06.html
7. UBB可視化編輯:http://xheditor.com/demos/demo07.html
8. Ajax文件上傳:http://xheditor.com/demos/demo08.html
9. 插件擴展:http://xheditor.com/demos/demo09.html
10.iframe調用文件上傳:http://xheditor.com/demos/demo10.html
11.異步加載:http://xheditor.com/demos/demo11.html
最新1.0.0 Final版本更新內容(2010-7-1):
1. 添加:添加html5Upload參數,用以關閉HTML5上傳功能,若關閉HTML5上傳,則upMultiple參數無效
2. 添加:添加delShortcuts API接口,以供插件或者外部動態的刪除快捷鍵
1. 修正:UBB模塊背景色在Firefox瀏覽器下某些情況會丟失問題的修正
2. 修正:IE6瀏覽器直接在標簽內調用初始化JS代碼失敗問題的修正
3. 修正:插件代碼在IE的某些特殊情況會造成焦點丟失問題的修正
4. 修正:Firefox瀏覽器下用jQuery的load動態加載帶編輯器代碼頁面無效問題的修正
5. 修正:從Word文檔粘貼內容在Chrome瀏覽器中清理不完全問題的修正
6. 修正:inlineStyle參數無效問題的修正
7. 修正:IE瀏覽器粘貼無法清理Word文檔問題的修正
1. 調整:優化初始化代碼以提高初始化速度
2. 調整:考慮到“關于”按鈕自動顯示容易影響正常用戶使用體驗,特關閉此按鈕的自動顯示功能
3. 調整:考慮php的json支持需要5.2版本以上才支持,對演示上傳程序upload.php進行了適當的調節以提高兼容性,并同時優化了某些代碼流程
4. 調整:upMultiple參數由原先的邏輯值,變更為數值型,代表允許一次最大上傳文件數,允許值:大于0的整數,等于1代表關閉多文件選擇
5. 調整:縮略圖等參數分隔符逗號:“,”在非常多的特殊URL中容易出現,因此變更為:“||”
6. 調整:根據用戶反饋意見,將默認表情變更為QQ表情
7. 調整:某些按鈕的功能代碼中使用title屬性傳值,會與某些toolTip插件沖突,因此變更傳值屬性值以提高兼容性
8. 調整:關閉所有textarea在Chrome瀏覽器中的拖動改變大小功能
最新v1.0.0 Final下載地址:
http://xheditor.com/download
Apple和Google現在是兩大推廣HTML 5和WebKit的巨頭,既然Apple有一個專門推廣HTML 5的網站,那Google也不能落后,于是他們祭出了HTML5ROCKS。HTML5ROCKS里目 前有9個關于 HTML 5功能的指南,通過“代碼練兵場”還能讓你插入自己的代碼進去實踐──很顯然Chrome對它們的支持是最好的,但Safari也沒 問題(Google不像Apple那樣小氣還),對了別忘記被Chrome Frame強行插入的IE也能勝任哦。
Via Chromium Blog 谷奧
1.HTML頁面直接寫
<img alt="powerbookg4.jpg" src="archives/images/powerbookg4.jpg" width="250" height="60" style="-moz-opacity:0.5; filter:alpha(opacity=50);cursor:pointer;" />
2.JS中寫
在IE中需要通過"filter"來定義透明度"opacity",而在Mozilla中是可以直接解析"opacity",所以如果要使得這個效 果在兩種瀏覽器中都得到支持,需要把兩種設定都加進去。針對IE的設定:this.filters.alpha.opacity=50 而針對 Mozilla的設定:this.style.MozOpacity=0.5
3.CSS樣式表中寫
css代碼里這樣寫就可以:
.div {
filter:alpha(opacity=50);/*IE*/
opacity:0.5;/*Mozilla*/
}
1)表格:插入表格采用dialog,可設置常用屬性。插入表格后在表格上點擊右鍵彈出表格控制菜單。
2)右鍵菜單(contextmenu):支持左側小圖標、分割線,外觀更美觀。
3)菜單(menu):標題、字體、文字大小、顏色可以反映當前狀態。
4)表情:增加分頁和預覽,通過allowPreviewEmoticons屬性可關閉預覽表情功能。
5)彈出框(dialog):彈出框支持陰影效果,通過shadowMode可關閉陰影效果。
6)國際化:3.5版本開始所有中文都提取到一個js里,制作其它語言版本只需要翻譯src/lang/zh_CN.js即可。
7)新接口:引入KE.html, KE.text, KE.selectedHtml, KE.insertHtml, KE.appendHtml, KE.isEmpty等函數。
其它改善和bugfix:
--------
* 改善: 編輯器底部顯示向下拖動指示圖標。
* 改善: 點擊編輯器外的頁面其它部位時關閉菜單。
* 改善: 移除編輯器時將編輯器內容設置到原來的textarea。
* 改善: 從外部粘貼內容時自動將font轉換成span標簽。
* 改善: ASP.NET程序改成ashx,使用時不需要編譯。
* BUG: 改善了文章內容比較多時速度比較慢的問題。
* BUG: 修改了在IE上選中圖片或表格后無法用backspace鍵刪除的問題。
* BUG: 修改了在Firefox上全屏后瀏覽器一直處于加載狀態的問題。
* BUG: 修改了在非IE上DOMContentLoaded事件不起作用的問題。
* BUG: 修改了刪除編輯器時沒有銷毀事件的問題。
* BUG: 修改了設置成無顏色時其它樣式也被刪除的問題。
* BUG: 修改了拖動時拖到瀏覽器外面放開鼠標后會粘住的問題。
* BUG: 修改了在Firefox上pre標簽自動生成br標簽的問題。
* BUG: 修改了在IE6上用KE.cmd.wrap方法設置class屬性后沒有效果的問題。
* BUG: 修改了在P標簽內沒選中內容時無法插入超級鏈接的問題。
* BUG: 修改了使用快捷鍵加粗體、斜體、下劃線時沒有同步的問題。
演示:
--------
http://www.kindsoft.net/demo.php
下載:
--------
http://www.kindsoft.net/down.php
下面是CSS代碼:
代碼說明
HTML代碼中各部分出現的順序是非常重要的。左欄和右欄div必須在中欄之前出現。這樣才可以讓這兩個邊欄浮動到它們的位置上(屏幕兩側),并讓中欄的內容將“流”入它們之間的空間。如果瀏覽器在一個或者兩個邊欄div之前先發現中欄,那么中欄將占據屏幕的一側或者兩側,這樣浮動的部分就會跑到中欄的下面而不是中欄的旁邊了。
div#header和div#footer樣式(style)中的clearoth申明用來確保這浮動部分不會占據標題和頁腳的空間。div#header樣式中的padding:1px申明用來消除頁頭背景色中的異常邊,如果padding設置為零,那么在Netscape瀏覽器中就會看到這個異常。
div#left樣式中的float:left申明是用來把左欄擠壓到左側。width:150px申明用來設置欄的固定寬度,不過你也可以把它的寬度設置為其它具體值。類似的,div#right樣式中的float:right申明用來把右欄div擠壓到右側。在本例中,float把左欄和右欄完全擠壓到瀏覽器窗口的左邊緣和右邊緣。然而,如果這些div被其它div包含,那么float將會把它們擠壓到包含它們的div的邊緣。
在div#middle樣式中,clear申明允許中欄的內容“流淌”在兩個邊欄之間。padding:0px 160px 5px 160px申明設置了到左欄和右欄的填充,這樣允許150象素寬度的欄div,在加上10象素的間距。
這個例子非常粗糙和簡單,但是它很好的演示了用浮動div來創建三欄液態布局的邊欄這一基本技術。
HTTP是Hyper Text Transfer Protocol(超文本傳輸協議)的縮寫。它的發展是萬維網協會(World Wide Web Consortium)和Internet工作小組IETF(Internet Engineering Task Force)合作的結果,(他們)最終發布了一系列的RFC,RFC 1945定義了HTTP/1.0版本。其中最著名的就是RFC 2616。RFC 2616定義了今天普遍使用的一個版本——HTTP 1.1。
HTTP協議(HyperText Transfer Protocol,超文本傳輸協議)是用于從WWW服務器傳輸超文本到本地瀏覽器的傳送協議。它可以使瀏覽器更加高效,使網絡傳輸減少。它不僅保證計算機正確快速地傳輸超文本文檔,還確定傳輸文檔中的哪一部分,以及哪部分內容首先顯示(如文本先于圖形)等。
HTTP是一個應用層協議,由請求和響應構成,是一個標準的客戶端服務器模型。HTTP是一個無狀態的協議。
HTTP協議通常承載于TCP協議之上,有時也承載于TLS或SSL協議層之上,這個時候,就成了我們常說的HTTPS。如下圖所示:
默認HTTP的端口號為80,HTTPS的端口號為443。
HTTP協議永遠都是客戶端發起請求,服務器回送響應。見下圖:
這樣就限制了使用HTTP協議,無法實現在客戶端沒有發起請求的時候,服務器將消息推送給客戶端。
HTTP協議是一個無狀態的協議,同一個客戶端的這次請求和上次請求是沒有對應關系。
一次HTTP操作稱為一個事務,其工作過程可分為四步:
1)首先客戶機與服務器需要建立連接。只要單擊某個超級鏈接,HTTP的工作開始。
2)建立連接后,客戶機發送一個請求給服務器,請求方式的格式為:統一資源標識符(URL)、協議版本號,后邊是MIME信息包括請求修飾符、客戶機信息和可能的內容。
3)服務器接到請求后,給予相應的響應信息,其格式為一個狀態行,包括信息的協議版本號、一個成功或錯誤的代碼,后邊是MIME信息包括服務器信息、實體信息和可能的內容。
4)客戶端接收服務器所返回的信息通過瀏覽器顯示在用戶的顯示屏上,然后客戶機與服務器斷開連接。
如果在以上過程中的某一步出現錯誤,那么產生錯誤的信息將返回到客戶端,有顯示屏輸出。對于用戶來說,這些過程是由HTTP自己完成的,用戶只要用鼠標點擊,等待信息顯示就可以了。
打開Wireshark,選擇工具欄上的“Capture”->“Options”,界面選擇如圖1所示:
圖1 設置Capture選項
一般讀者只需要選擇最上邊的下拉框,選擇合適的Device,而后點擊“Capture Filter”,此處選擇的是“HTTP TCP port(80)”,選擇后點擊上圖的“Start”開始抓包。
圖2 選擇Capture Filter
例如在瀏覽器中打開http://image.baidu.com/,抓包如圖3所示:
http://www.aygfsteel.com/images/blogjava_net/amigoxie/40799/o_http%e5%8d%8f%e8%ae%ae%e5%ad%a6%e4%b9%a0-%e6%a6%82%e5%bf%b5-3.jpg
圖3 抓包
在上圖中,可清晰的看到客戶端瀏覽器(ip為192.168.2.33)與服務器的交互過程:
1)No1:瀏覽器(192.168.2.33)向服務器(220.181.50.118)發出連接請求。此為TCP三次握手第一步,此時從圖中可以看出,為SYN,seq:X (x=0)
2)No2:服務器(220.181.50.118)回應了瀏覽器(192.168.2.33)的請求,并要求確認,此時為:SYN,ACK,此時seq:y(y為0),ACK:x+1(為1)。此為三次握手的第二步;
3)No3:瀏覽器(192.168.2.33)回應了服務器(220.181.50.118)的確認,連接成功。為:ACK,此時seq:x+1(為1),ACK:y+1(為1)。此為三次握手的第三步;
4)No4:瀏覽器(192.168.2.33)發出一個頁面HTTP請求;
5)No5:服務器(220.181.50.118)確認;
6)No6:服務器(220.181.50.118)發送數據;
7)No7:客戶端瀏覽器(192.168.2.33)確認;
8)No14:客戶端(192.168.2.33)發出一個圖片HTTP請求;
9)No15:服務器(220.181.50.118)發送狀態響應碼200 OK
……
每個頭域由一個域名,冒號(:)和域值三部分組成。域名是大小寫無關的,域值前可以添加任何數量的空格符,頭域可以被擴展為多行,在每行開始處,使用至少一個空格或制表符。
在抓包的圖中,No14點開可看到如圖4所示:
http://www.aygfsteel.com/images/blogjava_net/amigoxie/40799/o_http%e5%8d%8f%e8%ae%ae%e5%ad%a6%e4%b9%a0-%e6%a6%82%e5%bf%b5-4.jpg
圖4 http請求消息
回應的消息如圖5所示:
圖5 http狀態響應信息
Host頭域指定請求資源的Intenet主機和端口號,必須表示請求url的原始服務器或網關的位置。HTTP/1.1請求必須包含主機頭域,否則系統會以400狀態碼返回。
圖5中host那行為:
Referer頭域允許客戶端指定請求uri的源資源地址,這可以允許服務器生成回退鏈表,可用來登陸、優化cache等。他也允許廢除的或錯誤的連接由于維護的目的被追蹤。如果請求的uri沒有自己的uri地址,Referer不能被發送。如果指定的是部分uri地址,則此地址應該是一個相對地址。
在圖4中,Referer行的內容為:
User-Agent頭域的內容包含發出請求的用戶信息。
在圖4中,User-Agent行的內容為:
http://www.aygfsteel.com/images/blogjava_net/amigoxie/40799/o_http%e5%8d%8f%e8%ae%ae%e5%ad%a6%e4%b9%a0-%e6%a6%82%e5%bf%b5-8.jpg
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。
在圖5中的該頭域為:
Date頭域表示消息發送的時間,時間的描述格式由rfc822定義。例如,Date:Mon,31Dec200104:25:57GMT。Date描述的時間表示世界標準時,換算成本地時間,需要知道用戶所在的時區。
圖5中,該頭域如下圖所示:
一個傳輸層的實際環流,它是建立在兩個相互通訊的應用程序之間。
在http1.1,request和reponse頭中都有可能出現一個connection的頭,此header的含義是當client和server通信時對于長鏈接如何進行處理。
在http1.1中,client和server都是默認對方支持長鏈接的, 如果client使用http1.1協議,但又不希望使用長鏈接,則需要在header中指明connection的值為close;如果server方也不想支持長鏈接,則在response中也需要明確說明connection的值為close。不論request還是response的header中包含了值為close的connection,都表明當前正在使用的tcp鏈接在當天請求處理完畢后會被斷掉。以后client再進行新的請求時就必須創建新的tcp鏈接了。
HTTP通訊的基本單位,包括一個結構化的八元組序列并通過連接傳輸。
一個從客戶端到服務器的請求信息包括應用于資源的方法、資源的標識符和協議的版本號。
一個從服務器返回的信息包括HTTP協議的版本號、請求的狀態(例如“成功”或“沒找到”)和文檔的MIME類型。
由URI標識的網絡數據對象或服務。
數據資源或來自服務資源的回映的一種特殊表示方法,它可能被包圍在一個請求或響應信息中。一個實體包括實體頭信息和實體的本身內容。
一個為發送請求目的而建立連接的應用程序。
初始化一個請求的客戶機。它們是瀏覽器、編輯器或其它用戶工具。
一個接受連接并對請求返回信息的應用程序。
是一個給定資源可以在其上駐留或被創建的服務器。
一個中間程序,它可以充當一個服務器,也可以充當一個客戶機,為其它客戶機建立請求。請求是通過可能的翻譯在內部或經過傳遞到其它的服務器中。一個代理在發送請求信息之前,必須解釋并且如果可能重寫它。
代理經常作為通過防火墻的客戶機端的門戶,代理還可以作為一個幫助應用來通過協議處理沒有被用戶代理完成的請求。
一個作為其它服務器中間媒介的服務器。與代理不同的是,網關接受請求就好象對被請求的資源來說它就是源服務器;發出請求的客戶機并沒有意識到它在同網關打交道。
網關經常作為通過防火墻的服務器端的門戶,網關還可以作為一個協議翻譯器以便存取那些存儲在非HTTP系統中的資源。
是作為兩個連接中繼的中介程序。一旦激活,通道便被認為不屬于HTTP通訊,盡管通道可能是被一個HTTP請求初始化的。當被中繼的連接兩端關閉時,通道便消失。當一個門戶(Portal)必須存在或中介(Intermediary)不能解釋中繼的通訊時通道被經常使用。
反應信息的局域存儲。
《http_百度百科》:http://baike.baidu.com/view/9472.htm
《結果編碼和http狀態響應碼》:http://blog.tieniu1980.cn/archives/377
《分析TCP的三次握手》:
《使用Wireshark來檢測一次HTTP連接過程》:
http://blog.163.com/wangbo_tester/blog/static/12806792120098174162288/
《http協議的幾個重要概念》:http://nc.mofcom.gov.cn/news/10819972.html
《http協議中connection頭的作用》:
http://blog.csdn.net/barfoo/archive/2008/06/05/2514667.aspxCookie和Session都為了用來保存狀態信息,都是保存客戶端狀態的機制,它們都是為了解決HTTP無狀態的問題而所做的努力。
Session可以用Cookie來實現,也可以用URL回寫的機制來實現。用Cookie來實現的Session可以認為是對Cookie更高級的應用。
Cookie和Session有以下明顯的不同點:
1)Cookie將狀態保存在客戶端,Session將狀態保存在服務器端;
2)Cookies是服務器在本地機器上存儲的小段文本并隨每一個請求發送至同一個服務器。Cookie最早在RFC2109中實現,后續RFC2965做了增強。網絡服務器用HTTP頭向客戶端發送cookies,在客戶終端,瀏覽器解析這些cookies并將它們保存為一個本地文件,它會自動將同一服務器的任何請求縛上這些cookies。Session并沒有在HTTP的協議中定義;
3)Session是針對每一個用戶的,變量的值保存在服務器上,用一個sessionID來區分是哪個用戶session變量,這個值是通過用戶的瀏覽器在訪問的時候返回給服務器,當客戶禁用cookie時,這個值也可能設置為由get來返回給服務器;
4)就安全性來說:當你訪問一個使用session 的站點,同時在自己機子上建立一個cookie,建議在服務器端的SESSION機制更安全些.因為它不會任意讀取客戶存儲的信息。
Session機制是一種服務器端的機制,服務器使用一種類似于散列表的結構(也可能就是使用散列表)來保存信息。
當程序需要為某個客戶端的請求創建一個session的時候,服務器首先檢查這個客戶端的請求里是否已包含了一個session標識 - 稱為 session id,如果已包含一個session id則說明以前已經為此客戶端創建過session,服務器就按照session id把這個 session檢索出來使用(如果檢索不到,可能會新建一個),如果客戶端請求不包含session id,則為此客戶端創建一個session并且生成一個與此session相關聯的session id,session id的值應該是一個既不會重復,又不容易被找到規律以仿造的字符串,這個 session id將被在本次響應中返回給客戶端保存。
服務器給每個Session分配一個唯一的JSESSIONID,并通過Cookie發送給客戶端。
當客戶端發起新的請求的時候,將在Cookie頭中攜帶這個JSESSIONID。這樣服務器能夠找到這個客戶端對應的Session。
流程如下圖所示:
URL回寫是指服務器在發送給瀏覽器頁面的所有鏈接中都攜帶JSESSIONID的參數,這樣客戶端點擊任何一個鏈接都會把JSESSIONID帶會服務器。
如果直接在瀏覽器輸入服務端資源的url來請求該資源,那么Session是匹配不到的。
Tomcat對Session的實現,是一開始同時使用Cookie和URL回寫機制,如果發現客戶端支持Cookie,就繼續使用Cookie,停止使用URL回寫。如果發現Cookie被禁用,就一直使用URL回寫。jsp開發處理到Session的時候,對頁面中的鏈接記得使用response.encodeURL() 。
1)Session超時:Session在指定時間內失效,例如30分鐘,若在30分鐘內沒有操作,則Session會失效,例如在web.xml中進行了如下設置:
<session-config>
<session-timeout>30</session-timeout> //單位:分鐘
</session-config>
2)使用session.invalidate()明確的去掉Session。
1)Cookie:客戶端將服務器設置的Cookie返回到服務器;
2)Set-Cookie:服務器向客戶端設置Cookie;
3)Cookie2 (RFC2965)):客戶端指示服務器支持Cookie的版本;
4)Set-Cookie2 (RFC2965):服務器向客戶端設置Cookie。
服務器在響應消息中用Set-Cookie頭將Cookie的內容回送給客戶端,客戶端在新的請求中將相同的內容攜帶在Cookie頭中發送給服務器。從而實現會話的保持。
流程如下圖所示:
WEB緩存(cache)位于Web服務器和客戶端之間。
緩存會根據請求保存輸出內容的副本,例如html頁面,圖片,文件,當下一個請求來到的時候:如果是相同的URL,緩存直接使用副本響應訪問請求,而不是向源服務器再次發送請求。
HTTP協議定義了相關的消息頭來使WEB緩存盡可能好的工作。
q 減少相應延遲:因為請求從緩存服務器(離客戶端更近)而不是源服務器被相應,這個過程耗時更少,讓web服務器看上去相應更快。
q 減少網絡帶寬消耗:當副本被重用時會減低客戶端的帶寬消耗;客戶可以節省帶寬費用,控制帶寬的需求的增長并更易于管理。
q Expires:指示響應內容過期的時間,格林威治時間GMT
q Cache-Control:更細致的控制緩存的內容
q Last-Modified:響應中資源最后一次修改的時間
q ETag:響應中資源的校驗值,在服務器上某個時段是唯一標識的。
q Date:服務器的時間
q If-Modified-Since:客戶端存取的該資源最后一次修改的時間,同Last-Modified。
q If-None-Match:客戶端存取的該資源的檢驗值,同ETag。
服務器收到請求時,會在200OK中回送該資源的Last-Modified和ETag頭,客戶端將該資源保存在cache中,并記錄這兩個屬性。當客戶端需要發送相同的請求時,會在請求中攜帶If-Modified-Since和If-None-Match兩個頭。兩個頭的值分別是響應中Last-Modified和ETag頭的值。服務器通過這兩個頭判斷本地資源未發生變化,客戶端不需要重新下載,返回304響應。常見流程如下圖所示:
HTTP/1.1中緩存的目的是為了在很多情況下減少發送請求,同時在許多情況下可以不需要發送完整響應。前者減少了網絡回路的數量;HTTP利用一個“過期(expiration)”機制來為此目的。后者減少了網絡應用的帶寬;HTTP用“驗證(validation)”機制來為此目的。
HTTP定義了3種緩存機制:
1)Freshness:允許一個回應消息可以在源服務器不被重新檢查,并且可以由服務器和客戶端來控制。例如,Expires回應頭給了一個文檔不可用的時間。Cache-Control中的max-age標識指明了緩存的最長時間;
2)Validation:用來檢查以一個緩存的回應是否仍然可用。例如,如果一個回應有一個Last-Modified回應頭,緩存能夠使用If-Modified-Since來判斷是否已改變,以便判斷根據情況發送請求;
3)Invalidation: 在另一個請求通過緩存的時候,常常有一個副作用。例如,如果一個URL關聯到一個緩存回應,但是其后跟著POST、PUT和DELETE的請求的話,緩存就會過期。
q HTTP協議的GET方法,支持只請求某個資源的某一部分;
q 206 Partial Content 部分內容響應;
q Range 請求的資源范圍;
q Content-Range 響應的資源范圍;
q 在連接斷開重連時,客戶端只請求該資源未下載的部分,而不是重新請求整個資源,來實現斷點續傳。
分塊請求資源實例:
Eg1:Range: bytes=306302- :請求這個資源從306302個字節到末尾的部分;
Eg2:Content-Range: bytes 306302-604047/604048:響應中指示攜帶的是該資源的第306302-604047的字節,該資源共604048個字節;
客戶端通過并發的請求相同資源的不同片段,來實現對某個資源的并發分塊下載。從而達到快速下載的目的。目前流行的FlashGet和迅雷基本都是這個原理。
多線程下載的原理:
q 下載工具開啟多個發出HTTP請求的線程;
q 每個http請求只請求資源文件的一部分:Content-Range: bytes 20000-40000/47000;
q 合并每個線程下載的文件。
HTTPS(全稱:Hypertext Transfer Protocol over Secure Socket Layer),是以安全為目標的HTTP通道,簡單講是HTTP的安全版。即HTTP下加入SSL層,HTTPS的安全基礎是SSL,因此加密的詳細內容請看SSL。
見下圖:
https所用的端口號是443。
有兩種基本的加解密算法類型:
1)對稱加密:密鑰只有一個,加密解密為同一個密碼,且加解密速度快,典型的對稱加密算法有DES、AES等;
2)非對稱加密:密鑰成對出現(且根據公鑰無法推知私鑰,根據私鑰也無法推知公鑰),加密解密使用不同密鑰(公鑰加密需要私鑰解密,私鑰加密需要公鑰解密),相對對稱加密速度較慢,典型的非對稱加密算法有RSA、DSA等。
下面看一下https的通信過程:
https通信的優點:
1)客戶端產生的密鑰只有客戶端和服務器端能得到;
2)加密的數據只有客戶端和服務器端才能得到明文;
3)客戶端到服務端的通信是安全的。
代理服務器英文全稱是Proxy Server,其功能就是代理網絡用戶去取得網絡信息。形象的說:它是網絡信息的中轉站。
代理服務器是介于瀏覽器和Web服務器之間的一臺服務器,有了它之后,瀏覽器不是直接到Web服務器去取回網頁而是向代理服務器發出請求,Request信號會先送到代理服務器,由代理服務器來取回瀏覽器所需要的信息并傳送給你的瀏覽器。
而且,大部分代理服務器都具有緩沖的功能,就好象一個大的Cache,它有很大的存儲空間,它不斷將新取得數據儲存到它本機的存儲器上,如果瀏覽器所請求的數據在它本機的存儲器上已經存在而且是最新的,那么它就不重新從Web服務器取數據,而直接將存儲器上的數據傳送給用戶的瀏覽器,這樣就能顯著提高瀏覽速度和效率。
更重要的是:Proxy Server(代理服務器)是Internet鏈路級網關所提供的一種重要的安全功能,它的工作主要在開放系統互聯(OSI)模型的對話層。
主要功能如下:
1)突破自身IP訪問限制,訪問國外站點。如:教育網、169網等網絡用戶可以通過代理訪問國外網站;
2)訪問一些單位或團體內部資源,如某大學FTP(前提是該代理地址在該資源的允許訪問范圍之內),使用教育網內地址段免費代理服務器,就可以用于對教育 網開放的各類FTP下載上傳,以及各類資料查詢共享等服務;
3)突破中國電信的IP封鎖:中國電信用戶有很多網站是被限制訪問的,這種限制是人為的,不同Serve對地址的封鎖是不同的。所以不能訪問時可以換一個國 外的代理服務器試試;
4)提高訪問速度:通常代理服務器都設置一個較大的硬盤緩沖區,當有外界的信息通過時,同時也將其保存到緩沖區中,當其他用戶再訪問相同的信息時, 則直接由緩沖區中取出信息,傳給用戶,以提高訪問速度;
5)隱藏真實IP:上網者也可以通過這種方法隱藏自己的IP,免受攻擊。
http代理的圖示見下圖:
對于客戶端瀏覽器而言,http代理服務器相當于服務器。
而對于Web服務器而言,http代理服務器又擔當了客戶端的角色。
虛擬主機:是在網絡服務器上劃分出一定的磁盤空間供用戶放置站點、應用組件等,提供必要的站點功能與數據存放、傳輸功能。
所謂虛擬主機,也叫“網站空間”就是把一臺運行在互聯網上的服務器劃分成多個“虛擬”的服務器,每一個虛擬主機都具有獨立的域名和完整的Internet服務器(支持WWW、FTP、E-mail等)功能。一臺服務器上的不同虛擬主機是各自獨立的,并由用戶自行管理。但一臺服務器主機只能夠支持一定數量的虛擬主機,當超過這個數量時,用戶將會感到性能急劇下降。
虛擬主機是用同一個WEB服務器,為不同域名網站提供服務的技術。Apache、Tomcat等均可通過配置實現這個功能。
相關的HTTP消息頭:Host。
例如:Host: www.baidu.com
客戶端發送HTTP請求的時候,會攜帶Host頭,Host頭記錄的是客戶端輸入的域名。這樣服務器可以根據Host頭確認客戶要訪問的是哪一個域名。
《理解Cookie和Session機制》:
http://sumongh.javaeye.com/blog/82498
《淺析HTTP協議》:
《http代理_百度百科》:
http://baike.baidu.com/view/1159398.htm
《虛擬主機_百度百科》:
http://baike.baidu.com/view/7383.htm
《https_百度百科》:http://baike.baidu.com/view/14121.htm
Blowing up HTML5 video and mapping it into 3D space(將HTML5視頻吹散并組成3D效果)最近我研究了HTML 5中的Canvas 和Video 標簽,并發現了一些很酷的特性。其中之一就是Canvas.drawImage() api。此為詳細介紹。
Code a Backwards Compatible, One Page Portfolio with HTML5 and CSS3(用HTML5 和CSS3 打造向下兼容的網頁)HTML5更加語義化,使用HTML5 我們不必在網頁上布滿沒有意義的div。它引入了有意義的tag,比如 navigations 和 footers 使代碼更有意義也更接近自然語言。
Coding A HTML 5 Layout From Scratch(HTML 5 布局)
這篇文章將教你
Coding a CSS3 and HTML5 One Page Website Template(制作CSS3和 HTML5 一頁式站點模板)這篇文章介紹了如何利用CSS3 和jQuery的新特性制作HTML5 網頁模版。 HTML5 仍在完善當中,你也可以選擇性的下載XHTML版。
Comprehensive video tutorial on HTML5(全面的HTML5視頻指南)這 是一個叫Brad Neuberg的工程師制作的HTML5教學視頻。
Create modern Web sites using HTML5 and CSS3(用HTML5與CSS3打造時尚站點)這篇文章介紹了許多HTML5的功能和語法及API,還有CSS3的新的選擇器,效果和特性。最 后, 還將教你如何利用這些新特性開發一個網頁。當你讀完這篇文章,你就能用HTML5和CSS3開發一個自己的站點啦。
Designing a blog with html5(用html5設計博客)許多HTML5 特性要結合JavaScript API一起使用,以增加網頁的互動性。但仍有一些新元素可讓傳統的Web1.0頁面更加語義化。為了學習這些,我們來看怎樣建立一個博客。
Designing for the Future with HTML5 and CSS3 : Tutorials and Best Practices(為未來設計:HTML 5 和 CSS3 指南與最佳案例)這篇文章將介紹用 HTML5和CSS3搭建的幾個最佳站點。
Design and Code a Cool iPhone App Website in HTML5(用HTML5設計和實現一個超酷 iPhone App 網站)
Have a Field Day with HTML5 Forms(建立HTML 5表格)這篇文站將教你 如果用HTML 5 和高級CSS技術與最新的CSS3技術建立一個漂亮的表格。
How To Create A Nice Blog Design Touching The Future(不用photoshop,完成網頁設計)
How to Make All Browsers Render HTML5 Mark-up Correctly – Even IE6(怎樣讓所有瀏覽器都渲染HTML5標記——即使是IE6)這篇文章將教你如何用JavaScript和CSS,使 HTML5頁面向下兼容,即使是IE6也不例外。
How to Make an HTML5 iPhone App(制作HTML5 iPhone 應用)這是 一篇針對iPhone的指導,但是許多技術也可用在兼容HTML5的手機瀏覽器上。
HTML 5 and CSS 3: The Techniques You’ll Soon Be Using(HTML 5 和CSS 3:你將用到的技術)這篇文章使用HTML 5和CSS 3 搭建博客頁面。如果你已經熟悉html 和CSS,將很容易跟上。
HTML5 for Beginners. Use it now, its easy!(HTML 5初學指南)給 所有具有基礎HTML知識的初學者的HTML 5 入門指南
HTML5 Presentation這篇文章介紹了HTML5 的發展歷史和它的基本特性
HTML5 Tutorial – Getting Started(HTML 5 入門指導)
How to Build Web Pages With HTML 5(怎樣建立HTML 5網頁)
Simple Website Layout Tutorial Using HTML 5 and CSS 3(HTML5和CSS3布局指南)HTML5最令人期待的新標簽包括<header>, <footer>, <aside>, <nav>, <audio>,同時它還包括畫圖,線下存儲數據,拖放等API。頁面布局將會更易理解。這里將介紹一個最簡單的HTML 5 布局頁面,用CSS3 設置樣式。最終結果如下
Structural Tags in HTML5(HTML 5 結構標簽)HTML5 有許多標簽幫助網頁結構化,這能省去以網頁中許多div
HTML5 Boilerplates(HTML 5模板)此文介紹了一些你能拿來就用的HTML5 模板文件
HTML 5 canvas – the basics(HTML 5 基礎——Canvas)對HTML 5 Canvas使用方法的全面指導
HTML 5 Tutorials(HTML 5 指南)
Implementing HTML5 Drag and Drop: New Premium Tutorial(HTML 5 拖放)HTML5 的一個新特性就是拖放,不過IE早在5.5時代就支持拖放了,而HTML 5 的拖放也是基于IE的。本例將教你如果用拖放實現一個簡單的購物車界面。
Preview of HTML 5這是一篇比較老的文章,介紹了HTML5的特性和優點。
The HTML 5 Canvas For Flash Developers : Drawing(HTML 5 Canvas 的畫圖功能)
The Power of HTML 5 and CSS 3介紹了HTML 5 與CSS3能創造的各種效果。
View Source Tutorial: Sticky Notes With HTML5 and CSS3(HTML5 和CSS3 打造便利貼效果)
webOS HTML5 Database Storage Tutorial(webOS HTML5 數據存儲指南)HTML5 的本地存儲功能將使數據存儲十分簡便。
Yes, You Can Use HTML 5 Today!本文介紹了一些現已被支持的HTML 5 特性,對初學者十分有用。
文章來源:NTT.cc
翻譯:lovelyashes
誰需要HTML5?
Google最需要!Apple的Jobs也需要。但這兩個肯定各懷鬼胎。微軟無所謂了,反正他還有Silverlight。
Mozilla/Firefox非盈利組織,目標可能會高尚些,是w3c標準就要支持。Opera那點瀏覽器市場占有率估計還沒敢有太多想法。
Google的云計算帝國就差一個支持 RIA(Rich Internet Applications)富互聯網應用的客戶端了,試想HTML5得到普及,更多的應用轉向BS模式時,微軟帝國的桌面軟件生態環境必定受到很大威脅, 垂涎多年的Google一定是最大受益者。當在一臺操作系統免費的電腦上使用和MS Word差不多功能的免費Google Doc時,你還會掏錢買微軟的Word嗎?當你所有的辦公應用都只需要打開瀏覽器窗口時,你還會花錢買操作系統嗎?Google的Chrome OS操作系統界面已經說明了這個意圖。
Jobs也需要HTML5,他是打著小算盤,想讓瀏覽器原生支持視頻音頻,這樣iPhone、 iPad就不用嵌入Flash,Jobs當然不能讓Flash進iPhone OS,要不然App Store里的游戲誰去買?同時,如果大量的應用都能基于瀏覽器實現時,用戶就不會被Windows的桌面應用套牢了。漂亮的Mac電腦誰不喜歡。
他們選擇 HTML5都是為了更大野心,期望HTML5帶來整個軟件生態環境的改變,同時避開不受自己控制的Flash。
Macromedia和后來的當家Adobe把握住了互聯網應用的發展需求,不斷的完善的Flash,使之已經超越了瀏覽器本身的功能。各大瀏覽器廠商也 看到這種應用的需求,不甘于一個本該瀏覽器實現的功能,由一個幾兆大小的 Plugin實現了,并玩的風生水起。于是不遺余力的推進HTML5,并且矛頭直指Flash。
用戶想要HTML5嗎?用戶要的不是技 術,是應用,是體驗。如果你能拿Ajax實現一個開心農場,我想沒誰會在乎它是不是Flash做的。
開發者想要 HTML5嗎?那需要一個成熟的HTML5+CSS3+JS的開發環境,需要各個瀏覽器提供統一的用戶體驗,即標準的完全兼容。還需要增加新的學習成本。
Flash 的優勢?
Flash比HTML5強在哪?性能,功能?如果說HTML5將擁有和Flash所有內置對象類 似的DOM 呢,還有GPU的2D、3D加速呢?這不是沒可能,畢竟HTML5還只是草案。當然Flash也能不停的更新。
開發群體
我認為Flash的優勢是在開發人員上,十多年的積累,有眾多優秀的藝術家、程序員和互動設計師集中在Flash平臺上做互動媒體開發。也使無數的類庫 有了AS版,如FLARToolKit,Touchlib,OpenCV這些互動、圖像分析的c++庫都移植到了Flash平臺。在RIA應用上有相對成 熟且開源的Flex框架,越來越多的企業在嘗試使用Flex替代Ext等 Ajax框架,為客戶提供更好RIA應用體驗。
持續發展
FlashPlayer 是一個封閉的系統,是由Adoeb獨家控制,相對于開放的HTML5標準這是弱勢,也是技術上的優勢,它可以很靈活,可以隨時加入新技術,新功能。而 HTML5是一個公開標準,既然是標準就意味著不會經常改動。Flash的改進升級只需要用戶升級FlashPlayer插件,插件的升級相對用戶來說, 是輕量級的。HTML標準的改進意味著升級瀏覽器,這是相對重量級的用戶操作,尤其是還有很多人不明白什么是瀏覽器。
HTML5開放標 準一旦確定下來,就會有一個很長的使用周期,今天看是足夠先進的功能,十年后呢。就像當年我們用著HTML4+CSS2+JS沾沾自喜以為足夠表現Web 應用時,誰能想到今天Flash不斷改進所開拓的天地呢。或許十年后我們又該討論HTML6秒殺Flash的話題了。
超越web應用
如果當年SUN能重視Java Applet,或許就沒有Flash的今天,SUN也不會淪落到被收購的境地。而如今Adobe AIR更是讓Flash超越Java Applet,讓Flash超越了web,脫離了瀏覽器。Flash到如今功能不斷增強,在多媒體領域也在不斷地壓縮自家老大哥Director的應用空 間。多點觸摸、人臉識別、Socket通訊同步、AR增強現實、實時視頻等等功能在Flash平臺上的實現,讓越來越多的互動多媒體項目采用Flash方 案。
希望Adobe繼續能擴展Adobe AIR平臺的功能,提高性能。能有越來越多的跨平臺桌面應用在AIR上實現。
Flash 的劣勢?
FlashPlayer版權私有。
swf文件的內容相對封閉,搜索引擎不友 好。
插件的安全隱患。
相對與Ajax技術的學習曲線及學習成本。
FlashPlayer 94%裝機率!=100%。
iPhoneOS明確不支持Flash,而iPad首日12萬的訂單,預計將會開啟一個大市場。
不支持3D硬件加速。FlashPlayer如果支持3D硬件加速,必將重寫現有的2D矢量引擎,鑒于ShockWave 3D的表現,FlashPlayer 硬件3D,很難有很好的用戶體驗。
HTML5拿什么取代Flash
功能:HTML5目前還只是草案,從已提交的內容來看,增加了許多更具語義的標簽,新的標簽意味著在DOM中增加新的類,如果把瀏覽器比做一個大的 Flashplayer,HTML5無非就是在增加新的類,新的API。然后由JavaScript來調用這些API。如果HTML5要完全取代 Flash,至少要提供和Flashplayer10相似的功能。這應該不是問題,添加WebSocket 、WebSQL、WebGL……甚至WebQt、WebMFC都是可以無盡暢想的。或者干脆把瀏覽器就做成一個大虛擬機,完成Java的桌面遺愿。如果有 足夠的需求動力,這些都不是問題。
性能:在很多 HTML5激進派的文章里,都痛指目前Flash的效率低下,導致瀏覽崩潰。真的是Flash效率低到如此不堪嗎?肯定不是,只是Flash的濫用和參差 不齊的Web前端開發人員造成的。同樣如果用IE的JS引擎寫一個Ajax版的XX農場,如果所有頁面廣告動畫都用JS來寫,我想那才叫效率低下。如果真 的Flash效率低,為什么那么多網頁游戲都不是Ajax做的呢?為什么很多優化的很好的Flash3D游戲場景都很流暢,而一個2D的XX農場就能拖慢 你的酷睿2呢?不明真相的半吊子開發人員總是把瀏覽器不響應和崩潰歸結于Flash效率低下。所以未來HTML5要取代Flash 必須有一個高效的2D/3D圖形文字渲染引擎,和一個高效的JavaScript引擎。這樣才能帶來更好的用戶體驗。這些,眾瀏覽器廠商都準備好了 嗎?Chrome和Opera似乎正在走這條路。
兼容性:HTML4標準已經十多年了,今天我們還會寫下fxckIE6的CSS樣式 名。瀏覽器的兼容性會是最大的問題,尤其是加入n多特性后的HTML5和CSS3。IE,Firefox,Chrome,Safari這些瀏覽器背后的大 佬們,怎么去協調呢?這有個矛盾,開發差異化的產品,卻要提供同質化的功能。JS性能、標簽瀏覽,同步收藏,插件這些提高用戶體驗的功能,都是這些差異化 的方向。如果再出現類似ActiveX這類IE only的東西,那還不如維持HTML4這種方式不變。
開發模式:Flash IDE將無數優秀的藝術家、UI設計師和互動程序設計師團結在一起,最終成就了Flash,這也與Macromedia和Adobe在圖形設計和互動設計 群體中的號召力不無關系。HTML5的互動會將JavaScript提高到一個新的高度,這必將需要一個成熟的開發環境。繼續DW+Firebug?或者 DW升級為全新的HTML5互動開發IDE,或者微軟VS來干這件事,或者是Eclipse?成熟的開發環境才能聚攏人才,才能激發無窮的創造力,帶來更 多的內容。豐富的內容自然帶來更多用戶。
部署:這是最重要的一個問題,沒有這一步,一切都是零。Flash新版本怎么部署?在90%多 桌面占有率的基礎上更新插件就OK。HTML5怎么部署,更新瀏覽器,這個有點難,看看頑強的IE6。聽到有人建議微軟在系統 ServerPack里包含IE更新,只能說這想法很好,但是反壟斷的大錘一定會把微軟砸死。那怎么引導用戶去升級瀏覽器呢?對于互聯網“Core User”來說不是問題,目前支持HTML5和CSS3部分特性的Chrome開發版,很多人都在用了。但是那些“Light User”呢,可能連天天看網頁用的這個窗口跟瀏覽器是什么關系都不明白。這需要一個HTML5的殺手級應用去引導,“Light User”幾乎不會以技術為導向去升級瀏覽器的,他們只會以應用需求為導向去升級。比如YouTube不再支持IE6用戶,這樣喜歡YouTube視頻的 用戶會去升級IE6再來訪問。用戶不會是因為IE6的HTML標準兼容差而選擇更新IE6,這是必然的。那HTML5的殺手級應用在哪里呢?或者說都有 Youtube這樣的影響力和號召力嗎?而沒有這種號召力的網站,誰會貿然率先支持HTML5來要求用戶升級瀏覽器嗎?這些網站之間必定會陷入囚徒困境 中,在重復的囚徒困境中,博弈被反復地進行。最終才會全面進入 HTML5時代。這個過程或者很短,也可能很長。畢竟現存的Web前端還沒到不堪的地步,反倒是由于Flash這些插件和jQuery這些JS框架弄的有 聲有色。
總結
HTML5不是用戶應用的迫切需求,更多是廠商試圖改變軟件生態格局的戰略需求。
HTML5的兼容性鑒于各大瀏覽器的以往表現,有待觀望,不宜立即遷移應用。
HTML5需要一個成熟完整的開發環境,記事本+瀏覽器對付不 了。
HTML5功能的暴增,瀏覽器必須有一個高效的圖形引擎和腳本引擎。
HTML5需要殺手級應用來吸引和引導用戶升級瀏覽器, 最終完成HTML5終端的部署。
Flash是一個不斷在發展的技術,有很強的靈活性,HTML5不可能完全取代Flash,眾多的開發人員也 不會斷然拋棄Flash。
希望Adobe AIR能有更好發展,使Flash能超越瀏覽器Web應用,跨越操作系統,有更好發展,更多應用。
文/IT168
HTML5 主要新功能
從IETF到W3C:HTML4之路
HTML1并不曾存在,HTML的第一個官方版本就是由IETF(互聯網工程任務組)推出的HTML2.0。問世之前,這個版本中的很多細則已經被 實現,比如,1994年的Mosaic瀏覽器已經實現了在文檔中嵌入圖片的方法,后來HTML2.0便吸納了img這個標簽。
后來,W3C取代IETF的角色,成為HTML的標準組織,1990年代的后半頁,HTML的版本被頻繁修改,直到1999年的HTML4.01, 至此,HTML到達了它的第一個拐點。
XHTML1:XML風格的HTML
HTML在HTML4.01之后的第一個修訂版本就是XHTML1.0,其中X代表“eXtensible”,擴展,當然也有人將之解讀為 “eXtreme”,極端。XHTML1.0是基于HTML4.01的,并沒有引入任何新標簽或屬性,唯一的區別是語法,HTML對語法比較隨便,而 XHTML則要求XML般的嚴格語法。
使用嚴格的語法規范并非壞事,要求開發者使用單一的代碼風格,比如,HTML4.01允許你使用大寫或小寫字母標識標記元素和屬性,XHTML則只 允許小寫字母。XHTML1.0的推出剛好碰上了CSS的崛起,Web開發設計者們開始意識到Web標準問題,基于XHTML的嚴格語法規范被視為編寫 HTML代碼的最佳實踐。
W3C推出XHTML1.1
如果說XHTML1.0是XML風格的HTML,XHTML1.1則是貨真價實的XML。這意味著XHTML1.1無法使用 text/htmlmime-type直接輸出,然而,如果Web開發者使用XMLmime-type,則當時的主流瀏覽器,IE則壓根不支持。看上 去,W3C似乎正在與當時的Web脫節。
出力不討好的XHTML2
對W3C而言,到了HTML4已經是功德圓滿,他們的下一步工作是XHTML2,希望將Web帶向XML的光明未來。雖然XHTML2聽上去和 XHTML1類似,它們卻有很多差別,XHTML2不向前兼容,甚至不兼容之前的HTML。它是一種全新的語言,赤條條來去無牽掛。這實在是一場災難。
WHATWG:與W3C決裂
W3C閉門造車的作風引起了一些人的不滿,來自Opera,Apple,以及Mozilla的代表開始表達反對聲音。2004年,Opera的 Ian Hickson提議在HTML基礎上進行擴展以適應新的Web應用,該提議遭到W3C的拒絕。于是,他們自發組織成立了超文本應用技術工作組,就是 WHATWG。
從WebApps1.0到HTML5
從一開始,WHATWG就和W3C走不同的路線,W3C對問題的討論是集體投票,而WHATWG則由主筆IanHickson定度。表面上 看,W3C更民主,然而事實上,各種內部紛爭會使一些決議限于泥潭,在WHATWG,事情的進展會更容易,不過,主筆的權力并非無限大,他們的委員會可以 對那些過于偏執的主筆進行彈劾。
一開始,WHATWG的主要工作包括兩部分,Web Forms 2.0和Web Apps 1.0,它們都是HTML的擴展,后來,他們合并到一起成為現在的HTML5規范。
在WHATWG致力于HTML5的同時,W3C繼續他們的XHTML2.0,然而,他們慢慢地陷入困境。
2006年10月,Web之父Tim Berners-Lee發表了一篇博客文章,表示,從HTML走向XML的路是行不通的,幾個月后,W3C組建了一個新的HTML工作組,他們非常明智地 選擇了WHATWG的成果作為基礎。這一轉變帶來一些困惑,W3C同時進行這兩套規范,XHTML2和HTML5(注意,W3C的HTTML5在5之前有 個空格,而WHATWG的HTML5則沒有空格),而WHATWG也在進行著同樣的工作。
XHTML已死:XHTML語法永存
這一混亂局面到了2009年開始變得清晰,W3C宣布終止XHTML2的工作,這是一份關于XHTML2的遲到的訃告。這一消息被那些XML的反對 者視為珍寶,他們借此嘲笑那些使用XHTML1規范的人,然而他們似乎忘記了,XHTML1和XHTML2是截然不同的東西。于此同時,XHTML1規范 的制定者擔心,XHTML1中的嚴格語法規范會被HTML5棄用,這種擔心后來證明是多余的,HTML5既支持松散語法,也支持XHTML1般的嚴格語 法。
HTML5路線圖
HTML5的現狀是,它不再象以前那樣讓人困惑,然而仍不夠明朗。有兩個組織在同時制定它的規范,這兩個組織有著完全不同的行事風格,WHATWG 是先買后嘗,W3C是先嘗后買,他們形成了一個不太靠譜的聯姻,最終人們必將面臨一個HTML5還是HTML5的問題。
更讓開發者困惑的是,他們什么時候才可以試水HTML5。
在一次訪談中,Ian Hickson提到了2022,表示要到那時HTML5才會形成"推薦標準",此話一出,立刻招來Web設計者們的憤怒,盡管他們不知道推薦標準時什么意 思,但他們明白,2022已經是猴年馬月的事了。
這還不算,更重要的是,這個推薦標準涉及兩套規范,考慮到HTML5標準的規模,這個日期還是太樂觀了,畢竟,各大瀏覽器以往對既有標準的兼容并不 遂人意,想當初,IE花了10年才接納abbr這個標簽。
2012年,HTML5會被接納為候選標準,這將是HTML5真正開始發力的日子。對Web開發設計者來說,這并不重要,重要的是瀏覽器的支持,就 像CSS2.1,當有瀏覽器開始支持這一規范的時候,就有開發設計者在使用了,倘若必須等到所有瀏覽器都支持才開始入手,恐怕我們現在還在等待中。
HTML5也一樣,并不會有一個時間點,宣布HTML5已經準備妥當,相反,我們會先開始使用它的部分功能,HTML5并不是一個從零開始全新的東 西,它是舊的HTML標準的改進,事實上,不管你正在使用的HTML是哪個版本,你已經在使用HTML5了。
文/IT168