ASP.NET 2.0 當地語系化功能：一種當地語系化 Web 應用程式的新方法

作者：Michele Leroux Bustamante
IDesign Inc

2004 年 10 月

適用於：
   Microsoft ASP.NET 2.0
   Microsoft Visual Studio .NET
   Microsoft Visual Studio 2005
   當地語系化

摘要：隨著有越來越多的公司將他們的業務伸展到其他國家，使用 Microsoft ASP.NET 建立全球化的 Web 應用程式也變得越來越重要。ASP.NET 1.1 支援透過 ResourceManager 類別的方式來建立當地語系化的網站。ASP.NET 2.0 甚至使得提供支援給多國文化和地區支援更加簡單。

(此文章包含連至英文網頁的連結，列印共 23 頁)

下載本文的原始程式碼。

當地語系化與 .NET 1.x
介紹全新的 ASP.NET 2.0 當地語系化功能
 產生本機資源
 共用應用程式資源
 隱含的當地語系化運算式
 外顯的當地語系化運算式
 當地語系化 HTML 項目和靜態文字
 資源當地語系化和部署
 Runtime 資源提供者
 偏好的文化特定選擇
 結論
 其他資源

商業社群自我們 10 年前所知的網際網路開始，就陸續擴展到國際市場。各公司不僅透過其公司網站擁有全球化的 Web 呈現，更有越來越多的公司主控和/或授權最後可能服務全世界客戶的企業 Web 應用程式。準備好為這些網站和應用程式進行當地語系化是勢在必行的，因為大多數的客戶偏好以自己的母語和文化環境來做生意。不論為何種部署模型 (智慧型用戶端、網站和應用程式、Web 服務)，尤其是在架構和設計方面，這項突破需要規劃與努力是不容置疑的。有效的開發工具對於架構有比較良好的影響，但奇怪的是，Web 應用程式當地語系化這方面的工具改進還是不足。結果造成許多產業更依賴傳統且麻煩的當地語系化方法，反而花費更多的時間和金錢。

Microsoft ASP.NET 2.0 的發行承諾改變 Web 開發人員處理當地語系化的方式，使之變得更完備。隨著 Microsoft Visual Studio .NET 環境中有更多內建的工具、新的 Runtime 功能，以及豐富嶄新且特別針對當地語系化需求的程式設計 API，開發人員將能夠更迅速將可當地語系化的內容從他們的 ASP.NET 網頁分隔出來，以減少撰寫程式碼來存取當地語系化的工作內容，並可同時運用一致的程式設計模型擴充環境以滿足額外的需求。本白皮書將帶領您感受此一改良後嶄新的 ASP.NET 開發體驗，來為應用程式進行當地語系化做好準備。

當地語系化與 .NET 1.x

.NET Framework 1.x 引介了一種當地語系化的新架構，透過放入全新的附屬組件 (或僅資源的組件) 來支援非侵入性累加部署的文化特性支援。此一中樞與支點的開發形式允許開發人員藉由 Common Language Runtime 透過 ResourceManager 類別，來管理正確的當地語系化內容選擇。ResourceManager 的其中一項優點是，它會與封裝的資源後援機制互動，根據應用程式的 Runtime 文化特性設定，來尋找「最適合」的文化特性，藉此免去開發人員撰寫程式碼來管理載入每個 ResourceSet 的處理序以擷取當地語系化內容的需要。

資源可由 Windows 或 Web 應用程式取用，但 Visual Studio 2003 特別方便 Windows 開發人員當地語系化他們的 Windows Form。當表單的 Localizable 屬性設定為 true 時，會自動為可當地語系化的 form 和 control 屬性自動產生資源。屬性值會傳送至預設的資源以供稍後進行翻譯，而且會在 Runtime 從這些資源產生程式碼填入控制項，使用的是 ResourceManager 類別執行個體。ResourceManager 會取代執行中執行緒的 CurrentUICulture 設定，並嘗試在 ResourceSet 中找出與該文化特性相符的資源，否則的話，會重新排序到資源後援處理序。

注意：請在此處閱讀有關資源後援處理序。

.NET Framework 也包含許多文化特性感知的類別，會在產生像是格式化日期、時間和貨幣值時遵守 CurrentUICulture，進而減少開發人員所必須進行的冗長工作量。

注意：請從此 MSDN 參考閱讀更多有關文化特性感知類別的詳細資訊。

雖然附屬組件、資源管理員和文化特性感知類別的開發模式也都適用於 ASP.NET 應用程式，但還是缺乏用來將此模式整合至 Web Form 程式設計典型的開發者工具。到目前為止，產生網頁的資源項目、在 Runtime 存取那些資源，以及為每項要求設定正確的文化特性都需要手動來進行。因此，資源並未廣泛被認為是 Web 應用程式當地語系化過程的整合部份。當地語系化 Web 內容傳統上被視為是針對特定的文化特性複製整個網站、當地語系化所準備的靜態內容，以及針對任何共用程式碼基底撰寫自訂的程式碼，來管理當地語系化資料來源的擷取工作。但此方法在 ASP.NET 2.0 已得到大幅的改進。

