最近一個做收藏的用戶向我們提出一個需求，這個項目是湖南省收藏協(xié)會提供支持的一個項目，需求其實也到很簡單：1、有社區(qū)論壇互動；2、做一個像etao那樣的購物分享網(wǎng)站。其實一淘那個導購系統(tǒng)，就算從底層做也不復雜，甚至拿來任何一個開源程序，諸如dede、wordpress等等都可以做到，而且確實是不錯的解決方案。但是需要社區(qū)論壇，如果我們從底層來做，那這個工作量太龐大了，就包括騰訊、小米這樣的巨頭也不會傻到自己重新來做，而國內(nèi)首選的就是騰訊旗下的Discuz，而我們團隊有Discuz的開發(fā)者，因此對于這個項目決定采用Discuz的解決方案。

如果用discuz來做，這個項目功能上主要是首頁的導購功能，而社區(qū)論壇主要是寫一些前臺的界面（因為DZ的默認界面使用得太廣泛了，現(xiàn)在的人追求個性嘛）。而用戶對于導購系統(tǒng)的要求是：能分類檢索、能按照來源檢索、能自定義排序方式、把所有分類合并在一個頁面上查詢。如果單純的多字段那么dz的分類信息功能就具備這樣的功能。

誠然，要完全符合用戶的需求，我們需要在功能上也進行一個改進的，于是我們?yōu)榇藙?chuàng)建了一個新的入口文件hui.php（其實跟新建一個dz的插件類似），然后把數(shù)據(jù)結果輸出在模版中。涉及到的數(shù)據(jù)表也有好多個，但因為是基于Discuz,很多功能實際上已經(jīng)有了，諸如多字段、數(shù)據(jù)提交、分頁等等，因此實際上這個也不是特別復雜，這個功能擴展代碼量一百多行。

但其中一個細節(jié)，再次讓我提醒自己一定要不要省事，因為省了事可能會帶來更多的麻煩。這也是我們這里的這篇文章的重點，因為在調用分類信息圖片字段的時候，這個字段是采用先把內(nèi)容包裝到一個數(shù)組（內(nèi)容包含圖片的存儲路徑和這個圖片的id），然后序列化保存在數(shù)據(jù)庫中。而我們在做這個擴展的時候要讀取這個圖片的存儲地址，我們就得把數(shù)據(jù)庫里面的數(shù)據(jù)查詢到然后反序列化得到一個數(shù)組（就是一個與保存相反的過程）。

但是這個時候出現(xiàn)了一個問題：普通帖子發(fā)布后，在這個擴展調用圖片是沒問題的，但帖子一修改就出問題了。我就猜想肯定是修改帖子的時候會有一個動作改變，造成了這個結果。于是我在數(shù)據(jù)庫里看下這個字段，結果如圖所示：

到了這里，我想有基礎編程經(jīng)驗的人都應該知道是為什么了，其實對于這個問題我想我們在學習這個知識點的時候是再清楚不過了，但我就是偶爾想減少一點東西（實際上是可用性低的源頭?。?。就是在取數(shù)據(jù)的時候沒有通過stripcslashes()把數(shù)據(jù)中的轉義符過濾掉，因此造成了數(shù)據(jù)不能被反序列化。而原因就是DZ為了保證程序的安全性，在帖子被二次修改的時候會把這個字段加上反斜杠轉義符。而我們在讀取這個數(shù)據(jù)的時候必須先過濾掉這個轉義符，才能把這個數(shù)據(jù)正常進行后期處理。

很多人很多時候，都想省略自己當時想當然認為不不必要的東西，而實際上就是這樣的想當然就可以為以后埋下風險。實際上我個人開發(fā)習慣還算可以的，但就是看到這個擴展的復雜度低就放低了自己的要求，這才導致“很菜”的問題出現(xiàn)。因此我想，后面不管簡單還是復雜，都得按照一個規(guī)范的方式進行。