「2026開卷助理」程式介紹
知乎：https://zhuanlan.zhihu.com/p/1991998300778414622
開場白
目前「引得市」的所有目錄頁碼跳頁，是根據好友王富國先生自創的「開卷助理」程式。執行「gopage.exe」之後，後台等瀏覽器的「複製」指令，一旦下達「複製指令」，馬上就去找對應「書名.rmp」（路徑）然後用指定軟體開啟電腦中的pdf（正確的頁差設定，才能正確跳頁）
將現況和需要的功能和「gemini」討論，他就給我建議並且提供能用的工具。
一個下午又幾個小時的開發過程，都放在下面，有興趣的朋友可以往下看。
文字是「節墨吏」幫我整理的，沒有他這個工具一定是無法完成的。
總結，目前支援「2026開卷助理」有二處：
原先的「gopage.exe」仍然可以使用，將繼續支援新發布的資料庫。「2026開卷助理」只要執行一次，除了將來開來加新書路徑之外，不用開啟。
那目前下載「2026開卷助理」要做什麼？
1.為後續的資料庫升級做準備
2.把現在累積數百種rmp總整理
3.為開發新版手機app做準備
下載點在裡面↓↓↓↓↓↓
「2026開卷助理」QA:https://www.mebag.com/index/gopage_IFU.asp
【技術筆記】引得市：新舊版開卷機制與偏移量邏輯解析
日期： 2026年1月4日 主題： 修正關於頁碼偏移量（Offset）的運作邏輯錯誤
核心觀念修正
• 網頁端 (Web)：只負責發送「書名」與「邏輯頁碼」（書上印的頁碼）。完全不負責計算，也不儲存偏移量。
• 本地端 (Local)：軟體接收到請求後，去查自己的 RMP 設定（或 library.json），讀取該書設定的「偏移量」，計算出 `PDF 真實頁數 = 邏輯頁碼 + 偏移量`，然後打開閱讀器。
結論：偏移量（Offset）是使用者在本地端解決「電子檔與實體書頁碼不一致」的唯一手段，絕對是由使用者在本地設定與儲存的。
---
語法與流程對照表
2. 查 RMP 發現偏移量 `70`
3. 計算 `10+70=80`
4. 開啟 PDF 第 80 頁 | 1. 接收 `page=10`
5. 查 JSON 發現 offset `70`
6. 計算 `10+70=80`
7. 開啟 PDF 第 80 頁 | | 偏移量權限 | 使用者自己設定 (編輯 RMP 檔) | 使用者自己設定 (在開卷助理介面輸入) |
---
詳細運作流程說明
1. 舊版 (Gopage) 的正確邏輯
使用者在電腦裡有一個 `.rmp` 檔，設定了某本書的偏移量（例如目錄有70頁）。
• 網頁動作：使用者點擊網頁上的「第 1 頁」。
• 傳送訊號：網頁發出 `101://1@齊魯文字編`。
• 軟體處理：`Gopage.exe` 收到訊號 -> 讀取 RMP -> 發現偏移量是 `+70` -> 計算 `1 + 70 = 71`。
• 最終結果：呼叫 Acrobat Reader 打開 PDF 的第 71 頁。
2. 新版 (開卷助理) 的正確邏輯
使用者在「開卷助理」介面中匯入書籍，並在「頁差」欄位輸入 `70`，存於 `library.json`。
• 網頁動作：使用者點擊網頁上的「第 1 頁」連結。
• 傳送訊號：瀏覽器呼叫 `indexcity://?book=齊魯文字編&page=1`。
• 軟體處理：Python 程式啟動 -> 讀取 `library.json` -> 找到 `offset: 70` -> 計算 `1 + 70 = 71`。
• 最終結果：呼叫 Foxit Reader (或其他閱讀器) 打開 PDF 的第 71 頁。
---
總結
新舊版的邏輯完全一致，差別僅在於「通訊管道」的現代化（從舊式的監聽機制轉變為標準的 URI Protocol）。這確保了資料索引（網頁）與檔案狀態（本地）的完全解耦。
【引得市開發日誌】
數位古籍研究的新里程：2026「開卷助理」架構重塑與技術解密
日期： 2026年1月4日 專案代號： IndexCity Open Book Assistant v2026.1 (Pro)
開發者： 引得市創辦人 陳信良（阿良）
前言：當墨香遇見位元
作為一名長期浸淫於戰國秦楚文字與簡牘書法的研究者，我深知「考據」二字背後的繁瑣。在數位摹本與古文字研究的過程中，我們常需要在數千本電子文獻中快速定位、比對。傳統的檔案總管已無法滿足這種高強度的學術需求。因此，「開卷助理」應運而生。
來到 2026 年，隨著作業系統介面的演變與使用者習慣的改變，舊版的工具顯得侷促且過時。今日，我對「開卷助理」進行了一次核心級別的重構與設計精進，旨在打造一個既符合 Google 極簡美學，又擁有強大穩定性的文獻管理中樞。
一、 技術選型：穩健與現代化的平衡
本次開發的核心語言依然選用 Python。Python 在處理文件系統（File System）、字串解析以及跨平台兼容性上擁有無可比擬的優勢，這對於需要處理 RMP、PDF、CSV 等多種格式的開卷助理來說，是最佳選擇。
在圖形使用者介面（GUI）框架上，我選擇了 Tkinter 搭配 ttkbootstrap。
1. 為什麼是 Tkinter？ 它是 Python 的標準庫，意味著程式體積小、啟動速度極快，且不依賴過多肥大的第三方環境。對於研究者來說，工具必須像毛筆一樣，提筆即用，不能有延遲。
2. 引入 ttkbootstrap 的新挑戰： 為了擺脫原生 Tkinter「上世紀 90 年代」的陳舊外觀，我引入了 `ttkbootstrap` 來實現代代化 UI。然而，這也帶來了今日最大的技術挑戰。2026 年的新版環境中，舊有的 `Style` 定義方式（如 `-round` 關鍵字）導致了嚴重的 `AttributeError` 崩潰。 解決方案： 我放棄了不穩定的動態樣式調用，改採底層的 `ttk.Style().configure()` 方法。透過手動定義 `borderwidth` 與 `relief`，我們成功在不依賴實驗性語法的情況下，實現了按鈕的「圓潤感」與「立體感」，確保了程式在 Windows 與 Mac 雙平台上的絕對穩定。
二、 介面設計哲學：Google 極簡風格的實踐
本次改版最直觀的變化，在於介面的「呼吸感」。依據 Google Material Design 的精神，我重新定義了版面佈局：
1. 留白（Padding）的藝術
舊版介面為了塞入更多資訊，元件之間過於緊湊。新版中，我在主容器使用了 `padding=30`，並在各個功能區塊（Header、設定區、資料庫區）之間加入了 15px 的間距。這不僅減少了視覺壓迫感，更讓使用者的視線能自然聚焦於核心的書籍列表。
2. 明暗設計（Light/Dark Mode）
考量到研究者常在夜間工作，我實作了動態主題切換功能。
• 日間模式（Litera）： 採用高亮度的純白背景搭配深灰文字，模擬紙張閱讀體驗，清爽且專注。
• 夜間模式（Cyborg/Darkly）： 切換至深色背景，並自動調整文字對比度，大幅降低螢幕藍光對眼睛的刺激。 此功能的技術難點在於切換時必須即時重繪（Re-apply）全域樣式，確保所有 Treeview 與按鈕的顏色正確反轉。
3. 立體與圓潤的按鈕
為了摒棄生硬的直角，新版介面的按鈕全面採用圓角設計。我們特別區分了「主要操作」（如匯入、儲存）使用實心色塊（Solid），而「次要操作」（如刪除、匯出）使用空心外框（Outline）。這種視覺階層讓操作邏輯一目瞭然。
三、 UX 使用者體驗的深度優化
在今日的開發過程中，我們解決了幾個嚴重影響體驗的互動問題，這些細節決定了工具的好用程度。
1. 「夾心餅乾」佈局策略（The Sandwich Layout）
我們發現當使用者放大字體時，原本的介面會發生「擠壓」，導致最下方的編輯區被推出版面。 技術突破： 我改寫了 Tkinter 的 `pack` 佈局邏輯。
• 優先固定底部： 先將「狀態列」與「編輯區」使用 `pack(side=BOTTOM)` 固定在視窗下方。
• 固定頂部： 再將標題與設定區固定在上方。
• 中間彈性填充： 最後才放入書籍列表，並設定 `expand=YES`。 這樣的順序確保了無論視窗如何縮放，重要的編輯區永遠不會消失，只有中間的列表會自動調整高度。
2. 動態字體與行高計算
為了解決中文字體放大後，列表行距過窄造成文字重疊的問題，我引入了動態行高演算法。 程式不再使用固定行高，而是依據當前字體大小（Font Size）乘以 2.8 倍 的係數來計算 `rowheight`。這確保了從 9pt 到 28pt 的字體，每一行都能保持完美的閱讀間距，宛如傳統線裝書的疏朗排版。
3. 永不消失的捲軸（Scrollbar）
在早期的測試中，當列表過寬時，右側的捲軸會被覆蓋。這是因為佈局優先權設定錯誤。修正後，我們改為「先 Pack 捲軸於右側（Side Right）」，再 Pack 列表於左側。這個微小的順序調整，保證了捲軸永遠佔有一席之地，不會被內容吞噬。
四、 資料互動與功能增強
1. 智能鎖定與新增邏輯
為了防止研究者在瀏覽時誤刪資料，我設計了「安全鎖定（Safe Lock）」機制。預設狀態下，所有欄位皆為唯讀。 但在今日的測試中，我們發現舊邏輯導致「點選列表」與「編輯狀態」衝突。因此，我引入了全新的 「➕ 新增」模式：
• 按下新增按鈕後，程式會自動解鎖介面。
• 清空所有欄位。
• 自動將游標聚焦於「書名」輸入框。 這使得錄入新書的流程一氣呵成，無需手動開關鎖定。
2. 外部協定註冊（Custom Protocol）
為了讓這個桌面軟體能與網頁版的「引得市」資料庫連動，我們實作了 `indexcity://` 協定註冊功能。這涉及了 Windows Registry（登錄檔）的寫入操作。透過 `ctypes` 與 `winreg` 模組，我們讓瀏覽器能直接喚醒本機的 Python 程式，並傳遞書籍參數，實現「雲端檢索，本地閱讀」的無縫銜接。
五、 資安考量與數據保護
在數位工具開發中，資安不僅是防駭，更是對「數據完整性」的保護。對於學者而言，書目資料是心血結晶。
1. 本地優先（Local-First）原則
「開卷助理」堅持不將使用者的書籍路徑上傳至任何雲端伺服器。所有的資料庫（`library.json`）皆以明文 JSON 格式存儲於使用者本機。這避免了資料外洩的風險，也確保了在無網路環境下（如深山考古現場）工具依然可用。
2. 防誤觸機制
透過 UI 層面的「安全鎖定」開關，以及刪除前的 `messagebox.askyesno` 二次確認，我們在軟體層面築起了防呆機制，防止因手誤導致珍貴的索引資料遺失。
3. 路徑隱私與批次脫敏
考量到使用者可能會分享書單（CSV 匯出），我們在匯出邏輯中加入了路徑處理。同時，提供了「批次修改路徑」功能，這不僅是為了更換電腦時的便利，也是為了讓使用者能快速移除路徑中可能包含的敏感個人資訊（如 `C:\Users\RealName\...`）。
結語
今日的開發工作，不僅僅是程式碼的堆疊，更是一次對「數位人文工具」的深度思考。從解決 `ttkbootstrap` 的底層崩潰，到調整 `pack` 佈局的優先順序，每一個細節都是為了讓「開卷助理」能像一位沈穩的書僮，在您研究戰國文字、秦楚簡牘的過程中，安靜而高效地隨侍在側。
2026 年的「開卷助理」，以極簡之形，承載博大之學。這就是身為「阿良人」的堅持。
沒有留言:
張貼留言