這里的所謂“Web源代碼”，指的是客戶端的諸如HTML、Javascript之類的東西，當你辛辛苦苦寫出來一個web應用程序時，可能希望自己的勞動成果不被別人任意剽竊修改，但是這些東西如果不加處理，很容易被人拷貝。

其實說實話，我個人認為，作為描述性的語言，web源代碼沒有經過編譯，也就是說，無論怎么加密，它在客戶端都會最終以源代碼形式出現，要絕對的防止被察看是不可能的。但是，我們還是要討論這個問題，因為雖然沒有絕對，但是相對比較安全就好了，正如系統的安全沒有絕對，只有相對一樣。只要能讓絕大多數人束手無策，我們的目的也就達到了。

首先，禁止右鍵是一個比較常見的方法，這無論如何是不能徹底阻止用戶察看源代碼，但是既然無法防止用戶察看代碼，就只能把代碼加工，讓人看了也無法理解其意義。

一個比較經典而有效的方法是利用的js的escape方法，將源代碼經過escape編碼后，大部分文字被轉換成了型如%xx的編碼，unicode字符被轉換成%uxxxx格式，于是看起來一片混亂。使用的時候先將這段編碼作為數據，利用unescape轉換回原貌，再用js寫進需要的位置，于是便可正常使用了。

這個方法原理簡單，而且可以反復調用，將源代碼經過數層加密(將解密的程序本身也作為源代碼進行加密)，已經足以讓大部分的人摸不著頭腦了。他的缺點是編碼效率不高，經過編碼后數據量增加很多。而且這種編碼要解也很容易。

仿照這個原理，其實你可以自己寫出自己的算法來代替escape，不過因為這個部分源代碼也是明文，所以其實意義不大，只能唬唬那些利用現成工具解碼的人，稍微會編程的人都可以利用你的源代碼部分，修改一下輸出，得到你的代碼明文。

作為全球最大的軟件商，微軟公司也意識到了腳本的知識產權保護問題，因此在IE5以上的版本里加入了對編碼腳本的支持，這里的“編碼”和上面所述的略有不同，這是通過微軟專門的wse(windows script encoder)進行腳本編碼，其范圍也不僅僅局限于客戶端腳本，它也可以對wsh，甚至服務器端的ASP腳本進行編碼，經過編碼的腳本看起來是一堆亂七八糟毫無疑義的字符(好像unicode會不經編碼原封不動的保留下來)，在運行的時候在腳本引擎內部進行解碼，由于解碼算法是腳本引擎內置的，所以一般人難以解出源代碼。另外，由于解碼中要進行完整性效驗，即使unicode以原碼顯示出來了也不能被修改，修改哪怕是一個字節，就會使整段代碼失效。

這個方法目前看來很安全，還沒有現成的工具對其進行破解。但是要知道，這些算法是可逆的，也就是說遲早會有人找出其算法，我甚至猜測script engine本身提供了編碼解碼的接口，可以直接調用的。解密工具遲早要出來。而且這個加密方法有個很大的缺陷，就是必須要求IE5以上才能用，要知道，IE4的用戶不在少數，因此在很大程度上限制了推廣使用。

真的沒有兩全的辦法了嗎？

寫到這里，我自己產生了一個想法：利用隨機密匙+固定或隨機算法進行加密，只是一時想法，還不成熟，而且也只是可以騙過一般人而已，不妨寫下來供參考：

先想一種需要密匙的算法，比如xor，在服務器端寫好加密算法，當用戶訪問此頁的時候生成一個隨機密匙，將解密算法以及加密后的數據發到客戶端頁面上，而在之前將此次會話生成的密匙通過某種特別途徑發給客戶端(比如服務器發來的cookie)，然后在客戶端讀出cookie里的密匙進行實時解密。由于不帶過期參數的cookie是存在內存里的，在硬盤里找不到，因此除非用戶知道寫cookie的那個頁面并且察看其http頭(同時還要向服務器發去維持本次會話的sessionID以防止密匙改變)，否則是無法解密的。由于向客戶端發送cookie的頁面可以隨機(可以在加密頁面出現之前的任意頁面)，而且密匙甚至算法均可隨機，找到密匙，算法，數據三者相對應的過程相當之繁瑣，可以嚇倒不少的人。

這種加密法是否可行還有待探討，只是我一時想法而已，有空的時候我會試驗一下，看看到底能不能用。