注意：接下來的 MSDN 文件將探討在 ASP.NET 1.1 進行當地語系化的架構性方法。

介紹全新的 ASP.NET 2.0 當地語系化功能

ASP.NET 2.0 是以 .NET 1.x 當地語系化功能為基礎建置而成，特別改進了適用於網路開發人員的工作流程和功能。以下是驅動下一代當地語系化支援之設計目標的摘要：

支援 Web 應用程式資源產生的支援工具。
提供全新宣告式和 Runtime 程式設計建構函式來存取資源。
簡化將正確的文化特性套用至網頁要求，以及自動化 ResourceManager 安裝的過程。
支援 XCOPY 部署及小型商業網站之編譯步驟的去除。
支援企業開發人員擴充各個層面的資源取用和管理。
確保對整個 ASP.NET 控制項之全新當地語系化功能，以及其他適用 Runtime 元件和配接器的整合支援。

放入 Visual Studio 2005 和 ASP.NET 2.0 中的新功能承諾要藉由提供工具協助將可當地語系化的內容從網頁擷取出來、對資源取用提供更具整合性的 Runtime 支援以補足無狀態要求模式、提供現代宣告建構函式將資源結合到網頁輸出，以及提供新方法為往返過程自動化文化特性選擇等，來簡化 Web 應用程式當地語系化過程。以下功能尤其支援這些目標：

強型別資源 — .NET Framework 2.0 版本的核心是支援強型別資源，它們提供開發人員 Intellisense 並簡化在 Runtime 存取資源所需的程式碼。

Managed 資源編輯器 — Visual Studio .NET 2.0 包含一個新的資源編輯器，具有比較完備的支援可建立和管理資源項目，包括字串、影像、外部檔案和其他複雜的型別。

產生 Web Form 的資源 — Windows Form 開發人員已享有自動國際化的優勢。Visual Studio 2005 現在將透過自動產生 Web Form、使用者控制項和主版頁面的資源，來支援快速國際化。

改進 Runtime 支援 — ResourceManager 介面是由 Runtime 所管理，而且可透過更方便存取的程式設計介面迅速地存取到伺服器程式碼。

當地語系化運算式 — 網頁的現代宣告運算式支援將資源項目對應到控制項屬性、HTML 屬性或靜態內容範圍。這些運算式也可加以擴充，提供其他方式控制將當地語系化內容附加到 HTML 輸出的過程。

自動化文化特性選擇 — 管理每個 Web 要求的文化特性選擇可自動連結到瀏覽器喜好設定。

資源提供者模型 — 新的資源提供者模型可讓開發人員以不同的資料來源 (如純檔案和資料庫資料表) 來主控資源，同時用於存取該些資源的程式設計模型仍保持一致。

這些功能所具備的彈性足以為小型企業提供現成的支援，給予既可靠又有效率之產能導向解決方案，並在同時支援大型組織對無數部署架構與附加擴充性的複雜需要。此新模型的核心是在於改善運用與 Windows Form 程式設計模型配合的 Web 應用程式的資源的狀況，提供其他在開發週期及 Web 的 Runtime 需求方面的考量。以下案例詳細說明這些實作在 Beta 1 的新功能，另外解釋有關在 Beta 2 中可預期的革命性變更。

產生本機資源

.NET 資源使得選擇性取代特定語言和文化區域的內容成為可能，讓相同的程式碼基底可支援多種文化特性。但開發人員之所以針對 Web 應用程式投資此一途徑的小小誘因，是因為產生網頁的資源需要大量的人力。ASP.NET 2.0 提供一個簡單的方法自動產生網頁的資源，並同時支援複雜的內容代理分類，包括 HTML 項目和屬性、靜態內容，以及伺服器控制項。

若要產生特定 Web Form 的資源，請在 Visual Studio 2005 中的 [工具] 功能表選取 [產生本機資源]，在設計檢視中任何開啟的網頁都可以建立本機資源 (這包括 Windows Form、使用者控制項和主版頁面)。此步驟會自動產生為網頁一組預設的 .NET XML 資源 (.resx)，並將之放到本機資源專用的子目錄，目前命名為 \LocalResources (此目錄名稱在 Beta 2 將會變更)。

ms379546.loc_fig01(zh-tw,VS.80).gif

[圖 1] Web Form、使用者控制項和主版頁面全都可以從 Visual Studio .NET 2.0 內進行國際化。此特定的檢視展示針對數個頁面產生的預設資源。

本機資源是存放在 .resx 檔案中，其命名慣例會將之連結到它們提供服務的頁面 (請見 [圖 1])。例如，在為一個名為 site.master 的網站產生主版頁面的資源後，一個新的 .resx 檔案會出現在 \LocalResources 中，名為 site.master.resx。對於名為 default.aspx 的 Web Form，所產生的資源會命名為 default.aspx.resx。

Visual Studio 設計工具會先檢查該頁面及其控制項 (ASP.NET 伺服器控制項、自訂控制項，以及含 runat="server" 的 HTML 控制項) — 尋找以 LocalizableAttribute 標示的屬性：

 [Localizable(true)]
