在javaweb開發過程中get和post亂碼是一個老生常談的話題了，相信人人都遇到過。網上的文章也很多，但往往是看的越多就越糊涂，有些東西只有自己了然于心才能真正地明白。下面就寫一篇文章，就亂碼產生的過程分析一下。
為什么會產生亂碼？

1.   為什么會產生亂碼？

因為瀏覽器不允許提交非ASCII字符，如果提交了非ASCII，則瀏覽器自動對其進行編碼，將它們轉換為ASCII字符。根據瀏覽器的不同，轉換時使用的編碼也不同，比如有些瀏覽器會使用utf-8進行編碼，而有些會使用gbk進行編碼。

2.   瀏覽器為什么不允許提交非ASCII字符？

以下是我個人觀點，僅供參考。

因為瀏覽器和服務器通信，傳輸的都是字節。而我們在頁面提交的都是字符，所以瀏覽器底層就有一個將字符轉換為字節的過程，這個過程涉及到編碼，瀏覽器到底是用utf-8、gbk還是iso-8859-1將字符轉換為字節呢？我想應該是iso-8859-1，因為這是西歐默認使用的編碼。何況，也沒有任何理由使用前兩種編碼格式。但是iso-8859-1編碼是不能識別中文以及其他非ASCII字符的，所以如果字符中存在這類字符，那么將字符轉換為字節的過程中勢必會產生亂碼。為了避免這種情況的發生，瀏覽器自動對非ASCII字符進行了編碼，將這類字符轉換為ASCII字符，這樣就能避免亂碼問題。

3.   GET和POST提交表單，分別根據什么對非ASCII字符進行編碼？

GET：

情況比較復雜，不同瀏覽器也不一樣，有的使用gbk，有的使用utf-8不好一概而論。

POST：

瀏覽器會根據網頁編碼對表單中的數據編碼。比如我們在jsp頁面第一行所寫的：<%@page contentType="text/html;charset=UTF-8"%>。那么這個網頁響應給客戶端后使用的就是utf-8編碼，那么post時使用的也是這個編碼。

編碼后的格式可以參考java中的URLEncoder.encode方法編碼的結果。

4.   服務器底層如何處理提交的數據。

上面2已經提到，客戶端和服務器端傳輸的是字節，那么服務器端接收到的原始數據就是字節。但是我們的程序通常需要從服務器獲取字符，而不是字節，所以服務器端必須將字節轉換為字符。這里也涉及編碼，服務器采取什么編碼方式將字節轉換為字符？我想也是iso-8859-1，這樣和客戶端的編碼方式一致，不會產生亂碼，相當于一個還原字符的過程。這里有個問題，比如客戶端發送：name=%D6%D0%B9%FA，那么服務器端還原后也是：name=%D6%D0%B9%FA。那么我們使用request.getParameter(“name”)如何能得到正確的值呢？難道要我們自己再進行轉換？答案是：NO。根據Servlet規范，Servlet中獲取數據的方法會按照指定的字符集解碼。指定的字符集是什么？默認是iso-8859-1。正是因為使用了iso-8859-1解碼我們發送的參數，導致了亂碼的產生，這里才是產生亂碼的源頭。具體解碼的過程可以看看java的URLDecode.decode方法。既然知道了產生亂碼的原因是因為服務器默認使用iso-8859-1解碼，那我們就得想辦法更改服務器使用的解碼編碼。好在服務器已經提供給我們修改的方式了，我們可以在服務器中進行配置，比如Tomcat可以在server.xml中進行配置，比如：URIEncoding="GBK"這樣服務器就會使用gbk編碼解碼，這種方式主要針對GET提交的數據，對于POST更常用的是request.setCharacterEncoding(String charset)設置解碼編碼。

5.   為了避免亂碼，客戶端應該如何做？

GET：

對于含有非ASCII字符的URL自己進行編碼，比如使用javascript中的方法進行編碼。這樣就不需要瀏覽器為我們編碼了，從而解決了瀏覽器編碼的不確定性。

POST：

只要正確設置網頁編碼即可。

     摘要: 工作中經常遇到java編碼問題，由于缺乏研究，總是無法給出確切的答案，這個周末在網上查了一些資料，在此做些匯總。     問題一：在java中讀取文件時應該采用什么編碼？ Java讀取文件的方式總體可以分為兩類：按字節讀取和按字符讀取。按字節讀取就是采用InputStream.read()方法來讀取字節，然后保存到一個byte[]數組中，最后經常用new Stri...  閱讀全文

