從我所知道的,Facebook從鏈接頁面上的meta name="description"
標記的內容屬性拉。
如果沒有元描述標籤可用,它似乎從第一段<p>
標籤開始拉它可以在頁面上找到它。
從頁面上的可用<img>
標籤中提取圖像,並從發佈時提供輪播選擇。
最後,鏈接子文本也是用戶可編輯的(啓動狀態更新,包含鏈接,然後單擊顯示的鏈接子文本區域)。
就我個人而言,我會走這樣的路線:捲曲頁面,解析它的元標記描述,如果不是使用基本算法或僅僅是第一段標記抓取一些可能的數據,然後允許用戶編輯任何(對用戶更友好,同時也解決了用戶代理的不同回報問題)。將用戶作爲ajax面對控件,以便在您的網站訪問您想要預覽的鏈接所需時間不長的情況下不會出現問題。
我建議你使用DOM庫(你甚至可以使用DOM文檔,如果你熟悉它,並知道如何處理可能畸形的HTML頁面),而不是正則表達式解析頁面爲<meta>
,<p>
,並有可能也<img>
標籤。建立一個正則表達式,能夠正確處理所有可能遇到的「野外」與從已知網站中遇到的所有無數種不同情況,都可能會變得非常粗糙。通常會推薦QueryPath,並且有覆蓋many of the available options的stackoverflow線程。
大多數現代網站,尤其是大型網站,都擅長填充元描述標籤,尤其是動態生成的網頁。
您也可以爲<img>
標籤刮取頁面,但您需要在本地託管這些圖像:您可以託管所有圖像,然後刪除除選擇的圖像之外的所有圖像,也可以託管縮略圖(假設您安裝並打開了圖像處理庫)。你選擇哪一個取決於帶寬和存儲是否更重要,或者是一次性處理運行imagecopyresampled
,imagecopyresized
,Gmagick::thumbnailimage
等等(選擇你手邊/你喜歡的任何東西)。你不想熱鏈接到頁面上的圖像,這是因爲它在帶寬方面的道德性,尤其是在鏈接任何網站與熱鏈接預防(引用/等方法)時可能導致破碎的圖像,或者從到期/等我個人可能會去存儲縮略圖。
如果您想要最終刪除您自己的服務器上的圖像/縮略圖文件,您可以將整個鏈接實體作爲處理到期/ etc等的對象進行打包。自從你提出了一個高層次的想法以來,我會將特定的實施留給你。
但事情是,在很多情況下,facebook返回的文本在頁面上不可用。
你看過頁面的meta標籤嗎?到目前爲止,我已經測試了幾頁,這通常是在呈現的鏈接頁面上不可見的內容來自哪裏,並且似乎是Facebook算法的首選。