今天發現 Asp.net 在 Server 端收到 各瀏覽器 Response 回的UpLoadFile.PostedFile.FileName傳回的值有些差異。
以上傳D:\123.txt為例，各瀏覽器傳回值如下：
因此在CodeBehide取值時，要特別注意。會有差異。
可以多使用Path.GetFileName()，便可避免因瀏覽器傳回的差異，而取到不相同的值了!
程式碼如下：
Path.GetFileName(UpLoadFile.PostedFile.FileName);
FCKEditor 是個很讚的線上編輯器，這模組，可讓我們直接在線上，類似使用frontpage等工具一樣的操作，去編寫一個網頁。因此也被許多論壇所採用!如果有機會，看看FCKEditor的Source，會發現它基本上是個幾乎全部使用Javascript動態產生的環境。真的是嘆為觀止!今天要介紹的是一個在這編輯器上的客製功能。
因為我們慣用語言是中文，中文在編碼上要相當注意，不然時常會發生亂碼的問題，例如FckEditor的Link模組中，可讓我們加入MailTo功能，畫面如下： 
而編輯器最後便會幫我們在網頁上，加入一個如：mailto:電子郵件地址?subject=主題&body=內文，的連結。而問題也就發生在主題與內文的部分，FCKEditor預設會幫我們把主題與內文的部分，做Javascript的Encode，Encode過得編碼為UTF-8的格式(FCKeditor預設使用encodeURIComponent方法做Encode)，但這樣的連結，就必須考慮到讀取的介面是否支援了，例如outlook是否支援。經過測試，outlook 2010 以前的版本，均只支援讀取big5的編碼格式，而outlook 2010 則只支援使用unicode編碼。因此FCKEditor編輯器產生的MailTo連結，在使用outlook 2010開啟時，十分正常，但其他之前版本的outlook則全部變成亂碼。
因此有了今天這篇文章，如何在FCKEditor自訂，讓MailTo改使用Big5編碼。時做的步驟如下：
<%@ Page Language="C#" %>
<%
if (Request.QueryString["data"] != null)
{
try
{
string data = HttpUtility.UrlDecode(Request.QueryString["data"]);
string big5encode = HttpUtility.UrlEncode(data, Encoding.GetEncoding("Big5"));
Response.Write(big5encode);
}
catch
{
Response.Write(Request.QueryString["data"]);
}
}
else
{
Response.Write(Request.QueryString["data"]);
}
%>
新增第二個頁面FCKbig5decode.aspx，用於將字串做URLDecode。
<%@ Page Language="C#" %>
<%
if (Request.QueryString["data"] != null)
{
try
{
string data = Request.QueryString["data"];
string big5encode = HttpUtility.UrlDecode(data, Encoding.GetEncoding("Big5"));
Response.Write(big5encode);
}
catch
{
Response.Write(Request.QueryString["data"]);
}
}
else
{
Response.Write(Request.QueryString["data"]);
}
%>
將以上兩個檔案，新增於路徑 fckeditor\editor\dialog\fck_link\ 下。 function Big5encodeURIComponent(str) {
var xml = new ActiveXObject("MSXML2.XMLHTTP");
var data = encodeURIComponent(str);
xml.open("get", "fck_link/FCKbig5encode.aspx?data=" + data, false);
xml.send();
return xml.responseText;
}
第二段用來與Server端FCKbig5decode.aspx頁面互動，做字串的Decode
function Big5decodeURIComponent(str) {
var xml = new ActiveXObject("MSXML2.XMLHTTP");
var data = encodeURIComponent(str);
xml.open("get", "fck_link/FCKbig5decode.aspx?data=" + data, false);
xml.send();
return xml.responseText;
}
---------------------------------------------------------------------------------------------------------------------
[2010/07/22]最新訊息，上方有提到，outlook 2010已改 mailto 使用 utf-8 編碼格式。這是說法是錯誤的，說明如下：
正確來說，應該是在新版本的IE8中(不太確定是否是IE8、或更早版本、或其實在系統中亦可設定?!)，加入了一個選項，截圖如下：
這個選項便影響整體OS中，所有由瀏覽器送出 mailto 連結給 outlook 時所使用的編碼方式!
參考幾篇不錯的文章：
並依得到的資訊，實際測試字串"A
| 文字類型 | 英文 | 數字 | 中文 | Unescaped characters | Reserved characters | Score | |||||||||||||||||||||
| 原始字串 | A | Z | a | z | 0 | 1 | 堃 | - | _ | . | ! | ~ | * | ' | ( | ) | ; | , | / | ? | : | @ | & | = | + | $ | # |
| escape後 | A | Z | a | z | 0 | 1 | %u5803 | - | _ | . | %21 | %7E | * | %27 | %28 | %29 | %3B | %2C | / | %3F | %3A | @ | %26 | %3D | + | %24 | %23 |
| encodeURI後 | A | Z | a | z | 0 | 1 | %E5%A0%83 | - | _ | . | ! | ~ | * | ' | ( | ) | ; | , | / | ? | : | @ | & | = | + | $ | # |
| encodeURI Component後 | A | Z | a | z | 0 | 1 | %E5%A0%83 | - | _ | . | ! | ~ | * | ' | ( | ) | %3B | %2C | %2F | %3F | %3A | %40 | %26 | %3D | %2B | %24 | %23 |
由上方的資訊可以整理出一些結論：
所以在使用時，我認為可由兩方面去思考，判斷應使用哪一種Encode：
今天專案將Web應用程式部署至64位元的作業系統時，
果不其然的發生了問題，有支程式用 Microsoft.Jet.OLEDB.4.0 Provider 把Excel資料讀進來。
但在64位元的環境執行時，這段程式出了問題。
上Google一查，原來是 Microsoft.Jet.OLEDB.4.0 Provider 沒有For 64bit的版本。
查到的方法，就唯獨讓Web應用程式使用32bit mode一途，可解決此問題了。
在此情況下，以下介紹兩種可以讓Web應用程式使用32bit mode執行的方式!
但如使用第一種方式，須注意到，因預設使用AnyCPU的選項，會依您佈署作業系統環境，
而對應使用不同的CPU mode。
所以當所有Library都設定為AnyCPU，僅有其中一個Library被修改指定使用x86模式時，
當佈署於x86的作業系統環境，應用程式全部都會使用x86運行，便可完全正常運作。
但當佈署至x64的作業系統環境時，便會有些以x64運行，有些要以x86運行，便會發生無法載入的錯誤情況。
因此要相當注意，有參考到的Library都必須一併指定為x86 mode，
不然應用程式在Runtime時，會發生x64無法跟x86溝通的問題。
但這問題就來了，如果是我們自己開發的程式，指定運行的Mode當然沒問題。
但如果是使用一些Third party的Tool，這時就很難保證他會用什麼模式運行了。
所以總結，是比較建議使用上方介紹的第二種做法，直接指定整體環境(在Web環境是ApplicationPool)使用x86運行，
應該會是比較保險的做法。
依照上圖步驟，就可以輕易完成小圖示的新增囉~
可看到圖中步驟4.在FCKEditor功能中，便可看到新增的圖示囉~~
有時候，當專案有需求，希望可以在資料表中增加一個欄位。
當新增的欄位，或異動，需要重建資料表，才有辦法正確變更成功的話。
在Sql 2008 便會得到如下的訊息，提醒您的異動因為需要drop 再 re-create 資料表。
此異動在預設是不允許的，我想，也許這是要保護資料不會不小心被刪掉。
可是當我們是專案剛開始在設計資料表時，資料表內還沒有任何資料。
應該是可以異動，不會有風險的。那該怎麼辦呢?!
仔細看於上圖的訊息中，有提到一個新增的選項，
The Option Prevent saving changes that require the table to be re-created.
在新版的sql2008中，增加了這個選項的防護。確保資料不會不小心被刪除了。
但當我們真的需要直接重建資料表，
我們可以再以下路徑找到這個設定：
Option → Designer → Table and DataBase Designers → Prevent saving changes that require table re-creation.
預設這個選項是打勾的，表示需要啟用此保護機制。
在這邊只要將此選項勾選掉，即可直接儲存需Re-creation資料表的異動了。
但我想，異動完還是必須記得將此選項修改回啟用，
這選項應可有效確保資料不會因不小心異動資料表而被刪除!!!
這裡的測試使用環境為Vistual Studio 2010 ，因此可分別建立.net 3.5 使用EF2.0 ，與.net 4.0使用EF4.0的專案來做比較。相信可以更容易感受到此功能的差異。
在開始前，先建立關聯的資料表，關聯圖如下：
這裡有兩個多對多的資料表，分別為Block與Items，而這兩個資料表於Entity Framework 中的Model圖如下：
因為BlockItems是兩個Table的關聯資料表，因此會直接在Model圖中，對應多對多關係。
在建立Entity Framework 時可選擇的選項畫面如下。
VS2008 .Net3.5設定畫面：
VS2010 .Net3.5設定畫面：
VS2010 .Net4.0 設定畫面：
接著實際寫一段code將Block逐筆寫出，並且於Block下逐筆寫出其包含之Items，
static void Main(string[] args)
{
Entities context = new Entities();
var q = from a in context.Block
select a;
foreach (var block in q)
{
Console.WriteLine("取區塊名稱：" + block.BlockName);
foreach (var item in block.Items)
{
Console.WriteLine("---選購項目：" + item.Name);
}
}
}
寫出結果如下：
vs2010 .net3.5 輸出結果：
vs2010 .net 4.0 輸出結果：
這邊可以看出結果的差異!!!!!
為什麼會有這樣的差異呢?!
底下Debug，看一下分別在不同Framework 下，可取到的Items 資料的差異。
vs2010 .net3.5 Items內容數：
vs2010 .net 4.0 Items內容數：
可以看到，在Entity Framework 4.0 當我們用LINQ to Entity 取到Block 時，
便同時已經取到跟他相關聯的所有Items 了，可是在Entity Framework 2.0，這是沒辦法做到的。
因此於EF4.0中，更加貼近我們是在操做Entity了!
原因為何我還不清楚，原以為是新增的 Include foreign key columns in the model 功能影響。
但經過測試，於EF4.0建立Model時，故意不勾選此選項，結果EF4.0依然可正確的抓到Items 值。
先將此問題做紀錄，待有空再來研究原因為何。