Servlet/JSP技術和ASP、PHP等相比，由于其多線程運行而具有很高的執行效率。由于Servlet/JSP默認是以多線程模式執行的，所 以，在編寫代碼時需要非常細致地考慮多線程的安全性問題。然而，很多人編寫Servlet/JSP程序時并沒有注意到多線程安全性的問題，這往往造成編寫 的程序在少量用戶訪問時沒有任何問題，而在并發用戶上升到一定值時，就會經常出現一些莫明其妙的問題。

　　Servlet的多線程機制

Servlet體系結構是建立在Java多線程機制之上的，它的生命周期是由Web容器負責的。當客戶端第一次請求某個Servlet 時，Servlet容器將會根據web.xml配置文件實例化這個Servlet類。當有新的客戶端請求該Servlet時，一般不會再實例化該 Servlet類，也就是有多個線程在使用這個實例。Servlet容器會自動使用線程池等技術來支持系統的運行，如圖1所示。

　　

　　圖1 Servlet線程池

　　這樣，當兩個或多個線程同時訪問同一個Servlet時，可能會發生多個線程同時訪問同一資源的情況，數據可能會變得不一致。所以在用Servlet構建的Web應用時如果不注意線程安全的問題，會使所寫的Servlet程序有難以發現的錯誤。

　　Servlet的線程安全問題

　　Servlet的線程安全問題主要是由于實例變量使用不當而引起的，這里以一個現實的例子來說明。

Import javax.servlet. *;
Import javax.servlet.http. *;
Import java.io. *;
Public class Concurrent Test extends HttpServlet {PrintWriter output;
Public void service (HttpServletRequest request,
HttpServletResponse response) throws ServletException, IOException {String username;
Response.setContentType ("text/html; charset=gb2312");
Username = request.getParameter ("username");
Output = response.getWriter ();
Try {Thread. sleep (5000); //為了突出并發問題，在這設置一個延時
} Catch (Interrupted Exception e){}
output.println("用戶名:"+Username+"<BR>");
}
}

該Servlet中定義了一個實例變量output，在service方法將其賦值為用戶的輸出。當一個用戶訪問該Servlet時，程序會正常的運 行，但當多個用戶并發訪問時，就可能會出現其它用戶的信息顯示在另外一些用戶的瀏覽器上的問題。這是一個嚴重的問題。為了突出并發問題，便于測試、觀察， 我們在回顯用戶信息時執行了一個延時的操作。假設已在web.xml配置文件中注冊了該Servlet，現有兩個用戶a和b同時訪問該Servlet（可 以啟動兩個IE瀏覽器，或者在兩臺機器上同時訪問）,即同時在瀏覽器中輸入：

　　a： http://localhost: 8080/servlet/ConcurrentTest? Username=a

　　b： http://localhost: 8080/servlet/ConcurrentTest? Username=b

　　如果用戶b比用戶a回車的時間稍慢一點，將得到如圖2所示的輸出：

　　

　　圖2 a用戶和b用戶的瀏覽器輸出

從圖2中可以看到，Web服務器啟動了兩個線程分別處理來自用戶a和用戶b的請求，但是在用戶a的瀏覽器上卻得到一個空白的屏幕，用戶a的信息顯示在用 戶b的瀏覽器上。該Servlet存在線程不安全問題。下面我們就從分析該實例的內存模型入手,觀察不同時刻實例變量output的值來分析使該 Servlet線程不安全的原因。

　　Java的內存模型JMM（Java Memory Model）JMM主要是為了規定了線程和內存之間的一些關系。根據JMM的設計，系統存在一個主內存(Main Memory)，Java中所有實例變量都儲存在主存中，對于所有線程都是共享的。每條線程都有自己的工作內存(Working Memory)，工作內存由緩存和堆棧兩部分組成，緩存中保存的是主存中變量的拷貝，緩存可能并不總和主存同步，也就是緩存中變量的修改可能沒有立刻寫到 主存中；堆棧中保存的是線程的局部變量，線程之間無法相互直接訪問堆棧中的變量。根據JMM，我們可以將論文中所討論的Servlet實例的內存模型抽象 為圖3所示的模型。

　　

　　圖3 Servlet實例的JMM模型

　　下面根據圖3所示的內存模型，來分析當用戶a和b的線程（簡稱為a線程、b線程）并發執行時，Servlet實例中所涉及變量的變化情況及線程的執行情況，如圖4所示。