public virtual string Text
{
      get {...}
      set {...}
}

每個控制項可當地語系化的屬性都會自動放入資源中，加上每個屬性均有唯一識別碼可供識別。此一識別碼包含可識別頁面控制項和屬性名稱的前置詞。除非屬性值是在控制項宣告當中指定，否則該些值皆會設成控制項的預設值。下面的 LinkButton 宣告會在其宣告中為 PostBackUrl 和 Text 屬性指定一個值：

<asp:LinkButton id=lnkSelectCulture PostBackUrl="selectculture.aspx" 
  runat="server">Change Selected Culture</asp:LinkButton>

[圖 2] 顯示在其主控頁面產生本機資源 (在範例專案中，請見 cultureinfo.ascx) 後，針對此 LinkButton 所產生的資源。資源會存放在資源檔案中 (請見 cultureinfo.ascx.resx)，並將非當地語系化的屬性 (如 PostBackUrl) 預設排除在外。

[圖 2] 本機資源是根據 ASP.NET 伺服器控制項、自訂伺服器控制項，以及在伺服器上執行的 HTML 控制項 (runat="server") 而產生的。

當資源產生之後，也會跟著修改控制項宣告，以便透過宣告的方式建立屬性與資源項目之間的關聯。頁面剖析器會認出數個新的宣告運算式，而且它們會觸發程式碼產生，在 Runtime 以資源值填入控制項屬性。宣告當地語系化運算式是 ASP.NET 2.0 一種新的建構，類似資料繫結陳述式，但主要是針對存取資源而設計的。這些運算式分成兩種形式：隱含與外顯。隱含運算式會在產生本機資源時自動插入，而且它們支援在單一宣告中將多項資源項目對應到一組控制項屬性。外顯運算式則是開發人員可加入以進一步控制頁面當地語系化的宣告。

下列由 meta:resourcekey 所識別的隱含運算式，是針對前一 LinkButton 宣告而產生的，而現在為此控制項指定資源識別碼前置詞。

<asp:LinkButton id=lnkSelectCulture PostBackUrl="selectculture.aspx" 
  runat="server" meta:resourcekey="LinkButtonResource1">
  Change Selected Culture</asp:LinkButton>

使用此前置詞的控制項屬性的資源項目，會在 Runtime 時自動對應到適當的控制項屬性。控制項宣告中每個屬性的值會保持不變，包括該些置入資源的值。這些預設值會出現在「設計檢視」中，提供該控制項在頁面當中的位置。當頁面經過剖析之後，即會使用當地語系化運算式來產生會將資源套用到控制項屬性的程式碼。開發人員並不需要撰寫程式碼來產生實體的 ResourceManager，在 Runtime 時存取這些本機資源。

在 Runtime 時，會優先採用資源值，但缺乏資源時，會顯示預設值。這對於網路設計師非常實用，允許他們不需要完整的網站部署，就可以檢視網頁的內容。出現在「屬性 (Properties) 視窗」中已經當地語系化的屬性會以特殊的圖示標示，指出它們的值是從資源取出來的。[圖 3] 展示一個 ASP.NET ImageButton 控制項，其中一些屬性繫結到共用資源 (以藍色表示)，而其他則繫結到本機資源 (以紅色表示)。透過運算式建立的屬性繫結會在稍後章節更詳細討論。

ms379546.loc_fig03(zh-tw,VS.80).gif

[圖 3] 已經當地語系化的屬性可輕鬆藉由 [屬性視窗] 檢視中所示的特殊圖示找出。

截至目前，討論的重點一直放在產生本機資源，這預設會為可當地語系化控制項屬性產生隱含的當地語系化運算式及資源。它也會將屬性繫結至共用應用程式資源。此外，也可能自動產生非可當地語系化之控制屬性、其他 HTML 項目及靜態內容的本機資源。這是透過將外顯當地語系化運算式套用到該些頁面和控制項項目而完成的。換句話說，開發人員可以透過宣告的方式指出有哪些額外的內容應該要當地語系化，以便包含在頁面的資源產生過程中，或選擇從其他來源取出。

共用應用程式資源

自動產生每個頁面的本機資源可能會造成重複輸入和過度翻譯。幸運的是，ASP.NET 2.0 有一個內建的重複使用模式，具有主版頁面和使用者控制項，使得標題、功能表、提要欄位和 HTML 的其他區段可以在 Web Form 之間共用。每個主版頁面、使用者控制項和 Web Form 都擁有自己的本機資源組，因而能夠減少資源重複。然而，一些像是詞彙項目、錯誤訊息的資源項目，以及像是方向屬性的功能驅動程式，當要在全部頁面之間結合和共用時，可能蠻有用的。

