svn服務器端怎麼配置和客戶端數據同步？儘量清晰一點
首先聲明，該文爲原創，由於我對網站安全知道得很少，所以希望各路高手提出高見，完善我的這個策略。
緣起：jquery是目前用戶體驗效果最好的插件（暫時不考慮FLASH了，這玩意太笨重，目前的網速還承載艱難。），所以做頁面的時候，往往使js或者jquery做前端，達到良好的用戶體驗。php之類做後臺。
但問題是，前臺的JS很容易繞過。所以從頁面採集來的數據，還需要php重新過濾。如一個註冊頁面需要採集郵編。則出現這樣的情況：
用戶輸入的數據——JS正則判斷（前端）——php正則判斷（後臺）——交互數據庫。
這裏，連用兩種語言的正則，而且是必須的。功效重複，使得網站代碼量變大。如果需要採集的數據量很多，從姓名到地址到電話到QQ一直到三姑媽的二兒子的女友的爸爸的名字，總之一大堆input select radio等等，這時候，前端的JQUERY自然很大，而後臺PHP分析處理的數據很大，偏偏在這樣處理表單的功能上，php不如JS簡潔高效。
所以我想了個小辦法。後臺php不再進行數據分析過濾，一切都交給jquery來進行。爲了防止用戶繞過jquery，輸入惡意代碼。我在數據庫增加一個表。表中記載前臺表單action的值，或者說表單處理php文件地址（絕對路徑和相對路徑）在，暫時其名form_path。
然後再表單頁面，新增一個session，用來存貯頁面地址。
當表單提交，這個session值不等於form_path時，退出。如此，可以強迫用戶使用jquery寫成的表單輸入頁面。繞過JS處理的應該是僞造的表單，所獲得的session值自然不符），如此，我在php處理頁面，可以大膽直接post,不需要再過濾數據，節省了很多代碼。
大家覺得這個策略有什麼漏洞？還有什麼需要改進的？
你知道這段代碼幹什麼的麼？這是上傳文件的php代碼,js暫時還木有這種功能
較之前的終於有所改善。生成迷宮的算法和尋址算法其實是一樣。只是一個用了遍歷一個用了遞歸。參考了網上的Mike Gold的算法。
出現死循環的概率還是蠻大的up，測了一下，看上去很不錯
很是有點奇怪，刷新3～4次就會有一次無響應，但也沒有報超時錯。只是始終在等待
這個不會死循環的 所有的if條件那麼多的判定語句，你自己運行一下就知道了··
這個我試過n次，沒問題。比上次那個有改進。老大說的是上次那個隨機生成的那個吧。那個確實有bug。但是這個是深度遍歷的，沒問題吧？好貼留名 只是併發訪問的壓力如何呢 這麼多循環用起來 估計壓力夠大
不可能出現死循環。這種鑽洞會讓每個格子都有至少一面牆打開。
奇怪，刷新的時候確實碰到打不開頁面的時候了。
思路就是採用一個棧結構存儲當前路徑。
通過遍歷這個多維數組，來找出一條最短的路徑來。遞歸或循環的移動座標(數組索引).
每移動一步，判斷當前元素是否定義或當前索引是否爲2(是否躍出了矩陣的範圍和是否碰到了牆).
如果爲true，則回退一步，棧頂彈出一個元素。然後向另外的方向移動，規則可以自己定，1:右,2:下,3:左,4:上(控制數組的橫，縱索引).
如果爲true，則認爲達到終點。將棧結構中存儲的所有路徑索引打印出來就是迷宮的路徑.
如果生成的迷宮出現了死路，必然會出現死循環。需要在處理碰牆時，調轉3個方向後仍然不能前進就判定爲沒有可行進的路徑避免死循環。
如果僅僅是走出迷宮的話，簡單回溯就可以實現。
但如果要求最短的一條路徑,還是需要使用Dijkstra或Minimum Spanning Tree等算法理論才能得以實現。
我在1樓的生成迷宮算法中，生成的迷宮只有一條路可以通到出口，所以不存在最短路徑的問題。
我那種破牆方式，是將每個格子的四周包成牆。然後破的。挖道到頭之後如果發現有尚未破牆的格子，就彈棧回溯一直到都破完爲之。應該不存在包起來的死格子呀。相對來說當然是電子商務羅，不過具體也要看你的策劃。
技術不是關鍵 關鍵是拉項目的人 以及策劃項目的人
說得對，市場需要的產品就能賺錢，前提是你能想得到，撈第一桶金。
同求好策劃，別人做爛的東西你是沒什麼機會的。
來源：nba直播