調度時刻	a線程	b線程
T1	訪問Servlet頁面
T2		訪問Servlet頁面
T3	output=a的輸出username=a休眠5000毫秒，讓出CPU
T4		output=b的輸出（寫回主存）username=b休眠5000毫秒，讓出CPU
T5	在用戶b的瀏覽器上輸出a線程的username的值,a線程終止。
T6		在用戶b的瀏覽器上輸出b線程的username的值,b線程終止。

　　圖4 Servlet實例的線程調度情況

從圖4中可以清楚的看到，由于b線程對實例變量output的修改覆蓋了a線程對實例變量output的修改，從而導致了用戶a的信息顯示在了用戶b的 瀏覽器上。如果在a線程執行輸出語句時，b線程對output的修改還沒有刷新到主存，那么將不會出現圖2所示的輸出結果，因此這只是一種偶然現象，但這 更增加了程序潛在的危險性。

　　設計線程安全的Servlet

　　通過上面的分析，我們知道了實例變量不正確的使用是造成Servlet線程不安全的主要原因。下面針對該問題給出了三種解決方案并對方案的選取給出了一些參考性的建議。

　　1、實現 SingleThreadModel 接口

該接口指定了系統如何處理對同一個Servlet的調用。如果一個Servlet被這個接口指定,那么在這個Servlet中的service方法將不 會有兩個線程被同時執行，當然也就不存在線程安全的問題。這種方法只要將前面的Concurrent Test類的類頭定義更改為：

Public class Concurrent Test extends HttpServlet implements SingleThreadModel {
…………
}

　　2、同步對共享數據的操作

　　使用synchronized 關鍵字能保證一次只有一個線程可以訪問被保護的區段，在本論文中的Servlet可以通過同步塊操作來保證線程的安全。同步后的代碼如下：

…………
Public class Concurrent Test extends HttpServlet { …………
Username = request.getParameter ("username");
Synchronized (this){
Output = response.getWriter ();
Try {
Thread. Sleep (5000);
} Catch (Interrupted Exception e){}
output.println("用戶名:"+Username+"<BR>");
}
}
}

　　3、避免使用實例變量

　　本實例中的線程安全問題是由實例變量造成的，只要在Servlet里面的任何方法里面都不使用實例變量，那么該Servlet就是線程安全的。

　　修正上面的Servlet代碼，將實例變量改為局部變量實現同樣的功能，代碼如下：

……
Public class Concurrent Test extends HttpServlet {public void service (HttpServletRequest request, HttpServletResponse
Response) throws ServletException, IOException {
Print Writer output;
String username;
Response.setContentType ("text/html; charset=gb2312");
……
}
}

對上面的三種方法進行測試，可以表明用它們都能設計出線程安全的Servlet程序。但是，如果一個Servlet實現了 SingleThreadModel接口，Servlet引擎將為每個新的請求創建一個單獨的Servlet實例，這將引起大量的系統開銷。 SingleThreadModel在Servlet2.4中已不再提倡使用；同樣如果在程序中使用同步來保護要使用的共享的數據，也會使系統的性能大大 下降。這是因為被同步的代碼塊在同一時刻只能有一個線程執行它，使得其同時處理客戶請求的吞吐量降低，而且很多客戶處于阻塞狀態。另外為保證主存內容和線 程的工作內存中的數據的一致性，要頻繁地刷新緩存,這也會大大地影響系統的性能。所以在實際的開發中也應避免或最小化 Servlet 中的同步代碼；在Serlet中避免使用實例變量是保證Servlet線程安全的最佳選擇。從Java 內存模型也可以知道，方法中的臨時變量是在棧上分配空間，而且每個線程都有自己私有的棧空間，所以它們不會影響線程的安全。

　　小結

Servlet的線程安全問題只有在大量的并發訪問時才會顯現出來，并且很難發現，因此在編寫Servlet程序時要特別注意。線程安全問題主要是由實 例變量造成的,因此在Servlet中應避免使用實例變量。如果應用程序設計無法避免使用實例變量，那么使用同步來保護要使用的實例變量，但為保證系統的 最佳性能，應該同步可用性最小的代碼路徑。

原文出處:http://www.feeten.cn/html/jsp/01/20090102181631103402.html
作者:佚名

File類是用來構造文件或文件夾的類,在其構造函數中要求傳入一個String類型的參數,用于指示文件所在的路徑.以前一直使用絕對路徑作為參數,其實這里也可以使用相對路徑.使用絕對路徑不用說,很容易就能定位到文件,那么使用了相對路徑jvm如何定位文件的呢?

