㈠ 求教Java web項目一般怎樣做代碼混淆或加密
一、java web項目混淆
proguard4.8工具，說是支持war的，可混淆過後少了classes目錄了，自然成功不了。網上搜的過程不詳說了，最後找著－－「J2EE-web工程ProGuard代碼混淆07_28」，網址：http://wenku..com/link?url=CxToEqg5QWbz2_--cVqaImGKnLLLTO45u6uD_
根據提示一步步完成。
把web項目打成jar包後用proguard進行混淆，然後把混淆過後的class目錄替換發布包war中的對應目錄，啟動運行是正常的。
主要注意利用proguard生成xxx.pro文件，然後手動加工-keep class WebRoot.WEB-INFO.lib.* 等項目中不需要混淆的包和類。
二、java web項目打成.exe
沒找到免費的，這搜到個收費的－－Jinstall，試了下功能挺好，
可以加密、集成jdk、tomcat，如果資料庫是mysql也集成，其他資料庫的話要設置資料庫的url.
㈡ javaweb項目做混淆的詳細步驟
混淆的工具很多，最常用的為retroguard.
Java 代碼編譯後生成的 .class 中包含有源代碼中的所有信息（不包括注釋），尤其是在其中保存有調試信息的時候。所以一個按照正常方式編譯的 Java .class 文件可以非常輕易地被反編譯。反編譯工具有很多種，其中非常強大的一種是 jad。
為了避免出現這種情況，保護開發者的勞動，又有一種叫做 Java 混淆器的工具被開發出來。Java 混淆器的作用是對編譯好的代碼進行混淆，使得其無法被反編譯或者反編譯後的代碼混亂難懂。Java 混淆器也有很多種，其中比較強大的一種是 RetroGuard（只說比較強大是因為我對其功效還是有些懷疑的）。
這里我介紹一下 RetroGuard 的使用方法。
將下載的 .tar.gz 或者 .zip 文件解壓。有用的只有 retroguard.jar 一個文件，其它的是源代碼和文檔。
RetroGuard 是針對 jar 文件做混淆的。使用之前需要先配置一下。可以手工編輯配置文件，更好的方法是使用 RetroGuard 提供的 GUI 工具來生成配置文件。使用方法如下：
java -classpath retroguard.jar;xxx.jar;yyy.zip;... RGgui
然後在 GUI 的 Wizard 中設置各個參數。上面的 -classpath 中應該列出要混淆的 jar 所依賴的所有的包。
RGgui 的詳細使用方法可以看 RetroGuard 的文檔 docs.html。
配置文件生成後，就可以運行 RetroGuard 進行混淆了。使用方法如下：
java -classpath xxx.jar;yyy.zip;... RetroGuard vvv-unofb.jar vvv.jar vvv.rgs vvv.log
其中 vvv-unofb.jar 是未混淆的 jar 文件，vvv.jar 是混淆後生成的 jar 文件，vvv.rgs 是配置文件，vvv.log 是日誌文件。預設的配置文件名稱為 script.rgs，預設的日誌文件名稱為 retroguard.log。
在生成配置文件時需要注意的是：
1、所有 public 的類名、方法名、變數名應該全部保留。因為所有設置為 public 的內容代表了整個包對外表現的介面。若某個內容不想為外界訪問，就不應該設置為 public 的。
2、若包中某個類使用了 java.lang.Class 或者 java.lang.ClassLoader 中的某個方法載入了一個類，若這個類在包外，不需要特別處理；若這個類在包內，則需要保留這個類的類名，否則混淆後會找不到這個類。
3、在包中的所有調試信息（源文件名、行號、變數/參數信息等等）應全部刪除。
㈢ JavaWeb項目使用Proguard混淆問題
混淆的概念你就沒清楚，打個比方，就是把變數重命名（這只是其中一種），讓別人反編譯後也很難看得懂代碼，原來怎麼用，混淆後還是怎麼用。
㈣ 如何防止程序員反編譯
Java從誕生以來，其基因就是開放精神，也正因此，其可以得到廣泛愛好者的支持和奉獻，最終很快發展壯大，以至於有今天之風光！但隨著java的應用領域越來越廣，特別是一些功能要發布到終端用戶手中（如Android開發的app），有時候，公司為了商業技術的保密考慮，不希望這裡面的一些核心代碼能夠被人破解（破解之後，甚至可以被簡單改改就發布出去，說嚴重點，就可能會擾亂公司的正常軟體的市場行為），這時候就要求這些java代碼不能夠被反編譯。
這里要先說一下反編譯的現象。因為java一直秉持著開放共享的理念，所以大家也都知道，我們一般共享一個自己寫的jar包時，同時會共享一個對應的source包。但這些依然與反編譯沒有什麼關系，但java的共享理念，不只是建議我們這樣做，而且它自己也在底層上「強迫」我們這么做！在java寫的.java文件後，使用javac編譯成class文件，在編譯的過程，不像C/C++或C#那樣編譯時進行加密或混淆，它是直接對其進行符號化、標記化的編譯處理，於是，也產生了一個逆向工程的問題：可以根據class文件反向解析成原來的java文件！這就是反編譯的由來。
但很多時候，有些公司出於如上述的原因考慮時，真的不希望自己寫的代碼被別人反編譯，尤其是那些收費的app或桌面軟體（甚至還有一些j2ee的wen項目）！這時候，防止反編譯就成了必然！但前面也說過了，因為開放理念的原因，class是可以被反編譯的，那現在有這樣的需求之後，有哪些方式可以做到防止反編譯呢？經過研究java源代碼並進行了一些技術實現（結果發現，以前都有人想到過，所以在對應章節的時候，我會貼出一些寫得比較細的文章，而我就簡單闡述一下，也算偷個懶吧），我總共整理出以下這幾種方式：
代碼混淆
這種方式的做法正如其名，是把代碼打亂，並摻入一些隨機或特殊的字元，讓代碼的可讀性大大降低，「曲線救國」似的達到所謂的加密。其實，其本質就是打亂代碼的順序、將各類符號（如類名、方法名、屬性名）進行隨機或亂命名，使其無意義，讓人讀代碼時很累，進而讓人乍一看，以為這些代碼是加過密的！
由其實現方式上可知，其實現原理只是擾亂正常的代碼可讀性，並不是真正的加密，如果一個人的耐心很好，依然可以理出整個程序在做什麼，更何況，一個應用中，其核心代碼才是人們想去了解的，所以大大縮小了代碼閱讀的范圍！
當然，這種方式的存在，而且還比較流行，其原因在於，基本能防範一些技術人員進行反編譯（比如說我，讓我破解一個混淆的代碼，我寧願自己重寫一個了）！而且其實現較為簡單，對項目的代碼又無開發上的侵入性。目前業界也有較多這類工具，有商用的，也有免費的，目前比較流行的免費的是：proguard（我現象臨時用的就是這個）。
上面說了，這種方式其實並不是真正加密代碼，其實代碼還是能夠被人反編譯（有人可能說，使用proguard中的optimize選項，可以從位元組流層面更改代碼，甚至可以讓JD這些反編譯軟體可以無法得到內容。說得有點道理，但有兩個問題：1、使用optimize對JDK及環境要求較高，容易造成混淆後的代碼無法正常運行；2、這種方式其實還是混淆，JD反編譯有點問題，可以有更強悍的工具，矛盾哲學在哪兒都是存在的^_^）。那如何能做到我的class代碼無法被人反編譯呢？那就需要我們下面的「加密class」！
加密class
在說加密class之前，我們要先了解一些java的基本概念，如：ClassLoader。做java的人已經或者以後會知道，java程序的運行，是類中的邏輯在JVM中運行，而類又是怎麼載入到JVM中的呢（JVM內幕之類的，不在本文中闡述，所以點到為止）？答案是：ClassLoader。JVM在啟動時是如何初始化整個環境的，有哪些ClassLoader及作用是什麼，大家可以自己問度娘，也不在本文中討論。
讓我們從最常見的代碼開始，揭開一下ClassLoader的一點點面紗！看下面的代碼：
Java代碼
publicclassDemo{
publicstaticvoidmain(String[]args){
System.out.println(「helloworld!」);
}
}
在編譯代碼時（如使用ant或maven），使用插件將代碼進行加密（加密方式自己選），將class文件裡面的內容讀取成byte[]，然後進行加密後再寫回到class文件（這時候class文件裡面的內容不是標準的class，無法被反編譯了）
在啟動項目代碼時，指定使用我們自定義的ClassLoader就行了，而自定義的部分，主要就是在這里做解密工作！
上面這段代碼，大家都認識。但我要問的是：如果我們使用javac對其進行編譯，然後使用java使其運行（為什麼不在Eclipse中使用Runas功能呢？因為Eclipse幫我們封閉，從而簡化了太多東西，使我們忽略了太多的底層細節，只有從原始的操作上，我們才能看到本質），那麼，它是怎麼載入到JVM中的？答案是：通過AppClassLoader載入的（相關知識點可以參考：http://hxraid.iteye.com/blog/747625）！如果不相信的話，可以輸出一下System.out.println(Thread.currentThrea().getContextLoader());看看。
那又有一個新的問題產生了：ClassLoader又是怎樣載入class的呢？其實，AppClassLoader繼承自java.lang.ClassLoader類，所以，基本操作都在這個類裡面，讓我們直接看下面這段核心代碼吧：
看到這里，已經沒有必要再往下面看了（再往下就是native方法了，這是一個重大伏筆哦），我們要做的手腳就在這里！
手腳怎麼做呢？很簡單，上面的代碼邏輯告訴我們，ClassLoader只是拿到class文件中的內容byte[]，然後交給JVM初始化！於是我們的邏輯就簡單了：只要在交給JVM時是正確的class文件就行了，在這之前是什麼樣子無所謂！所以，我們的加密的整個邏輯就是：
如此，搞定！以上的做法比較完整的闡述，可以仔細閱讀一下這篇文章：https://www.ddtsoft.com/#developerworks/cn/java/l-secureclass/文章中的介紹。
通過這個方法貌似可以解決代碼反編譯的問題了！錯！這里有一個巨大的坑！因為我們自定義的ClassLoader是不能加密的，要不然JVM不認識，就全歇菜了！如果我來反編譯，呵呵，我只要反編譯一下這個自定義的ClassLoader，然後把裡面解密後的內容寫到指定的文件中保存下來，再把這個加了邏輯的自定義ClassLoader放回去運行，你猜結果會怎樣？沒錯，你會想死！因為你好不容易想出來的加密演算法，結果人家根本不需要破解，直接就繞過去了！
現在，讓我們總結一下這個方法的優缺點：實現方式簡單有效，同時對代碼幾乎沒有侵入性，不影響正常開發與發布。缺點也很明顯，就是很容易被人破解！
當然啦，關於缺點問題，你也可以這么干：先對所有代碼進行混淆、再進行加密，保證：1、不容易找到我們自定義的那個ClassLoader；2、就算找到了，破解了，代碼可讀性還是很差，讓你看得吐血！（有一篇文章，我覺得寫得不錯，大家可以看一看：http://www.scjgcj.com/#blog/851544）
嗯，我覺得這個方法很好，我自己也差點被這個想法感動了，但是，作為一個嚴謹的程序員，我真的不願意留下一個隱患在這里！所以，我繼續思索！
高級加密class
前面我們說過有個伏筆來著，還記得吧？沒錯，就是那個native！native定義的方法是什麼方法？就是我們傳說中的JNI調用！前面介紹過的有一篇文章中提到過，其實jvm的真實身份並不是java，而是c++寫的jvm.dll（windows版本下），java與dll文件的調用就是通過JNI實現的！於是，我們就可以這樣想：JNI可以調用第三方語言的類庫，那麼，我們可不可以把解密與裝載使用第三方語言寫（如C++，因為它們生成的庫是不好反編譯的），這樣它可以把解密出來的class內容直接調jvm.dll的載入介面進行初始化成class，再返回給我們的ClassLoader？這樣，我們自定義的ClassLoader只要使用JNI調用這個第三方語言寫的組件，整個解密過程，都在黑盒中進行，別人就無從破解了！
嗯，這個方法真的很不錯的！但也有兩個小問題：1.使用第三方語言寫，得會第三方語言，我說的會，是指很溜！2.對於不同的操作系統，甚至同一操作系統不同的版本，都可能要有差異化的代碼生成對應環境下的組件（如window下是exe，linux是so等）！如果你不在乎這兩個問題，我覺得，這個方式真的挺不錯的。但對於我來說，我的信條是，越復雜的方式越容易出錯！我個人比較崇尚簡潔的美，所以，這個方法我不會輕易使用！
對了，如果大家覺得這個方法還算可行的話，可以推薦一個我無意中看到的東西給大家看看（我都沒有用過的）：jinstall，
更改JVM
看到這個標題，我想你可能會震驚。是的，你沒看錯，做為一個程序員，是應該要具有懷疑一切、敢想敢做的信念。如果你有意留心的話，你會發現JVM版本在業界其實也有好幾個版本的，如：Sun公司的、IBM的、Apache的、Google的……
所以，不要阻礙自己的想像力，現在沒有這個能力，並不代表不可能。所以，我想到，如果我把jvm改了，在裡面對載入的類進行解密，那不就可以了嗎？我在設計構思過程中，突然發現：人老了就是容易糊塗！前面使用第三方語言實現解密的兩個問題，正好也是更改JVM要面對的兩個問題，而且還有一個更大的問題：這個JVM就得跟著這個項目到處走啊！
㈤ U3D如何做代碼混淆
Unity代碼混淆方案
內容提要：Unity引擎下的代碼保護，由於Unity引擎的一些特殊性，實行起來較為復雜，在國內外業界並沒有現成的方案。筆者通過在《QQ樂團》項目上的實際嘗試，得出了一種具體可行，能夠有效保護代碼邏輯的方案。特此分享給關注Unity引擎的項目，希望能提供一些的參考。
背景
Unity引擎上的程序執行在Mono運行時上，使用Mono編譯出的程序集格式與.NET標准一致。C#是Unity引擎下主要的開發語言，它具備不少高級語言特性，如反射、元數據、內置序列化等。但C#同時也是很容易被反編譯的語言，如果不採用任何保護措施，使用常用的工具（.NET Reflector）便能很容易得到可二次編譯的代碼。對項目運營帶來了比較大的風險。
.NET平台下通常的保護手段是混淆編譯出的程序集。VisualStudio自帶了一個混淆工具Dotfuscator可以對程序集進行混淆。功能包括名稱修改，流程混淆，字元串加密等。經過Dotfuscator混淆後的程序集，能夠避免被常用反編譯工具破解。變數的表意性被破壞，同時函數的內部流程也被混淆（如下[B1] ）。能有效起到保護源代碼的效果。
publicclass181: 218
{
// Fields
publicuint0;
publicushort1;
publicstaticreadonlyuint2;
publicstaticreadonlyuint3;
// Methods
static181();
public181();
public95.02();
public95.02(ref515A_0, uintA_1);
public95.02(79A_0, refuintA_1);
public95.02(ref79A_0, uintA_1);
public95.02(byte[] A_0, intA_1, refuintA_2);
public95.02(ref481A_0, intA_1, charA_2);
public95.02(refstringA_0, intA_1, charA_2);
public95.02(refbyte[] A_0, intA_1, refintA_2, uintA_3);
public95.03(ref79A_0, uintA_1);
public95.03(refbyte[] A_0, intA_1, refintA_2, uintA_3);
public95.04(refbyte[] A_0, intA_1, refintA_2, uintA_3);
}
public95.00(refsbyteA_0, intA_1)
{
// This item is obfuscated and can not be translated.
goto Label_0006;
if(1!= 0)
{
}
95.0local= 95.0.0;
bytenum= 0;
local = this.0(refnum,A_1);
A_0 = (sbyte) num;
returnlocal;
Unity引擎下，Mono編譯出的程序集，由於採用與.NET相同的格式標准。能夠直接被Dotfuscator混淆。但Unity引擎有一些特殊的地方，使混淆工作與一般的.NET程序存在差異。第三節將主要討論這些特殊點。
Unity引擎下代碼混淆的特殊性
代碼被資源引用[B2] 。Unity的可視化編輯特性在設計上的關鍵之處在於使代碼能夠以組件的形式依附到資源實例上。相比傳統游戲，Unity的兩類資源（scene和prefab）不僅包括數據，還包括附加在資源上的類對象。也就是說，這兩類資源的存儲格式中存在唯一標識某代碼類型的數據。混淆流程必須不破環這種對應關系才能使資源上的代碼邏輯正確被執行。（Unity這樣設計的意義並不是本文討論的重點，而另一篇分享個人對Unity可視化編輯的理解的文章中將會詳細說明。）
發布到Web的Unity項目，在生成播放器可執行包（*.unity）的介面中，將編譯程序集和打包這兩個步驟捆綁在的一起。我們沒辦法像普通.NET程序那樣，對編譯出的程序集進行混淆後再打到播放器可執行包中。
UnityEngine按函數名進行調用。MonoBehaviour是Unity引擎的一個重要的組件基類。其上的很多方法，Unity是通過方法名稱進行訪問的，如Awake、Start、Update等等。這些方法如果在混淆中被改名，將使方法調用失敗。這個問題相對比較好處理，Dotfuscator的重命名功能提供了排除配置。我們只要得到繼承於MonoBehaviour的所有類型，就能生成相應的排除配置，告知Dotfuscator不要對這些方法進行重命名。生成的配置節選如下[B3] ：
<option>xmlserialization</option>
<excludelist>
<type name="CEventMgr|CGameRoot|…|…" regex="true" excludetype="false">
<method name="Update"regex="true" />
<method name="LateUpdate"regex="true" />
<method name="FixedUpdate"regex="true" />
<methodname="Awake" regex="true" />
<customattributename="System.Runtime.CompilerServices.CompilerGeneratedAttribute"regex="true" />
<method name=".*"regex="true" />
<field name=".*"regex="true" />
</type>
<type name=".*"regex="true">
<customattributename="ANoRenameInObfuscate" regex="true" />
</type>
<type name=".*"excludetype="false" regex="true">
<method name=".*"regex="true">
<customattributename="ANoRenameInObfuscate" regex="true" />
</method>
</type>
思路
何時混淆？由於Web項目編譯和打包的過程是捆綁在一起的，官方沒有提供獨立的介面。（之前有跟官方反饋，但目前官方並沒有提供具體計劃。）想自己來分析官方的打包格式是行不通並且不太科學的。僅剩的辦法就是自己將代碼編譯成DLL，混淆之後再添加到Unity項目中。
順著這條思路，筆者在《QQ樂團》項目上作了嘗試。將項目中所有執行相關的代碼（不包括編輯器擴展的代碼）移出，指定相關的Unity依賴庫，編譯成DLL。再將此DLL復制到原項目中。這時意料之中的事情發生了——項目中所有資源上的代碼引用全部丟失。為了找到資源對代碼的映射形式，筆者調整Unity編輯器的設定，將資源的序列化格式改為文本格式，並進行對比分析。發現資源中是通過一個GUID來對應具體代碼的[B4] 。（如下）
m_ObjectHideFlags: 1
m_PrefabParentObject: {fileID: 0}
m_PrefabInternal: {fileID: 100100000}
m_GameObject: {fileID: 100000}
m_Enabled: 1
m_EditorHideFlags: 0
m_Script: {fileID:11500000, guid: , type: 1}
m_Name:
mInt: 1
mFloat: .5
中的類型雖然還沒有進行過混淆，但GUID已經發生了變化。將新的GUID替換到資源文件中，引用關系果然恢復了。
Unity引擎下的特殊問題都是可以解決的。於是順著這思路，開發了若干工具，得到了前後GUID的對應關系，並掃描所有資源以進行GUID的替換。另一方面，在混淆之後，類型的變數名發生了改變，資源中變數名賦有具體的值，也需要替換資源中的變數名對應到混淆後的變數名。這一切花費了不少的精力，終於是把工具都做成了。
然而人算不如天算，最終導致此方案走進死角的是一個之前很難意料到的問題：Unity引擎在處理DLL中的模版類型時存在缺陷——DLL中的模版類型沒有GUID，不能被資源所引用。這個問題在Unity官方網站上有少量反饋，而官方承認了這個bug，且沒有給出解決方案。而《QQ樂團》的項目在UI操作上比較廣泛地使用了模版類型，去除模版的使用談何容易。就這樣，這么一個不經意的問題為這個嘗試的方向畫上了句號。
「系著枷鎖跳舞」，這句話是形容的是在各種條件約束下盡可能的追求解決方案的一種狀態。總結之前的失敗，最終還是找到了實際可行的改進方案，並成功應用到《QQ樂團》的Web版本和微客戶端版本上。
最終的思路是將項目進行分層。獨立出一個不被資源引用的，包含最敏感的協議解析和各個系統模塊的「邏輯層」，將邏輯層的代碼獨立編譯成一個DLL，進行混淆再包含到項目中。邏輯層之外的代碼主要包括被資源引用到的，或是系統模塊部分介面定義這樣的不太敏感的內容，姑且稱為「行為層」。為了讓邏輯層可以獨立編譯，我們要求邏輯層可對行為層進行引用，而行為層則只能通過留在行為層的邏輯層介面訪問邏輯層。這樣我們就保護了我們最重要的代碼，同時繞過了資源引用代碼的問題。
這個方案對項目架構提出了一定的要求。一是要求敏感代碼和資源保持獨立，需要一個框架來載入各個模塊，而不是直接將模塊代碼直接附在場景物體的資源中。二是要求層次清晰，不允許反向依賴。有利於《QQ樂團》項目的消息是，《QQ樂團》從最早期就實現了一個較清晰的架構管理方法。因此花費了一定的時間進行分層，和實現介面訪問機制後，就成功執行了這個方案。
實際混淆步驟。《QQ樂團》是使用VisualBuild來執行版本構建和發布流程的。以下介紹版本構建中混淆相關的流程：
從Unity項目的Assets目錄中拷貝出邏輯層的代碼目錄（CodeGameLogic）。和編輯器擴展代碼（避免混淆後編輯器擴展代碼對邏輯層的依賴丟失導致編譯出錯）。
調用Unity.exe命令行編譯剩餘的行為層部分：
這個函數實際執行了：
BuildPipeline.BuildPlayer(new string[] {"Assets/obfuscated.unity" }, "WebPlayerObfuscated",
BuildTarget.WebPlayer, BuildOptions.None);
Editor程序集（也就是編輯器擴展程序集）時編譯失敗，中斷編譯過程，避免在BuildPlayer過程結束時構建生成的DLL被清理掉。BuildPlayer之前故意在Editor目錄下弄一個錯誤的代碼文件即可。
將生成的行為層DLL拷貝到邏輯層構建目錄。行為層DLL的路徑是在項目的Library/ScriptAssemblies下，有Assembly-CSharp.dll和Assembly-CSharp-firstpass.dll兩個文件。另外也拷貝邏輯層依賴的其它DLL到構建目錄，包括UnityEngine.dll，以及項目Plugins目錄下的依賴庫。
調用Mono的編譯器mcs編譯邏輯層DLL——CodeGameLogic.dll。編譯命令如下：
生成DotObfuscator的配置文件」WebCfg.xml」。這里是用自己編寫的工具，掃描CodeGameLogic.dll中的類型，得到不能被混淆的類型名和方法名，加入到配置文件的排出列表中。如「三。3」小節所示。
調用DotObfuscator對CodeGameLogic.dll執行混淆，得到混淆後的CodeGameLogic.dll：
將混淆後的CodeGameLogic.dll拷貝到項目中，然後構建項目。這里要注意的是，如果是構建Web項目，需要將dll拷貝到Plugins目錄。如果是Standalone（即客戶端）項目，直接拷貝到Assets目錄下即可。另外，這次構建是不可以有編譯錯誤的，所以第1部需要移除Editor目錄下的編輯器擴展的代碼。
接下來將構建好的項目與資源合並，就可以得到完整的混淆版本。
總結：
Unity項目的代碼反編譯較為容易。需要在重視代碼混淆工作。
Unity項目的代碼混淆方案實施起來限制較多。本文介紹的方案是筆者知曉的目前唯一可用的混淆方案。對項目的架構分層有強制性的要求。最好是在項目初期就考慮如何對項目進行分層，將需要保護的內容放置在被混淆的層中。
㈥ 誰給推薦個c++代碼混淆工具
1、Stunnix CXX-Obfus
Stunnix CXX-Obfus 是 C 和 C++ 源碼的混淆器，可變成非常難於讀懂、重用以及編輯的代碼。提供多個選項用於控制代碼混淆處理，完全支持所有的語法構造，支持 C 和 C++ 源碼混合的項目。
2、JsCompressor
JsCompressor，主要用來壓縮、混淆JS(Javascript)與CSS，基於YUI Compressor，目的是方便不熟悉Java或者不喜歡命令行方式進行壓縮的Web開發者使用。
㈦ javaweb項目如何混淆打包
File->Export->General/Archive file,在選擇你要打包的項目
㈧ html5可以將web代碼全部加密 為什麼這么說
html5可以將web代碼全部加密，其實就是HTML可以混淆代碼
代碼混淆簡單地說是對代碼進行重新組織和處理，使得處理後的代碼與處理前代碼完成相同的功能，但難以閱讀。一般代碼混淆器會將代碼中的所有變數、函數、類的名稱變為簡短的英文字母代號，刪去代碼注釋。
㈨ 求教Java web項目代碼混淆，網上教程用proguard各種報錯，有沒有大神教我怎麼配置
java是編程語言里比較難學的一門，如果有心從事編程方向的工作，最好到專業機構學習並有更多的項目實踐，更貼近市場，這樣更有利於將來的發展。
㈩ 如何對網頁代碼進行混淆和加密
方法一、一般來說利用程序來進行密碼驗證的方法比較通用，現在大多數網站都使用ASP程序，它對Web伺服器沒有具體要求，而其加密就是藉助資料庫及ASP程序進行設計，來實現一種通用網頁加密。 1. 打開Microsoft Access，建立一個「用戶名及密碼」的數...