2015年12月11日 星期五

Lolinote 蘿莉筆記:極簡主義的後繼者

先來講點古吧。

2010 年 9 月的某一天,大概是寫作不順之類的原因,我感到極度煩躁,想要掀桌。我受夠永無止盡地尋找測試那堆混蛋筆記軟體了。什麼 Evernote,連個 <h2> 都打不出來;什麼 tomboy,筆記一多就根本無法管理,什麼 vimwiki,愛用自己獨特的語法缺乏相容性。

因為所以加上年少輕狂,客觀上說起來有點白痴的事情就那樣發生了:嗯,我打算自己搞一個。

為了著手寫隻全新程式,我研究了幾種比較流行的程式語言特性,接著興沖沖地去網路書店訂了一本 Python 的入門書。厚厚的一本花了我六百多元,說實話有點肉疼,但我已經忍無可忍。

開發進行得出乎意料順利。

第一第二週時,把語言學了個大概,教科書翻到第四章左右。接下來就忍不住開始實戰寫 code,一個月後可運作的原型已經完成,兩個月後原型已經穩定到我自己敢用的程度。我發出八神庵三段笑(哼哼哼哼呵呵呵呵哈哈哈哈),停止大規模開發,轉頭作為使用者用了接近一年的時間。隨後藉由使用過程中持續累積的自我吐嘈,嘗試開發了第二版 (1.X)。

隨後是第三版 (2.X) 與第四版 (3.X)。

為了回饋社會(純屬炫燿),軟體開發到某種程度後,我將自己的得意作品公開,也因此認識了一些有趣的傢伙。有人教我用輕量級標記語言寫 README 檔案,有人幫我打包轉發到其他 Linux 平台,有人回報了 bug,還有人回報了太多 bug 與 Feature request 讓我神經緊張根本沒法睡覺 XDDD。嘛,諸如此類。

這是一段很漫長。也很快樂的時間。



在此非常遺憾地宣佈,Lonote 專案的開發到此暫時告一段落。

順便一提,有點感傷是真的,但說遺憾只是開個玩笑,其實我還蠻開心的。Lonote 專案停止的原因,不是我在這個領域失敗了,而是我找到了更適合用來解決筆記問題的方法,並且終於甩掉大量包袱的緣故。

為此開了新的專案。專案名為 Lonote Lite Note-taking Rule Set,簡稱 Lolinote

我和所有蘿莉賭咒發誓這和我是蘿莉控一事沒有任何關係。

Lonote 專案的問題


要說明 Lolinote 專案究竟是怎麼回事,得先說明 Lonote 的問題。必須要強調的是,我並不認為 Lonote 是一個差勁的專案,它的特色與優點相當鮮明,其中有些功能特性即使到了現在我也相當喜歡,這包括但不限於:

  • 基於 HTML 的富文本格式:幾乎可以紀錄任何東西
  • 方便的熱鍵編輯
  • 內建某種類型的版本控制機制 
  • 伺服器、客戶端架構:符合現代技術發展方向、讓多人共享、或單人多設備同時存取同一資料庫成為可能
  • 透過 CSS 變更佈景主題
  • 嚴肅紀錄 Metadata:像是創建時間、修改時間、筆記的說明、筆記間的排序等
  • 允許附件:如圖片
  • 分層的安全授權機制
  • 便捷的 wiki 式連結

但用戶真的需要上面那些功能嗎?

比方說,我真的需要分離伺服器與客戶端嗎?我需要知道筆記新建與更新的時間嗎?我會想要撰寫並閱讀筆記的說明 (description) 欄位嗎?我需要完整支援 HTML 的所有格式嗎?我真的需要變更佈景主題嗎?我需要讓多人同時存取我的筆記嗎?我真的需要分離讀寫權限嗎?我需要 (限定只能以某種特定形式進行的) 版本控制嗎?我需要筆記之間的 wiki 式連結嗎?

就算是如附加圖檔這種功能,我也肯定至少在百分之九十五的筆記中都用不著--前提是用戶沒把它當成網頁剪貼簿來用。時間戳記之類的東西更是一次也沒派上用場過。

但作為代價,Lonote 付出了什麼?

  • 很難匯入匯出資料
    如果不附上一大堆說明與前提條件,其他用戶無法使用 Lonote 匯出的筆記庫,而且是連讀都沒法讀。
  • 用戶無法針對特殊需求與偏好,改用不同的處理工具
    我相信 Lonote 的編輯器與熱鍵相當好用,但如果用戶今天想要批次取代 500 多個筆記中的某些關鍵字,它沒法換用 sed 之類的工具來解決問題,這非常磨人。目錄產生器、筆記移動介面與搜索功能也相同。
  • 想存取筆記,需要先起服務器
    哪怕只打算查/記錄一個短短的電話號碼也是如此。非常麻煩。
  • 部份資料損壞,有可能波及整個筆記簿
    一旦有筆記頁之間的關聯性需要紀錄,存放相應紀錄的 Metadata 就會因此成為系統中的弱點。雖然我個人沒有碰過這種狀況,但有用戶碰過這種問題,這讓我很不安。一個系統在設計之初就該假設它是可能會面對損壞的,但這種假設在節點間具有複雜關聯性的系統中會非常麻煩。
  • 要隨時 on 一個近代瀏覽器作為客戶端
    因為近代瀏覽器全是記憶體怪獸,因此在低規系統上存取筆記變得很不方便。此外在手機上存取筆記時也會因為瀏覽器實作不同受到某些特殊的限制,比方說「關閉分頁前自動存檔」的功能在手機瀏覽器上就一直實作不出來。而在 tty 中取用筆記內容更是妄想。
  • 熱鍵常會起衝突
    當瀏覽器升版時,熱鍵常會起衝突。跨瀏覽器造成的熱鍵衝突則更多。我接到一海票這方面的 bug 回報。
  • 沒法運行或安裝程式時,對筆記什麼也做不了
    因為資料格式複雜,沒法運行或安裝程式時,對筆記什麼也做不了。就算手動查找檔案系統也沒用,資料不透明。

前述提及的功能,能有當然很好,但絕大多數功能實際使用時幾乎都用不到。然而為此付出的代價,卻血淋淋的賞我一刀。我還沒把身為程式作者,必須面對大量 coding 與 dirty work 算在內。讀讀看 Lonote 的設計哲學吧,裏面寫著「開放的資料格式」,但是如果 Lonote 確實擁有一個真正的開放資料格式,為什麼我還會煩惱上面那些問題呢?畢竟如果 Lonote 真的做到了,面對一個開放的格式,我應該會有大批現成的工具可用來存取我的資料,以致於上述絕大部分的問題都不該發生。我確實沒有限制他人存取,設計也全部公開。但這種「開放」是狹義的,是紙面上的;而不是廣義的,可以被人在日常中實際拿來運用的。

我感到不滿,但一開始我並不清楚自己在不滿些什麼。為了解決這些撓得我癢癢的心頭刺,我詳細構思了 Lonote 4 的設計草案,大幅擴張 Lonote 的功能與效能,其內容包括使用 AngularJS 與 json-base metadata、更優秀的版本管理機制與多用戶與樹狀權限管理系統等等,總共有數十項之多,並互相協調。而在此同時,我也再次開始尋找其他筆記軟體已完成的實作,甚至一度把 Lonote 中存放的資料又遷移到 Evernote 與 vim-notes 上面去。

然而我很快就意識到這一切努力根本是在開倒車,先前讓我頭疼的問題,有很多不是 Lonote 獨有的,部份軟體甚至比 Lonote 還要慘烈許多。我逐漸意識到我眼前困境不是透過大幅增加功能就能解決,而是 Lonote 的「取捨」沒有落在最佳的點上。

新專案 Lolinote 就是為此而生的。

Lolinote


蘿莉筆記的概念與 Lonote 截然不同,也與世界上絕大多數的筆記不太相似。因為它不需要依賴專門的程式來操作它

它不像其他筆記系統那樣,嘗試將所有功能聚合在同一個或少數幾個程式裡。取而代之,它只是定義了一組簡單直觀符合直覺且只需要最少人力維護的規則集,讓使用者可以使用任何工具來讀、寫、刪、改、同步、備份、版本控管他們的筆記。

用戶可以使用其他程式來強化蘿莉筆記的使用體驗,但是並不真的需要他們。

蘿莉筆記的核心考量,在於筆記對我們實在太太太太太重要,以致於我們根本離不開它。我們應該要能在任何情境、任何場合、任何時間、任何平台、使用幾乎任何工具來存取自己的知識庫,且即使是在最糟糕的狀況下,依然能確保一個合理的操作效率。

與簡單、穩定、易用、易維護、易與外部工具整合這些性質相較,蘿莉筆記認為在筆記領域中,華麗的排版與多媒體支援是比較次要的問題。

蘿莉筆記適用於以下用戶:

  • 希望個人知識庫完全由自己掌握,不會流到其他公司手上
  • 希望筆記和外部工具擁有最高的相容性
  • 希望能完全了解筆記資料的所有細節,沒有「隱藏的秘密」
    沒有額外的註冊表、沒有四散的 Metadata 檔案、沒有分離到系統中的資料庫、沒有無法解讀的 Binary 檔案等等等
  • 希望筆記擁有最高的容錯性,任意一小部份資料損毀不會摧毀整個系統
  • 希望筆記佔用空間儘可能地小
  • 希望筆記能夠輕易匯入轉出
  • 希望筆記系統中所有功能都是可選/可抽換的。
    從編輯器到同步程式,從檔案瀏覽器到全文檢索系統,從頁面渲染器到版本管理機制,甚至是 outliner。所有功能都可裝可拔,系統規模可大可小,或是隨時按需抽換使用。
  • 經常面對各種惡劣狀況,或不想未來面對惡劣狀況時束手無策,包括:
    系統連不上網路,或時斷時連
    無法在機器上安裝任何軟體,但又被迫使用它好幾天
    只有純文字介面的機器可用
    想在智能手錶、Android 冰箱或 google 眼鏡上查自己的食譜

蘿莉筆記不適用於以下用戶:

  • 主要目的是想剪貼保存網頁
  • 會在筆記中加入大量附件與多媒體內容
  • 需要複雜的富文本支援

再次強調,蘿莉筆記並不是一隻程式--她只是一套簡單到幾乎光靠常識都能遵循的規則集而已。

規則


蘿莉又小又可愛。它的核心規則如下:

  • 規則一:一個筆記對應一個檔案,每個筆記都互相獨立。
  • 規則二:筆記為 markdown 格式。
  • 規則三:筆記檔案檔名等於 "標題" + ".md"。
  • 規則四:所有筆記檔案被放置在一個多層的目錄樹中。
  • 規則五:筆記的排序等於檔名字串順序。
  • 規則六:筆記樹的最高層目錄下必須要有一個 .loli 的資料夾。
  • 規則七:筆記的內容必須要以 utf-8 編碼。

七條規則中每一條都有意義,也對優缺點做出了明確的取捨。比方說規則一簡化了管理程序與運用彈性,並因此犧牲了紀錄額外 metadata 的能力等。詳情請參閱維基 設計哲學與規則 的章節,這邊不詳述。

讀完設計哲學與基本規則後,您還可以繼續參看擴展規則頁面。擴展規則可能比較複雜難記、或有某種較嚴重的副作用,也可能會稍微改變 Lolinote 的原生規則細節。但無論如何,擴展規則絕對不會打破 lolinote 的設計哲學。以目前來說,像是對圖檔與附件的支援就被放在擴展規則裡面。

為什麼要遵循蘿莉的規則


講到這裡,您可能會面露微笑,想說自己早在用類似的方法記筆記了,幹嘛這樣大驚小怪。或儘管覺得不錯,但覺得這樣條列規則太過嚴肅。對!問題是,這麼簡單的東西,為什麼我們還需要規則呢?