按照jdk Doc上的說法”絕對路徑名是完整的路徑名，不需要任何其他信息就可以定位自身表示的文件。相反，相對路徑名必須使用來自其他路徑名的信息進行解釋。默認情況下，java.io 包中的類總是根據當前用戶目錄來分析相對路徑名。此目錄由系統屬性 user.dir 指定，通常是 Java 虛擬機的調用目錄.”

相對路徑顧名思義,相對于某個路徑,那么究竟相對于什么路徑我們必須弄明白.按照上面jdk文檔上講的這個路徑是”當前用戶目錄”也就是”java虛擬機的調用目錄”.更明白的說這個路徑其實是我們在哪里調用jvm的路徑.舉個例子:

假設有一java源文件Example.java在d盤根目錄下,該文件不含package信息.我們進入命令行窗口,然后使用”d:”命令切換到d盤根目錄下,然后用”javac Example.java”來編譯此文件,編譯無錯后,會在d盤根目錄下自動生成”Example.class”文件.我們在調用”java Example”來運行該程序.此時我們已經啟動了一個jvm,這個jvm是在d盤根目錄下被啟動的,所以此jvm所加載的程序中File類的相對路徑也就是相對這個路徑的,即d盤根目錄:D:\.同時” 當前用戶目錄”也是D:\.在System.getProperty(“user.dir”);系統變量”user.dir”存放的也是這個值.

我們可以多做幾次試驗,把”Example.class”移動到不同路徑下,同時在那些路徑下,執行”java Example”命令啟動jvm,我們會發現這個”當前用戶目錄”是不斷變化的,它的路徑始終和我們在哪啟動jvm的路徑是一致的.

搞清了這些,我們可以使用相對路徑來創建文件,例如:

File file = new File(“a.txt”);

File.createNewFile();

假設jvm是在”D:\”下啟動的,那么a.txt就會生成在D:\a.txt;

此外,這個參數還可以使用一些常用的路徑表示方法,例如”.”或”.\”代表當前目錄,這個目錄也就是jvm啟動路徑.所以如下代碼能得到當前目錄完整路徑:

File f = new File(“.”);

String absolutePath = f.getAbsolutePath();

System.out.println(absolutePath);//D:\

最后要說說在eclipse中的情況:

Eclipse中啟動jvm都是在項目根路徑上啟動的.比如有個項目名為blog,其完整路徑為:D:\work\IDE\workspace\blog.那么這個路徑就是jvm的啟動路徑了.所以以上代碼如果在eclipse里運行,則輸出結果為” D:\work\IDE\workspace\blog.”

Tomcat中的情況.

如果在tomcat中運行web應用,此時,如果我們在某個類中使用如下代碼:

File f = new File(“.”);

String absolutePath = f.getAbsolutePath();

System.out.println(absolutePath);

那么輸出的將是tomcat下的bin目錄.我的機器就是” D:\work\server\jakarta-tomcat-5.0.28\bin\.”,由此可以看出tomcat服務器是在bin目錄下啟動jvm的.其實是在bin目錄下的” catalina.bat”文件中啟動jvm的.

通常所說的cookie實際上可以分為2種,一種是由Cookie對象產生的保存在客戶端硬盤上的持久化的cookie,另一種就是由session對象產生的保存在瀏覽器內存里的session cookie.session cookie的組成是形如: JSESSIONID=0EB8CEDE030A4B6FB5366317D8BF1978(tomcat下).Session cookie何時產生?當新創建一個session對象時產生session cookie.當使用request.getSession()或request.getSession(true)方法時,如果請求范圍內根據jsessionid能夠找到一個對應的session對象,則不產生session cookie也不返回給客戶端保存,找不到則新創建一個session cookie并生成一個形如JSESSIONID=0EB8CEDE030A4B6FB5366317D8BF1978(tomcat下)的session cookie并放在本次響應頭信息中返回給客戶端保存,客戶端之前保存的session cookie也將被這個session cookie所代替.與session cookie不同的是,如果服務器端明確使用Cookie類來生成的持久化cookie將在每次響應中返回給客戶端保存,不管客戶端是否存在這個cookie.當瀏覽器接受cookie后(不管是持久化cookie還是session cookie),在對同一站點進行訪問時,會自動把這些cookie信息放在請求頭信息中一起發送給服務器端.這樣服務器端就能得到這些cookie來跟蹤會話.向服務器端發送cookie這個過程對用戶來是完全透明的,是瀏覽器自動進行的.