本機資源是透過設計工具針對每一頁自動產生，而共用應用程式資源則是靠手動建立的。這等於是新增一個新的應用程式資源 (.resx) 到解決方案，並將之放置到共用資源專屬的專用目錄，目前命名為 \Resources (此目錄名稱將在 Beta 2 變更)。這與為 1.x 應用程式產生共用資源的方法一致，不過，新的資源編輯器可簡化資源項目的建立和編輯工作，而且共用資源是具備 Intellisense 支援的強型別。共用資源也包括 ASP.NET 2.0 新的頁面剖析及 Runtime 模型。使用外顯當地語系化運算式可將它們繫結至各頁面，而且會自動產生實體的 ResourceManager 並加以快取，進而免除開發人員管理此生命週期的需要，在 Runtime 存取資源。

Visual Studio 2005 包括一個新的 Managed 資源編輯器，如 [圖 2] 和 [圖 4] 所示。[圖 2] 說明資源字串編輯器，類似於 Visual Studio 2003 中的資源編輯器。另一方面，[圖 4] 則說明編輯器所支援的預定義資源類別，包括字串、圖示和其他影像檔案類型、音效檔案類型，以及其他檔案，包括 XML。在這些資源編輯其所支援的預定義類型之外，還可以透過撰寫程式的方式將其他複雜的型別插入資源中。基本的資源檔案是以 XML 為基礎。

[圖 4] 全新的 Managed 資源編輯器為無數預定義資料型別提供整合支援，並提供其他資源檢視，包括縮圖檢視，如此處所示的影像資源類別。

當以檔案為主的資源，如影像、聲音和 XML 檔案透過編輯器插入時，預設會被定義為 ResxFileRef 項目。比方說，下例即說明針對外部影像和 XML 檔案，分別建立的資源項目。

<data name="Spain" type="System.Resources.ResXFileRef, System.Windows.Forms">
    <value>..\Images\Spain.gif;System.Drawing.Bitmap, 
     System.Drawing, Version=2.0.3600.0, Culture=neutral, 
     PublicKeyToken=b03f5f7f11d50a3a</value>
</data>
<data name="supportedCultures" type="System.Resources.ResXFileRef, 
  System.Windows.Forms">
    <value>..\Xml\supportedCultures.xml;System.String, mscorlib, 
     Version=2.0.3600.0, Culture=neutral, 
     PublicKeyToken=b77a5c561934e089;iso-8859-1</value>
</data>

資源編譯器會解析每個檔案參考，而且 Runtime 會處理將參考檔案載入資料流的工作，將之轉換成正確的資料型別。若是影像，型別會是 System.Drawing.Bitmap，而且預設會將 XML 當作 System.String 傳回。對於預先編譯的 Web 應用程式，會將資源內嵌到輸出組件中。這表示實際的檔案並不需要與網站一起部署。與 ASP.NET 2.0 新的編譯模型一致 (詳細資訊，請參閱本文)，也可以部署資源及相關檔案以進行完整的 Runtime 編譯。

共用資源其中一項顯著的優點是，它們會編譯成一種強型別類別，使項目可依它們的資源識別碼直接存取。舉例來說，一個叫做 Flags.resx 的共用應用程式資源會當作 Runtime 型別 Resources.Flags 來存取。Intellisense 可透過內建的 Resources 型別來使用，但若有可用的型別轉換器，資源項目就會以其原始的資料型別傳回。若是影像，則資料型別即是 System.Drawing.Bitmap，如 [圖 5] 所示。

ms379546.loc_fig05(zh-tw,VS.80).gif

[圖 5] 共用資源會編譯成強型別資源，而且可透過內建的 Resources 物件存取。

以影像為主的資源對於 Web 控制項的開發人員，在封裝控制項所用的內嵌圖形時可能蠻實用的，但一般對可迅速取用二進位影像格式來進行顯示的 Windows Form 開發人員比較受用。無論如何，強型別資源和 Intellisense 都會提高在 Runtime 存取資源的效率。例如，[圖 5] 也示範了強型別「詞彙 (Glossary)」資源如何使擷取已命名的字串值更加方便。

本機和共用資源都可透過宣告或撰寫程式的方式來存取，已產生當地語系化內容。下文將討論這些方法。

隱含的當地語系化運算式

如前所述，當產生本機資源時，它會觸發對頁面上的控制項宣告的修改動作。預設的表現方式是讓隱含的當地語系化運算式新增到伺服器控制項，如剖析階段所指出的 meta:resourcekey 屬性。

<asp:LinkButton id=lnkSelectCulture PostBackUrl="selectculture.aspx" 
  runat="server" meta:resourcekey="LinkButtonResource1">
  Change Culture Settings</asp:LinkButton>

此運算式會指定所有與控制項屬性相關之資源項目的預期前置詞 — 所以採用「隱含運算式」一詞。自動產生資源只會考慮可當地語系化的屬性，但實際上任何使用此前置詞後面跟著一個有效屬性名稱的資源項目，都會在編譯的頁面程式碼中繫結到該屬性。在上例中，LinkButtonResource1 是資源識別碼前置詞，而 [圖 2] 中顯示的資源項目在每個適用於相同控制項執行個體 (亦即 LinkButtonResource1.Text) 的屬性是使用此前置詞。

