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

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

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

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

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

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

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