主要是為了工具的互通性。

蘿莉筆記不依賴工具,也能達到一個不錯的運用效率,這是她的關鍵設計目標。但是我們依然可以揉合一些工具讓她能運作得更方便。舉例來說我就寫了支叫作 Lolikit 的命令行輔助程式,可支援使用者對整個筆記庫進行全文檢索、依據 mtime 時間戳列出最新修改檔案、還有快速定位筆記庫中的瑕疵並(可選地)自動修復問題等等。

如果您使用了與 Lolinote 相同的規則集,則我設計的工具包您也可以通用,有興趣甚至可加入合力開發。或是之後有人寫了個諸如直接把一本筆記直接當成網站 Host 起來的工具時,大家也都可以共享開發成果。

Lolinote 的 wiki 中也有一個頁面,專門用來列出哪些工具適合與 Lolinote 共同使用。我已經先一步在其中放了些覺得不錯的工具。如果大家共享經驗,一定能探索出更多更好用的東西與使用方法出來。至少我是這樣期待的啦。

因為一時找不到更好的 wiki 平台,所以就先暫時 host 在 bitbucket 上面,日後要移動到別處再說。這個 wiki 採用 markdown 格式,權限被設定為所有人都能修改編輯。如果您發現什麼好工具,請直接上去紀錄一下。主要頁面請使用英文撰寫,但您可單獨開其他語言的頁面,文法不通也可直接修改,不要搞破壞都OK。

lo2loli


為了遷移原先用 Lonote 寫成的筆記,我寫了一隻將 Lonote 轉成 Loli 格式的命令行轉檔程式。稱為 lo2loli。因為這算是一次性工具,所以我沒有將其上傳到 pypi 上面,操作起來可能比較繁瑣一點,請聽我說明。

要使用這個工具,首先您必須要有一個 python3.4 版本。python3.5 不行,更低的版本也不行。這是因為程式中的相依套件 html2text 目前在 python 3.5 版上運行時有 bug 還沒修好,在本文撰寫的這個時候該套件作者暫時不允許 Python 3.5 執行它。

python 準備好之後,用 pip install html2text 安裝輔助套件。

然後對從 Lonote3 網頁介面下載下來的 .lo3 檔案直接執行程式:

python3.4 lo2loli.py xxx.lo3 -o output_dir

您也可以透過 --help 參數翻查一下其他可選的選項。

注意:轉換後不會自動添加「規則六」所提到的 .loli 資料夾,就請各位全部轉好之後再依需要手動添加一下。

相關連結


  • lolinote wiki:lolinote 的文件都放在此。目前是設成 public 的,覺得對其他人有幫助的訊息如推荐工具之類各位可自行補充進去,不需要問我。改文法錯誤、增加說明或用例也都 OK,但是請不要偷改規則,明顯亂來的內容我會回退版本。
  • lo2loli:Lonote3 到 Lolinote 的轉檔程式。
  • lolikit:蘿莉筆記常用工具包。集結了一些我覺得能經常派上用場、可和 lolinote 協作的腳本,用戶安裝後可以透過類似 loli find、loli fix、loli list 之類的指令來做一些操作。理論上是跨平台的,但是我沒有測試得很徹底。有問題直接報一下 issue
  • lonote:這五年來持續開發使用的筆記專案,因為 lolinote 的誕生而停止維護,如果有人想接手請 fork,謝謝。

