對於web網站, 客戶端全局考慮用戶UGC的處理

對於UGC這塊兒一直想要總結出一套比較舒服的作法, 但是隨着需求的不斷改變,以前以爲行得通的作法如今感受也變得愈來愈複雜,囉嗦. 若如今若是須要實現新浪微博, QQ空間說說等一些作的比較好的網站來看. 我來談談對於這一整套流程的作法, 這裏包括WEB, IOS,Android來考慮. 結合本身的網站來隨便說說:

         用戶輸入一段文本, 網站須要有的功能:

1.       @用戶, 在瀏覽時候, @用戶須要加上連接, 而且以 @用戶 形式展現;

2.       IOS用戶, 輸入法軟件輸入的emoji表情, 也可以正常顯示. 這裏我是用的替換,既在存入數據庫的時候, 就將替換成[神馬]->

3.       用戶在貼一個URL地址的時候, 若是http://www.google.com.hk 純文本的時候, 頁面也可以點擊 http://www.google.com.hk

4.       大多數狀況下, 原則是用戶輸入什麼, 顯示什麼?

例如: <a href=」http://www.google.com.hk」> http://www.google.com.hk</a>,  最後用戶展現的時候, 仍是應該以原文本的形式展現出來, 而不是 http://www.google.com.hk , 可是若是你輸入[神馬]這種特殊的仍是會顯示圖出來;

         大概的功能就是這些, 因此我須要將input->DB->output這個流程, 每一步幹什麼,總結一下:

1.       用戶在提交數據的時候, 在action中咱們對於emoji表情作替換, 替換成[XXX], 過濾掉網站中不容許的標籤(看狀況而定), 就這樣子存入到數據庫中, 這裏不須要將特殊標籤作轉義. 例如: 「<」 -> 「&lt;」. 這樣子的好處就是存儲了用戶比較原始的數據.

2.       從瀏覽頁面上來看, 最終的代碼應該都是未轉義的, 由於emoji要在WEB顯示, 其實仍是顯示一個圖片<img>, 也就是說<img>標籤須要執行. 可是若是咱們輸入<a href=」http://www.google.com.hk」> http://www.google.com.hk</a> 仍是要顯示純文本,  因此,就會遇到一個問題, 同一段文本中, 一部分代碼是但願它能執行的, 一部分是不執行的.  那就是先將標籤轉義掉例如: 「<」 -> 「&lt;」, 再替換emoji標籤, <img>讓其執行.

3.       @用戶, 在存儲的時候仍是存純文本, 只是在查詢的時候, 在服務端代碼裏面根據必定的規則(我用正則)爲其添加上<a>標籤. 貼連接跟@用戶作法相似;

4.       若是是這樣子, 在JS中就會存在必定的問題, 就是當你從action中拿數據的時候, 由於是從DB直接讀取, 而DB的數據是未轉義的, 在JS中若是直接拿到數據append到一個DOM節點的時候, 他是會執行的. 這會形成JS注入安全問題. 因此就要JS調用者明確知道, 在調用以前須要轉義.

 

這就是我對於處理用戶UGC的處理方法, 不知道是否走了彎路. 特別是JS取action中數據的時候, 每次都須要轉義, 這個比較繁瑣.