此宣告陳述式 (meta:resourcekey) 向 ASP.NET 頁面剖析器指出，它應該產生程式碼從預設本機資源擷取屬性值。所得的程式碼最後會使用 Runtime 方法，加上 GetPageResourceObject (此方法名稱在 Beta 2 可能會變更) 的協助來存取資源。在所提供的範例程式碼中，編譯的 cultureinfo.ascx 頁面包含以下程式碼，會建立並初始化 LinkButton、lnkSelectCulture：

LinkButton button1 = new LinkButton();
this.lnkSelectCulture = button1;
button1.ID = "lnkSelectCulture";
button1.PostBackUrl = "selectculture.aspx";
button1.AccessKey = ((string) 
  base.GetPageResourceObject("LinkButtonResource1.AccessKey"));
button1.SoftkeyLabel = ((string) 
. base.GetPageResourceObject("LinkButtonResource1.SoftkeyLabel"));
button1.Text = ((string) 
  base.GetPageResourceObject("LinkButtonResource1.Text"));
button1.ToolTip = ((string) 
  base.GetPageResourceObject("LinkButtonResource1.ToolTip"));
button1.Visible = ((bool) 
  base.GetPageResourceObject("LinkButtonResource1.Visible", 
  typeof(Control), "Visible"));

隱含的當地語系化運算式會在產生頁面資源時，套用到所有伺服器控制項宣告。您可以使用此一替代語法指出該控制項不應該進行當地語系化，來抑制此行為。

<asp:LinkButton id=lnkSelectCulture PostBackUrl="selectculture.aspx" 
  runat="server" meta:localize="false">Change Culture 
  Settings</asp:LinkButton>

在您的當地語系化策略中被認為不重要的各個控制項屬性，可使用如 [圖 2] 中所示的 Managed 資源編輯器，將之從本機資源中手動移除。這可減少頁面剖析器要將本機資源項目套用到控制項屬性所產生的程式碼數量，因為它只會反映出現在頁面預設本機資源中的該些項目。這也表示其他新增到當地語系化資源的識別碼值，將不會在 Runtime 時套用，因為沒有產生任何程式碼來進行此動作。

這類的當地語系化運算式會運用將與 .NET Framework 2.0 一起發行的全新「運算式產生器」功能。隱含的當地語系化運算式可從單一宣告產生程式碼填入所有可當地語系化的伺服器屬性，進而節省開發人員的時間。這免除了目前 1.x Web 應用程式所需的手動步驟，該步驟需要有典型的自訂資料繫結陳述式或自訂程式碼，從當地語系化資源或資料來源提取值。下一節將評論如何為靜態文字及特定的控制項屬性的當地語系化 (包括那些不會被 LocalizableAttribute 標示的屬性)，自動產生額外的資源。

外顯的當地語系化運算式

雖說要自動產生當地語系化控制項屬性的資源相當順手，但開發人員需要的是一套也可以支援當地語系化特定屬性值及其他內容區塊的解決方案。外顯的當地語系化運算式提供這樣的一種方式，透過宣告將特定資源項目指定到伺服器控制項屬性及其他 HTML 項目。譬如，下面的 ImageButton 控制項宣告就是使用外顯運算式來設定它的 AlternateText 屬性：

<asp:ImageButton id="btnIDesign" Runat="server" 
  ImageUrl="~/Images/idesignlogo.jpg" 
  AlternateText='<%$ Resources: MissionSatatement, "IDesign Inc." %>' 
  PostBackUrl="http://www.idesign.net" 
  meta:resourcekey="ImageButtonResource1" />

外顯的當地語系化運算式是遵循此語法：

<%$ resources: [applicationkey], resourcekey, [default] %>

在上列的範例當中，忽略了 applicationkey，因為 MissionStatement 的值是從本機資源取出。resourcekey 值指出要提取的資源項目，而 default 值則表示設計工具的預設值。設計工具預設值只會在設計階段出現，而且對於編輯頁面配置的開發人員或網路設計師來說，相當實用。

外顯運算式也可以透過 [屬性 (Properties)] 視窗使用如 [圖 6] 中所示的 [運算式 (Expressions)] 對話方塊來產生。此對話方塊支援建立可將控制項屬性繫結至本機或共用資源的外顯運算式。

[圖 6] 開發人員可使用「運算式 (Expressions)」對話方塊，以直覺的方式將資源對應到屬性，並產生外顯的當地語系化運算式。

使用此對話方塊，開發人員可像在設定其控制項屬性一樣，透過 [屬性 (Properties)] 視窗建立外顯運算式。若從「運算式屬性 (Expression Properties)」忽略 ClassName (請見 [圖 6])，就會出現一個內有可用本機資源識別碼的下拉式清單 (假設已經建立該些資源)。否則，會在識別碼符合 ResourceKey 的地方，使用目標為本機資源的外顯運算式來產生本機資源項目。再次強調，這可減少開發人員建立資源項目以及在 Runtime 時產生程式碼來填入屬性的工作量。

