Microsoft SharePoint Foundation 中主要有兩種類型的頁面，分別是應用程序頁(Application Page) 和網站頁(Site Page)。

?? 應用程序頁(Application Page) 和網站頁(Site Page)都從同一母版頁繼承其布局。

?? 應用程序頁(Application Page)與傳統的 Microsoft ASP.NET 3.5 網頁最為相似。但是，應用程序頁面并非直接派生自System.Web.UI.Page，而是派生自 LayoutsPageBase 或 UnsecuredLayoutsPageBase。應用程序頁面不在安全模式下運行，并且可能包含內嵌代碼。只有場管理員可以安裝應用程序頁面。

?? 網站頁(Site Page)是由最終用戶創建、編輯和自定義的頁面，是可以由用戶個性化定制與修改的頁面。網站頁是通過存儲在前端 Web 服務器（Front-End Web Server）的文件系統上的模板頁面設置的。在設置網站時，SharePoint Foundation 會創建指向文件系統上的頁面模板實例的指針，這個指針存放在使用了此網站頁的Website的Content Database中。這樣，SharePoint Foundation 就可以避免重復創建每次創建網站時都要設置的頁面的副本。

?????? ?????????????????????網站頁(Site Page)具有兩種類型 - 標準頁(Standard Page)和 Web 部件頁(Web Part Page)。

? ?? 標準頁(Standard Page)包含文本、圖像、Web 部件及其他元素。這些頁面是啟用 wiki 的頁面，可以包含 Web 控件和內嵌 Web 部件。標準頁(Standard Page)派生自 WikiEditPage 類，而不直接派生自 System.Web.UI.Page。

???? Web 部件頁(Web Part Page) ：顧名思義，它們是包含 Web 部件區域(Web Part Zone)的 Web 部件(Web Part)頁。Web 部件頁(Web Part Page)派生自 WebPartPage，而不直接派生自 System.Web.UI.Page。

???? Sharepoint2010中加入了第三種網站頁（Site Page）：PublishingPage，這種頁面只使用在發布網站(Publishing Sites)中。在發布網站中，作者和批準者(Author and Approvers)使用發布功能(Publishing Feature)來創建內容以提供給網站用戶訪問。通常來說，一個發布網站都會綁定有Approval工作流，這樣待發布的內容才能在正式發布前把握質量。Publishing Pages通常基于Page layouts這樣的頁面模板創建，Page Layouts提供了一致性的結構給Publishing Pages，并且它是可以被客戶化定制的。

???? Sharepoint還包括一套內建的用于移動設備的網頁。SharePoint Foundation 移動網頁比非移動網頁簡單得多。移動網頁不使用 ASP.NET 母版頁/內容頁技術，也不劃分為應用程序頁面和網站頁面。SharePoint Foundation 移動網頁都是應用程序頁面，且位于 \_layouts\Mobile 文件夾中。SharePoint Foundation 移動網頁在某個方面特別類似網站頁面：如果頁面包含移動的 Web 部件適配器，則必須將該適配器注冊為安全控件，否則將不呈現該適配器

上面對Sharepoint的網頁情況作了大致說明

下面讓我們來重點比較一下應用程序頁(Application Page)與網站頁(Site Page)，看看它們具體的區別:

1、應用目的(Typical purpose):

??? 應用程序頁( Application pages)側重于"功能"實現（function-oriented），比如象提供給用戶的用于創建一個新的Web Application的頁面那就是應用程序頁，你在那個創建頁面上輸入所需的參數，然后再點確定，從而創建一個新的Web Application。

??? 而網站頁（Site Pages）則側重于"內容"實現（Content-oriented），比如像在標準的Team Site中給用戶展示當前網站都有哪些list的頁面就是網站頁。

??? 當然，這種區分并不是強制性的，有時也有混用的情況，第三方可以開發一個用戶定義的Web Part，在這個Web Part上實現一些特定的用戶操作功能(eg:List管理功能，信息處理功能…，就像你一般的應用程序處理界面上的那些功能一樣)，然后再把這個Web Part加載到網站頁，從而讓網站頁也具有了"功能"操作性。有時這種方式比開發一個應用程序頁更靈活，也更便捷。

2、用戶定制能力(Customizability):

???? 網站的所有者(owner)以及擁有相應權限的用戶可以對網站頁(Site Page)進行用戶定制修改，用戶還可以添加一個新的ASCX頁面到網站頁陳列區（Site Pages Gallery）。

???? 但用戶卻無權對應用程序頁(Application Page)進行定制與修改，只有管理員才有權限安裝一個新的應用程序頁到網站上來。

3、繼承基類(Class inheritance):

??? 應用程序頁( Application pages)繼承自?LayoutsPageBase?類 或者UnsecuredLayoutsPageBase?類。

??? 網站頁（site pages）繼承自?WikiEditPage?類或?WebPartPage?類.

??? 而所有上面提到的基類又都繼承自ASP.NET的?Page?類.

4、Web 部件支持(Web Part support):

??? 應用程序頁( Application pages)沒有Web Part Zone或者動態的Web Parts，但它可包含靜態的Web Parts，可這種靜態的Web Parts沒多少實用價值，因為開發者完全可以采用傳統控件來實現要在此頁面上完成的功能。

