先簡單講一下 "entity" 這個字 的中文翻譯。"entity" 常見的翻譯是「實體」，但嚴格來說（好啦，根據我的哲學癖來說），這不是乙個好的翻法。哲學上來說，「實體」通常是用來翻譯 "substance" 這個字，而 "substance" 到底是指啥可是個歷史上出名複雜難解的議題（可以去 sep 史丹佛哲學百科查一下）。撇開煩雜的理論問題不談，在蒐羅語詞慣用法的維基字典上，"entity" 意義也不同於 "substance"。（這裡是指英文版。中文版的翻譯基本上完全忽視兩者意義和用法上差異，把兩者都翻成「實體」。然而基本上就算是看英文版，你也需要一些哲學訓練才能搞清楚差別在哪裡。
為什麼 "substance" 常被翻成「實體」？因為它有表達物質、事物的本質等意思，通常是指那些占有時空位置的基本存有物以及/或者在環境變化中能夠保持獨立自存的東西（相對於事件或可被擁有/喪失的性質）。而 "entity" 則較為抽象，它表達任何獨立自存的東西，而這些東西不一定會有物質性的存在。像是抽象存有物（數字）或虛擬存有物（孫悟空），或是無形體、非物理的東西（像是語言、鬼魂或精神...等等；如果你發覺你沒法接受這些東西有「存在」可言，恭喜你，你剛發現自己是個物理論者了）。甚至在比較寬鬆的用法中，它可以指存有或存在的狀態本身。
在這些的意義下，"entity" 比 "substance" 來得廣泛與抽象。在其他較具體的脈絡下， "entity"則被用來指涉抽象或具體的組織單位。在商業脈絡中，"entity" 指能夠進行商業活動的獨特單位，像是一家公司、乙個部門、乙個團隊組織，甚至是乙個人。在計算科學中，則是指任何可以被存入資料庫的資訊或資料。如果可以理解 "entity" 和 "substance" 的這層對比，就可以為什麼 "entity" 不該被翻成「實體」（因為那只是它的一部份而已嘛），而被翻譯成「存有物」、「元目」甚至俗稱的「東西」都還好一點。由於我們在這裡討論的是計算科學中的應用，把 "entity" 翻成「單元」，比較可以保持它既能表達具體事物又能表達抽象存有的意涵。
接下來回去講 drupal。
在 drupal 4.x ~ 6.x 的發展過程中，內容管理的主要角色是 node（中文多翻成「節點」）。在這個階段，cck 模組是必備的第3方模組，用來規劃與自訂各種 node type，也就是「內容型別」。而內容型別之間的差異就在於其組成元件—field（字段）—的不同搭配方式。而 node 之外的其他專案，比方說分類詞(taxonomy term)或者位置(location)，則被設計成可以被組裝到 node 上的配件。
以分類詞來說，使用過 drupal 4.x ~ 6.x 的人都應該很熟悉 taxonomy 模組，通常的設定方式就是在主分類(vocabuary)設定頁中，將某個主分類指派給乙個或多個內容型別。設定好之後，在新增這些型別的 node 的表單中就會出現屬於該主分類的分類詞選單或輸入框，讓使用者替該 node 指派或建立分類屬性。
然而，在這個階段大家會共同有的乙個困擾就是，這些被額外裝配進來的屬性專案不像 cck 字段那樣好控制或者客製化。在 cck 的「字段管理」裡頭，你可以自由拖放字段次序，調整不同欄位在 node 的檢視模式(view mode)中的顯示方式。taxonomy 等模組雖然可以大大擴充 node 的屬性與功能，但是沒法子像 cck 字段那樣有彈性，可以方便地進行調整。後來開發出的 taxonomy image 或者 content taxonomy 等模組就是在這樣的架構下試圖去克服這個缺點，後來也的確愈來愈流行，變成幾乎像 cck 那樣的必備模組。
可以說 enitty 的概念就是為了解決這個問題而提出來的。畢竟，如果 cck 這麼好用，那為什麼不把所有的東西都納入這個架構呢？drupal 7.x 放棄了 node 為設計中心的架構，而改採一種去中心式的、但可以彼此關聯的分散架構。在這個新架構底下，沒有 node 和屬性的區別，只有 entity 之間的差異。這個重大的改變來自三個方面：
cck被納入核心模組，改成 field 模組。日後所有可以加入 node 的屬性都以字段的方式呈現，而同乙個字段可以在不同的 entity 中被重複使用。
entity 之間能夠完全以 reference 欄位的方式來彼此關聯、引用。這保持了不同 entity 的關聯性，也讓關聯欄位有了調整彈性。
entity 表單字段與字段顯示(display)的分離。這點完全解放了 node 前後臺的對應架構，讓 node 的表單和檢視模式可以獨立開來，不僅可以讓表單元素可以在檢視模式中有不同的排版順序，更可以隱藏有資料庫用途但不必要顯示的元素。而其他模組（如 views attach）也可以利用這點，將其他資料化為顯示字段，呈現在 node 裡頭，而不必新增乙個表單字段才能做到。
這樣講可能還是太過抽象，舉一些例子可能會比較好懂。情況是，幾乎所有過去被當作是附加屬性的東西，像是 user、taxonomy、comment 等等，在 7.x 裡面都變成了獨立的、可裝配欄位的 entity。所以我們可以在某個 vocabuary 裡頭加裝圖片字段 field_image，替不同的分類詞加上不同的代表圖片。我們也可以在 comment 中重複使用同乙個圖片字段 field_image，讓發表回應的使用者可以自行上傳與該回應有關的圖片（比方說螢幕截圖）。或者我們可以在 user 裡頭加裝乙個文字字段，蒐集使用者的姓名、聯絡電話或者郵寄位址。
drupal 7.x 預設有兩個 reference 字段，user reference 與 term reference 。可以用來在 entity 中引入 user 和 taxonomy tern 這兩種 entity。不過加裝了 entity reference 這個模組之後，基本上你可以在任一種 entity 中引入任何其他種的 entity。比方說，一般的情況下，在「文章」entity 中可以引用 user 和 term 這兩種 entity，用來鏈結相關的「作者」和「分類標籤」。在高階的用法裡，你可以在 user 中引用 term，將使用者分門別類。或者在 comment 中引用「部落格文章」entity，讓使用者在撰寫評論時可以加入「相關部落格」資訊。假設你有 n 種 entity，就可以有 n × (n-1) 種引用鏈結的方式，全看你要滿足什麼樣的需求。
這種去中心但又可互相引用的設計，帶來了內容架構上的超大彈性。這不僅影響到單一的 node 會如何編輯和呈現，也讓 views 的建置工作有了根本的變化。在過去的 views 管理介面中，user、term 裡頭的相關資訊預設都被放在「字段」裡頭，和所有 node 裡頭的字段沒有兩樣。但是在 views 3.x 裡頭，「字段」裡頭將沒有固定的專案，而是會隨著前述 reference （引用）關係變化。
舉例來說，當我們在 views 過濾出屬於 a entity 的節點專案時，可加入的「字段」專案將只限於與 a 有關的字段。假設 a 透過 reference 字段引用了 b entity，那麼就可以利用這個引用關係，把屬於 b 的相關資訊加到「字段」中，共同呈現在 views display 裡面。具體說來就是，你可以製作一張**，列出你所有的「農產品」節點標題以及它們所引用的的「分類」標題。在過去，這種作法大概就是可處理的極限了。但在 drupal 7 中，如果你的「分類」專案中有圖片或文字字段（比方說「英文標題」），你都可以透過在 views 中加入這種引用關係，而把這些圖片或文字等屬於 b 的字段資訊，加入到同一張**裡頭。（換言之就是，你可以用「分類圖片」取代「分類標題」來標示出產品的類別）
在 views 中利用引用關係而加入所需字段的具體作法，就是使用它的 relationship 功能。views 7.x 的乙個重大變革就是，過去少用甚至完全不會用到的功能， relationship，變成了和 context filter（過去的 argument）同等重要與基本的專案。如果你想要製作豐富與多元的 view display 來呈現複雜的資料關係，了解 entity 的概念以及怎麼樣在 views 中透過 relatinship 來結合不同的 entity 字段，將會是必要的學習過程。
android post提交的entity問題
1。提交的是一些json的string 2。提交的是一些key value 3。提交一些有點大的，聲音檔案，將其轉換成byte 4。其它一些自定義的資料 比如 post提交一些檔案，也想用httppost這個類通一進行提交 1.先將模擬post上傳檔案的一些格式上的東西，檔案等寫到乙個bytearr...
Cesium 實現Entity的拖拽
引入 有時候我們需要對我們在cesium上繪製的點，線，麵等物件微調位置。如果可以直接拖拽物件到指定的位置最方便不過了。思路 1.覆寫滑鼠事件，其中 leftdownaction leftupaction mousemoveaction 是自定義的函式，有vm是因為使用了vue。this.viewe...
CesiumJS 旋轉entity物件的方式
最近用cesium做的一些效果，載入的entity物件，希望通過滑鼠操作，或者資訊輸入，實現位置移動以及圍繞中心位置的旋轉。網上搜了很多案例，沒有解決這個問題。今天偶然解決了，把解決辦法梳理如下。viewer.entities.add id blue rectangle,zindex 3 recta...