若要存取共用資源，ClassName 應該在全域資源目錄中指出有效資源檔案的名稱。與本機資源不同的是，目標是共用資源的外顯運算式並不會自動產生該些資源。

隱含和外顯的當地語系化運算式可混合使用，以便從共用資源提取出特定的屬性，並同時從本機資源提取其他屬性。下例顯示相同的 ImageButton 控制項宣告，從共用資源 Glossary.resx 擷取它的 AlternateText，而同時間使用隱含語法從本機資源取出其他屬性。

<asp:ImageButton ID="btnIDesign" Runat="server" 
  ImageUrl="~/Images/idesignlogo.jpg" 
  AlternateText='<%$ Resources:Glossary, MissionSatatement, 
  "IDesign Inc." %>' PostBackUrl="http://www.idesign.net" 
  meta:resourcekey="ImageButtonResource1" /></td>

使用外顯的當地語系化運算式，就有可能運用細微性來控制要當地語系化的屬性，以及位置。在控制項宣告同時包含外顯和隱含運算式的情況下，頁面資源會依如下方式產生：

由指定共用資源的外顯運算式所繫結的屬性會從本機資源產生的過程中忽略。
由本機資源的外顯運算式所繫結的屬性會產生一個 resourcekey 的項目加上 default 值。
其餘不由外顯運算式所繫結的可當地語系化屬性，會產生一個 resourcekey.propertyname 的項目，加上在控制項宣告中指定的值，或該控制項的預設屬性值。

如稍早所述，當剖析頁面時，會從這些宣告自動產生程式碼，從共用或本機資源來取得屬性值。在上例中，所得的程式碼會建立一個 ImageButton 控制項，並從共用的 Glossary 資源設定其 AlternateText 屬性，而其餘可當地語系化的屬性會由本機資源設定。

ImageButton button1 = new ImageButton();
// other initialization code
button1.ID = "btnIDesign";
button1.AccessKey = (string) 
  base.GetPageResourceObject("ImageButtonResource1.AccessKey");
button1.AlternateText = (string) base.GetAppResourceObject("Glossary", 
  "MissionStatement");
button1.ImageUrl = (string)
   base.GetPageResourceObject("ImageButtonResource1.ImageUrl");
button1.ToolTip = (string) 
  base.GetPageResourceObject("ImageButtonResource1.ToolTip");
button1.Visible = (bool) 
  base.GetPageResourceObject("ImageButtonResource1.Visible", 
  typeof(Control), "Visible");

當地語系化 HTML 項目和靜態文字

使用隱含和外顯的當地語系化運算，使得產生伺服器控制項屬性的資源更加簡單。但是，要準備將頁面進行當地語系化，也必須考慮其他內容，如 HTML 頁面標題、方向屬性及靜態內容。當地語系化運算式也可套用於 @Page 指示詞及 HTML 的其他區段，透過宣告的方式指出在產生頁面支援之前其他要進行當地語系化的區域。

HTML 控制項

除非在伺服器上執行 HTML 控制項 (runat="server")，否則它們無法享有隱含或外顯運算式的優點。一旦標示為伺服器控制項，該控制項可當地語系化的屬性就會自動產生本機資源。與 ASP.NET 和自訂伺服器控制項一致，HTML 伺服器控制項也可以繫結到隱含或外顯運算式，後者可透過稍早提過的 [運算式 (Expressions)] 對話方塊來產生。

在頁面標題中發現的 HTML 項目也可以透過宣告的方式繫結到資源，這對頁面標題和樣式表連結很有用。實際上 HTML 頁面標題項目蠻特殊的，因為它也是一個 Page 屬性，可透過 @Page 指示詞設定。在預設情況下，在產生本機資源時，即會將隱含運算式指定給每一頁。

<%@ page title="Global Welcome" meta:resourcekey="pageTitle" %>

這也可修改成外顯運算式，從共用資源來取代本機資源取出值。

<%@ page title='<%$ resource:Glossary, DefaultPageTitle, "Global Welcome" %>' %>

不論是哪一種運算式，都會覆寫 HTML 標題的 <title> 項目中找到的值，而且也可在缺乏運算式時，使用外顯運算式直接套用到在此處顯示的 <title> 項目。

<head runat="server">
   <title text='<%$ resource:Glossary, DefaultPageTitle %>'>Global Welcome</title>
</head>

方向屬性

方向性設定已透過一個新 Direction 屬性的提供而加入改進的支援，像是 <asp:Panel> 的控制項都支援該屬性。使用共用資源指出應用程式整體方向性，根據文化特性的不同，預設 "LTR" 方向可以在預設的共用資源中標明，並可指定 "RTL"，依文化特性來覆寫此值。

為了控制瀏覽器捲軸的方向性並設定網站的整體方向性，此外顯運算式會從共用資源提取正確值，並使用設計工具的預設值，"LTR"：

<html runat="server" dir='<% $Resources: Direction, "LTR" %>' >
...
</html>

另外也會使用一個面板來影響內含控制項的方向性：

<asp:panel runat="server" direction='<% Resources:Direction, "LTR" %>'>
...
</asp:panel>