??? 網站頁（Site pages）既可以包含靜態Web Parts也可以包含動態Web Parts和Web Part Zone。

5、存儲位置(Storage location):

????應用程序頁( Application pages)存儲在前端Web服務器(Front-End Web Server)的文件系統上，其位置是在對應的Web Application的_Layouts虛擬目錄(Virtual Directory)下,此虛擬目錄會映射到(Map to)服務器文件系統的實際磁盤目錄上，此目錄是 :%ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\TEMPLATE\LAYOUTS 目錄或其子目錄。

?????網站頁(Site Page)通常根據它們是否已經被進行了定制來分為Uncustomized Page和Customized Page兩種（在SPS2003中，使用的是Ghosted Page和Unghosted Page這兩個術語）,具體說明如下

???????????I、網站頁沒有被客戶個性化定制修改：當我們新建一個站點的時候，所有的頁面都是Uncustomized Page，這些頁面都是直接使用了存放在前端 Web 服務器（Front-End Web Server）磁盤上的頁面模板（位于%ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\TEMPLATE目錄及其子目錄(eg: SiteTemplates與Features子目錄就是常用的子目錄)，換言之，這個新站點的頁面其實是"不存在的"，它們只是一個"標記"（這也就是在SPS2003中，它們被稱為Ghosted Page的原因），如果用戶訪問一個頁面，SharePoint會自動從磁盤上找到那個真正的頁面模板文件，然后將其載入到內存中，解析它，并將其編譯成一個獨立的DLL文件（為了性能，這個DLL會緩存在磁盤上以避免下次重復編譯），然后載入這個DLL并運行和輸出.

??????????II、網站頁被個性化定制或修改：一旦網站頁被Microsoft SharePoint Designer這樣的工具修改，那么SharePoint會自動將修改后的文件內容保存到站點所用的內容數據庫(Content Database)中，它就成了一個Customized Page。當用戶訪問這個頁面時，SharePoint會自動從內容數據庫中讀出這個文件的內容，然后對其進行解析，運行。這種情況下，SharePoint不會再將其編譯成一個獨立的DLL文件，實際上，SharePoint會在內存中載入這個頁面的結構，運行，然后輸出，然后將它從內存中卸載以節省內存。

???????? 注：Uncustomized Site Page雖然存放在文件系統中，但實際上它在Content Database中也會有記錄，這個記錄主要用于保存.aspx頁面文件的存放路徑，這就是指向文件系統上的頁面模板實例的指針。為什么會這么做呢，那是因為Uncustomized Site Page通常會被若干個Website共享，所以，凡是調用到此Uncustomized Site Page的Website就會在它們的Content Database中存放此Page的路徑。例如：每一個Team Site的Content Database都會有記錄指向Team Site的Home Page，這個HomePage就是Uncustomized Site Page，當打開TeamSite的相關網頁時，系統就會根據此處存放的HomePage的路徑把HomePage調取并顯示出來。當然，如果有網站對此HomePage進行了個性化的修改，那么它會變成了Customized Page，于是相關修改內容就會保存進Content Database，而原先Content Database中保存的路徑記錄就會被移除。不過，可以通過 Web 瀏覽器或 SharePoint Designer 之類的工具將自定義頁面重置為原始模板頁面，即放棄用戶的個性化定制，重新使用以前的頁面模板，這樣一來，在Content Database中又會重新存放指向文件系統上的頁面模板實例的指針記錄。 有的時候，Uncustomized Site Page會被做為模板(Page Template)被存放在Content Database中的頁面實例所引用。總之記住：只要網站上的頁面沒有被個性化定制或修改，那么放在Content Database中的記錄就只是一個路徑指針用于指向這個頁面在文件系統中的存放路徑的。

6、可訪問性(Availability):

??? 一個應用程序頁(Application Page)可以被其所在的WebApplication中的任何Website訪問到。

??? 而一個網站頁(Site Page)通常卻只能被它所部署的網站中的用戶訪問到，雖然我們前面提到Uncustomized site pages也可以被多個Website訪問到，但這需要特定的手段才能做到（那些網站需要被做為Feature的一部分或Site Definition的一部分提供出來）。

7、解析模式(Parsing mode):

??? 應用程序頁(Application Page)通過"直接(Direct)"方式進行解析。所謂直接方式就是指通過標準的ASP.NET頁面解析器進行解析，當這個網頁首次被訪問時，它就會被解析器解析(Parsed)、編譯(Compiled)，并緩存在前端 Web 服務器（Front-End Web Server）的內存中，直到此請求所關聯的application domain或IIS被回收清空(recycled)。如果在回收前有其它訪問請求，那么它就會直接從緩存中提供給請求者而無需重新進行解析、編譯的過程。

??? 網站頁(Site Page)分兩種情況 ：

??????? I、Uncustomized site pages也是通過"直接(Direct)"方式進行解析。

??????? II、而customized site pages與添加到陳列區(Site Page Gallery)的新建網頁則是通過"安全模式(Safe Mode)"進行解析的。

