準備做許可權的時候，有兩套方案。一·在資料庫儲存所有的那些需要控制的點叫做許可權表。基本就是一些id。然後乙個角色表，角色對應許可權，使用者對應角色。
第二種是以前在乙個專案中見過的許可權控制方法。使用者-角色-許可權，這些不變，有變的是:許可權不用一堆資料表示：使用二進位制即類似"01011100110"這樣的字串來表示，在使用者拿到這些資料以後使用同一的方式進行解析，比如前四個表示某個窗體，某個頁面，前四個中的第乙個表示新增0是可用1是不可用。
初步分析兩者之間的差異，先說共同點。都有一些寫死的東西。官方一點的話叫做，擴充套件性較差。
差異：第乙個結構清晰，維護起來比較容易。但使用者頻繁的查詢，增加了不必要的io操作，效能方面會差很多，尤其web程式。
第二中：可讀性差。維護起來麻煩。可能需要在對應的結構資料中新增一些必要的資訊才能達到擴充套件的可能，一旦出錯，除錯也是個麻煩事。優點就是佔的地方小，如果用到web中可以很大程度上的提高效能。對於某使用者的許可權資訊，可能只有不到1kb.
那麼理想中的許可權應該是可以擴充套件的，而且在網路傳輸中盡可能的減少傳輸內容，最好是在這個基礎上再減少io的操作，讓各部分的負載能達到某種意義上的平衡。當然了，最重要的還是可靠穩定以及拿到任何地方都可以使用。
可擴充套件，目前能想到的貌似也只能是將資料像類一樣儲存，將來若是某個頁面或者窗體新增了某個需要控制許可權的按鈕只需要在對應的類裡邊加上要給屬性就ok.資料儲存上吸取第二種方式的那種儲存。但不能完全複製。在它的基礎上做改動，想來想去貌似只有json格式的資料能同時滿足這兩種方式的操作。。
結構化滿足，能被反序列化。能擴充套件，而且，修改不會對之前的資料產生影響。當然這個裡邊該考慮的還有json支援的資料量的大小。
還有乙個容易忽略的問題，就是如何將這些資訊定義到乙個類裡邊，或者某個可結構化的東西中去。將來如果要給某頁面加個按鈕，實現一些無關後台的東西，但同時要求只有某人才能看到一類的需求。重新修改程式當然可以做到，但希望能把這個東西做成可拆卸的。只修改某個配置檔案，以及頁面就完美實現。
《元素id/>《元素id/>
《元素id/>
《元素id/>
在許可權分配的頁面中讀取這個xml文件。被選中的節點，在儲存的時候放到json串中。放到資料庫裡面...
如果這麼做，乙個專案中許可權只會有乙個xml，乙個頁面維護這個xml(開發時，新增節點，刪除），乙個許可權賦值（修改）的介面。資料庫 使用者表中新增乙個角色（varchar）,存放使用者的角色屬性。乙個使用者可能會屬於多個角色，這裡的大部分資料只會是乙個資料。不排除有多個角色的使用者，但這樣的資料會非常少，所以這裡只需要用逗號隔開，程式那邊做點處理就好了。角色表中會有乙個欄位來儲存該角色對應的json資料。將來使用者登入的時候獲取到對應的角色對應的json資料。通過一點點計算就可以控制到每個頁面的元素展示，顯示還是隱藏...
到這裡許可權功能已經算是基本搞定了。這需要注意的就是xml中的pagename，元素id，與對應頁面的耦合度高，一處頁面名稱的修改直接會導致許可權控制失效，id的修改也會導致。一般情況下，頁面的名稱是不會變的。會變化的可能只會頁面中的元素id.可以新增額外的標籤描述attribute。來判斷對應元素的顯示隱藏..
關於許可權角色管理的一些想法
我們在系統需要定義以下幾種型別 group,user,role,perssion,resource 可是物件object或者是操作operation 1.group 使用者組 一些特定任務所組成的使用者集合。2.user 使用者 對應到我們的系統的使用者，也就是人 乙個使用者可以在不同的使用者組扮演...
關於資料許可權設計的一些想法
在各種系統中，要保證資料物件的安全性以及易操作性,使企業的各業務部門 職能部門能夠方便而且高效的協同工作，那麼乙個好的資料許可權管理設計就成為乙個關鍵的問題。雖然企業中各個單元的工作流程有所不同，處理的資料物件也有所不同，但是在組織結構 資訊的處理方式上具有很多相同的地方，這就為設計資料物件的許可權...
關於OCR，一些想法
ocr一般分為兩種 1，根據給定的字元特徵集合，提取未知字元的特徵進行匹配識別 典型例子 gocr 2，不知道字元特徵，但給出提取特徵的規則，通過機器學習training來獲取某個字符集的特徵集，對未知字元進行匹配識別。典型例子 tesseract 第一種方法簡單，在某些場合很高效，但比較侷限，字符...