Q：
Cookie與中文亂碼的問題？
A：
中文字的編碼與Cookie預設的編碼方式不同，因此必須先行在URL傳輸過程中經過一道編碼、解碼的程序，才不會發生中文字在Cookie中讀取出來為亂碼的情況。
編碼
HttpCookie cookie_name = new HttpCookie("name");
cookie_name.Value = HttpUtility.UrlEncode(txtUsername.Text);
Response.AppendCookie(cookie_name);
解碼
String Username = HttpUtility.UrlDecode(Request.Cookies["name"].Value.ToString());
Q：
讓firefox支援text-overflow: ellipsis
A：
萬萬沒想到ie有一個css的屬性text-overflow，設定後可以讓文字產下截字效果，超出的文字用省略符號(…)來代替；而更萬萬沒想到firefox居然完全不支援此一屬性…
https://bugzilla.mozilla.org/show_bug.cgi?id=312156
網路上有人分享了很多解決方案，不過以這篇
溢出文本顯示省略號,關於text-overflow:ellipsis的那些事 - Leeiio Chaos Made.
http://leeiio.me/text-overflow-ellipsis/
的第二種方法利用jQuery完美地解決這個問題，不過奇怪的是，請注意必須將有應用到解決方案的網頁跟這個.js和.css(包括jquery-1.4.2.js)等檔案都放在同一個資料夾才會有作用!!
http://plugins.jquery.com/project/textOverflow
Q：
在GridView控制項中以DropDownList分頁
A：
參考http://www.dotblogs.com.tw/poto/archive/2009/01/14/6798.aspx
然後在後製程式碼中加入…
protected void Page_Load(object sender, EventArgs e)
{
if (!Page.IsPostBack)
{
GridView1.DataBind(); //為了自訂分頁數字按鈕的繫結
}
}
Q：
ASP.NET如何用Button打開新視窗?
A：
可以參考這個網址的程式寫法：http://yukisan.pixnet.net/blog/post/26796800
或者也可以使用ASP.NET AJAX Control Toolkit ModalPopup，這就像是以前JavaScript用的showModalDialog。
不過如果有參數要傳值到後置程式碼(Code Behide)的話，這個方法就不行了，必須還是使用傳統的方法!!
參考範例：
.aspx
.cs
閱讀全文...
根據WIKI，Android是基於Linux核心的軟體平台，是Google在2007年11月5日公佈的行動電話系統平台，早期由Google開發，後由開放手機聯盟（Open Handset Alliance）開發，這個組織是Google和其他幾十個手機公司為了推廣此技術所成立的。它採用了軟體堆疊（software stack）的架構，主要分為三部分：
- 低層以Linux核心為基礎，只提供基本功能。
- 其他的應用軟體則由各公司自行開發。
- 以Java作為編寫程式的一部分。
Android應用程式是用JAVA程式語言來編寫，並且運作在一個虛擬機器(VM)中，其中VM不等於JVM，而是Dalvik Virtual Machine。除此之外，還包括Android SDK、APT(Android Development Tools)、Eclipse IDE和JDK。因此要開發Android應用程式，最好是在Linux環境之下，尤其是Ubuntu，當然如果要在Windows環境下開發也可以。
如果要移植Android至Embedded System的產品開發，就必須理解Android系統內部的函式庫、Android執行環境與Linux核心的細節。而就最重要的是開發者不用花費到一毛錢，便可以建構一個很完整且便利的Android應用程式開發環境，並 發展屬於自己的應用程式
Android內建的網頁瀏覽器(Web Browser)的名稱叫做Google Chrome Lite，與iOS當中內建的Safari網頁瀏覽器一樣是採用Webkit網頁引擎(Web browser engine)。Webkit是目前最多知名智慧型手機作業系統採用的網頁引擎。這些作業系統包括了Symbian OS、iOS、Palm webOD與Android等。
Webkit可以讓正常網頁(非手機版本)自動調整成頁寬(auto fit page)的方式完整縮小呈現在手機的小螢幕中，如此可以方便使用者立即在手機上看到正常網頁的全觀，如果要近看某區塊之內容時，只要將該區塊放大即可。
另外Android內建了SQLite的關聯式資料庫引擎(Relational database engine)式的設定資料或者上一次遊戲關卡的資料等。在應用程式當中，如果使用了SQLite，則手機用戶可將相關資料儲存在手機儲存設備中，無需再以網路連線方式存取遠端的資料庫。
Android在未公開之前大多傳聞認為Google開發的是自己的手機電話產品，而不是一套軟體平台。到了2010年1月，Google開始發表自家品牌手機電話的Nexus One。
對於使用者而言，只要先申請一個免費的Google帳戶，當想換一台手機時，就可以在不同廠牌，同樣使用Android作業系統平台的手機之間選擇，簡單地將如聯絡簿等個人資料轉換到新手機上。
Android Market是一個由Google為Android所創建的線上應用程式服務，允許用戶瀏覽和下載一些由第三方開發商為Android開發的應用程式。用戶可以購買或免費試用，讓該應用程式直接下載到Android的手機中。上傳應用程式到Android Market需要20元美金的帳號註冊費，而下載付費軟體需1元美金。
目前應用程式的數量已經突破10萬組以上，不過整體僅為蘋果App Store約1/3的比例，而且Google線上評審似乎顯得「寬鬆」許多，也因此不少應用程式的品質參差不齊，甚至還有人刻意透過撰寫 Android應用程式竊取使用者個人資訊。不過隨著目前Android平台市占率逐漸提昇，數量和品質是後勢看漲！
閱讀全文...
Spring最初是Rod Johnson在2002年由其著作Expert One-on-One: J2EE Design and Development中提出的，另外一本書Expert One-on-One J2EE Development without EJB更進一步闡述了在不使用EJB（Enterprise JavaBean）開發J2EE企業級應用的一些設計思想和具體的作法（題外話：EJB是sun的伺服器端元件Model，最大的用處是部署分散式應用程式，類似微軟的.com技術。Sun在2006年5月2日發布了JSR 220定義，也就是EJB3.0，企圖減輕EJB以往開發過於複雜以及不必要的負擔。參見-
伺服器端元件Model－EJB3.0(Enterprise JavaBean 3.0)論述）。
Spring在2004年初發佈1.0版本，到2006年10月3日發佈了2.0版本，基本上維持著每半年就會有一次大的更新，可到http://www.springsource.org/下載最新版本的Spring。
Spring是一個應用於J2EE領域的輕量應用程式框架，其核心是一個IoC（Inversion of Control）以及AOP（Aspect-oriented programming）。在核心上面的一個主要部份是資料存取DAO框架，包括一個自己的JDBC資料存取封裝以及對眾多ORM框架的工具集支持。Spring內置了一個功能強大、靈活的Web MVC框架Spring MVC框架，以提供快速的Java Web應用程式開發，在程式開發中，程式開發者可以直接使用Spring框架內建的Spring MVC框架。除此之外，對於現在比較流行的各種層面上的框架（如Hibernate、JSF、Struts等），Spring也提供了與它們相互整合的方案。
Spring框架系統架構如圖，從圖中看出Spring提供了很多J2EE應用的基礎設施及解決方案，便於開發J2EE應用。
其中Core是框架的最基礎部分，提供IoC（Inversion of Control，控制反轉）和DI（Dependency Injection，依賴注入）特性。所謂的控制反轉是指控制權由程式改到Spring Container（容器），控制權的移轉，是所謂的反轉；或可說是依賴注入，將原先程式間的耦合降到最低，改由Spring容器注入程式間的關連。使用IoC通常會使得程式碼非常清晰，更為重要的是，IoC可以使得程式碼之間、類別與類別之間有很好的解耦性。DI有三種形式：Setter-based、Constructor-based、Getter-based，Spring推薦使用第一種方式，Setter-based類似典型的JavaBean，帶有一個無參數的構造函數和setter方法。
BeanFactor代表了Spring的心臟，可以配置和管理幾乎所有的Java類別，在存取和操作IoC的初期充當了IoC容器的作用。然而在大多數的情況之下，不會直接使用BeanFactor而是使用ApplicationContext，因為ApplicationContext具有更多的企業級特性如多國語言支援、資源存取、事件傳播和多實例載入等等。
Bean在Spring容器中大致要經歷以下四個階段：Bean定義、初始化、準備狀態以及銷毀。
Spring的AOP是OOP（物件導向程式設計）的延續，提供了符合AOP Alliance規範的層面導向程式設計（Aspect-Oriented Programming）的具體實現，讓使用者可以定義，像方法攔截器（method-interceptors）和切入點（PointCuts），從軟體設計上看，通過這樣的方式可以降低耦合性（coupling），提高內聚性（cohesion），從而在軟體結構上得到改善。
DAO模式是一種資料存取物件模式，它通過抽象方法來提供資料存取的介面，這樣便消除了冗長乏味的JDBC編碼，並且通過這樣的封裝方式更容易為程式設計提供介面，而且對所有的POJO適用。
ORM封裝提供了物件關係對應的API介面，使用ORM工具集的產品除了提到過的Hibernate，還包括了如JDO等產品。
<未完 待補充更新>
閱讀全文...
Struts框架最早是作為Apache Jakarta專案的組成部分問世運作，專案的創立者希望通過對該專案的研究，改進和提高JAVA Server Pages、Servlet、標籤庫(tag library)以及物件導向的技術水準，它的目的是為了減少在運用MVC設計模型來開發Web應用的時間。
建立基於Struts框架的web應用程式最快捷的方式就是利用Struts框架發佈包中包含的struts-blank.war文件。該檔不僅定義了struts web應用程式的標準的目錄結構而且還包含了開發struts web應用程式所必需的包。
如果使用Eclipse IDE作為開發工具，並部署在應用伺服器Tomcat 5.0中執行，然後再import struts-blank.war進來。由於struts框架本身就是基於servlet，因此需要將tomcat目錄下common\lib中的servlet-api.jar拷到strutsSample\WebContent\WEB-INF\lib中。
在探討Struts MVC運作架構之前我們先來看看基本的MVC運作模式，如圖所示：
所有進入到系統中的Request都會導給一個Controller程式，由Controller來判斷目前這個Request必須交由哪一個程式處理(那一個Request必須交由哪一個程式處理可能是設定在另外一個地方)，接著便會呼叫執行該處理程式，並將收到的Request當作參數傳給該程式。在處理過程中需要進行商業邏輯處理的部分就會呼叫執行Model中的程式，Model處理完之後再將結果回傳給Controller，Controller再將結果傳給指定的View來進行畫面呈現。在這個架構中Controller是所有Request的唯一進入點，Model的部分只負責處理系統中的商業邏輯，畫面呈現則全部都由View來負責。
Struts的運作模式是採用MVC的架構，整個運作方式大致如圖所示。當Request進入到Struts時會導給一個ActionServlet來處理，這個程式會根據設定檔struts-config.xml中的設定呼叫執行我們所撰寫的Action處理程式，並將Request當作參數傳給這個Action處理。Action在處理過程中會呼叫一些商業邏輯物件(Business Objectc)中的程式存取後端的資料庫；當Action處理完之後會將結果回傳給ActionServlet，最後ActionServlet再將這個結果可以在struts-config.xml中設定一些JavaBean(ActionForm)來接收Request中的資料，此時Struts便會幫我們將資料塞到JavaBean中，讓我們可以在Action中直接取用，讓我們可以在Action中直接取用，在使用上會比較方便。
我們在使用Struts開發系統時，必須撰寫流程控制程式(Action)、商業邏輯處理程式(Business Object)、畫面呈現程式(JSP)並在設定檔(struts-config.xml)中設定這幾個元件之間的運作關係。當然，如果在流程控制與商業邏輯處理程式之間有使用到一些物件來當作資料傳遞的參數(DTO，Data Transfer Object)，那麼這些傳遞資料的物件也必須由我們自行撰寫。
閱讀全文...
Hibernate 是「物件/關係對應」（Object/Relational Mapping）的解決方案，簡寫為 ORM，簡單的說就是將 Java 中的物件與物件關係，映射至關聯式資料庫中的表格與表格之間的關係， Hibernate 提供了這個過程中自動對應轉換的方案。
2001 年未 Hibernate 第一個版本發表，2003年6月8日 Hibernate 2 發表，並於年未獲得 Jolt 2004 大獎，後被 JBOSS 收納而成為其子項目之一，2005年3月 Hibernate 3 正式發表，當中有了一些重大的改變，這份文件將以之前 Hibernate 2 時撰寫的文件為基礎，針對 Hibernate 3 作重新整理的動作，所使用的版本為 Hibernate 3.2。
在撰寫 Hibernate 程式的過程中，我們可以粗分四大步驟(1~4) 與二大檔案(5、6)，依序是 :
1. Configuration：
1.1. 透過 Configuration File (hibernate.cfg.xml) 設定與 Database 連線的方式與設定要匯入哪些 Mapping File。
1.2 (JavaEE 環境) 透過 JNDI Service 來註冊 org.hibernate.SessionFactory 成為 Global 物件。
1.3 (JavaEE 環境) 設定 AP Server 所提供的 Transaction 的功能。
1.4. 透過 org.hibernate.cfg.Configuration 的 configure() mathod 來讀取 Configuration File。
1.5 透過 org.hibernate.cfg.Configuration 的 buildSessionFactory() 來產生 下一步驟要用到的 org.hibernate.SessionFactory 。
2. SessionFactory：
2.1 一個 org.hibernate.SessionFactory 只對應到一個 Database
2.2 必須在程式要使用之前就必須建立好 SessionFactory，因為需要一點時間才能建立，所以最好是在網站或程式初始化時就去建立，至少必須在程式開始接觸 Database 之前就要建立。
2.3 必須放在所有程式都可以取用到地方 ( 有 JNDI 就註冊到 JNDI 中, 如果沒有 JNDI, 且是Web Apps, 也可以註冊在 ServletContext)。
2.4 org.hibernate.SessionFactory 會 catch 執行 Hibernate 所產生的 SQL statement 和 Database 的 metadata。
2.5 org.hibernate.SessionFactory 是 thread-safe 物件，會自己處理 multi-thread。
2.6 透過 org.hibernate.SessionFactory 的 openSession() 或是 getSession() 來 產生/取得 下一步驟要用到的 org.hibernate.Session。
3. Session：
3.1 org.hibernate.Session 包含了 JDBC 的 Connection object。
3.2 所以可以視為 Hibernate 與 Database 之間溝通的橋樑、過程。
3.3 org.hibernate.Session 可以提供 org.hibernate.Transaction object
3.4 所以存取 Persistent Class 都需要透過 org.hibernate.Session 。
4. Transaction：
4.1 org.hibernate.Transaction 將真正在底層執行 Transaction service包裝起來，
在 J2EE 中使用 JTA 的 UserTransaction 服務多個 Database (ex: 轉帳)；或利用 J2SE 中 JDBC 的 Transaction 來服務一個 Databae。
4.2 在 Hibernate 3.x 中，存取 Persistent Class 的動作一定要包在 org.hibernate.Transaction 的可視範圍之中。
例如:Transaction transaction = session.beginTransaction();
存取 Persistent Class ...
......
transaction.commit();
5. Persistance Class：
5.1 最好是 JavaBeans 的架構。
5.2 使用 Hibernate 來處理的 Table 一定要有 primary key，且對應到 Java Class 中的 欄位與 setter，為了避免誤改，所以都應該宣告為 private 屬性。primary key 是獨一無二的 id，所以在選定時最好避免與目前專案相關性太高的欄位，應儘量使用流水號。
5.3 不要使用 final。Hibernte 會自動為每個 Persistent Class 產生各自的 proxy，但 proxy 會繼承 Persistent Class，所以一旦設為 final，將會限制 proxy 所提供的功能。
5.4 要小心處理 Persistent Class 的三種狀態：
transient : 尚未跟 Persistent Context 接觸。( 與 Session 沒有關係的狀態 )
persistent : 正在跟 Persistent Context 接觸。
detached : 以前曾經跟 Persistent Context 接觸，但現在分開了。
6. Hibernate Mapping File：
6.1 每一個 Persistent Class 都會有自己的 Mapping File，以維護 Table 與 Persistent Class 的對應關係。
6.2 Mapping File 的副檔名為 .hbm.xml。
6.3 Mapping File 的存放位置必須跟所對應的 Persistent Class 的目錄相同。
6.4 在使用 Mapping File 之前必須註冊到 Configuration file 中，通常使用靜態的方法，直接寫入 hibernate.cfg.xml 中。
閱讀全文...
JSP 2.0最重要的變革之一，便是將Expression Language(以下簡稱EL)整合進JSP標準規格，EL並非全新的語言，最早出現於JSTL 1.0當中，被用來簡化資料存取的相關作業。
由於EL已是JSP的標準，因此你可以選擇直接在JSP網頁當中使用EL替代Java進行資料的存取操作。
EL有其專屬的一套語法，包含了兩項基本要素：變數與運算子。變數用來儲存各種型態的資料，運算子則是資料運算符號。儘管EL是為了特定目的而發展出來的一個特殊語法，然而相較於其他的程式語言的變數與運算子，它們的意義是相同的。對於EL而言，變數是一個儲存了特定資料的符號，EL可以直接對其作存取，或是結合運算子進行必要的運算之後作輸出。
EL另外還有一組內建的預先定義隱含物件(implict variables)，它們以Java集合物件的型態出現，其中儲存了網頁的各種資訊，包含session、cookie以及網頁傳輸過程當中所使用的參數值。EL的語法相當簡潔，為了與其他的網頁元素作區隔，EL必須以一個金錢表示符號加上左大括弧${開始，並且以右大括弧}作結束。
閱讀全文...
JSP Standard Tag Library(簡稱JSTL)，是一套預先定義好、協助程式設計人員簡化JSP網頁製作的標籤函式庫，包含了各種網頁運作所需的功能，例如迴圈、流程控制、輸出入、文字格式化，甚至XML文件處理以及資料庫存取操作均為其涵蓋範圍。
JSTL雖然是JSP網頁技術的一環，但是與JSP不同的是，JSTL本身並非由SUN公司所開發出來，相反的，SUN制定其規格之後，便直接開放讓外界進行實作，而目前提供相關規格實作成品的最主要的組織為Apache的Jakarta Project。
我們並沒有辦法直接使用JSTL，還必須先至Jakarta Project網站下載並且安裝JSTL。依其功能面作分類，JSTL提供了五種形式的標籤函式庫，列舉如下表：
閱讀全文...
由於Internet的快速發展，網際網路上的應用服務也跟著日新月異，從以往最初的資訊流通共享，時至今日，各式各樣更多的需求和服務為消費者及開發廠商提供更多選擇和機會。如今，單純的網頁早已不敷使用，使用者需要更個人化、更多元化的「服務」。Java因為具跨平台能力，其共通性讓更多開發者投入它的懷抱，也不斷發展出更多應用，而其觸角也理所當然伸向網際網路領域。在1997年所提出的Servlet產生了網路服務的另一波新革命，結合了使用者直接接觸的JSP和後端連結資料庫的JDBC應用，Java相關應用在網路服務上創造了難以想像的衝擊和便利。Struts的目的便是要結合這些功能強大的元件，架構出一個兼具功能性及開發便利性的框架。
MVC Model
要想理解Struts的架構，必須先了解何謂MVC model(Model 2)。
字面上來說，MVC所代表的分別是Model、View以及Controller。這是一種將設計工作分層處理的概念，我們可以將一項網路服務的流程區隔為三個部分，每個部分由個別元件處理，只要製訂好各元件間如何聯絡的合作方法，就可以讓一個大型服務切割成數個較簡單的工作。
MVC-model將會有三個不同的元件，也就是模型元件(Model_Component)、視圖元件(View_Component)和控制器元件(Controller_Component)等，模型元件負責商業邏輯(Business_Logic)，視圖元件作為使用者介面，負責服務主體中和使用者的互動，而控制器元件則是接收使用者發出的需求，介接到相對應的商業邏輯，並取得結果後回應使用者，負責前二者的連結。如同一所大公司一樣，將工作區分做到專業化，讓開發人員各司其職，分別做好三個部分的設計，也讓一個大型服務開發過程能夠變得更加明確而清晰。MVC架構起始於一個GUI(Graphocal_user_interface_design_patter，圖型使用者介面設計原型)原型，早期是使用在Smalltalk這個語言，而今隨著網路服務的快速發展，MVC架構已經成為一個流行且成功的網路服務設計方法。
閱讀全文...
開發JSP網頁程式的過程中，如果需要的應用程式功能已經存在其他網頁，最快的方法便是重複使用相同的程式碼，將內容複製到新的網頁，或是直接將其載入。
當應用程式的規模越來越大，複製程式碼的做法很容易就會導致程式碼維護上的困難，為了維持不同版本之間功能的完整與一致性，每次修改原始版本的程式碼，其複本的程式碼必須一併作更動，當一份程式碼同時被數十甚至數百個網頁使用的時候，你所開發的JSP網頁系統將會變成一場災難。
解決程式碼重複使用的問題有很多種方式，其中一種比較簡單的作法便是將其寫成副程式網頁，其他的程式設計人員只需引用這個網頁即可獲得相同的功能而不需重新開發，當相同的功能需要調整的時候，只需修改幅程式即可將所做的改變，直接反應到使用此副程式的所有網頁。
JSP網頁取得外部檔案，並且將其嵌入目前的網頁中，由於顯露在外的程式碼非常容易被更改，因此很快的便導致各種不同的版本產生，如下圖：
為了徹底解決程式碼重複使用的問題，同時建立強固的商業及應用程式，元件化的程式技術被發展出來，提供這一方面相關問題的最佳解決方案。
JavaBean是一種可跨平台且重複使用的Java標準元件，通常用來設計一些特定功能的小程式，簡單的說就是可在JSP網頁中執行的Java程式，我們可把JavaBean想像為功能特定且可重複使用的副程式，當應用程式需要提供相同的特定功能，只需直接引用編譯好的JavaBean元件，而不需撰寫重複的程式碼。
以上為JavaBean運作的示意圖，JavaBean經過編譯成為類別檔，它由原始程式碼產生，然後由網頁所引用，這個過程是單向的，使用JavaBean的網頁並不能修改已編譯後的類別檔，也因此可以保證所有的網頁使用的都是同一個版本，同時由於類別檔是編譯過的元件，因此非常容易被其他的應用程式所引用。
大型的JSP應用系統非常依賴JavaBean元件，它們用來封裝所有包含運算邏輯的程式碼，畫面資料的輸出與展示的部份則交由網頁程式，如此一來，當JSP網頁需要JavaBean元件的功能，只需於網頁中直接引用此元件即可，除了達到簡化JSP程式架構、程式碼重複使用的目的之外，同時提供應用程式擴充與修改更大的彈性。
閱讀全文...
JSP與Java Servlet皆是在伺服端執行程式，同樣也是用來設計互動式網頁上的技術，既然這二者之間有著這些共通處，那它們兩者之間又有何不同呢？
Java servlet(底下通稱為servlet)本身就是一種Java程式，主要是應用在網頁上的一種伺服端技術，與JSP有著相當密切的關係，底下就其特性與架構進行基礎的說明。
servlet的特性
servlet出現之前，程式設計人員使用一種簡稱為CGI(Common Gateway Interface)的技術設計伺服端執行的動態網頁，達到與web使用者雙向動態溝通的目的。由於CGI程式每執行一次便會產生一個新的行程(Process)，一定數量的連線人數便會輕易的佔用掉Server端龐大的系統資源，快速降低系統的執行效率。
CGI另一項致命的缺陷同樣與其所產生的行程有關，由於各行程本身獨立且彼此無法溝通，導致連線過程當中，各種資訊的傳遞難以被處理。
servlet透過多執行緒機制解決行程所衍生的諸多問題，相較於行程，執行緒所耗用的資源相當輕，同時一個行程可執行多個執行緒而不會有效能上的問題，同時由於連線狀態均由同一個行程作處理，因此可以輕易的讓各階段的連線進行溝通。
servlet程式執行之前必須經過編譯，而產生的class檔案則存放在伺服端電腦的固定資料夾下，當客戶端使用者對伺服器提出請求時，則會自動執行被請求的servlet程式，最後再回應給客戶端所需的資料。
除了傳統CGI所面臨的問題，servlet另一項優勢在於由標準的Java所寫成，而Java語言的特性之一就是跨平台，也因此servlet自然的擁有跨平台的能力。只要支援servlet語言的網頁伺服器都能順利的執行servlet程式。
servlet的架構
雖然說servlet本身就是個Java程式，但它在架構上卻和Java程式有所不同。servlet程式中並沒有main()這個方法，此為它和Java程式主要的不同處。此外，設計servlet程式必須使用javax.servlet及javax.servlet.http這二個套件下的類別及介面。
下面讓我們概略地解說這兩個套件在設計伺服器端程式上的用途：
javax.servlet：在這個套件底下所定義的是一些和FTP協定無關的類別及介面，主要是用來協助servlet程式處理客戶端送來地請求或將servlet執行的結果傳給客戶端。
javax.http.servlet：這個套件則是繼承自上一個Javax.servlet套件，並增加了與HTTP協定有關的類別及介面，例如處理SMTP或HTTP協定之類別或介面。
除了上述支援servlet的專屬套件，servlet程式事實上同樣可以存取Java本身所提供的眾多類別API，這也大大的提升了servlet應用程式的強度與擴充能力，透過Java的結合，servlet可以在網頁上完成幾乎傳統應用程式才能達到的功能。
閱讀全文...
JSP從標籤FORM所構成的表單區塊中，取得使用者於其中特定欄位輸入的資料內容，進行的邏輯運算之後，產生符合條件需求的網頁內容，重新將結果回傳給瀏覽器，整個過程如下圖所示：
圖中左半部為瀏覽器解譯網頁的部份，右半部則是Tomcat伺服器，當使用者於提供JSP網頁的內容填入資料之後，重新回傳至Tomcat啟動資料處理網頁，其中的JSP程式碼進行資料的處理運算，同時輸出結果網頁，重新傳送至瀏覽器。
整個過程中，處理資料網頁、原始資料網頁以及結果輸出網頁，可以是同一份JSP網頁檔案或是不同的JSP檔案，端視JSP程式開發人員的設計而定。
JSP網頁透過HTML表單欄位，取得使用者輸入的資料內容，依據使用者的需求與特定運算邏輯，於同一份JSP檔案展現不同的網頁結果，達到與使用者互動的目的，因此HTML表單欄位標籤對JSP而言，相當的重要，沒有視窗物件的輔助，動態網頁的技術將成為空談。
閱讀全文...
JavaScript是由Netscape公司開發並隨Navigator導航者一起發佈的、介於Java與HTML之間、基於物件事件驅動的編程語言，不需要Java編譯器，而是直接運行在Web流覽器中，它的前身是Live Script。
而JScript是一種類似JavaScript的語言，這兩者的區別就相當於英國英語和美國英語的區別。
1.最開始web上只有靜態的html。
2.為了滿足更好的交互需求，netscape開發了在Navigator中使用的LiveScript語言，後改名為avaScript。
3.Microsoft發行jscript用於internet explorer。
4.最初的jscript和javascript差異過大，web程式師不得不痛苦的為兩種流覽器編寫兩種腳本。於是誕生了ECMAScript,是一種國際標準化的javascript版本。現在的主流流覽器都支持這種版本。
5.我們寫程式的時候最好寫 script language="javascript" 而不是 script language="jscript" 因為javascript是一個通用的名稱，所有流覽器都認識，而jscript只有IE認識。
6.其他語言細節上的區別，不是一兩下能說完的。不過編程時最好遵循ECMAscript標準。這樣可以保證相容性。
7.順便說一下,javascript原來叫Livescript，後來Sun的java風頭正盛的時候netscape就把名字改成javascript。
閱讀全文...
Java程式的功能主要是由Java套件下的各個類別，於執行期所產生的物件所提供，JSP基本上還是一種Java程式，只是它簡化了撰寫Java伺服端應用程式的過程。Java提供了9種預設的物件，我們將其稱為隱含物件，這些物件內建於JSP網頁環境之下，因此我們不需引用這些物件所屬的套件，便可以直接在JSP網頁中使用這些物件。
下表列出了這9種JSP的預設物件，以及各個物件是從何種類別衍生而成，並作一簡略的說明：
上表簡述衍生的基礎類別與物件功能，根據物件的特性，底下進一步說明這些物件之間的關聯。
out
JSP是一種動態的網頁，與HTML這一類靜態文件最大的差異，在於同一份網頁經過程式運算之後，根據各種條件狀況呈現不同的內容，伺服端利用out物件將所要輸出的內容，於傳送網頁的時候動態寫入用戶端。
request與response
JSP網頁能夠具備與使用者互動的功能，主要的關鍵在於request物件與response物件所提供的功能，request讓伺服器取得使用者於網頁表單所輸入的資料內容，response則提供伺服端程式回應用戶端訊息所需的功能。
request與response物件，是學習建構JSP網頁互動式功能最重要的兩個隱含物件，它們與HTML表單標籤有着相當密切的關聯。
application與session
application以及session這兩個物件，基本上被使用於記錄以及處理JSP網頁之間的共用資料。
由於網際網路本身是一種無連線線狀態的應用程式，當一份網頁文件從網站伺服器傳送至用戶端的瀏覽器之後，用戶端以及伺服端之間，就沒有任何連線狀態存在，這個先天的缺陷，讓網頁無法儲存應用程式執行期間所需的共用資料，application與session物件被設計用以解決這樣的問題。
config、pageContext以及page
這三個物件使用於存取JSP網頁程式執行階段的各種資訊內容，其中config包含JSP網頁檔案編譯成為Servlet之後的相關資訊、pageContext則是提供系統執行期間，各種資訊內容的存取作業功能，page代表目前正在執行的JSP網頁物件。
JSP伺服端應用程式可以運用這三種物件，存取網頁執行期間各種環境資訊，同時將目前網頁當作物件進行操作。
exception
exception為JSP提供用於處理程式執行錯誤的例外物件，此物件搭配功能強大的例外處理機制，運用於JSP網頁的程式除錯與例外處理。
閱讀全文...
JSP嚴格說來是一種整合技術，以Java平台為基礎，提供一種簡便的方式，讓Java技術能夠輕易的運用於建構動態網頁內容。
Java為了產生與使用者互動的動態網頁，發展出一種名稱為servlet的應用技術，servlet是一種純粹以Java語言編寫，符合標準規格的Java應用程式，於網站伺服器運行的時候被載入，針對客戶端瀏覽器提出的要求，作出動態回應。
儘管servlet應用程式產生動態網頁的功能相當強大，但是卻不容易開發，JSP即是為了克服這個障礙而發展出來的一種伺服端網頁技術，其本身是一個內容混雜HTML標籤與Java程式碼的純文字檔，當瀏覽器要求JSP網頁，文字檔於網站伺服器被編譯成為servlet載入，然後產生動態的網頁內容。
由於JSP本身被設計的非常容易學習使用，因此Java動態網頁技術得以快速的發展而且被廣泛的接受，程式開發人員只需學習基礎Java語法以及相關的JSP物件，便可以輕易完成動態網頁的建構設計。
JSP與JavaBean
讓JSP如此出色的原因，除了servlet之外，另外一點便是其運用JavaBean的能力，JavaBean是一種元件技術，提供Java應用程式一種極為彈性的設計模型，它將程式依功能切開，包裝成為一種稱之為JavaBean的程式元件，可以被外部JSP網頁重覆使用以提供所需的功能，同時藉以擴充JSP網頁的功能，維持簡潔易於維護的JSP網頁程式碼。
使用JSP設計動態網頁並不困難，然而當網站的複雜度開始增加，我們還是必需面對如何有效管理與切割程式內容的課題，於提供強大功能的同時，保有網頁程式設計的彈性、以及容易維護的程式碼。
JavaBean本身是一種包含特定功能的Java程式元件，當一個JSP網頁需要此項功能，只需直接引用相關的JavaBean元件即可；而JavaBean最重要的概念在於將程式邏輯與建構網頁介面的程式碼分開，網頁只負責資料的收集以及畫面擺設的處理，而JavaBean元件則是包含重要的程式邏輯運算，如此一來JSP網頁將更容易維護與建構，JavaBean同時也是建構商業級JSP網頁程式最為重要的核心。
閱讀全文...
Subversion，簡稱 SVN，是一個開放原始碼的版本控制系統，可以智慧化更新客戶端檔案的程式。使用 SVN 可以自動比對您腳本資料夾內的檔案以及 SVN 伺服器上的檔案，做出刪除檔案、更新檔案、比對檔案、加入檔案等等...功能，讓使用者能在第一時間上取得最新腳本。
SVN 是一個檔案伺服器，就跟你使用 FTP 一樣，只是你在使用 SVN 的時候...您沒有上傳檔案的權限，沒有權限的帳號，SVN 只能幫你做到更新(下載)腳本而有權限的帳號，則可以上傳腳本，幫腳本做更新，基於安全面，怕人搗亂，所以普通使用者都沒有上傳的權限。
SVN 是個檔案伺服器，這點剛剛有提到，它就像是一個"在網路上的腳本包"它隨時會因為我、或者其他有權限的人的上傳腳本，而得到更新。換言之，一般使用者也可以隨時透過 SVN 系統，取得最新被更新的腳本這就是使用 SVN 能取得最新腳本包的原因。
閱讀全文...
對於原先『單工式』程式開發的技術人員而言，『多執行緒』是一項 Java的全新特色，也就是在每一個行程(process)中包含多個執行緒(Thread)，因為多執行緒應用程式將程式分割成一些獨立的工作，在運用得當的應用程式中，多執行緒可以大幅提升效能。
何謂執行緒(thread)
在說明執行緒前，讓我們先來了解什麼是行程(process)。作業系統在執行一個應用程式時，正在執行的應用程式稱為一個行程，系統會分配相對的系統資源與CPU時間，執行另一個應用程式時，則是另一個行程與資源分配的產生，同時會有對應的CPU時間。在執行應用程式時，行程與資源各自獨立才不會發生應用程式間相互干擾的現象。
CPU時間只有在程式執行的狀態才能取得，但不見得每一個應用程式都能被配置到100%的CPU時間。為了充份使用CPU時間，將暫時閒置的CPU時間用在執行應用程式的其他工作上，便是執行緒的概念。以往應用程式在一個行程中只能處理一件事情，現在利用執行緒可使一個應用程式在同一時期能執行多項工作，以達到程式多工。
多執行緒的程式的語法不難卻很難控制，因為相較於單工的應用程式，其困難度與複雜度皆增加許多，例如執行緒的執行先後順序與資源維護在程式控制上便是一大考驗，控制得宜可提昇程式效能，控制不好反而使執行效能比單工程式還低。
程式中一次可以處理多個執行緒，不過在同一個時間點真正執行的只有一個(這是指單一CPU的系統而言，因為大部分的PC只有一顆CPU)。也就是說，雖然程式可以一次處理多個執行緒，但真正執行的時候一次只有一個執行緒在執行(Running)，其他執行緒則在Runnable區塊中等待。執行緒的執行先後順序也會依照執行緒的優先權來判定，其他的則仍然在Runnable區塊中等待下一次優先權的判定。
圖1-說明了執行緒的工作流程：
1. 執行緒(New Thread)經由start()方法進入Runnable pool中準備執行。
2. 在Runnable pool中的每個執行緒都有自身的優先權及時間順序。
3. 再由Scheduler(排程器)進行排程。
4. 經過排列後將選出來的執行緒丟入Running中執行。
5. 此時執行緒會觸發Run()方法，並執行實作內容(寫在Run()內的程式碼)。
6. 執行完畢或程式中呼叫了stop()方法時，執行緒便銷毀，不過其狀態還將會保留，只是銷毀的執行緒將無法再被執行。
7. 若執行緒未執行完成(例如取得的CPU時間已到卻還沒完成工作，或是程式呼叫了特定的方法)將會觸發Blocking event並進入封鎖區(Blocked)。
8. 被封鎖的執行緒解除封鎖(Unblocked)或者是程式中呼叫了resume()方法之後，將再進入Runnable pool中等待下一次執行。
9. 若程式中呼叫了yield()方法(讓與)則是將執行權先給其他執行緒執行，不過其本身仍然還是在Runnable中。
實作Java執行緒
每個應用程式至少要有一個執行緒(又稱之為主執行緒)來執行應用程式，為了讓程式在執行期間能執行多樣工作--也就是所謂的多執行緒應用程式(multi-thread)--必須利用其他方法產生額外的執行緒來執行程式。Java程式語言中提供了二種方法來撰寫執行緒程式：
1. 繼承Java.lang.Thread類別。
2. 實作Runnable介面。
二種方法皆可實作出多執行緒的程式，就看程式開發人員如何抉擇與使用。通常來說，利用Thread類別撰寫比較容易，用Runnable則可以忽略Java中單一繼承的限制(例如：若要在Applet中撰寫Thread程式，因為已經繼承了Applet類別所以必須要用Runnable介面來實作)。
利用Runnable介面來撰寫執行緒，程式較有一致性，當其他程式要用到時，可以有共同介面的標準，也比較符合物件導向(OO)的精神。
閱讀全文...
Android 是基於 Linux 核心的軟體平台和作業系統，是 Google 在 2007 年 11 月 5 日公布的手機系統平台，早期由 Google 開發，後由開放手機聯盟（Open Handset Alliance）開發。它採用了軟體堆疊（software stack）的架構，主要分為三部分。低層以 Linux 核心工作為基礎，只提供基本功能，其他的應用軟體則由各公司自行開發，以 java 作為編寫程式的一部分。另外，為了推廣此技術，Google 和其它幾十個手機公司建立了開放手機聯盟（Open Handset Alliance）。Android 在未公開之前常被傳聞為 Google 電話或 gPhone。大多傳聞認為 Google 開發的是自己的手機電話產品，而不是一套軟體平台。
對於 Android 的重點整理如下：
- Android 是Google 的手機作業系統和相關軟體的總稱，和一般在說「Symbian」、「Windows Mobile」時是相同的。
- 今天的發表有兩個不同，但相關的組成元件：以 Linux 為核心的 Android 行動平台（這間公司是 Google 在 2005 年買下的）和 Open Handset Alliance，一個由 33 間手機製造商、軟體商和電信業者組成的 Android 推廣聯合會。
- 並沒有所謂的硬體「Gphone」，而 Google 也沒有打算（或至少沒有公開打算）要進入手機硬體市場。到時候真的做手機的，是 HTC、Samsung、LG 這些手機廠，而因為 Android 的程式碼是開放式的，理論上任何人都可以以 Android 為基礎開發新手機。
- 雖然平台是開放的，但並沒有辦法保證裝到手機上了之後還是開放的。手機商和電信業者有權利決定是否在特定的機種上允許第三方軟體的安裝。
- Nokia、Apple、Palm 和 Microsoft 不在這個 33 間公司的名單中。Palm 稍早發佈了新聞稿表示將繼續在 Palm OS 平台上支援 Google 的服務。
- 國際、本土手機廠商紛紛推出Android平台手機，電信業者也看好Android平台可帶來加值服務營收。
- Android採用開放平台及免付授權金的特性，將打破以微軟、Symbian、Linux等作業系統為主的全球智慧型手機市場生態，進一步帶動行動數據與內容應用的無限商機，遠傳也將成為繼Vodafone、DoCoMo、中國移動之後，國內首家開設網路軟體商店的電信公司。
- 除了宏達電、英華達、雙A、廣達、華寶、正文、華冠等業者之外，國際與本土晶片大廠、知名硬體廠商也正與經濟部洽詢加入，準備與台灣NB、手機大廠一起合作開發支援可以應用在手機、小筆電、MID等終端產品的本土Android內容應用。
閱讀全文...
JAVA 應用程式要呈現圖形化的介面，可使用：
1.AWT(java.awt.*)-Java 早期剛推出時提供的GUI元件(或稱GUI類別庫)。
2.Swing(javax.swing.*)-Java 1.1 推出一組強化的 GUI 元件類別庫。
3.SWT-Standard Widget Toolkit，最初由 IBM 開發用來與 Swing 競爭。著名的整合開發環境 Eclipse就是用 Java 和 SWT 開發的。
以 Swing 為例：
1.設計視窗元件
2.傾聽者(Listener)介面
ActionListener
MouseListener
KeyListener
.
.
.
3.事件(Event)
ActionEvent
MouseEvent
KeyEvent
.
.
.
Java秘史:隱藏在SWT/Swing背後的故事(轉載)
譯注：本文來自_talking_java@yahoogroups.com">straight_talking_java@yahoogroups.com討論組，已經是一年多前的文章。Alan Williamson是Java Developers Journal的編輯，下文來自他在IBM的一個消息來源。SWT和Swing的論爭我見過不少，Netbeans和Eclipse的也同樣多。譯者翻譯此文並不是要激起什麼爭執，也不是支持哪一方（雖然我的確是站在SWT一邊的），更不是要攻擊Amy。我最重要的理由是，這是一篇有趣的文章。裏面有內幕、線人、公司政治、壟斷巨頭、美女、商界風雲……足夠拍一出電影。有趣，這就夠了。不過此文反映了IBM對Swing的看法和SWT的由來，還是有一點營養的。
------
要想弄清楚為什麼一切都被弄得如此混亂，要從幾年前只存在AWT的時候說起。SUN當時已經建立了一套基本的可移植控制項類，這些類映射到不同作業系統上的原生視窗元件（native widget），顯然下一步應該繼續增強這套模型，除了初始的CUA 92元件（文字、按鈕等等），再繼續加上表格、樹、記事本、滑塊等等……當時的AWT還滿是漏洞，遠不能稱為可靠，還需要SUN的coder們去修補。SUN的developer們如Graham和Otto總是習慣於公開把他們的bug歸咎為作業系統的差異，比如“Windows和OS/2的焦點次序不同”或者“在……之間Ctrl-X的行為不一樣”，以及其他蒼白的託辭，好讓批評的火力從SUN太早釋出代碼這個問題的真相上移開。然後Amy Fowler來到了SUN。不是我大男子主義，Amy是個聰明的美女，大多數呆頭呆腦只懂技術的開發人員都要被她捏在手裏。Amy來自一家Smalltalk公司，叫做Objectshare，在那裏她負責搞UI類別庫。
跟Java相比Smalltalk的歷史有些悲慘，曾幾何時有3家龐大的Smalltalk公司——IBM、Parc-Place和Digitalk。在90年代初期3家公司的市場份額大致相等，生活是美好的。Parc-Place採用仿視窗部件（emulated widgets）的設計（即Swing的設計），IBM和Digitalk則採用原生視窗部件（native widgets）。後來IBM壓倒了另外兩家，因此他們打算合併成一家，假設叫做Parc-Place Digitalk。隨後當他們試圖將他們的產品融合到一個叫做Jigsaw的計畫中時爆發了一場大戰，計畫由於政治原因失敗了（開發人員實際上已經能讓它運轉起來），就因為原生和仿造兩派的死戰。
Amy贏得了精神上的勝利，不過在IBM我們贏得了他們所有的生意，因為這兩家公司在一整年裏除了吵架什麼都沒做。當塵埃落定之後PPD（Parc-Place Digitalk當時已改名為Objectshare，跟Windscale改名為Sellafield的原因相同——讓人們淡忘之前發生的災難）的股票價格從60美元掉到了低於1美元1股。他們因為偽報收入被NASDAQ摘牌，從此消失。此時SUN正走上與PPD類似的技術方向，於是PDD的技術人員都把他們的履歷投到了SUN。Amy被雇用了，她承諾通過羽量級方案解決所有視窗元件的問題，因此說服SUN管理層讓她當了GUI開發部門的頭頭。她是拿著“這裏原來的人都搞砸了，我是來解決的”的鑰匙進來的。隨後Amy雇用了所有她過去在Parc-Place的舊朋友，讓他們來開發Swing。
顯然Swing應該做的是僅僅成為一個繪製框架，給那些希望創建地圖軟體或者繪圖軟體的人們使用，無論如何，應該圍繞AWT類庫來建造它，按鈕之類的東西仍然交給AWT來管。SUN的人比如Philip和Mark已經讓AWT能夠處理表格、樹和記事本（notebook，？），所以Swing的方向應該說很明顯了。但那些毀了PDD的人不幹，他們非要把一切都弄成羽量級的。由於SUN管理層的無知，再加上Amy無情的政治手段，造成了我們今天所見的混亂局面。Amy還使SUN相信Swing是作為Mozilla專案的一部分與Netscape聯合開發的，事實上這只是她的宣傳伎倆。
在IBM，我們從第一天起就憎惡Swing。龐大、滿是錯誤，而且難看至極。原先我們的工具如VisualAge for Java都是用Smalltalk（用的是原生視窗元件）寫的，所以當我們將這些工具向Java代碼庫遷移時，我們需要一套視窗元件。IBM這邊的開發人員都是原來搞Smalltalk的那一批人，我們對管理層要求用Swing來構建WebSphere Studio工具都非常不情願。Swing是個可怕的充滿缺陷的怪獸。
在WebSphere Studio最初的預覽中，當與Microsoft Visual Studio作對比演示的時候，我們所有的客戶都討厭它，就因為它的外觀，而不管它的功能有多強。大多數消費者都不會買一輛讓人覺得難看的車，哪怕這車有一台出色的引擎。因此我們開始了一個項目，是把我們的Smalltalk原生視窗元件移植到Java上去。這個項目是加拿大的Object Technology International小組做的。這個項目獲得了成功，被運用在我們發佈的VisualAge Micro Edition產品中，VisualAge Micro Edition後來成為J2ME開發方面一個非常成功的IDE。但是OTI的人發現，Swing在讀取Windows事件方面有極嚴重的缺陷，我們甚至無法進行SWT（S開始是Simple的縮寫，不過後來變成了Standard的縮寫）和Swing間的互操作。他們在讀事件佇列的時候用了一種可能留下記憶體漏洞的方式，所以我們不得不採用我們自己的查詢Windows事件佇列的迴圈，以糾正這個錯誤。
我們試了一次又一次讓SUN修復這個錯誤，但Amy就是聽不進去，所以我們才決定SWT和AWT/Swing不能共存。我們甚至在SWT中定義了自己的Point和Rectangle類——整個工具包對AWT或Swing都沒有任何依賴。我們把這個工具包放到了Eclipse中，這是一個工具平臺，它的總體設計目標就是要戰勝Micrsoft和Visual Studio。Eclipse是開源的，所以任何人都可以在上面構建自己的東西，我們已經有像TogetherSoft和Rational這樣的公司移植到了上面。我們的競爭者是Microsoft，所以我們所有努力和注意力都是從正面針對Microsoft。
不管怎麼說SUN對此非常不滿。他們的Netbeans跟Eclipse做的是相同的事，因此他們向IBM高層抱怨。他們認為SWT是要將你綁到Windows上，這純粹是胡說，因為SWT能通過GTK在Mac/Linux上執行，以及一大堆嵌入式平臺。他們拒絕讓Eclipse獲得Java認證，因為裏面有原生代碼，所以Eclipse產品必須很小心地使用“Java”這個SUN的商標。Eclipse甚至不能把自己稱為一個Java IDE，SUN已經威脅過要採取法律行動來制止IBM在任何時候把Eclipse稱作一個Java IDE。結果之一就是IBM在Eclipse上創建的GUI設計工具，允許你構建Swing/AWT GUI，卻不讓你往裏面拖放SWT視窗控制項。
將SWT從Eclipse中分離出來是完全可能的，只需要把DLL拷貝出來放到路徑中，並使用視窗元件工具包來給你的銀行或者保險或者其他什麼應用程式開發GUI。再次說明，我們無法更進一步，因為SUN把我們的雙手綁上了。雖然作為Eclipse開放源碼協議的一部分，CPL允許我們提供這樣的解決方案，但SUN已經很清楚地表明他們不希望我們這樣做。 對於用戶社區來說，無論IBM和SUN的最終動機是什麼，我發現有一點總是很有趣：喜愛Swing的人總會說“一旦你花上幾年時間去掌握它，你就能正確地使用它”，這基本上是他們在試圖證明和維護他們辛苦得來的用途有限的專門技術；而SWT的擁護者們說的是“哇，這真快，這跟原生的一樣，還可以用XP皮膚……它還又輕又小”。有一句話是我喜歡的，我們的一個用戶說，Swing就像Java決定不通過作業系統來實現原生的IO，而是通過磁頭馬達API自己來讀磁片的磁區。Swing基本上就是這樣的，它拿著個底層的“paint(Graphics)”方法，自己來繪製所有的視窗元件。
閱讀全文...