??????? 安全模式(Safe Mode)解析特點如下:

???????? (i)、只有在Web Application的Web.config文件中注冊為"安全(Safe)"的控件(包括Web Parts)才能被解析和呈現。

???????? (ii)、內聯服務器端代碼(Inline server-side code)在安全模式下是不允許的，如果你在網頁中嵌入了內聯服務器端代碼，那么系統會返回給你一個報錯頁面。 所謂內聯服務器端代碼如下:?

<script?runat="server">?
[code?is?here]?
</script>?
或?
<asp:button?OnClick="MyButtonHandler()"?/>?

????????????? 對于后臺代碼(Code behind)和內嵌的JavaScript(embedded Javascript)是被允許的，因為它會被編譯成單獨的程序集并部署。

????????(iii)、這種Customized Site Page網頁與直接模式處理的應用程序頁是不同的，因為它不像應用程序頁一樣需要被系統編譯，因此，如果在此類網頁中加入諸如編譯指令之類的東西都是不起作用的。

???? 需要注明的是，這里的安全模式解析(safe mode parsing)與Sharepoint其它文檔提到的安全模式處理(safe mode processing)和安全模式呈現(safe mode rendering)其實指的都是同一件事。

?????Sharepoint為什么會引入這種安全模式呢?

???? 你可以想想，既然允許用戶個性化定制，那么就必須涉及到網頁行為的定制，由此產生的問題就是：用戶可能在個性化過程中加入執行代碼，如果這些代碼既安全又高效那也沒什么，但誰又能保證所有用戶都做到這點呢。還有就是這種網頁不能被編譯，這也不難理解，試想如果有成百上千個用戶都做了個性化定制，而這種個性化定制的網頁都必須要通過重新編譯才能呈現，那么我們的服務器將承受多大的壓力，并且這些被編譯的結果要放到服務器內存中緩存，這個緩存的內容只能通過回收application domain來清除，但問題是回收application domain就會清空程序集，程序集中還包括了其它網頁內容，你做不到僅僅清空你想要移除的那個特定用戶定制的網頁，要么都清空，要么都保留，這顯然是不合理的。此外在一個application domain中可以加載多少個程序集，在系統中也是有限制的。所以，所有這些因素都決定了為什么Sharepoint會引入安全模式解析，并且此解析方式為什么要按如此的規則開展工作。

???? 我們在前面提到：內聯服務器端代碼(Inline server-side code)在安全模式（Safe Mode）解析下是不允許的，其實準確的說應該是在"通常情況"下是不允許的。其實Sharepoint也不是那么絕情，它也留得有退路，它允許你通過修改Web Application的Web.config來實現允許內聯服務器端代碼或不安全控件，也即：向Web.config中的<Sharepoint>節點下的<SafeMode>元素中添加<PageParserPath>子元素，通過設置此元素的相關屬性來指明要向哪個網頁中添加內聯服務器端代碼或非安全控件(unsafe contrl)。顯然這樣作是比較危險的，所以你必須要非常小心,因為這種解禁可以是單個特定頁面，也可以是整個目錄的頁面。添加 PageParserPath 設置將使可將頁面上載到指定文件夾的任何人都能將任意的完全信任代碼寫入服務器。所以管理員在提供這些設置時應格外小心，要提前了解此操作存在的安全隱患，盡量保證系統的安全與性能。

???? 一種威脅的例子：

???? 如果你允許所有以 GetInfo*.aspx模式命名的網頁添加內聯服務器端代碼，那么別有用心者就會個性化一個攻擊性網頁并以GetInfoAsMyMind.aspx來命名，此命名當然能通過Sharepoint的查檢規則并獲得運行相關代碼的權力，結果就是對你的系統進行攻擊與傷害。

???? 下面的示例演示使用通配符的 PageParserPath 設置。

????? 添加此 PageParserPath 將允許對母版頁樣式庫具有權限的任何人上載服務器端代碼。在添加此類型的 PageParserPath 設置時要格外小心。

<SharePoint>?
<SafeMode?...>?
<PageParserPaths>?
<PageParserPath?VirtualPath="/_mpg/*"?CompilationMode="Always"?AllowServerSideScript="true"?IncludeSubFolders="true"/>?
</PageParserPaths>?

?????至于非安全控件(Unsafe control)是指通過編輯工具(Editing Tool)添加的控件（如：通過Sharepoint Designer添加的控件）。而至于WebPart則不管使沒使用<PageParserPath>元素來開啟(enable)非安全控件(Unsafe Control)，都必須要注冊為安全才能被允許。

????你還可以通過使用<PageParserPath>元素來開啟允許用戶定制網站頁(Customized Site Page)的可編譯功能。這樣這個網頁就會被編譯成DLL并存放到緩存中，顯然這種做法就類似于應用程序頁(Application Page)的編譯方式了，這樣做的好處就是加快此網頁的訪問響應速度。所以，它只針對那些經常會被訪問到的網頁有效。????

?

創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

以上是生活随笔為你收集整理的Sharepoin学习笔记—架构系列--01 Sharepoint的网页(Page)，网页解析(Parsing)与解析安全处理(Security)的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。