有關 Visual Studio .NET 中方向支援的詳細資訊，請造訪此網站。

靜態文字

當地語系化運算式在設定控制項屬性和其他 HTML 項目時很實用，不過，許多準備好進行當地語系化的網頁都已經包含大量與 ASP.NET 控制項相互混合的靜態內容區塊。藉此，提供了一個新的 ASP.NET Localize 控制項將靜態內容標示成可當地語系化，使之可包含在資源的產生過程中。若在發出命令產生資源之前，指定了一個 meta:resourcekey，就會使用在控制項中指定的識別碼 (這也適用於其他控制項)。

<asp:Localize runat="server" 
  meta:resourcekey="welcome">Welcome!</asp:Localize>

在此例中，會為 Localize 控制項的 Text 屬性產生新的本機資源項目，並加上資源前置詞 "welcome" (welcome.Text)。為了外顯地從共用資源填入靜態文字，可由外顯的當地語系化來指定 Text 屬性。

<asp:Localize runat="server" text='<%$ resources: Glossary, 
  welcomeText%>'>Welcome!</asp:Localize>

與其他情況一樣，這些宣告陳述式會剖析成程式碼，要求資源設定控制項屬性，在此例中為 Text 屬性。任何出現在此控制項的宣告中的 HTML 標記，都會包含在資源的產生過程中，而這可能會複雜化翻譯過程，所以最好避免包含標記。

Localize 控制項比其基底類別 (Literal 控制項) 還重要的地方是它會在 Runtime 的時候被視為 Literal 控制項；不過，設計工具會加以忽略並允許開發人員直接在「設計檢視」中編輯靜態內容 (不像 Literal 控制項會在「設計檢視」中受容器限制)。

資源當地語系化和部署

全新的宣告陳述式、自動產生頁面資源，以及強型別共用資源的出現，一起使得開發人員準備 Web 應用程式進行當地語系化的工作更簡單。存放在 \LocalResources 和 \Resources 目錄 (分別是本機和共用資源) 中的預設資源，可翻譯成受支援的文化特性，它們翻譯的版本會複製到與來源一樣的同一個目錄中。翻譯資源的命名慣例遵守的規則與 1.x 一樣。文化特性代碼會包含在翻譯的 .resx 檔案名稱中。[圖 7] 展示頁面資源翻譯成西班牙文、法文和義大利文的範例專案的展開檢視。

ms379546.loc_fig07(zh-tw,VS.80).gif

[圖 7] 與 1.x 資源一致的命名慣例，.resx 檔案應該根據文化特性代碼命名。

.NET Framework 1.x 應用程式通常會一同推出已經過當地語系化的附屬組件，但 ASP.NET 2.0 有一組新的部署選項：

ASP.NET 2.0 Runtime 會繼續支援傳統的部署模型，其中的 \bin 目錄包含本機組件相依性，而子目錄會根據支援的文化特性包含附屬 (僅限資源) 組件。
ASP.NET 2.0 預先編譯會將網頁 (也就是頁面、使用者控制項和主版頁面)、其本機資源及其程式碼分隔檔案視作同一單元 — 將它們編譯成部署組件。共用資源也會預先編譯成要部署的組件。任何參考的資源項目，像是影像或 XML 檔案，也都會編譯成組件單元。基本上，預先編譯 ASP.NET 2.0 Web 應用程式變成是捨棄二進位編碼，而透過封裝提供更高層的保護來保障檔案安全。
ASP.NET 2.0 也支援完整的 Runtime 編譯。這表示網頁、程式碼分隔檔案、其他原始程式碼、資源 (共用及本機)，以及其他輔助應用程式檔案，全都可以依原始形式部署。Runtime 編譯器接著會負責剖析頁面並馬上產生組件。此模型提供最大的彈性，但主要只對於經常變更，並且不需要高階原始程式碼安全性的輕量型 Web 應用程式才比較適用。
ASP.NET 2.0 發行時，也可能可以混合兩和三種選項。也就是說，具備了將頁面和資源部署成來源，並同時將所有程式碼分隔檔案及其他來源編譯成二進位組譯碼以進行部署的能力。這提供編輯頁面配置和資源內容，或為一或多頁部署新當地語系化資源的彈性，而不會導致不受影響的應用程式組譯碼中動態重新編譯。

ASP.NET 2.0 編譯器在第二、第三和第四種情況下，會自動將位在 \LocalResources 和 \Resources 目錄中的原始檔編譯成組譯碼。在第三和第四種情況中，會在頁面編譯之前、第一次存取頁面或當頁面來源或其 .resx 檔案經過修改時，編譯本機資源。因為 .resx 有一個建置提供者，所以不需要編譯步驟就可加以部署。

如第一種狀況所述，與 1.x 組件舊版相容的支援、中立資源，以及相關聯的附屬組件都會保存下來。此部署模型並不會利用 2.0 的當地語系化運算式，這些資源無法透過預設 Runtime 資源提供者模型存取。運算式產生器和資源提供者的擴充模型，在將 2.0 的產能功能與 1.x 資源部署搭配運用時，將蠻實用的。