以上討論是在瀏覽器接受cookie的情況下,下面談談瀏覽器禁用cookie的情況.

如果瀏覽器禁用了cookie,那么瀏覽器不會接收保存服務器端存在響應頭中的cookie信息(ie6有bug,會保存session cookie).瀏覽器再次訪問同一站點時,請求頭信息里也不會攜帶任何cookie信息的(因為瀏覽器根禁止了該功能).正因如此,服務器端接收不到客戶端的cookie信息,也就無法識別客戶端的身份,從而把它當作一個新的客戶對待,也就會丟失以前的會話信息.在這種情況下服務器端使用request.getSession()或request.getSession(true)方法時將會重新創建一個session.

那么如何在用戶禁用了cookie的情況下維護會話呢?以上討論我們已經知道,服務器端判斷是新的會話還是舊的會話是根據請求頭中是否有一個jsessionid的.由于瀏覽器禁用了cookie從而不會自動向服務器發送這個參數,那么要維持會話就需要我們自己每次服務器發送請求時帶上這個參數.url重寫正是這樣一種技術,只要在我們的代碼中把所有向服務器發送請求的地方用response.encodeRedirectUrl(String arg0)包裝一下,這樣我們請求的url就會自動加上當前session對象產生的jsessionid.服務器端也能取得這個值從而識別客戶端.

    splice方法是javascript中數組的一個方法,其功能是:可向數組刪除并加入新的元素.其方法聲明如下:
index:必選項.指定在哪個位置加入/刪除元素,必須是數字.
howmany:必選項.指定有多少元素應該被刪除,必須是數字,可以是"0".
element1:可選.指定要加入到數組中的新元素.
elementX:可選.可以加入多個元素.
說明:如果howmany為0或"0",則該數組中將沒有元素被刪除,那么element1至elementX個參數將從index指定的位置插入到該數組中,數組中原位置的元素將后移.如果howmany不為0,則從index指定位置開始刪除howmany個元素(包括index位置的元素),然后再從index開始插入element1至elementX個參數,數組中原位置的元素將后移.
例1:
輸出結果為:
例2:
輸出結果為:
例3:
輸出結果為:

        終于到了要離開的一天,畢業之后來到這家公司,從一個畢業生成長為一個程序員,經歷過許多辛酸與磨煉,回想往事,眼前浮現出曾經那一張張熟悉的面孔.謝謝曾經給過我幫助的同事與朋友,沒有你們也沒有今天的我,希望大家越來越好,也希望公司越來越好,也希望自己能有個美好的未來.         眾所周知,javascript中的繼承是通過原型對象(prototype)來實現的.原型對象是由函數的構造函數創建,它所擁有的屬性能被所有對象共享.初始時原型對象指向一個Object對象,并且定義了一個constructor屬性,該屬性指向定義該原型對象的構造函數本身,上述過程可以理解為以下代碼:
因為原型對象的所有屬性能被構造函數創建對象共享,所以創建的對象可以訪問這里的constructor屬性:
由于對象本身也可以自定義屬性,所以在讀取對象屬性時js先檢查該對象是否定義了該屬性,如果已經定義了則使用該屬性,如果沒有定義則再從其原型對象中讀取該屬性,所以如果對象自定義的屬性和其原型中的屬性存在重名則自定義屬性"隱藏"了其原型對象中的同名屬性.例:
加入上述代碼之后再次調用c.constructor(),則會打印出"This is c".這是因為c已自定義constructor屬性"隱藏"了其原型對象中的constructor屬性.當然js保證了讀寫的不對稱性,也就是說讀取一個對象的屬性時有可能要從其原型對象中去讀取,但寫一個對象的屬性時卻從不涉及其原型對象,無論在一個對象加入或修改多少屬性這都不影響其原型對象中屬性的本來面目.比如這里c自定義了constructor屬性,但這一行為并不影響其原型對象中constructor指向其構造函數這一事實,如果再創建一個對象且不自定義constructor屬性,再調用constructor則依然調用對象的構造函數,例:

很容易理解js為什么這樣做,因為一個對象的行為不能影響到其他對象,否則將會造成混亂.
        理解上述規則之后讓我們看看js中是如何通過原型對象實現繼承的.當我們創建一個對象時,可以把該對象看成是由2部分組成的,一部分存儲了該對象自己定義的屬性(稱為A部分),而另一個部分則存儲了其構造函數所定義的原型對象引用(稱為B部分),例如這里的BaseClass.prototype.當讀取對象的屬性時可以分為以下2步:
1.js先檢查該對象引用所指向的內存區域的A部分是否存在該屬性,如果存在則讀出.
2.如果沒有則再從B部分存儲的引用(BaseClass.prototype)所指向的內存區域中讀取該屬性.

從步驟2開始這就是個不斷往上尋找的過程,因為BaseClass.prototype所指向的內存區域也會分為A和B兩個部分,如果再A部分也不存在該屬性,則又會從其B部分所指向的內存區域去尋找該屬性,而該內存區域也有A和B兩個部分,如果A部分仍然不存在,則還要從B部分所指向的內存區域去尋找該屬性,直到達到最頂層的Object類.所以在無形當中就形成了一條鏈,也就是我們常說的原型鏈.如果理解了這個過程我想也就能了解原型對象了.下面簡單分析下b.constructor();的調用過程便于加深理解.
1.js會在b所指向的內存區域A部分讀取constructor屬性.
2.當發現沒有該屬性后再從其類的構造函數原型對象引用所指向的內存區域讀取該屬性.因為原型對象引用初始時指向一Object對象內存區域(BaseClass.prototype = new Object();)
3.再從此Object對象的A部分尋找constructor屬性.
4.沒有找到該屬性則從其類的原型對象即Object.prototype中去尋找constructor.
5.如果找到該屬性則調用.
6.否則,到達鏈的頂端,返回.
到此能很清楚的知道js中是如何實現繼承的,如果我們自定義的類不想繼承自Object,則可以修改其prototype的指向,可以讓其指向任意一個類,這樣也就實現了繼承自定義類,但js中所有的類都繼承自Object類,所以原型鏈的關系仍然存在.

    項目中經常使用createDelegate()方法來創建代理函數,從而改變當前函數中this的作用域.看下了源碼,發現是通過js中的apply()方法來實現,想想也只能通過apply()或者call()方法來實現,因為js中只有這2個方法提供了改變當前函數內部this作用域的功能.此外,Ext中很多地方用到了call()和apply()方法,要想看懂源碼,則必須先搞清這2個方法的用法.
    createDelegate方法聲明為: 其中obj表示函數內部this作用域的范圍,args是數組,appendArgs是"Boolean或Number",如果appendArgs是Boolean型的且值為true,那么args參數將跟在調用代理方法時傳入的參數后面組成數組一起傳入當前方法,否則只傳入args,如果appendArgs為Number型,那么args將插入到appendArgs指定的位置.
注意點:
1.函數內部的arguments關鍵字是函數執行時動態創建的,用來存儲調用函數時所傳入參數.這里第4行的arguments   并不指調用createDelegate方法所傳入的參數(obj,args,appendArgs),而是指調用return function()時所傳入的參數,即調用代理函數時所傳入的參數.而args和appendArgs就是調用createDelegate方法時所傳入的參數.總的來說,函數是在定義它的作用域中執行,而不是在調用它的作用域中執行.但也有特殊,比如這里的arguments.
2.call和apply的區別.
二者的第一個參數都是函數內部this的作用域,call的參數只能作為一串參數傳入,而apply可以傳入數組或arguments對象.如
fun.call(window,args0,args1,.....);
fun.apply(window,[1,2,3]);
但要注意的是apply方法傳遞到函數內部的參數實際也是作為一個個參數傳遞的.如果在fun內部測試arguments.length的話,則長度為3.同樣,我們可以采用arguments[0],arguments[1],arguments[2]來分別引用1,2,3三個參數,而不是用arguments[0][0],arguments[0][1],arguments[0][2]來引用3個參數.這樣才能解釋11行的代碼.

        Ext2.0中,Ext類有個namespace方法,該方法的作用是把傳入的參數轉換成對象.使用該方法的目的主要在于可以區分類名相同的類,這有點和java中的package作用類似.讓我們先看下源碼: 從代碼可以看出,如果我們傳入的字符串參數是以"."分割的,那么將會創建多個對象,比如:
則會創建2個對象,相當于執行了下面的代碼: 這樣,我們在自定義類的時候就能這樣使用:
如果還想定義一個同名的類,那么可以就使用不同的namespace來區分,這樣2個類就不會沖突了:

此外,注意源碼中"eval"方法的使用,如果有需要可以采用這種方式來解決問題.