43 則留言:

  1. 我最近也在反思目前的筆記實做方式,看來筆記軟體的尋找永無止境啊orz

    嗯…我的故事且不說了,從 Lonote 到 Lolinote 的方向變革看起來好大,我好奇的是:

    1. 您實際使用 Lolinote 多久了?通常在哪些場合、以哪些方式存取筆記?體驗如何?

    2. 您曾經在哪些場合遇到「只有純文字介面的機器可用」又得存取筆記的情況?那些情況下不能使用智慧型手機嗎?(還是您根本不使用智慧型手機?XD)

    3. 您如何在不同機器間存取及同步 Lolinote 筆記?自架伺服器?隨身碟及同步軟體?手機?不同機器間的資料發生衝突時怎麼處理?

    回覆刪除
    回覆
    1. 好久不見啊。

      我剛好又發了一篇文章,那篇專講工具與配套使用的軟體。應該可解您大部分的問題。

      關於純文字介面的機器,我目前的家用機因故改成 raspberry pi 了,因為效能差受不了所以乾脆不開 X Window,剛好就符合這個沒 GUI 的用例。不用手機寫筆記的原因是輸入太不方便了,寫入量一多就想抓狂。也可能是我拇指比較笨吧 XDDD

      關於使用時間,我是內部測試大約一個多月後公佈的。本來是想要測試更久一點,不過因為有新用戶跑來研究 Lonote 嘛你知道的 XD,就想說感覺起來既然沒什麼問題,還是趕快給他發一下,不要害人掉坑裡,也方便把 Lonote 收掉。

      整體使用狀況都很 OK,運用效率也很高,操作沒有什麼不便的地方。

      在我的用例中,唯一的煩惱就是 Lolinote 不適合擷取網頁內容,但有時候又想連圖與複雜的排版一起保存,比方說攻略、教學文或網路笑話之類的。我想這種情境應該要有獨立於筆記之外的解決方案。我手邊有幾個備選案還在研究中,包括用 mht 保存、pdf 保存,或是直接保存在 evernote 裏面。

      我是覺得 evernote 是個不錯的網頁保存工具,方便度也還夠,對於重要度遠比真正筆記要低的網頁封存用途來說,或許是個可選的解決方案?但我還沒決定,打算再多想想看。

      刪除
    2. 在忙,先簡單回一點。

      保存網頁要先釐清具體需求,比如需不需要能搜尋,要不要未來能 copy 帶格式的富文本,需不需要能編輯等等。

      總體而言目前保真及後續應用最好的方案應該是 ScrapBook X,若有需要可轉存成 MAF (本質是 zip 包,Fx 套件可存取)、MHT 、PDF、或丟進 Evernote ,反之其他格式很難互轉,也變不回 ScrapBook X。

      Evernote 不是很建議,一是格式常會掉,二是如果圖多很容易就超出每月60MB的限制,除非是只挑重點擷取。至於PDF 、 MHT 等有什麼缺點您應該有能力列出不少,就不贅了。

      好奇以前 Lonote 時代您是怎麼解決此需求的?

      刪除
    3. 您說的對,確實要釐清需求。

      我的網頁封存手段,理想目標包括:

      1. 希望能封存為單檔
      2. 可按需將富文本優雅降轉為純文字格式或至少先轉為 html 格式,方便任意串接到其他應用,如灌進搜尋引擎中建索引之類的
      3. 主要目標是能支援嵌入圖片與表格,CSS 之類的東西差不多就好,細節重現度不完美也無所謂
      4. 不要求封存完整網頁,取用網頁的其中關鍵部份就足夠,其實能濾掉無關的訊息反而更好。如果可能的話,有工具允許重排資料,比方說把多頁含圖的富文本內容剪貼串接到同一頁中。

      當然啦這都是理想。也許還要多取捨一下。

      基於前述需求,目前看來 mht 是不錯的格式,它的內部是純文字的,所以有必要時可以透過簡單的工具將 html 重新取出來。不過無論是轉換或是顯示,支援 mht 的工具都較少,像是 Firefox 還要裝外掛才能處理,我對此依然有些疑慮。聽起來您對 MHT 似乎有所批評,可以分享一下嗎?也許和我的著眼點不太一樣。

      pdf 不容易 copy,而且還會被分頁,我不太喜歡,而且他的規範複雜得太離譜很難手動操作。不過支援軟體很多,我也有辦法找軟體簡單將 pdf 降轉為 text,加上保真度還不錯,所以也有在猶豫。

      MAF 我覺得本身很不錯,不過好像只有一個 Firefox 套件 MAFF 可以存取,其他瀏覽器似乎全無支援,這讓我有點擔心。其實我從幾年前就在關注這個了,只是不太敢跳坑去用,一直都在觀察她的發展狀況。

      小規模運用的場合,看起來說不定「存成完整 html」反而更加理想,只是那樣就得犧牲第一個條件「存成單檔」了。話說回來,之所以想要存成單檔主要目的是想減低管理負擔。當封存數量增長為成百上千件之後,希望調整/移動/重命名這些紀錄不要太費事,不過存成完整 html 的策略怎麼構思都無法管理,大概最終還是不能用吧。

      在 Lonote 時代要擷取網頁就直接貼進 Lonote 中囉,Lonote 中有少部份功能是專門設計來支援這個目的的。基本上格式重現度足夠高,也方便剪剪貼貼部份我感興趣的內容,而不需要整頁複製,這對於避免資訊超載還蠻有幫助的。

      ScrapBook X 我也研究看看吧,已經太久沒用這類套件了,感謝推荐。您不提我都要忘了 XD

      刪除
    4. 仔細想想 ScrapBook X 就是您開發的嘛!感謝辛苦工作!借我用一下試試。

      刪除
    5. 初步試了下 ScrapBook X,感覺確實不錯,特別是擷取部份的功能對我特別好用,設計很用心啊。不過那個選項「擷取成 html」是什麼意思呢?點了好像沒什麼差別。

      目前乍看之下沒有將資料匯出成單檔的選項。有什麼組合技可以用嗎?
      對了關於 ScrapBook X 的同步問題您是怎麼解決的。

      刪除
    6. Maff 看起來比我想像中還要好,而且重點是他內建有轉檔工具,所以日後策略錯誤應該也相當容易匯出。看似可用。雖然強制綁定 Firefox 有點討厭,但此外應該還是可以安心使用的。目前暫時傾向於 Maff。

      謝謝好建議啦!

      刪除
    7. 您可以考慮 Read The Fine Manual,基本問題應該都有答案。不過這手冊寫得很急迫簡略,如有語焉不詳看不懂儘管再問。

      1. 「擷取成 html」是把 Firefox 目前開啟的非 HTML 檔案,比如 txt、xml、圖片等,強制擷取成瀏覽器當下呈現的 HTML,而非儲存原始檔案。差別在於前者之後用 ScrapBook 開啟時可編輯內容而後者不行,但後者還原度較高。對於一般 HTML 網頁勾不勾是沒差別。

      2. 資料匯出成單檔:可以裝 ScrapBook X MAF Creator 把它匯出成 MAF 格式。(不過目前發現極少數 ScrapBook 轉存的 MAF 檔打開會不正常,但解壓縮打開卻無問題,懷疑是 MAF 套件的 bug,有回報給作者,但目前未收到回應。)

      3. 同步:可用雲端硬碟和同步軟體解決,我個人是用 Dropbox 和 FolderSync (Android) 或 Good Reader (iPad)。不過如果網路條件好,您也可以考慮把它公開在網路上(網址不公開),透過網路存取。

      至於您談到的需求:

      >1. 希望能封存為單檔

      ScrapBook 是以剪貼簿為管理單位,ScrapBook 可管理並在多於一本剪貼簿間切換,剪貼簿之間可輕易搬移資料,單一剪貼簿也很容易轉成靜態網站分享。在這樣的前提下,我目前並不覺得「存成單檔」有那麼重要,偶爾有此需求也只要轉存成 MAF、MHT、PDF、或全頁面擷圖等就好。

      >2. 可按需將富文本優雅降轉為純文字格式或至少先轉為 html 格式,方便任意串接到其他應用,如灌進搜尋引擎中建索引之類的

      ScrapBook 內建就有全文搜尋引擎,匯出 HTML 資料列表後就是個靜態網站,並內建可用瀏覽器操作的 AJAX 全文搜尋引擎。如有需要您還可以自己添加 CSS 及 JS 做更進階的利用。

      >3. 主要目標是能支援嵌入圖片與表格,CSS 之類的東西差不多就好,細節重現度不完美也無所謂

      ScrapBook 主要著眼於完美重現細節,不只嵌入圖片與表格,連框架頁都能保存,CSS 可完整保存;倒是 JS 可保存但保存後不保證能 work,但那本來就不是任何網頁封存方案能解決的。

      >4. 不要求封存完整網頁,取用網頁的其中關鍵部份就足夠,其實能濾掉無關的訊息反而更好。如果可能的話,有工具允許重排資料,比方說把多頁含圖的富文本內容剪貼串接到同一頁中。

      擷取關鍵部分及剪輯網頁正是 ScrapBook X 的強項。至於把多頁串成一頁,ScrapBook X 有兩個解法,一是建立筆記頁面,把各網頁的內容複製貼進去,就像您在 Lonote 做的事一樣,不過這很容易造成樣式失真,理由您應該可想而知;另一解法是先個別擷取再用合併精靈合成一頁,不過目前只有很制式(而且不太好看)的模版,我也用得不多。

      對了,我以前也覺得 MAF 很棒,也一度想把網頁封存成 MAF 管理,但目前手機上實在找不到能直接讀取它的應用程式,想看個檔得先解壓再找出 index.html 開啟實在很惱人,所以沒採用。

      至於 MHT,我曾經遇過 A 瀏覽器儲存的 MHT 換用 B 瀏覽器開啟後失真,但很久沒用了,不曉得目前是否改善。另外 MHT 規格真的有點複雜(相較於 MAF),想寫程式解析或編修內容感覺就很麻煩,所以我不偏好。

      刪除
    8. 補充:

      MAF 除了支援的軟體太少,還有個隱憂是由於使用 zip 壓縮,而 zip 中的檔名編碼不跨平台,如果網頁關聯檔案的檔名含有中文,可能在不同作業系統間轉移會出問題。

      MHT 方面,中文維基百科有提到「由於儲存為MHTML的方式未經標準化,因此各瀏覽器讀取的效果略有不同」。剛試了用 Firefox + MAF 套件把這個頁面存成 MHT 再用 IE 打開,CSS 樣式就稍有跑掉。

      MHT 檔案中所有字串都編過碼,用純文字編輯器打開也無法有效編輯,非找專門轉檔程式不可,相較於 MAFF 只要 unzip 就能改,實在不怎麼討喜。

      我目前還沒看過有簡單的工具能把 MHT 轉成可編輯的格式,Firefox MAF 套件有提供 MHT 和 MAF 互轉,但 MHT 轉 MAF 也會失真,而且似乎非 Firefox MAF 套件儲存的 MHT 便無法轉檔。(剛才試了用 IE 把這個頁面存成 MHT 再用 MAF 套件轉檔就失敗了)

      總之,目前幾乎所有把網頁存成單一檔案的嘗試都有不足,最安穩的方法似乎還是存成完整網頁,存成單檔大概是把網頁及關聯檔案包成 7zip 最安全,MAF 算是其次可接受的方案,這些用起來都不太方便。

      刪除
    9. 謝謝手冊。非常詳細連資料規格都有。

      maff 無法在手機上開,實在有點麻煩。mht 可在手機上開,但內部字串居然還真被編碼過,我剛剛開了編輯器想要實際觀察看看但超絕望的,完全行不通……orz

      其實優雅降級顯示的能力,有一部份的目的也在於當一個檔案無法以最理想格式呈現時,至少希望能以不完美的形式呈現。開不開的時候圖就算了,至少把文字內容顯示出來也好。

      其實轉檔/匯出功能也能完成一些跨平台的跨環境的問題,但是就必須要「事先」將檔案匯出好才行,假設今天我搭公車時臨時想把 Dropbox 中封存的網頁檔拿出來看,如果沒有事先做好匯出就沒戲了。而且也不適合隨時保持全部匯出的狀態,因為這樣等於需要儲放兩倍份量的資料。網頁封存因為圖片是重點,所以意外地還挺佔空間,空間佔用因為匯出再加倍,再加上如果還要到處同步的話,雖然不是對付不了,但很難說是個好辦法。

      稍微扯遠一點,像是用 Lonote 與 Evernote 這種工具來保存網頁內容時,剪剪貼貼其實蠻方便的。當然這是在用戶願意接受某種程度的格式不一致時才能用。不過以我來說,常常會利用剪貼的機會將額外的框架移除,比方說我部落格的當前這頁,頁寬被限死在某個寬度。在封存時我更希望能把限制頁寬的框架移除,改成能動態適應寬度的文字流,背景也隨便怎樣都好可以直接去掉,CSS 也全部濾掉,只要好好留下圖片表格就好,這樣不管手機還是桌面瀏覽器都能適用。

      用剪貼預處理這些 HTML 資料有時確實是個不錯的好辦法,不過這樣的目標就和 ScrapBook X 與 MAFF 之類的基本設計理念「完美保存」背道而馳,或許需要其他類型的工具也說不定。

      或許最理想的工具是把選擇區中的 html 擷出,然後把選到的圖片全部轉成 baseuri,然後存進普通 html 檔案中的功能反而更適用,也方便到處開。雖然我覺得不難寫,不過目前就是沒有找到這一類的工具,個人覺得是蠻奇怪的。

      ZIP無法存檔名編碼這個缺點會導致 maff 可能在跨平台時開啟不正常,這我完全沒意識到,意料之外慘遭痛恨一擊。我再繼續研究一下。

      無論如何謝謝分享,這都是些做判斷時非常有用的情報。

      刪除
    10. 看來我弄錯了您的需求,如果您要的是把一些 HTML 頁面的片段存成單一檔案以塞進蘿莉筆記系統,ScrapBook X 大概幫不上太多忙。

      說到 datauri,我查了一下是有個 Chrome 套件 SingleFile 能把網頁存成單一檔案,除了不能儲存框架頁以外,其他似乎都 ok。不過據說 dataURI 有字元長度限制,如果嵌入的內容太長可能會在許多瀏覽器上無法正常呈現,而比較老舊的瀏覽器可能也無法支援 dataURI。

      刪除

    11. 身為幹過類似事情的人,我完全能夠理解重要資料保持開放、相容、易轉換、能應付環境變化的重要性。不過我漸漸覺得追求開放相容反而會把生活搞得像原始人。

      我也不喜歡資料被大公司把持,不過雲端服務讓我能在全世界有網路的地方取得資料,這方便性實在太重要了。若不用雲端硬碟,我要嘛得自己架設、維護伺服器,要嘛得用手工、非網路的方式在不同機子間用傳輸線或隨身碟同步資料,要嘛別搞同步和多點存取,這代價也太大了點。

      況且 Dropbox 萬一倒了,我可以換 Google Drive;Google Drive 倒了,我可以換 MEGA;甚至 GitHub、Bitbucket 某方面都能達到類似功能。在目前的雲端硬碟運作方式下,我手上永遠保有資料備份,那些雲端服務真的倒了,我也不會損失任何資料,既然如何,幹嘛不用呢?

      至於資料放雲端會不會不安全?我是覺得還好。我當然不喜歡筆記被別人取得,不過筆記這種東西多半是對自己有意義,別人看了不見得懂的東西。再說不只是筆記,我們用 Gmail、MSN、Skype、臉書都不知多少年了,難道為了安全考量連 Email 也要自己架,即時通訊一律不用或自己搞一套嗎 XD?

      至於相容性,我的原則是資料保持在足夠開放且我有能力解析及修改就好。對我而言 Evernote 和 ScrapBook 都是這樣的性質,Evernote 就算倒了,我還有本機端軟體可以資料匯出成 enex (即 xml) 解析,甚至就算短時間沒能力解析,也可以匯出成 HTML 用隨手可得的瀏覽器開出來看。ScrapBook 也一樣,就算因故 Firefox 或 ScrapBook 不得不消失,原來的 ScrapBook 資料也都是靜態網站規格,讀取完全不成問題,寫入方面寫套新工具就好,甚至可以手工編輯,儘管那會麻煩些但也不致於不可行。

      相較之下,我並不覺得 markdown 會比較有優勢。確實如果我必須在純文字界面的機器前工作,markdown 會勝過 HTML,但論讀取,用手機瀏覽器看網頁顯然勝過看純文字版原始碼;論寫入,手機編輯 HTML 是慢,但您自己也說過,缺乏富文本預覽下就算能編輯純文字也難以完稿。此外 markdown 本身也包括對 HTML 的支援,本質上是比 HTML 更難解析、更難找到好工具處理的格式。

      況且就做筆記而言,能隨處複製、收集東西才是最重要的,對電腦而言,從網頁或 office 複製富文本或貼圖,就遠比慢慢輸入純文字和語法便利地多(所以 markdown、wiki 等等都不適合做筆記);對手機或平板電腦而言,拍照、掃描辨識、錄音轉文字、手寫轉圖片或文字、 GPS 定位記錄等,都遠比 key 純文字方便的多,先把資料搜集起來,回去有空再慢慢整理就好,Evernote 就是靠這些吃飯的,我花幾輩子大概都寫不出那種水平的多媒體處理功能,那幹麻不讓 Evernote 代勞呢?

      至於關聯式資料庫與單檔的問題,我同意資料庫的損壞風險高些,但即便是像 Evernote 那種資料庫,只要定期備份出 enex 封存,真有資料庫損壞,清空再重新匯入就好了。而像 ScrapBook 是純文字和 XML 組成,真出狀況也不會某處死全部死,壞的部分可以手動修復,這點我相信 LoNote 也是一樣。相較之下,存成單檔和用檔案瀏覽器管理,反而犠牲筆記最重要的相互連結能力(比如搬移檔案會毀滅連結)。

      總體而言,我覺得支援近乎純文字的工作場合是 rare case,為 1% 不到的可能性犠牲平時絕大多數時候的操作便利性,大概是醉了。

      刪除
    12. 作者已經移除這則留言。

      刪除
    13. SingleFile 似乎可用,試試看吧。



      「……如果您要的是把一些 HTML 頁面的片段存成單一檔案以塞進蘿莉筆記系統……」

      嗯,不是啦,這是誤會。筆記歸筆記,網頁擷取歸網頁擷取,兩邊各算各的。我前面的留言主要都是針對網頁擷取用途哦。lolinote 完全在討論範圍之外。

      因為這兩個目標使用的工具確有相似之處,所以大部份時候我們都將其混為一談,我在 Lonote 時代也是直接用 Lonote 做這些操作,改用 lolinote 之後我大幅強化了筆記能力,並因此捨棄了網頁擷取能力,這才會想說要用其他什麼工具取代這一部份。



      在我眼中,他們的差別大約如下:

      筆記:

      - 除了少數局部引用外,幾乎都是親手撰寫的
      - 重要、心血結晶、絕無僅有、無可取代
      - 知識密集度高,對自己的可再利用度高。
        - 幾行字,一兩份筆記文案,就能協助自己,在腦中重建起當初構想、思考模式、相關知識體系等。
      - 為了重整更新自己的知識體系,經常需要翻查、整理、修改。
        - 內容經常改變
        - 需要強大編輯彈性與效率

      網頁擷取:

      - 內容不是自己寫的,或是自己修改的部份極少
      - 資料定型後幾乎不需變動,很多時候甚至「不該」變動,以反映原始資料狀態
        - 因此不需要強大的編輯功能支援
      - 重要性低,網路上通常有多個副本,重要的內容甚至會有多個人寫出多個版本。
      - 知識密集度低,取用效率低。
        - 蘊含大量非知識性的框架寬度、背景圖、頭像等。有時會成為閱讀時的干擾。
        - 字多,但自己的體會較少。因為不是自己寫的,打開檔案後得多花些心力才能釐清有用的部份。
        - 資料的總份數一般比筆記多。比方說一個題目是「在 Raspberry 上連接無線網路」這個問題,在網路上可能有多篇文章,每篇重點不同。此時可能會需要擷取多篇。然後日後取用時需要查用好幾個頁面,逐一檢查,這同樣分散了注意力。
      - 使用機會低:如非閱讀時有「精神上的深刻體悟」,大部分的「擷取內容」都會被忘掉,根本不記得自己曾經抓過這頁,日後有類似問題是還是反射性問 Google 先。
      - 如非要求「絕不遺失」,否則用個 url 就能取代

      (以上特質與任意軟體的優缺點無關,而是需求的特性)



      您可以看到上面兩個需求看似相似,用途也能互相支援,但目標是截然不同的。

      以我個人來說,我注意到真正有用(真的會重看)的網頁擷取,其用途從來不脫「將精神上讓我得到深刻體悟的文章保存下來,日後重讀回味」之用。非此類的文章,需要用時透過 Google 搜尋,或記個 url 還比較快,反正並不是「非那篇不可」的情境,而且如果是知識性文章,往往到想用時已經過時了,重搜的效果常常更好,資料也更多。

      換句話說,網頁擷取的主要目標是收藏個人喜歡的東西,對累積知識庫的幫助相對較小。作為知識庫有時甚至可能有害,因為注意力被巨量但低知識密度的訊息分散出去了。這是我的將筆記與網頁擷取工具混用後的使用經驗啦,您參考就好。



      關於寫部落格的問題……

      我覺得 Markdown 用來寫部落格表現能力不足,然而筆記很少需要那樣華麗的表現能力。

      此外,早先文章中提及用輕量標記語言寫部落格無法完稿的問題,焦點之一在於部落格的最終呈現格式是 HTML,而不是純文字。但在 lolinote 中純文字就是最終呈現格式,因此沒有確認渲染效果的需要。用戶需要時可以渲染它,但讀寫時主要都是瀏覽 TEXT,這就是差異。其二在於,部落格內容是需要公開給不特定多數閱讀的,而筆記則不需要,因此兩者之間的完稿程度也處於不同等級,就像是要用來出書的稿子與自己私用筆記完稿程度會有差一樣。嚴格說來,筆記並不需要完稿,甚至格式部份錯誤也沒有問題。

      此外關於部落格那篇文章中,作為案例使用的是 reStructuredText 格式。reStructuredText 是會因為格式不正確而渲染出報錯訊息,那非常難看,但是 markdown 並不會報錯。因此就算有人寫錯格式,也只是最終頁面渲染結果不理想而已,就和 html 寫錯是一樣的,問題影響比較小。退一步,如果有人完全不會寫 markdown,也可以直接把 markdown 當成純文字來寫,不會造成系統無法運作之類的問題。

      Markdown 缺點不少,但就一個「具有基本格式規範但又能容錯的純文字檔案」來說(換言之在純文字筆記的用例中),它幾乎是最佳解答了。



      關於自由軟體的偏執……

      我沒有拒絕使用非自由軟體啦。我只是剛好覺得在某些情境下自由軟體更好用而已。你看我前面都很認真地在考慮是否要用 Evernote 呢。而 Dropbox 也只是因為它剛好不支援 ARM 系統,能力匹配不上我的需求才換掉的。之前會擔心 Dropbox 的安全性,也是因為我甚至在用 Dropbox 同步一些我記了上百個密碼的個人密碼本(儘管密碼本本身也有加密),這種程度的不安應該還好啦。

      我知道您關於自由軟體方便性的論點主要不是針對 Lolinote 的啦,下面只是剛好藉機說明一下。

      有時候,自由軟體或自由的設計確實會造成不便,不過 Lolinote 在筆記的使用領域中,剛好並非如此。它的方便度甚至比絕大多數解決方案都要更高。舉例來說,建新筆記只要滑鼠右擊後選新建檔案;刪除筆記則是選擇後按下 DEL;想寫段落標題先打 # 號再輸入標題;移動筆記則是滑鼠拖拉又或 Ctrl-x -> Ctrl-v;想開檔則是滑鼠雙擊。實在想不出什麼更方便的操作了。

      我還沒提一些其他類型的操作,比方說故事設定中突然要改女主角的名字,需要跨檔案批次取代;或是需要將一個內含 60 個段落與兩個子 Section 的 level 3 Section,下移到文件的最底部--這用 Voom 就可以在五次鍵盤敲擊內完成。這類重組與再處理,在筆記撰寫中都非常常見,然而絕大多數的筆記系統面對這類問題都只能苦笑,但 Lolinote 不受限制。

      即使是需要圖檔的場合,也 Lolinote 也可以用 ExtRule.1 規則來解決。單一筆記十張圖內管理效率都很高,如果要用更多圖也 OK,只是檔名多看了煩而已。瀏覽時,也可以用各種即時渲染工具免 build 就立刻進行瀏覽。

      當然,如果考慮設定初期裝 Syncthing 之類的東西看起來很麻煩,那也很有道理,然而如果用戶用不到特定功能,其實也大可不裝,或是裝個 Dropbox 就能簡單搞定同步問題。Lolinote 是可以和任意工具整合的。和工具整合是一種選擇,而不是非裝一堆東西不可。按需選用自己愉快的使用方式,需要時再追加功能或變幻功能,輕鬆用就可以了。

      刪除
    14. 我大致同意您對「筆記」和「網頁擷取」的分析,不過我的習慣和您稍有不同。一般而言我把資料分成三個等級:

      LEVEL 1: 剪輯資料:大致上和您所謂的「網頁擷取」相近,特點是他人的創作,某方面是為滿足個人搜集癖好而做,平常不太使用但心血來潮會一陣狂翻,原則上保持原樣不改內容。

      LEVEL 2: 筆記資料:大致上和您所謂的「筆記」相近 ,特點是大部分是自己的東西,常翻查、整理、修改,內容常是隨性的、缺乏標準化的。

      LEVEL 3: 個人知識庫:經過較細緻的整理,較精華的東西,規格較標準化。


      關於 LEVEL 1,我目前認為 ScrapBook X 是最佳解,理由是:

      1. 我需要能夠最大化保持原貌。當然我往往也會重整內容,比如去除不必要的廣告,多頁併成一頁,改掉太糟糕的配色,做些格式調整讓它比較好看順眼。但無論如何,這個工具必須要在我希望保持原貌時能最大化滿足需求。目前為止只有 ScrapBook X 和瀏覽器內建的網頁儲存功能可以滿足此需求。

      2. 我需要維持原始的富文本格式,以便需要時能夠做複製貼上等再利用。所以 PDF、全頁擷圖、Save to Google Drive 等方式在這關被淘汰了。

      3. 我需要記錄 metadata,尤其是來源位址(以便需要時能溯源)和擷取時間(才知道它是否過時)。所以 PDF、全頁擷圖、Save to Google Drive、貼到 Office 、及至多種不記錄 metadata 的網頁封存方式都在這關被淘汰了。

      4. 我需要註解功能,以便在裡面寫下個人體悟、心得、或吐槽等等。註解功能必須不汙染原始內容且能在必要時和原始內容完全分離。其他網頁剪輯工具要嘛不支援註解,要嘛開放完整編輯功能而會汙染原始內容。除了 ScrapBook 以外次一方案是 PDF,次二方案是全頁擷圖,但它們無法滿足 2.。

      5. 我需要良好的搜尋引擎,它至少要能搜尋全文和 metadata,以便在想找東西時快速找到。目前能滿足此需求的只有 ScrapBook X 和 Evernote,但後者不能滿足 1.~3.,且會和筆記互相汙染,導致想搜尋筆記時秀出一大堆並不想看到的內容。此外 ScrapBook 有個令我欣賞的特性是瀏覽資料項時能一鍵反查它在目錄樹中的定位,然後我就能快速翻出前幾則和後幾則相關資料;Evernote 乃至很多資料庫系統要嘛沒這功能,要嘛很大費周章(比如先從屬性欄找到它的位置,然後花時間一層一層點出來)。

      6. 我需要隨處可瀏覽。ScrapBook 搭配「匯出 HTML 資料列表」就是個有目錄表、有全文搜尋引擎的靜態網站,丟到網路空間或同步到其他機器再用瀏覽器開啟即可(當然,如果是丟到網路空間,得選個低調的網址免得被偷窺)。相較之下,許多網頁封存方案使用的檔案格式在手機上不易讀取,且它們對「丟到網路空間用瀏覽器開啟」的支援度差,一來它要求伺服器支援「列出當前目錄下所有檔案」,而許多服務像 Dropbox 的 public 資料夾並不支援;其二是能支援的也無法全文搜尋。您可能會問「丟到網路空間用瀏覽器開啟」有何重要?我認為很重要,因為手機容量有限、頻寬也不大,平時一直花時間把使用頻率不高的東西存到手機上不太明智。對了,我並不要求「隨處可編輯」,反正這類資料需要編輯的頻率本來就不高,ScrapBook 在所有能跑 Firefox 的電腦上都能跑對我而言很夠用了。

      順帶一提,除了網頁以外,一些小型 PDF 、文件檔或各種格式的參考用檔案,我一般也會擷取進 ScrapBook 以便統一管理及搜尋。

      就這些需求而言,我覺得「存成單檔」並不是很重要的需求,因為本來就是以整個資料庫為單位做管理,且編輯或修改的頻率非常低;至於少數要特別拿一兩個項目來用的場合,要轉存成單檔也不是問題,因為 ScrapBook 格式本來就最大化保持了原貌,任何能把網頁轉存成單檔的方案都必然能應用在 ScrapBook 擷取下來的版本。

      這方案最大的競爭對手大概是「把網頁封存成容易直接開啟的單檔,和其他文件一起用檔案系統管理」,它也的確有些小缺點:對於非網頁檔案,透過 ScrapBook 從瀏覽器開啟後常常要先轉存再打開,有點囉嗦。又如果要編輯原檔(最常見的情形是對 PDF 做註解),ScrapBook 方案下得先用檔案瀏覽器開啟對應的資料夾再找出檔案打開編輯,雖然 ScrapBook 有提供把目前資料項對應的資料夾立即從檔案瀏覽器開啟的功能,這仍比本來就從檔案瀏覽器開啟來得麻煩些。然而由於絕大多數此類資料都是網頁,ScrapBook 直接從瀏覽器側欄搜尋、開啟擷取資料比從檔案瀏覽器開啟方便快速,而即使是非網頁資料 ScrapBook 也提供了檔案系統缺乏的 3.、5.、6.,總體而言 ScrapBook 方案是利多於弊。

      刪除
    15. 關於 LEVEL 2,我目前認為 Evernote 是最佳解。這可能是因為我們習慣不同,我個人的理由是:

      1. 筆記雖不需要太華麗的格式,但通常還是少不了粗體、底線、劃記、變色、表格,而 markdown 對變色和表格的支援極差。又就粗體、底線等格式而言,所見即所得編輯器的編輯效率往往還是勝過以純文字編輯器開啟、編輯再用閱讀器開啟看渲染結果的方式。

      2. 即使是真正不帶格式的純文字筆記,markdown 也不會勝過所見即所得編輯器,後者一直打字就好,想從他處複製貼上純文字也可以用 Ctrl+Shift+C 辦到。相較之下在 markdown 我起碼得留意字元跳脫以免不小心誤觸語法地雷,其中最最最最常見的是萬惡的單換行,這東西我超常用,而行尾加上反斜線的規矩真是蠢斃了!

      3. 我個人挺常在筆記中放圖片,比如手寫筆記懶得重打就拍照丟進去,讀書時把幾個重要頁面拍照丟進去,或者把心智圖檔及匯出的圖片丟進去,markdown 在附檔上效率不太好。

      4. 「跨檔案批次取代」之類的情形,markdown 方案的確勝一籌。不過由於筆記本來就是以隨性、缺乏標準化的東西為主,這種場合相當罕見,我可以容忍偶爾的不便。如果很常見,這東西很可能應該屬於 LEVEL 3。


      關於 LEVEL 3,我目前沒有固定的解法。有時我會想用 ScrapBook X,因為它便於交互連結、全文搜尋、隨處存取,簡單的手工編輯原始碼和多頁共享 css 或 js 庫也能辦到。有時我會想用 BlueGriffon 或純手工網頁,因為 ScrapBook X 產生的原始碼有時還是不夠漂亮。有時我覺得 markdown 或維基語法是比較好的選擇。有時我會想用 Google Drive,因為它不吃空間、容易協作,且內建版本管理功能。有時我會想用 Office 搭配適時匯出 PDF,因為它比較能針對「頁」優化,且能產生目錄及頁碼,適合送印。有時也許 LaTeX 才是王道?……

      我還沒找到最佳解,也許那根本不存在。總之,對我而言,蘿莉筆記方案只能部分滿足 LEVEL 3 而已。


      當然我相信您的習慣和需求不會和我一樣,以上僅為個人經驗,聊供參考。

      刪除
    16. 嗯,聽您這樣詳細解說,ScrapBook 在網頁擷取的領域應該是能滿足相當需求的。我也沒有堅持要讓所有理想都達標啦,所以才會一開始就連 Evernote 都列入考慮。



      以下是關於筆記的分享 ~

      筆記放圖片的量大概真的是個人習慣問題吧,我只有特定主題需要圖片說明時--像是畫派風格研究、不同馬匹血統外觀之類的題目,可能會放個幾張作為代表。

      將資料直接拍照後塞進筆記中,是一件蠻便利的事,不過就前文提到的那種「筆記類內容」來說,個人偏好轉成文字重新手動整理過,日後重用遠為方便。而且直接把照片塞進筆記中,腦中不容易產生印象,總覺得這種狀況反而更接近剪輯網頁的用例,差異只在於收集來的內容不是 Html 格式。

      如果拍照存儲的資料是只有短時間會用到的「便條類內容」--如翻拍手寫的購物清單之類的--所以根本不想費工整理的情境,我覺得這時 Google Keep 反而是理想的工具,也不會汙染您的 Evernote 筆記庫。我也是用這一套來記便條與備忘的,大推荐試試看。



      您很依賴替文字標色等方法來劃重點嗎?我在 Lonote 中雖然實作了這種功能,但五年使用經驗是幾乎不曾用到,覺得不實用才會在後續開發中直接把它排除。其實咱蠻想知道只用黑體強調為什麼會不足?我這邊連斜體都沒機會派上用場過。

      --主要是因為發現畫太多重點,反而無法讓視線自然在文字流間「只擇取重點」地跳動,結果重點多到某種程度(接近每段落一個)的時候,會導致即使光看重點也等於要全文都讀,導致「重點」完全派不上用場,因此重整訊息時我常常會反過來試著把過去畫太起勁的重點刪掉一些,以便使用。因為重點少,所以也不需要多種重點顏色來分類。大概是這樣子的模式。

      而且老實說,我總覺得絕大多數的筆記其實根本不用畫重點。因為筆記本身就是經過整理、對自己最適化的重點了。(網頁擷取另算)



      表格我也覺得是很實用的東西,這是 markdown 支援較差的部份,沒得講。

      其實 markdown 最流行的 Github 方言有支援表格,不過我就是不想用方言。我想等 CommonMark 規範出來後再看看能不能用,畢竟現階段分歧還比較多(但目前看來也許不會納入核心規範中,畢竟表格太複雜了,論壇上已經爭執過幾次了)。



      關於單換行(硬換行)問題。Markdown 的設計目標是優先使用段落 (p),而不是換行 (br),偶爾有特別需求用用換行 OK,但是打算將單換行當作預設分斷方式就比較麻煩了。其實我覺得「段落」語意上遠比「換行」合理,使用情境也幾乎能完全替代換行,為什麼非要用換行 (br) 不可呢?

      還是說之前用的格式都慣用單換行,所以試轉一下才發現資料全都轉不過去嗎?

      如果是單純更喜歡「單換行的排版」,覺得好看比較開心,這就沒辦法了。這樣的話用 markdown 真的會很痛苦,畢竟設計違反個人偏好是沒法用的。咱也有些偏好,像是英數字和中文間沒夾空白就會抓狂,如果有個規範說英數字和方塊字中間絕不能夾有空白我也會放棄的。

      對了,您提出的這點也讓我注意到,我先前提過「要是完全不會 markdown 可以把他當純文字寫」是有前提的:要寫 Markdown,用戶最少還是要知道換行時該採用雙換行才能寫出像樣的東西來。



      Markdown 要求雙換行,在剪貼方面確實是不如富文字編輯器方便。不過如果剪貼的數量真的多到處理起來會麻煩的程度,那就是網頁剪輯,而不是筆記了啊。

      再說,不想用逐一修復的時候,這種問題也是可以快速解決的,以 VIM 為例快速取代所有單換行為雙換行就可以了(而且可以選擇是否要讓原本就雙換行以上的換行量增加),我想不少編輯器也能做到吧--算了啦,我是覺得這種細微差異怎樣都好,反正剪貼的量本來就很有限。



      個人覺得,您提到的 LEVEL 3 訊息,除非打算出書或寫部落格發表,否則平時大概是沒有必要產出的哦。我也有一些寫得太爽而從筆記逐步演化成的 LEVEL 3 文件,但那些文件定型後大都僵死了,接著轉瞬間過時。

      有些時候是相對外部變化的過時,比方說寫了軟體使用技巧但軟體出了新版本;有時是因為個人已經開發出更好的思維邏輯,導致對個人過時了--比方說我開發了一套劇本規劃策略,內容寫得美觀清晰,洋洋灑灑附圖詳細解說細節,但接下來很快又開發出新策略,結果寫好的文件就連我自己也不用,當初下在格式與美觀上花的時間純屬白費工夫……雖然放在那裡真的很好看啦,就像個證書一樣。

      個人認為,LEVEL 3 就個人內部使用時是沒必要的,反而因為完美主義作祟而影響了修改的意願,而且因為水準高產出也不高。真有需要生出 LEVEL 3 等級資料時,開個 word 或同類軟體也許會是個更適當的主意?



      依照您的分級,Lolinote 是為了 LEVEL 2 而設計的哦,雖然我理解依照您的使用習慣可能不適用啦。

      話說回來,也許我們還可以再開個 LEVEL 0 來對應「便條」這種情境 XD

      刪除
    17. 作者已經移除這則留言。

      刪除
    18. 附記:來興趣了剛好順便摸一下 VIM 方便的單換行轉雙換行(且原本就雙換行以上的換行量不變)。請把以下這幾行貼進 vimrc 中。

      function! VisualTo2Newline()
      exe "'<,'>" . 's/\([^\n]\)\n\([^\n]\)/\1\r\r\2/ge'
      endfunction
      vnoremap q2 :call VisualTo2Newline()

      然後以後就在 visual 模式中先選好範圍,按 q2 即可替換範圍中的單換行。

      如果是臨時要用有單行版本:

      :'<,'>s/\([^\n]\)\n\([^\n]\)/\1\r\r\2/

      刪除
    19. 調查回報:先前提到的 SingleFile 可用,不過一陣子沒維護了,有些網頁砍不下來,開 console 會看到一些錯誤。

      刪除
    20. 作者已經移除這則留言。

      刪除
    21. 筆記或個人知識庫管理的問題其實很龐大,我覺得一直聚焦在 markdown 好不好似乎有些模糊焦點了.....

      其實我的需求一直很簡單:

      1. 方便多平台瀏覽
      2. 方便多平台編輯
      3. 方便多平台搜尋
      4. 方便多平台同步
      5. 資料格式開放、方便程式操作、且夠豐富


      就第 1. 點而言,其實 lolinote 有點像純手工網頁和靜態站台生成器的混合版,只是進一步做到可以獨立開啟罷了。

      我覺得 Lolinote 的附檔系統不是很理想,我不喜歡「筆記 abc 就是 abc 目錄下的 abc.md 和其他檔案」的管理方式,比如說……假如一個目錄下有幾十則帶附圖的筆記,我要瀏覽那些筆記得頻繁切換資料夾,感覺會很麻煩;如果同層目錄下有幾個子目錄和幾個帶附檔的筆記, 我無法辨識哪些目錄是子目錄、哪些是筆記;再來是如有人在 abc 目錄裡放個 aaa.md 和 bbb.md,天知道如何辨識誰是筆記、誰是附檔;如果 aaa 目錄下有個 ddd 目錄裡有 ddd.md ,又該怎麼處理?再來,這會導致 xyz 沒附檔時放在 ./xyz.md 有附檔時卻得放在 ./xyz/xyz.md,這樣即使是增刪附檔也會相當於移動檔案,並造成舊連結中斷。

      哦對了,如何從一堆 .md 檔案中偵測壞掉的超連結並修正?若是 HTML 可用 HTML DOM parser 解析處理再寫回,md 要如何解析語法、修正連結再寫回改過的 md 原始碼?

      相較之下,有種更常見的組織方式是把 aaa.html 的附檔放在 aaa.files 目錄裡,這似乎是 IE 首創的;另一種是 Fx 和 GC 硬要打對台搞出的 aaa.html 和 aaa_files 規格。這規格可以解決上面三個問題,無論是人或程式都可以輕易辨識誰是子目錄誰是同目錄網頁的支援資料夾;又因這規格很常見,已有很多軟體可以支援,比如 Windows 下刪除 aaa.html 時會同時刪除 aaa.files 或 aaa_files,MAF 套件也支援把 aaa.html + aaa_files 轉檔成 aaa.maff。這做法有個頗令人討厭的缺點──更名 aaa.html 時必須一併修改 aaa.files 和 aaa.html 之中所有連往附檔的超連結──但總體而言,我覺得問題還是比目前的架構少一點(以上 .html 請自行套用至 .md)

      再來我覺得其實 markdown 和 HTML 都有各自的優缺點,就算像您這樣以 md 為主,恐怕也會在少許場合需要 HTML 吧?與其爭論誰好誰壞,或許不如考慮兩者都支援(甚至再加上 txt, rst 等等)?(順帶一提:如果支援 HTML 又採用 .files 或 _files 的方案,可以把網頁剪輯完美整合進來!)而且我不曉得您說的 markdown 是否打算包括對 HTML 的解析和支援(按標準似乎是有,但很多軟體或閱讀器是不按標準跑的……),如果是,讓相關工具多支援個 HTML 應該不會是太大難題(畢竟本來就要支援 markdown 裡的 HTML)。不過這麼一來當一個 aaa 目錄下有 bbb.md 和 bbb.html 時該怎麼認定,也許得再想想就是......。


      就第 2. 點而言,我覺得還滿難的。目前看來要在手機能快速把事情做好,還是非要手機端 app 不可。Evernote 畢竟是下過很多工夫在行動筆記上的,不少功能看來不費一翻心思大概是不太容易超越的:

      - 拍幾張照片放入一則筆記中:如果是 Lolinote,得拍照、建資料夾、移動照片、開新文字檔、寫入超連結……光想就累了。
      - 把書頁拍下來,自動對正,然後存入筆記中:把有點歪的照片矯正的功能我大概一輩子都寫不出來XD
      - 為筆記附加檔案:App 支援直接選擇檔案插入基本上就是會比較快
      - 建立及編輯手寫筆記:建資料夾、開另一個 app 手寫、存檔、開新文字檔、寫入超連結……怎樣都不可能有原生 Evernote App 快速
      - 把目前的 GPS 定位座標附記在筆記裡:市面上有記錄 GPS 座標並生成 md 的 app 嗎?有空自己寫一個吧XD…等等,metadata 要儲存在哪裡?

      當然,如果你幾乎只會在手機上做純文字筆記,影響就不會那麼大。


      就第 3. 和第 4. 點而言。先談 4. 好了,由於手機容量有限,最好是兼備「同步到手機上使用」和「透過網路使用」兩種方案。對於前者,我個人覺得用 dropbox 還行,不過免費版有容量限制(謎之聲:那就買啊!)及同步要等一段時間是比較麻煩的地方。話說之前看到 SyncThing 本來以為問題能解決了,但
      SyncThing 目前在 Android 上還不支援寫入記憶卡不支援寫入記憶卡不支援寫入記憶卡不支援寫入記憶卡不支援寫入記憶卡……只好殘念了。

      如果是「同步到手機上使用」,要支援全文搜尋應該不是太難,但動手寫些程式大概是跑不掉的。雖然純文字起碼有 grep 之類的工具可用,但實務上不是很實用,搜尋筆記最常見的需求大概是 "and"(「請找出所有含 "關鍵詞1" 和 "關鍵詞2" 的筆記」),次常見的需求是排序,其中最有用的「按關聯性排序」恐怕是很難做到的,其他常見的像「按修改時間排序」、「按建立時間排序」、「按標題排序」,即使是 Linux command line 也要會點 bash magic 才能做到,在手機上不太可行。

      而如果是「透過網路使用」,要看單個頁面可以直接從 Dropbox 下載,附檔的頁面就麻煩了,大概得像 ScrapBook X 那樣生成檔案列表再放到公開網路上,而這樣一來若不用雲端硬碟就是要自己架站了。要支援全文搜尋就更麻煩了。ScrapBook X 的做法是透過 AJAX 讀取整個 rdf 資料庫,雖可行但很陽春,rdf 檔大些就很吃流量又速度慢,和 Evernote 根本不能比。要做更好的優化大概架站及寫些伺服端程式也是跑不掉了......。


      嗯......這些問題解決一下,或許大有可為哦!

      刪除
    22. 筆記又不是作文,為了方便快速,一般都是幾段不成句文字的堆砌,為了視覺上更突顯,一般就是寫成一行一行的。您不妨參考手寫筆記,一般也很少刻意寫成一段一段段吧?(無論是中間空白一行或是段首空兩格、空一格等等)

      另外還有很多種使用場合,比如說我很常用純文字形式的項目符號與編號,因為格式化有時縮排太深,一項一行可能會折成兩行而更難看;或者為了突顯前兩項有關、後三項相近之類的情況,就把前兩項間用單換行,第二和第三項間用雙單換行;編號則如用 1、1.1、1.2、……之類的形式會比巢狀 ol 更方便後續引用,這種編號列表一般不太會中間空兩行。這些情況下我寫 md 得跳脫行尾換行,又得跳脫行首的符號,用起來煩死了。

      又或者我要解決程式的問題,筆記裡可能會貼幾段程式碼,程式碼有單換行是常見的事。您可能會說何不縮進四格做成 pre list?因為我通常會把較關鍵的片段上色標示,而 markdown 內建的 pre list 不允許其中有任何格式。

      至於顏色,基本上顏色給人的視覺刺激還是比較強烈的,用不同顏色可以有效幫助區分不同性質的文字,比如我很常用深綠色加括號表示註解或吐槽、褐色表示補充資訊等等。話說黑體往往在某些平台看起來和沒黑體差不多,有時效果還滿差的;斜體則是不適合中文;底線應該算最好用的,我一般用於標示標題或「東西」,不過 markdown 不支援。

      如果發現某則「筆記」內容幾乎都會像寫文章那樣有頭有尾,有分段,只用粗體等少數格式,而且會持續重整、濃縮、精煉,對我來說那就算是 LEVEL 3 了,開個 Google Doc 寫大概會更適合。

      刪除
    23. 更正:pre list => pre block

      刪除
    24. 哇哈哈。聊聊各種設計背後的細節與取捨也是很有意思的。

      Lolinote 的附檔處理方案確實是其弱點,畢竟設計目標就指出「不適用於需要大量貼圖的場合」。而 ExtRule.1 是一個接受附檔--但濫用依然不適當--的手段。這方面確實不及其他筆記系統便利。

      關於 ExtRule.1 再講一下好了。這個擴展規則是基於 Rule.1 「One Note, One File」延伸出來的。將「One Note, One Files」的概念微調成類似「One Note, One Entry」這般。但所有筆記依然是「互不相關、互相獨立」的。



      因此針對您的想法:



      > 「假如一個目錄下有幾十則帶附圖的筆記,我要瀏覽那些筆記得頻繁切換資料夾,感覺會很麻煩」

      同意你說的,確實麻煩,因為要多歷一層資料夾,但是相對於其他選項所造成的負面效應,這恐怕已經非常接近最適解法了。而且如果用戶三天兩頭就會碰到這種用例,本來就不該用 Lolinote,這是它明確聲明不適用的範圍。

      我先前研究過直接把「有附件資源的筆記之 .md 檔」曝露在外層,但是這樣就難免需要在同層資料夾中,另外放置一個專門存放資源檔案的「資源子目錄」。這會導致一個筆記變成有「兩個入口」--一個「md 檔」,一個「資源子目錄」,類似於在瀏覽器中儲存頁面時選「完整封裝」儲存下來的東西一樣。這造成的問題包括:

       1. 要搬移時得要同時面對兩個入口。
       2. 「資源子目錄」的目錄名,該如何才能讓用戶快速識別出「哦這和旁邊那個 md 是一組的」?唯一策略大概只有讓資源目錄名,強制和 title 同名或命名有某種相關性。
       3. 基於上面 2,改變 title 時,因此會被迫強制同時修改 md 檔名與資源子目錄名。除此之外,還包括 md 檔中「所有」連到資源檔案的路徑(因為資源子目錄的名字改變了,因此路徑必然改變)--這是難以接受的維護成本,且此模式並不直觀。這是最大的問題。
       4. 在檔案瀏覽器中找筆記資料時,可能會誤入根本沒有必要進入的資源子目錄中?

      結果採用這種方案,產生的問題比解決的問題還要多。

      以上這些改名相關的問題,其實有種消解方法,這也是 lonote、ScrapBook 以及現存幾乎所有筆記軟體所慣用的方法,那就是「讓筆記的標題名與檔名/資料夾名脫勾」,比方說一個筆記標題叫作「天使魔法」,但是實際的檔名可能是「11123」且永不改變,因為標題與實際檔名脫勾,故修改標題不會造成任何副作用。我將此稱為「間接映射模式」

      但是如果使用了「間接映射模式」,我們就一定需要一個獨立的檔案或資料庫來儲存「檔案名/標題名」的映射關係。而一旦通過了某個中介檔案(可能是 json 或 xml 或資料庫)建立了這樣的映射關係,系統就再也不是人手能維護的了,因為每次取用檔案都得先去資料庫中查一下真正檔名,沒人能受得了--也因此,幾乎所有存取、修改、查找、維護,都變成得要透過某支「專門設計的處理程式」來完成。

      這與 Lolinote 的設計哲學以及想要甩開的問題,都是相違背的。Lolinote 的思路在此非常清晰,除非我根本不開這個專案,否則既然要做,就不可能讓「間接映射模式」成為一個選項,在排除此項之後,最佳的解決方式應該就是 ExtRule.1 吧。當然我能理解會有人覺得用個支援程式沒啥,為此失去任意組合工具的彈性也無所謂,這就說明 Lolinote 對該使用者來說不是最佳解答。就像是飛機有飛機的市場,但長途巴士一樣有人搭一樣,這倒不用急。



      > 「如果同層目錄下有幾個子目錄和幾個帶附檔的筆記, 我無法辨識哪些目錄是子目錄、哪些是筆記」

      同意。但就我的使用經驗看來,其實根本不用刻意去辨識這件事,畢竟用戶會在檔案瀏覽器中逐層瀏覽,表示您此時並沒有一個極度明確的目標(有明確目標的用戶會用搜尋)。您只是對那個主題的大方向感興趣。在該主題上點兩下後,下面可能是一個含有多筆筆記的目錄(會鑽探一層看到更多細節,等您再收束範圍)、或是一個筆記(會立刻打開)、或是一個帶資源的筆記(因此需要再開一個 md),您都會反射性知道接下一步要怎麼做,根本不用經過大腦分析,就能找到想要的東西。影響不是沒有,但非常微小。

      不過您的說法讓我注意到一個例外,目前的 ExtRule.1 中提及在「Resourced Note」中,可以使用「多層子目錄」來存放資源,這可能會導致用戶意外在只有資源的目錄中團團轉卻找不到筆記檔案。此外,允許多層資料夾的方針還引入了額外複雜性與維護難度,而這除了替單一筆記內的資源分類外卻別無好處。

      我考慮修改 ExtRule.1,規定禁止資源使用多層子目錄,藉此強制筆記與資源被放置在同一層級中。是我思慮不週,謝謝您的提示。(必須要替規則標版本號與寫 Changelog 了)



      > 「再來,這會導致 xyz 沒附檔時放在 ./xyz.md 有附檔時卻得放在 ./xyz/xyz.md,這樣即使是增刪附檔也會相當於移動檔案,並造成舊連結中斷。」

      移動方面,只有在附檔數量從 0 變 1 / 1 變 0 時才需要變更檔案位置(將其放深一層),附檔數量從 1 -> N 或 N -> 1 這種數量波動都不用變更。我判斷這種變更還能接受。

      但注意:如果用戶是會大量使用附檔與多媒體內容,比方說因為使用習慣,50 % 以上的筆記中都要放插圖的話,那就算例外,這的確會顯著增加管理成本。這種狀況下不應該使用 lolinote 作為筆記解決方案。關於這點已經很清楚了。

      此外,關於「造成舊連結中斷」這個問題,在 lolinote 中並不存在。Rule.1 明確指出所有筆記「互不相關」,因此筆記內容中並不會也不該存有交叉連結/交叉參照。

      我過去曾在部落格中撰文說明過 wiki 系統的致命缺陷。因此我非常確信,在沒有實作「間接映射模式」的系統中都不該導入交叉連結,否則就要承擔巨大的維護成本。

      剩下來的問題就是,不存在筆記間的交叉連結,會不會導致筆記功能不足?根據我過去五年持有上千頁筆記的經驗是,在筆記中沒有交叉連結不存在任何問題。如果要找尋與當前筆記相關的資料,階層式結構與搜尋都是更完備更有彈性的處理方法。(在易用性方面,交叉連結雖然很容易點擊跳頁,但也得費時預建,而且建好了之後絕大部分都用不到,或是真要用時發現就剛好面前這個關鍵字沒建連結,創建者基本上也很難預測哪些連結會用到哪些不會,經常預測錯誤)

      我覺得從筆記檔案的「外面」來看,不管內部格式的話,交叉連結在筆記系統中的意義相當類似於 tags。它透過一些手段,暗示了筆記與筆記間的關係,但是又不像階層式結構一樣做出任何保證。這會造成一些與 tag 類似的維護議題。不過這話題感覺講起來會很累,先跳過。

      不過您會提出「舊連結中斷」這個問題,顯然意味著 Rule.1 規則說明寫得還不夠清楚,我得再去補充一下。多謝。



      > 「我覺得其實 markdown 和 HTML 都有各自的優缺點,就算像您這樣以 md 為主,恐怕也會在少許場合需要 HTML 吧?」

      其實我超喜歡 HTML 的,不過您提到的那些方法,基於剛剛的解說,總有些窒礙難行之處。特別是我試圖讓 loli 系統儘量保持簡單,因為簡單才能人手維護,而且必須是「彷彿呼吸般什麼都沒做」就能憑直覺完成九成以上的維護工作,這樣的系統才是可實際使用的。

      如果是記筆記的場合,就先前的經驗,我想應該是可以不用 HTML 的。當然這也與個人的習慣與需求有關,真要說大概會沒完沒了,先壓住不表。



      > 「而且我不曉得您說的 markdown 是否打算包括對 HTML 的解析和支援(按標準似乎是有,但很多軟體或閱讀器是不按標準跑的……)」

      如果是在說 lolinote 的話,因為 lolinote 是一個規則集而不是一隻程式,所以沒什麼程式實作方面的考量。markdown 規則怎樣訂,格式就是怎樣囉。

      如果用戶覺得「用 markdown」這句話太過模糊,我強烈建議用戶使用 CommonMark 作為精確的 markdown 定義,因為現在市面上唯一堪稱有詳細定義,且預期能成為 markdown 未來的語法就是 CommonMark 了(包括 Github 風味在內好幾個主要 markdown 風格的開發團隊,都有參與到規格書的撰寫中)。當然,如果用戶寫作時比較隨便,不完全照定義走,或是明明用 CommonMark 規格寫筆記卻用 Github 口味的工具渲染,那結果就是渲染時會出些小瑕疵。這種問題就算問我我也沒辦法 XDDD

      不過我想這也不重要,筆記的內容還是在檔案裡,也沒被破壞。真的很在乎渲染成果,覺得這件事很重要的朋友,就(一)好好照著格式寫,(二)選個正確的工具來渲染。大概也只能這樣吧。

      就算是我自己,也沒去嚴格確認自己的所有筆記都有照著 markdown 格式來寫。不過只要不刻意反著規格書幹,它在大部份狀況下都還是能工作得很漂亮的。讀過一點規則後,不用記憶,憑直覺就完成大部份日常格式所需,這點是我很喜歡的地方。



      GPS 座標這個用例蠻有趣的,雖然我截至目前為止都沒有這樣用過,不太清楚到底怎樣能派上用場……寫旅行日誌嗎?

      真要用時應該不用直接產成 md。把經緯度或地址直接當純文字貼上去就 OK 了。我查了一下 Android 有個方便軟體叫「地圖座標」,可以瞬間把經緯度以及對應的地址複製出來到處貼,可以試試。之後如果要看地圖,就再把經緯度丟進 Google maps 之類的地圖服務裡面吧。雖然還是沒有 Evernote 方便,不過也沒差幾個步驟了。當然,如果是大量使用地理座標的用戶或許會更偏好專用工具吧。

      刪除
    25. Syncthing 不支援寫入記憶卡!!??感謝提示。

      重新調查了一下後發現,不寫入似乎只限於 Android 5.X 版,不影響包括 6.X 版等其他版本。因為純文字筆記容量較少,我之前都直接寫進主要儲存空間裡根本沒注意到。Dropbox 還是有它好用的地方啊……



      全文搜尋:我自己寫的 lolikit 中包含針對多字詞的搜尋操作,也包括計分排序功能。在桌面平台上用起來應該還不錯,計分也蠻準的,除此之外 Windows 平台上應該也有些可以搜內容的解決方案如 DocFetcher 與 FileSeek 等等,不過有沒有計分排序就不確定了,需要調查。

      不過手機平台如您所說,目前看不到漂亮現成的搜尋解決方案(檔名搜索除外)。要針對內容搜索的話,有個 aGrep 可以用,不過在筆記的用例中並不理想,暫待研究。

      用 AJAX 完成搜索任務很棒啊,之前碰過的實作不幸都是沒支援 CJK 的,讚。

      您最後對 LEVEL 3 的描述讓我感到有些矛盾,不過這也不是個有價值的討論點,就先別管吧。

      刪除
    26. 您好像遺漏了一種我提過的狀況:如果 abc 目錄下有 aaa.md, bbb.md, ccc.jpg,那該做何處理?

      然後,「./abc/def/ghi.md」「./abc/def/1.jpg」同時存在時,「./abc/def/ghi.md」筆記的路徑是什麼呢?如果要寫一個視覺化的樹狀列表,它應該把筆記「./abc/def/ghi.md」放在「abc」下的「ghi」,或是「abc」下的「def」下的「ghi」?

      如果我要求程式「請列出 ./abc/def/ 目錄下所有筆記」,程式是否應該列出「./abc/def/ghi/ghi.md」呢?別說程式了,當我想找「./abc/def/ 目錄下所有筆記」,我要怎麼爬檔案樹呢?

      並且,如果使用了「aaa.files」方案,這會讓「*.files」資料夾下允許無限多檔案或無限多層子目錄只是小菜一碟。如果一則筆記的附圖非常多,比如幾十個好了,您的方案會導致進入「./abc/def」目錄時很難找到入口「*.md」;而在 .files 方案下無論「abc.files」目錄裡有幾百幾千個檔案,都不會對我尋找入口「abc.md」的順暢性有絲毫影響。

      這才是比較 scalable 的架構。


      至於改變 title 的維護成本,我想在您的前提「大部分筆記不會有附檔,或只有很少附檔」之下,應該不是大問題。所以我會還您這句話:「如果用戶三天兩頭就會碰到這種用例,本來就不該用 Lolinote,這是它明確聲明不適用的範圍。」

      筆記應該是瀏覽比寫入頻繁的東西,即使是很常寫筆記的人,搬移及重命名也是相對少見的事,搬移及重命名帶附檔的筆記就更不容易發生了。我想瀏覽及程式判斷的便利性應該會比搬移及重命名的便利性重要得多。


      ----
      附記:

      在我使用 ScrapBook 以前便非常常使用 IE 內建的網頁存檔功能,身為過來人,我的經驗是這種結構一點都不難遍歷,只要把檔名欄位拉長些,視覺上便不難分辨一個目錄下哪些目錄是真正的子目錄、哪些目錄是網頁封存的支援資料夾,像這樣

      當然,如果 .files 資料夾很多,尋找子目錄時必然會受到一些干擾,但您的方案只會更糟。

      刪除
    27. >開個 Google Doc 寫大概會更適合
      跟您說 真的用 Google Doc 創作長文 很容易會瘋掉..
      不用說 自然是我用過後的唯一感想....

      更別說現在的APP
      它的效能..............................我寧願開破破android的瀏覽器去開線上寫作網站= =...

      刪除
    28. 怪了...寫了半天的留言又被吃掉...

      刪除
    29. >如果同層目錄下有幾個子目錄和幾個帶附檔的筆記, 我無法辨識哪些目錄是子目錄、哪些是筆記

      個人的想法是 只要不是目錄和.md都去識別一次 似乎不須太理會這個
      例如 只認目錄的話
      檢查 abc子目錄下時如有abc.md 它自然是 子筆記
      無時 它自然是 附件資料夾 其內如有的 xx.md 1.->視為附件 2.自動產生空abc.md(或程式虛現為筆記,有輸入文字才真的存入abc.md)並將xx.md 視為abc下的xx筆記處理

      這似乎端看程式端是否打算讓它處理到此程度即可
      如果要規範標準
      那就是規範成解讀時通通用2的方式
      就似乎應該沒這種問題

      >我無法辨識哪些目錄是子目錄、哪些是筆記;再來是如有人在 abc 目錄裡放個 aaa.md 和 bbb.md,天知道如何辨識誰是筆記、誰是附檔;如果 aaa 目錄下有個 ddd 目錄裡有 ddd.md ,又該怎麼處理?再來,這會導致 xyz 沒附檔時放在 ./xyz.m


      如果是打算用 目錄名 為筆記名 那自然abc裡的 aaa.md 和 bbb.md 應該都只是附件

      如果是用.md為筆記名 那應該 ddd 目錄裡有 ddd.md 時 它不過就是 ddd筆記下還有一個ddd筆記


      其實我覺得目錄在有附檔和子層時才會出現即可


      不過 如果不想搞出太多目錄出來

      home
      |-xxx.md
      |-xxx (有子筆記和附件時才建立)

      只掃描.md
      似乎可以避免產生過多目錄


      >筆記又不是作文

      這有點不正確
      許多使用筆記軟體的人士
      很多正是"重度文字工作者"
      組織筆記寫作是根本的寫作者習慣

      國外許多高級筆記軟體 筆記軟體部份寫完後
      最後的方向幾乎全開始導向或補充的幾乎都是
      --小說與劇本編寫功能 + 大綱管理功能 + 串連文檔輸出功能
      可見需要的人並非只是我們這些創作力較為低迷的東方人士想得那麼少

      而且 中文環境這種方面好的軟體極少 也許開發迫切性其實還更高..


      盜 與 創 這是國格等級問題...就不多贅言= =



      >markdown的問題

      其實個人覺得...
      無須爭論
      因為markdown本來就不是為了取代HTML
      他的目的寫作和簡易理解撰寫優先

      就很像java語法很煩 但py就簡單多了 可以都會存在就都有原因


      以筆記來說
      個人覺得html的確是[不適合筆記->但"複製文章"可能很需要]
      至於其他情況MARKDOWN應該可以吃掉其他需求了..


      不過
      我的最後建議是(不要只認 .md 一種格式)也許對標準的定義還輕鬆一點
      如果同層有存在同名 .md .html .txt 則視為衝突或優先解讀 .md

      同時用.md和.html應該也是一種方法

      不過 其實如果應用程式端是願意處理複製html時的md轉換 其實用.md應該可滿足筆記和寫作的需求了

      如果滿足上面的情況 那 .html 我覺得可當作 "備選方案" 因為滿足上面的情況的話 還可能會那麼一定要 .html的 很可能只剩下 網頁設計師的筆記需求 和 強烈依賴CSS的錯位排版 的這些需求

      另外 其實markdown並沒那麼強烈要求一定用定名為.md 因為這其實有違它一開始的設計目的 所以就用txt似乎也沒差
      (不否認.md在沒有gui程式的情況下是容易識別沒錯)

      同時支援.txt和.html的好處是 ->反正對以前寫了一堆的使用者 都丟進去讓應用程式端建立樹狀選單(或端看程式端的GUI管理界面去分類)就好了...


      另外一點html不適合筆記的一大重點是 撰寫
      markdown確實支援比較高階的 需要特別渲染的沒錯(那些幾乎都是後來才擴增的)
      但 對筆記和寫作而言 那些通常不是那麼急迫需要的功能
      而如果是說 方程式 流程圖 這類的
      事實上 html這方面的處理也向來極度糟糕 原始碼組合起來可能還比markdown難看懂..


      ScrapBook我也用了很久 也順道感謝大大的付出XD

      網頁筆記ScrapBook確實方便
      只是我也是常常會得將東西由ScrapBook轉到其他寫作中的軟體
      所以我想Lolinote是方向不太一樣的東西
      用firefox時我會用ScrapBook
      但整理和寫作時 我的確是跟雪凡大大一樣 找不到足夠滿意的軟體

      刪除
    30. @丹尼
      嘛,該怎麼說呢,世界上有上千種軟體,自然是有各種原因。不同的系統存在有不同的目的與使用情境。我唯一能說的,大概也只有咱開發的系統絕對是咱自己用最多啦,不會閒著沒事存心搞你。要知道東西不順手,第一個倒楣的捨我其誰嘛。我不會整你的啦。再說,lolinote 也不是我腦門一拍半個下午就設計出來的。如果不符合您的情境、偏好、哲學,我也只能說聲抱歉囉。

      回一下下面這個有趣的問題:
      「如果 abc 目錄下有 aaa.md, bbb.md, ccc.jpg,那該做何處理?」

      這模式看似 Resourced Note,但其實不是,仔細分析會發現它並沒有符合任何一條規則。因此在 lolinote 的框架下它處於「未定義狀態」。對於未定義的結構,我認為 lolinote 專用程式不應該特意去對它做任何事情。不過這也是看不同實作的目標而定。以 lolikit 的 fix 指令來說,因為目的就是修復,可能會將此視為一個潛在的錯誤而提出建議性警告。但對 find 指令來說,簡單忽略則是最佳策略。

      老實說,這種案例在用戶合併使用其他專案時,會相當常見。舉例來說如果用戶搭配 git 使用,難說 ".git" 資料夾內會出現一些什麼怪結構;或是用 vim 時意外留下了 .swp 暫存檔等等。這些東西問 lolinote 的軟體要怎麼處理的話,果然無視才是最好的嘛。
      lolinote 相關軟體面對不確定該如何利用的內容時,除非有特殊的目的與處理方針,我都會建議作者將其忽略。當然 Lolinote 是一個規則集,實際寫程式的人可能另有想法,而個別用戶也可以選擇是否要搭配這些程式來使用囉。

      刪除
    31. 既然雪凡堅持那是個人偏好,咱就先不深究了。

      談點實際面的,這些規則的存在究竟影響了什麼?

      舉例來說,要全文搜尋,我們完全可以寫個程式對某目錄下所有符合條件的檔案做索引(所有純文字檔、所有 *.md 等等),搜尋時也只要列出路徑即可,換言之,該程式根本不必管檔案有沒有按照蘿莉法則組織;「依照 mtime 排序列出某目錄下的檔案」更是有點 shell 功夫的人都能寫出單行指令解決的。

      我好奇的是,就您目前所規劃的,究竟有哪些實際程式的功能會因為有或沒有遵守蘿莉規則影響運作?

      刪除
    32. 哈 我也了解規則集是不太會去定義這種去程式端非得怎麼處理的東西啦 ^^
      我寫的只是"真的成為一個實際的程式時"比較實際會發生的況狀^^
      畢竟 使用者要的大多就是簡單易用而且能把東西都集中在一個作業情境裡 我想這也是為什麼國外寫作者往往都會要求去函筆記軟體公司把筆記和寫作合一吧 畢竟有在寫作的 久了都會很討厭東西東一個西一個的
      我以前就是 word excel onenote evernote scapebook等等一堆混用 最後最大的問題就是 寫東西常常還變成 查東西或之前的想法得開另一個軟體..甚至多個軟體 而且常常忘了之前臨時的想法或片段到底寫在那個地方 很浪費時間 常常東西找到了 本來寫一半的點子反而又忘了= =

      另外treeline在win7是正常的 另外兩個軟體 也都有win版 不過Scrivener確實MAC上的表現比較好

      刪除
    33. @WindStar
      謝謝啦,建議都收到了。我大部份都在 Linux 下面過活,所以可用的軟體比較少,找工具時常常很糾結啊。嗯,雖然想抱怨但大概是純屬自找的 XDDD



      @Danny
      「規則」在此的用途是定義資料結構。
      至於如何運用這個資料結構,則由使用者的雙手與巧思,以及個別程式的實作而異。

      至於確立「共通規則」的目的,則是為了分享。
      短期內是分享我的研究經驗,長期是為了讓大家能共享彼此的知識。讓大家的「工具」「經驗」「技巧」能互相傳承累積,而不需要讓每個「透過相似手段(純文字筆記)」,「達成相似目標(自由組合工具)」的朋友,都需要從頭發展這一切手法。
      這包括但不限於決定取捨、設計規則、搜羅測試各種看似匹配規則的工具、研究小技巧、實作支援程式、兜組腳本、避開或至少明示出某些看似方便但其實危險的 Anti-pattern 等。這些程式、技巧、知識、容易踩到的雷,可能全都很小很雜很瑣碎,但也都是障礙、都是麻煩。
      對一個用戶來說,如果需求差異沒有大到需要另起爐灶,共用一套相同的規則,可以顯著減少痛苦。而且就整個社群的角度來說,也可以少踩很多次雷,因為知識是共通的。



      關於程式。某 A 可以基於 alpha 需求,用「安全但比較麻煩」的實作策略寫出 a 程式;某 B 同樣也可以基於 beta 需求,用「自動方便但某些特例情境會誤刪檔案」實作策略搞一支 b 程式。而某用戶 C 到底滿不滿意 ab 的功能與實作策略,又要不要用,那就是某 C 與個別程式之間的問題了。和規則是沒關係的。

      以目前來說,程式實作只有 lolikit 一個。以其中的搜尋操作為例,對 Rule 的依賴部份舉例如下:

       Rule.2 「筆記全是 markdown」,有這個特性讓系統可以直接對檔案內容進行搜尋(舉例來說,如果筆記中允許用 html,搜尋實作就會不同)
       Rule.3 「檔名 = title + .md」特性,因此可以只對副檔名為 md 的檔案進行分析,並且回傳 title(如果 title 藏在別處,回傳 title 的實作會不同)。
       Rule.6 「根目錄存在 .loli 資料夾」,因此可以從任一次級目錄下搜索完整的筆記樹(如 git 可在子目錄下操作整個倉庫一樣),且提供了位置儲放 lolikitrc 設定檔。
       Rule.7 「內容為 utf8」,如非有此特性,否則根本無法可靠查找純文字內容,在 decode 階段就會出錯。

      我明白這太過理所當然,以至於看起來根本不需要規則對吧?當然,讓設計符合直覺,以至於用戶憑直覺就能完成 9 成的維護,這也是 lolinote 規則的重要目標。將其明確說出看似多餘,但可避免用戶一拍腦袋圖個方便,卻沒想過之後要付出什麼代價。如果沒有這些規則,會面臨大量例外狀況,工具程式的難寫程度會暴增數倍,而可靠度則反向降低。

      現實世界中我們也可能無法完全遵循規則,不過這種破壞相容性的行為,就要看用戶自己覺得划不划算了。作為規則的推動者,我當然是不推荐隨便破壞規則相容性,如果真要這麼做,最好有個夠好且「具設計一致性」的好理由。如果是有這種理由的話,或許可以提交 ExtRule 的建議給我或社群,或可討論研究一下。我已經另外開了 lolinote 的討論區了。



      PS: 除專有程式實作以外,還有一些與程式無關但會因為規則帶來好處的情境,如:

      Rule.1 「全為單一檔案且互不依賴」 因此不需複雜工具,甚至包括在手機上使用時,也能很快重組調整知識庫結構。
      Rule.5 「排序等於檔名字串順序」 因此任何檔案瀏覽器都能簡單完成排序操作,確保排序一致性。

      要能在這些情境下得到好處,也需要依賴用戶遵守規則的。

      刪除
    34. 嗯...試想某甲想寫筆記時就隨性地依內容性質建立 txt, word, ppt, xmind 記錄,要全文搜尋時便用當時找得到工具處理(比如 DocFetcher 或 Google Drive;或如只要搜尋純文字時用 Notepad++);某乙則嚴格遵守蘿莉筆記規則、幾乎只使用 .md 記錄筆記,並使用 lolikit 做全文索引及搜尋。您覺得後者相較於前者有什麼優勢呢?

      我沒有針對誰,這也是我最近在反思最近鑽研筆記軟體的狀況。我有好幾年的時間刻意不使用 office,而試圖使用 Scrap Book、TiddlyWiki、BoltWire、Mediawiki、Dokuwiki、各大部落格系統、手工網頁、Evernote、ScrapBook X,甚至自己寫 javascript 和 JAVA 動態程式,就為了搞一套所謂的筆記或知識庫,不過每個方案幾乎都有令人困擾的侷限性......如果我當初就繼續用 office,也許省的時間足夠自我充實到成仙了XD

      既然市面上已有一大堆廣為運用且運作良好的現成檔案規格及工具,何不就大方使用?真有必要自己搞一套支援格式少、搜尋速度差、適用平台也相對有限的筆記系統嗎?這樣折騰來折騰去到底得到了什麼、又失去了什麼呢?

      刪除
    35. 1.單換行是很惡劣的寫作習慣 但這是歷史共業 (當初的時代背景和網頁渲染器的中文支援極度差勁造成的)原則上這是 非常錯誤 非常錯誤 非常錯誤 的寫作方式
      事實上markdown單換行相對等於 br 雙換行相對等於 p
      2.中文使用者常常使用 p 當單換行 或常用雙 br當換段這則是-->無知 (別懷疑..雖然我們幾個都知道差別 但一般中文使用者往往不知道 ..這就是現實)
      3.以往的網路文章常常有單br換行的原因是-->中文顯示不會自動換行...
      但這問題其實目前的網頁瀏覽器幾乎都已經解決了..
      但那種惡劣的使用習慣卻被留下來了......

      現在例如如果常上小說網站的
      一定常常遇到這種的
      如果想把其文轉成其他電子書檔格式
      那就成了極度頭痛的問題之一

      例如 有10行文字是同一段 卻被每30個字用BR(甚至p)換成10行
      這光是要修正就很頭痛了..(因為不會每個人都是用30個字去換)

      這會造成電子書顯示很嚴重的問題
      因為移動設備的寬度和長度非常多樣化
      不可能永遠剛好都是在30字的位置到達邊緣或底部

      對今日已經沒必用的情況下 那是非常惡劣的習慣

      BR 單換行其實大多是在同段內但"需要時"才該使用者
      與其說BR是單換行也是非常錯誤的 嚴格說 他應該叫做 "段落內強迫換行"
      但中文使用者幾乎都因為以前的時代背景形成濫用的情況

      相反的
      同段內的條列式寫作時反而他們都不去用BR...而用P = =
      (br幾乎最主要會出現就是因為這種情況...)

      2.關於多種文檔格式時的問題,我覺得是未來蘿莉筆記軟體的"附件管理器"寫得好不好才是重點..

      寫得好 那您說的問題根本不太存在
      因為滿足前面這情況下蘿莉筆記就自然成了"集中管理器"

      說適用平台有限其實有點問題,因為這時代願不願意讓軟體跨平台似乎是該歸咎軟體撰寫者的心態和時間問題

      搜尋純文字時用 Notepad++ 這應該根本不是問題 因為那只是一個裝了很多文檔的資料夾
      而且Notepad++ 根本將MD視為TXT處理

      md只是純文字文件
      DocFetcher 或 Google Drive不會無法處理
      真想完全無縫讓他們可以處理
      不要用.md命名 改用 .txt即可
      連TXT都不支援的話 那是軟體濫...= =

      刪除
    36. 折騰來折騰去 這說法也有點怪
      問題是 舊檔案或是其他格式的話都把附件丟進去就好...何必折騰..
      所以前面我說 重點是附件管理是否簡易使用和完善

      適用平台也相對有限的問題
      其實word和線上式個人wiki才是最差的...
      而且word格式的處理速度也是極度的糟糕(無論是MS office和open office包括googleDOC都是)

      刪除
  2. 我覺得 Lolinote 的架構和 gitbook 有很多相通的地方,
    都是以 Markdown 做基底,來組織更複雜的資料。
    有些規則不妨直接借用
    http://help.gitbook.com/format/index.html

    回覆刪除
    回覆
    1. 謝謝意見!我讀過了,其實我本人也是 Gitbook 的愛用者,特別是最近經常在用。不過您提供的那頁提到的規則剛好都不適用。嗯,也不是說不好,比較像是目的不同所以派不上用場這樣。比方說筆記倉庫其實不太需要獨立的 README 檔案來做簡介、也不需要書本的 metadata--像是書名與作者名等等。

      不過 Lolinote 應該是可以和類似 Gitbook 這種專案整合的。他們之間的規則看起來並無矛盾之處,可以既是 Gitbook 又是 Lolinote。只是看需不需要這麼做囉。

      僅供參考!

      刪除

  3. 題外話.. 我猜 過些年 接下來會出現 Lolitanote
    (打半天的留言又被吃了 所以開始胡言亂語...)

    回覆刪除
    回覆
    1. 抱歉抱歉,不是被吃了,是被廣告過濾系統擋掉。
      那個系統真的蠻煩的,上面的丹尼也經常被擋掉,我一直找不到方法關他囧rz

      刪除

☆每日吐嘈,有益身心☆
…不過還是請手下留情別太狠啊。