Darkthread

黑暗執行緒
  • Chrome 網頁中文變醜之謎

    我習慣將 Chrome 標準字型設成 思源黑體字型 , 除非網頁硬將 font-family 指定成細明體(例如: Mobile01),換了字型讓網頁質感變好,比新細明體賞心悅目許多。 Pocket 是我慣用的稍後再讀服務,在 FB 或爬文時看到不急著看但值得花時間讀的相關文章,我會先丟進 Queue 裡收藏,有空再讀。在使用 Pocket 網頁介面閱讀文章時我注意到一件事 – 文字閱讀模式(不開啟原始網頁,改用 Pocket 自訂樣式呈現文章內容) 下,標題字型是 Chrome 預設的思源黑體沒錯...
  • 全文檢索筆記 – Lucent.Net (4) 詞庫校正

    體會過自動分詞(一元分詞、二元分詞)與詞庫分詞的 特性差異 ,但是到目前為止有個問題一直被忽略,我測試用的詞庫直接下載自網路,內容是簡體中文,拆解精準度大有問題。 以 CWSharp 詞庫分詞為例,使用 Github 下載的 cwsharp.dawg 詞庫檔 分析這句中文「競選活動已日趨白熱化,參選人莫不全力尋求廠商支援,其中以鄭少秋勝算最大。」,使用 Luke.net 查看分詞結果如下: 雖然還是能查到關鍵字,但分詞結果並不好,幾乎都拆成單一字元,跟一元分詞沒什麼兩樣。這意味詞庫命中率極低,其根本原因在於我們用的詞庫是簡體...
  • 全文檢索筆記 - Lucene.Net (3) 自動分詞 vs 詞庫分詞

    前篇筆記 試用了盤古分詞器跟 StadnardAnalyzer,繼續研究其他分詞器選擇。 英文能依據空白快速精準分詞,中文沒這麼幸運,必須借助演算法,邏輯複雜許多。中文分詞主要有兩個方向: 第一種是自動分詞,依循固定規則自動切分,例如: 一元分詞、二元分詞;第二種則是詞庫分詞,查詢詞庫識找出已知詞彙;也有分詞器選擇兩種做法兼用,以求互補。 一元分詞與二元分詞的優點是做法簡單,不需維護詞庫,但其索引幾乎跟原文一樣大,查詢效率也較差;詞庫分詞的索引可縮小到原文的 30%( 參考 ),但詞庫完整性是成敗關鍵...
  • 全文檢索筆記 - Lucene.Net (2) 盤古分詞

    前一篇筆記 談完 Lucene.Net 術語與基本觀念,感覺用盤古中文分詞器是不錯的主意。先來個最簡單的「盤古中文分詞->建立索引->查詢關鍵字」 Lucene.Net 範例: private static string IndexPath = "E:\\LuceneIndex" ; public static void SimpleDemo() { //指定索引資料儲存目錄 var fsDir = FSDirectory.Open(IndexPath); //建立IndexWriter...
  • 全文檢索筆記 - Lucene.Net (1)

    網站專案的規格提到了網站內容的全文檢索,不要求比美 Google 的速度與精準度,提供最基本的關鍵字查詢就成。陸續評估了一些解決方案,整理成筆記備忘兼分享。 談到在 .NET 做全文檢索,不能不提 Lucene.Net 這個開源全文檢索引擎! 如果你對 Lucene.Net 很陌生,推薦 CSDN 有篇不錯的入門指引: 使用Lucene.Net实现全文检索 。 剛開始接觸 Lucene.Net 被一堆術語搞得昏頭轉向,尤其是建立索引欄位時,參數裡有一堆 ANALYZE、NORMS、POSITION...
  • MemoryStream 不可擴展錯誤

    記錄自己遇到的蠢問題一枚。 抽象類別 Stream 常被當成輸入輸出參數 ,如此資料可以來自檔案、網路、記憶體或使用者自訂來源,還可套用 裝飾者模式(Decorator Pattern)壓縮加密一次完成 ,提供強大彈性。實務上我常應用的情境是 ClosedXML /OpenXML SDK 之類原本要讀寫 Excel、Word 檔案的場合,函式接受檔案路徑或 Stream 以開啟現有檔案。遇到檔案保存於資料庫,取出的資料格式為 byte[],沒必要寫成暫存檔再開啟,我習慣用 new MemoryStream...
  • 使用 Open XML SDK 在 Word 插入圖片

    客戶提了需求,套表應用想在文件範本的特定位置插入圖片。花了點時間研究如何用 OpenXML SDK 實現,以下是我的筆記。 Word docx 其實是一個 ZIP 檔,文件主體是一份 XML。如果你有興趣研究,可以將 docx 更名成 zip 解壓縮(或在 docx 按右鍵選單直接用 7-Zip 解開),其中 word 資料夾有一個 document.xml,打開它會發現 Word 文件是由一堆 <w:p> 包 <w:r> 組成,其中 <w:p> 對應到 Open...
  • Notepad++ 7.5 取消預設安裝 Plugin Manager

    在新安裝的 Notepad++ 找不到 Plugin Manager 可用,先前遇過安裝 64bit 版本有些 Plugin(插件) 無法使用,但確定我裝的是 32bit 版本沒錯,所以是哪邊出了問題? (什麼? 你沒聽過 Notepad++,快安裝它取代記事本 Notepad 吧! 好用豈止十倍? 而且還是台灣開發者的開放原始碼專案,舉世聞名獲獎無數,又一項台灣之光! 維基百科 ) Release Note 載明預設安裝的插件只剩 NppExport、 Converter、Mime Tool,確實未包含...
  • 【茶包射手日記】Win7 + Chrome 才看得到的網頁特殊字元

    使用者報案網頁多了一個像 L 的字元,在同事的電腦可重現,但在我的機器卻看不到。進一步測試,發現這個像 L 的字元在同事的 Windows 7 要用 Chrome 才會出現,用 IE 看不到;而在我的 Windows 10 上,不管用 Chrome、IE 還是 Firefox 都看不到。透過 F12 開發者工具鎖定可疑字元,複製貼上到 中文編碼解析工具 ,發現原來是 ASCII 0x03 字元,有可能是網頁製作者從 Office 文件複製貼上被夾帶過來的。ASCII 0x03 這類控制碼字元,看不見是合理的...
  • 2017 根除小兒麻痺扶輪社公益路跑

    避暑沈寂了大半年,下半年第一場馬拉松登場 - 2017 扶輪社根除小身麻痺公益路跑。(學到新單字 POLIO - 小兒麻痺,目前全球僅存阿富汗及巴基斯坦仍有病例,扶輪社長期致力於讓小兒麻痺從地球絕跡,並可望 於今年提前達標 ) 跟觀音山馬一樣從微風運河出發,繞河畔一周近 4 公里再進入河濱。多雲無風,溫度 22 度左右,是慢跑的好天氣。 六點多,朝陽從雲間探出頭來,難得一睹日出美景~ 跑淡水河左岸必經的關渡大橋,拍到有點膩了,但沒拍又怪怪的,所以來一張吧。 看到有人開著小船(如下圖)在河中央撒網捕魚...
  • Oracle 自訂函式查詢加速密技–Scalar Subquery Caching

    在 SELECT 指令對欄位執行自訂函式行運算通常很傷效能,但實務上無法完全避免。查詢一萬筆資料代表要呼叫自訂函式一萬次,若函式包含資料表查詢,如同在迴圈裡跑 SQL,是典型的效能殺手,經驗裡也是許多複雜查詢逾時的主因。 見識到同事露了一手,簡單加幾個字元一口氣將內含自訂函式的 Oracle SELECT 加速數十倍! 瞠目結舌之餘,立馬實驗證明效果驚人,特筆記並分享如下。 以下為實驗環境,JeffTest 資料表有 IDX, N 兩個 NUMBER 欄位,先塞入 256 筆資料,IDX 由 0...
  • 為 PDF、Office 檔案產生文字索引

    遇到文件檔全文檢索需求,打算用 SQL Server 全文檢索或 lucent.net 實現,無論使用何者都免不了從 Word、Excel、PowerPoint 或 PDF 檔萃取純文字內容建立索引的程序。經簡單評估,使用微軟的 IFilter 介面 應是較簡單可行的做法。搜索引擎面對的檔案種類五花八門,不太可能涵蓋各種檔案格式,知道從中取出文字內容的方法,IFilter 制定統一程式介面,不管檔案格式為何,只要廠商或第三方有提供專屬 IFilter,搜尋引擎便可使用呼叫統一的 API 方法傳入檔案名稱取得文字內容...
  • 【茶包射手日記】只能跑 32 位元的 AnyCPU .NET 程式

    測試某個 COM+ 元件應用專案,開發者所附的範例專案測試成功,我自己新增 Console Application 或 Windows Form 專案則卡在找不到 Registry 無法執行。強烈懷疑與 x86/x64 有關,由於只有註冊 64 位元 COM+,專案跑 x86 找不到 Registry 是意料中事,但詭異之處在於我已確認過範例專案跟我新增的專案都是設 Any CPU 無誤,甚至放在同一個 Solution 測試,卻一個成功一個失敗。 實測將新增 WinForm 或 Console...
  • IE showModalDialog + IFrame 內嵌網頁無法複製貼上

    今天遇到的奇妙 IE 問題。同事報案,有個網頁單獨開啟操作正常,使用 ModalDialog 顯示時無法複製貼上。( Ctrl-C/Ctrl-V 快速鍵與右鍵選單同步失效) 深入研究後發現這現象在特殊條件下才會發生: 網頁 A 先以 showModalDialog 顯示網頁 B,網頁 B 以 <iframe> 內嵌來自另一站台的網頁 C,此時在網頁 C 上將無法執行複製貼上作業。 使用以下程式重現問題。 Parent.html 以<iframe>內嵌跨站台(localhost...
  • JavaScript 中文排序問題

    今天才發現 JavaScript 中文字串排序有個大問題! 下圖是 KendoGrid 在 Chrome 使用 JavaScript 排序的結果,如圖所示,一到七由小到大排序結果為一、七、三、二、五、六、四,既不是依筆劃,也不是依注音: (SQL 的中文定序就區分筆劃跟注音,例如: Chinese_Taiwan_Stroke_CI_AS vs Chinese_Taiwan_Bopomofo_CI_AS 參考 ) 爬文後得知這是 JavaScript 中文字串排序的己知問題(我 Lag 真大),字串型別有個...
更多文章 下一頁 »
Powered by Community Server (Non-Commercial Edition), by Telligent Systems