Runtime 資源提供者

為了與 ASP.NET 1.x 應用程式中的 ResourceManager 搭配使用，在執行資料繫結陳述式或其他從資源擷取值的機制之前，必須在程式碼中產生實體的 ResourceManager。ASP.NET 2.0 會依需要、在存取本機和共用資源時自動產生實體的資源管理員，以免去撰寫程式碼來管理此程序。透過使用宣告陳述式以資源值填入控制項屬性和 HTML 項目，不需要撰寫任何程式碼就可以產生完整當地語系化的頁面！

預設的 ResourceProviderFactory 會負責透過相關的設計工廠在 Runtime 時及設計階段，產生頁面的資源提供者和共用資源。開發人員可以撰寫程式碼，使用透過 Beta 1 中的 Page 物件公開的 GetPageResourceObject，來存取本機資源中的值：

if (this.Context.User.Identity.IsAuthenticated)
mnuLogin.Text = GetPageResourceObject("Login");
else
mnuLogin.Text = String.Format(GetPageResourceObject("LogoutUser", 
  this.Context.User.Identity.Name);

這可以在 Runtime 決策對資源相依的 HTML 輸出是必要時，用來覆寫宣告當地語系化運算式。若要存取共用頁面資源，Page 物件會公開不同的方法：

string cultures = 
  (string)this.GetAppResourceObject("supportedCultures");

對於共用資源，開發人員比較有可能會運用在此處顯示的 Intellisense 和強型別資源存取，擷取一個儲存為 String 型別的 XML 資源：

string cultures = Resources.Cultures.supportedCultures;

最後，GetPageResourceObject 和 GetAppResourceObject 會透過設定的資源提供者取得對適當資源的存取權。因此，若建立自訂資源提供者來存取共用 1.x 的資源，這些方法就能夠透過 GetAppResourceObject 從該些共用資源擷取。

偏好的文化特性選擇

傳統上在 1.x ASP.NET 應用程式中，要為每項要求選擇文化特性時，會考慮兩個重要的方法。對於將整個網站複製到文化特性特定的子目錄中的應用程式，web.config 中的 <globalization> 項目會指出，從該些子目錄要求資源的 Runtime 執行緒應該使用哪個文化特性和 UI 文化特性。

<system.web>
<globalization culture="es-ES" uiCulture="es">
</system.web>

而對於使用單一程式碼基底的應用程式，這些宣告設定並沒有什麼功用。而是使用 Runtime 程式碼手動對每項要求執行緒設定文化特性，使其可動態地為每個提出要求的使用者選擇文化特性。使用者偏好的文化特性可從資料庫設定檔、HTTP Cookie，或從 Web 瀏覽器的語言設定加以收集。不論是哪一種情況，要求執行緒的 UI 文化設定都會決定 ResourceManager 要在 Runtime 時取出哪些當地語系化資源，而文化特性設定會影響文化特性感知的格式，如前所述。

ASP.NET 2.0 引介了一種新功能，根據 Web 瀏覽器的喜好設定在 Runtime 時自動化文化特性的選擇。同樣支援文化特性和 UI 文化特性設定的 @Page 指示詞，可用來指示要根據瀏覽器的喜好設定執行特定頁面。

<%@ Page uiCulture="auto" culture="auto">

應用程式的 web.config 檔案也可以為整個應用程式套用此設定：

<system.web>
<globalization culture="auto:en-US" uiCulture="auto:en">
</system.web>

auto 之後的冒號可讓您在沒有事件 HTTP 標頭可用的情況下，指定預設的文化特性。因為文化特性必須設定為特定文化特性，在上面的範例顯示其文化特性為 en-US。

最終的結果是 Runtime 會自動偵測由瀏覽器送出的 ACCEPT_LANG 標頭，並在頁面生命週期相當早的階段將執行緒設定為使用者語言喜好設定清單中的第一個語言。若為應用程式使用者另外存有設定檔，或使用者可以透過網站選擇特定的文化特性，開發人員就必須撰寫程式碼來覆寫由 Runtime 處理的 auto 設定。範例程式碼中示範有完成此一動作的其中一種方法。

結論

為了迅速因應未來產品發行的需要以擴展到全球市場，在產品開發週期中提早定義全球化策略是刻不容緩。ASP.NET 2.0 這些全新的當地語系化功能將方便開發人員遵循策略來當地語系化應用程式，並同時減輕產品開發週期的額外負擔。自動產生頁面資源及全新的 Managed 資源編輯器使得建立 Web 應用程式的資源更加簡單。宣告式當地語系化運算式不但確保了所有必要的頁面項目都已當地語系化，更有助於自動產生適當的頁面資源。一套新的 Runtime 模型象徵著開發人員可以選擇不要再編譯附屬組件、產生資源管理員，以及根據文化特定來設定要求執行緒。最後，這也造就 Web 應用程式與單一程式碼基底的推出，縮減推出一套可擴展到全球市場的解決方案相關的成本和精力。