2015年3月1日 星期日

整理漫畫圖檔的小工具: ftcbz

在講 ftcbz 之前,先來聊聊電子化漫畫的收藏問題。

漫畫是由圖片組成的,但與傳統圖片不同,並不是以「單張圖片」作為邏輯單位,而是以卷為單位。在這種狀況下,一本電子化的漫畫資料,本質上其實也就是一堆有序的圖片。

不過,任由一堆圖片赤裸裸地放在資料夾中,很多時候難以管理。舉例來說,您可能會不小心變更了一個檔案,不小心弄亂檔名順序,或是想要透過搜尋查找檔案時,找到一海票單獨存在毫無意義的圖片檔案。此外大量細小圖檔也可能造成一些作業系統的效能問題,比方說,每次瀏覽資料夾時,系統就會試圖建立起一海票縮圖,或是透過 MTP / FTP 協定傳檔時效能超慢等等問題。

而這許多因素,也就引出了「對漫畫檔案進行打包」的需求。理想中,是以漫畫的邏輯單位,也就是每卷或每章節為單獨一包。



常見的漫畫歸檔格式

cbz


「.cbz」正是一種基於 zip 的漫畫打包格式。

不過,說 cbz 「基於 zip」其實多少有點不盡不實啦。cbz 格式說得更直白一點,其實也就只是一包用 zip 格式包起來的壓縮檔,他和 zip 的差別,僅僅在於副檔名不同,真的沒別的了。

相對其他漫畫歸檔格式,cbz 的主要優點在於他很常見,閱讀程式的支援也很廣,我用過的漫畫閱讀器全都支持,一個不差。反過來說,其主要缺點是壓縮檔內不支援檔名編碼,所以如果在不同的作業系統上進行壓縮與解壓縮,檔名可能會變成亂碼。不過這個問題在處理漫畫圖檔時基本可以無視。

cbz 不是唯一的漫畫歸檔格式,其他同類格式還有 cbt, cb7, cbr 等,分別對應到 tar, 7z, rar 等壓縮格式。與 cbz 相同,他們與原始格式的差異也都只是副檔名不同,這方便雙擊時讓作業系統知道用圖片瀏覽器去打開他們,而不是用壓縮程式去打開。

cbt


相比 cbz,基於 tar 的 cbt 格式則是我最看好的格式之一。

cbt 天生經過沒有壓縮,打包解包都很快,幾乎就和直接存取磁碟一樣快,而且隨機讀取內部任一張圖的速度也很優秀。圖片畢竟沒法壓縮,在那邊壓來壓去只是徒然減緩響應速度而已,沒什麼好處。當然,其他格式如 cbz 也能支援無壓縮模式,不過用戶得自己去設定它--非技術用戶鐵定會忘記這一點。

話說回來,舊版的 tar 檔案也不支援檔名編碼,不過在新的 tar pax 版本中,檔名編碼也被實作了。並不是問題。

不過 cbt 目前支援的軟體比較少,想要普及還需要在努力

cbr 與 cb7


基於 rar 的 cbr 也還算流行,軟體支援度還不錯,不過真要我說,其唯一的優勢就是不知道為啥大家都用 rar 來壓檔案,因此各家漫畫瀏覽器都不得不支援。

rar 格式的另一個優點是壓縮率較高,但這在壓圖片的場合沒有意義,而且解壓速度一般來說比 zip 慢。此外 rar 格式是專有軟體格式,開發起來有點麻煩……總之,只要我能選,我就不會選用它來存放漫畫圖片。

另一方面,基於 7z 格式的 cb7,則是解壓速度與隨機存取速度都慢到讓人髮指 (不過這可能與我的壓縮設定有關,待確認),而且 7z 原始函式庫是設計在 Windows 下運行的,雖然是自由軟體,也有 p7zip 專案,但在 Linux 環境下嚕起來還是比較詭異。

7z 的壓縮率比 rar 還要好,不過這在壓圖的場合同樣沒有任何意義。



以上這些格式,原始設計是漫畫歸檔用,但我也把這些格式大量用在圖檔需要成叢打包的場合。之後要瀏覽,就直接拿漫畫瀏覽器來看,非常方便又好處理。我現在直接將漫畫瀏覽器 (mcomix) 設為作業系統的預設圖片瀏覽器來用,用起來快又順手。

關於 ftcbz


前面說了些檔案格式的事情,現在說說 ftcbz。

ftcbz 是咱寫的一支簡單腳本程式,已經發佈了一年左右,其名早期(<=1.1 版)為 Folder to cbz 之意,顧名思義就是把資料夾批次壓成 cbz 用的。

其實一般壓縮軟體也能做這個,只要壓成 zip 後再改個檔名就好,不過這就要一個一個資料夾手工慢慢壓。假設每本漫畫有十來個「卷資料夾」,十套漫畫就可能破百個資料夾,加上壓縮速度不快,電腦 IO 總是卡住,很長時間都只能呆在電腦面前發呆,又不能丟著不管,總之啥也不能做……煩死了!

太有忍耐力的程式設計師鐵定不是個好程式設計師,看在懶惰的名義上。那就寫個程式來批次把圖庫/漫畫壓成 cbz 吧 ♥

好吧,我知道這是典型的不折騰會死行為。程式設計師是一種精神疾病……大家就別糾結這件事了。

改版 2.0


這篇發表的時候,ftcbz 剛好改版到 2.0 版,因應功能增強,重新定名為 Freezing to cbz!。如新名稱暗示的那樣,新版不只能接受「資料夾」作為資料來源,還能接受其他格式 (目前僅支援 rar/cbr) 作為資料來源,而且還支援在轉換過程中拆除討厭的密碼。

除此之外,2.0 也修改了框架,讓程式內部管線化,明確分離出 input phase 與 compress phase 兩部份。換句話說以後可以透過直接撰寫新組件,支援更多的輸入格式與輸出格式。不過具體要支援哪些就等我啥時有需要時再去弄了。

安裝與用法簡介


安裝方式是透過 pypi,如下:

pip3 install ftcbz

程式目前只在 Linux 環境下測試過,不過我沒有寫平台專屬的 code,運氣不差的話在 windows 下也能跑吧?不然就等誰報 bug 時再修。執行條件為 python>=3.3,如果需要用 rar 方面的相關功能請自行另裝 unrar 套件 (沒裝卻想用相應功能時會有提示)。

簡單的指令使用範例:

ftcbz 漫畫資料夾1 漫畫資料夾2

以上每個「漫畫資料夾」下都會有多個「卷資料夾」,程式會自動把「卷資料夾」壓成 cbz 檔案。更進一步的詳細用法與解說請見專案官網與程式內幫助 (ftcbz -h),這邊就不囉唆了。

有需要的人就自行試玩看看吧!

25 則留言:

  1. 請問PC和手機上推薦哪些支援 cbz 的閱讀軟體?當然最好是開源免費跨平台的

    回覆刪除
    回覆
    1. 如果可以,再加個綠色(要求真多XD)

      刪除
  2. 我已經很久沒在windows下生活了,不過以前在windows平台下用的漫畫瀏覽軟體是comicviewer,剛剛去看了一下開發者網頁,如今還有在持續開發,也有綠色。您可以試試。

    linux平台下,我早期是用comix,但是這套軟體的開發者不知為啥毫無預兆就憑空蒸發了。後來有人受不了就基於它fork出了mcomix。推薦mcomix,各大disto 套件庫應該都有得裝,不然comix 也還是不錯的。

    android 下推薦的是 perfectviewer 這套,好用得沒話說,如果覺得不錯的話可以給作者捐款。

    回覆刪除
  3. 感謝推薦。試了一下發現 cbz 真是好物,PerfectViewer 也的確好用到沒話說,立馬把陪伴多年的 ComicBricks 拜拜掉了XD

    關於批次建立壓縮檔,在 Windows 平台下有高人寫了個腳本,存成 .cmd 以後把多個資料夾拖曳上去即會個別執行批次壓縮,個人覺得用起來頗順手,可以參考看看(Linux 桌面版應該也能寫成對應的腳本)

    http://ilowkey.net/tool-7-zip-batch-zip/

    回覆刪除
  4. 關於壓縮檔,一般壓縮率是 7z > rar > zip,但 7z 的演算法對圖片支援度頗差,圖片測試一般是 rar > zip > 7z (你沒看錯,7z 比 zip 還差),以上都是設定為最大壓縮比。

    另外 7z 預設使用結實壓縮 (solid compression),猜測可能是因此導致看圖軟體效率下降,試試加上不使用結實壓縮的參數或許可以改善?

    (雖然咱還是傾向選擇支援度比較高的 cbz,以上看看就好)

    回覆刪除
    回覆
    1. 說的沒錯!效率不佳就是固實壓縮搞出來的問題。移除固實壓縮選項後問題就解決了。

      在 Linux 下用以下指令壓:
      7z a -m"s=off" "目標檔名.cb7" "要壓的資料夾"

      還可以加上額外的 -m"x=0" 來完全取消壓縮功能,僅僅只做歸檔:
      7z a -m"x=0" -m"s=off" "目標檔名.cb7" "要壓的資料夾"

      測試確認,perfectviewer 與 mcomix 都支援 cb7,如此一來,說不定將 cb7 作為標準漫畫格式也不錯,或可以避免 cbz 的潛在檔名亂碼問題 (雖然這真的不是重點,但潔癖嘛……)。當然,進一步的軟體支援度還有待確認。如有其他慣用軟體的測試情報也請順手發一下。

      另外,剛剛發現 mcomix 也有 windows 版的,想試的話請到這裡下載:
      http://sourceforge.net/projects/mcomix/files/?source=navbar

      刪除
  5. 各種好情報GJ!明天立刻試試。

    壓根沒想過還有拖曳執行這回事,看起來蠻有趣的趁機研究一下♡

    回覆刪除
    回覆
    1. 找到方法了,拖曳執行功能在 Linux 下的 nautilus 檔案管理器中,想支援必須這樣寫。

      先新建一個 desktop 檔案,如 ftcbz.desktop,再將他的權限設為可執行,然後將以下內容寫入:

      [Desktop Entry]
      Type=Application
      Terminal=false
      Name[en_EN]=ftcbz
      Exec=ftcbz

      關鍵是 Exec 那行。我這邊為方便測試直接引用了 ftcbz 組件,沒有另寫。總之這樣就可以將資料夾拖到上面去操作了。

      寫是寫了,不過冷靜想想,這樣寫也沒比指令行介面更好用,這個運用場景大概比較不適合吧?總之先記著,下次再找地方用。

      刪除
  6. 試了 mcomix ,功能很簡單,但相當順手,但有個問題是只要不是在壓縮檔的第一頁或最後一頁關閉,下次開啟就會一片全黑,什麼都看不到,必須到書庫把該壓縮檔從書庫中移除再重開。

    不知這是否為 Windows 版獨有,總之它導致閱讀體驗破壞殆盡,所以出局。

    其他試了 CDisplayEx、ComicsViewer、ComicRack、Hamana,覺得不是界面過度複雜就是操作起來不順手。

    目前是改用 HoneyView,實測確定可支援 cbz 和 cb7,界面簡單,我需要的功能好找,預設快捷鍵也很順手。有興趣也可以玩玩 (Linux 要喝酒的樣子)

    回覆刪除
    回覆
    1. 您跟我最後選的一樣XD
      雖然我覺得HONEYVIEW比不上HAMANA
      但是畢竟HAMANA應該不會有新版本的\了..

      刪除
  7. 你提到 CBZ 和 CB7 可以用於其他打包圖片的場合,這點我有些好奇。

    雖然 CBZ 和 CB7 用於打包漫畫再理想不過,不過在其他場合似乎不太能滿足需求:

    比如有時我會把實體書掃描歸檔,以便隨時瀏覽,此時我會比較偏好包成 PDF 檔,主要是因為 PDF 可以標書籤、劃線、加註解,體驗上比較像是讀一本書。當然 PDF 的編輯軟體少,且圖片嵌入後似乎便無法原樣取出,不過掃好的書一般是當做靜態資料,此類需求幾乎可以忽略。

    另一種情況是圖文說明集,目前圖片說明文字的主流處理方式是寫在 EXIF,但偏偏大多數 CBZ 軟體都無法瀏覽 EXIF 資訊。雖然可以把圖片命名為 [數字+說明] 的形式再包成 CB7 以防亂碼,但總覺得美中不足……

    我想知道你還曾經把 CBZ 用在哪些地方?是否碰過麻煩或瓶頸?以及怎麼解決的?


    回覆刪除
    回覆
    1. 我討厭用相簿軟體管相片,一本相簿整理好後就直接壓成一包。

      另外掃書時也會用,但這時 pdf 確實是更好的方案,不過 Linux 下中文 OCR 不太好 (這時就很想換回去用 Windows 了……),PDF 比較派不上用場。不過反正在下用 PDF 也幾乎沒用過搜尋功能,影響不大,就壓成 cbz。

      pixiv 抓下來的圖片也是加壓對象。這些圖片老是隨時間愈積愈多,又沒法分類,檔案多到幾百上千個後,就給它打個時間戳,然後換個新資料夾繼續抓。之前抓的圖嫌太多了就用 cbz 封印起來,反正即使散放著也不太可能刻意找哪張圖看,啥時興致來了也就依著順序看下去了,沒什麼差別。檔案數少了很多,管理起來比較愉快。

      刪除
    2. 相片管理真是件複雜的事。如果以事件為單位,好比「某時某地出遊」,一般都會有「我拍」的相片、「拍我」的相片,再來還有依相機分類、依拍攝者分類(同一台相機有時是不同人在拍),還有原始照片、編修後照片、精選照片、要公開分享的照片等等,處理起來真是一個頭兩個大orz

      我目前主要是用 Picasa 管理,因為它可以在同樣原始檔的基礎上建立許多虛擬相簿,可以打星號或加 EXIF 註解,編修照片會自動將原始檔備存,且後設和備存資訊是儲存在圖片資料夾下的隱藏檔,管理起來不錯方便,此外它還可以和 Google+ 相簿同步,解決一些分享和備份問題。

      Picasa 和 cbz 可說是不相容的,因為 cbz 軟體幾乎都不支援 EXIF,且 Picasa 放在隱藏資料夾裡的備份檔會被 cbz 軟體傻傻秀出來XD

      當然 Picasa 也有不少缺點,比如軟體綁定,我目前也不很滿意這方案。不知你通常怎麼處理相片的分類加註、編修之類的問題?想參考參考。

      掃書方面,我個人也幾乎不用 OCR,用 PDF 主要考量是劃線加註記。

      pixiv 完全沒用過,就不予置評了。

      刪除
    3. 老實說遇到的問題和你一樣,總之討厭軟體綁定!

      試用過一陣子給照片打註解後,發現替個別照片加註在我的使用情境中不是絕對必要的,所以很快就放棄了這種行為。

      如果您有這種需求,或許可以找那些會在 jpg 內嵌註解的圖片管理軟體 (有些需要開些選項才會將 Metadata 內嵌進檔案中),直接將註解嵌在照片中的 EXIF, IPTC 與 XMP 之中,如此依來就有機會跨軟體使用。

      但這種作法也並不完美:
      1. 並不是所有圖檔格式都支援內嵌這種訊息,印象中 png 就無法內嵌 IPTC Metadata,當然如果你只處理 jpg 相片則沒問題。
      2. 部份軟體不支援或會完全無視這些訊息。有些軟體只支援 IPTC,有些只支援 XMP。IPTC 是比較老的標準,支援的軟體較多,但它也比較原始,聽說還會有些編碼問題(需驗證)。XMP 並不是 IPTC 的後繼者,而是 Adobe 一幫人覺得 IPTC 不夠用而自己設計的,希望能成為世界標準。
      XMP 確實正在朝世界標準的方向走,但因為有這種需求的人少,進度非常緩慢,我一直擔心他可能還沒能成為實質標準就先過時了。
      3. 複雜,哪個欄位才是註解的位置?另一個名字看起來很像的欄位又是幹嘛的?我印象中 IPTC 與 XMP 中,個別有至少 3 到 4 個欄位看起來像是用來填註解的 (參考官方說明文件後還是覺得很模糊),我嚴重懷疑不同的圖片軟體在讀寫註解時是否會對應到相同欄位。XMP 強調可擴展性,因此格外複雜。
      4. 此外,填了 XMP 的欄位後,IPTC 的欄位是否也要複製一份?畢竟有些程式只吃其中之一……

      總之就是麻煩!在這些解決方案確實成為標準之前,實在不太想用。真要用時還不如用個 txt 檔案把註解寫下來。

      如果能接受用 txt 寫註解,那麼許多漫畫軟體其實也支援這種註解方式。畢竟 cbz 只是個壓縮檔,裏面要裝什麼都沒問題。於是乎,有些漫畫軟體會去讀內部副檔名為 txt (或可自定義) 的檔案,然後將其視為註解檔。

      這倒不失為一種寫註解的好辦法,使用純文字註解的話,之後面對其他標準時也有轉移的餘地。Mcomix 就有這種功能。不過基本上這種註解是針對整個 cbz 的,粒度或許無法滿足您的需求。總之,有需要就再自己 workaround 一下了。

      不過相片註解功能我畢竟比較少用,您的經驗應該比我足。這些隨便聽聽就可以了。

      PS: 我也覺得 picasa 蠻好用的,用起來很滑順,之前也用過一陣子,不過 Linux 版本已經被廢棄很久了,稍微有點可惜囉。

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

      刪除
    5. 對了,您有用 Windows 8.1 的手勢功能來看漫畫過嗎?搭配什麼軟體比較好?感覺起來效果如何?有情報的話借我參考一下謝謝!

      刪除
    6. Picasa 在更新圖片註解時會同步更新三個地方,一個是 IPTC 的 Caption-Abstract 欄位,一個是 XMP 的 Description 欄位,一個是 .picasa.ini 資訊。這些加上註解的圖片上傳 Google+ 或 FB 時,伺服器會自動加上相應的圖片註解。其他相簿服務我沒試過,不確定他們是否支援同樣的規格。總之你可以參考看看。

      純文字檔註解要看不同軟體能否支援相同的寫入/讀出格式,CBZ 有共通的註解格式標準嗎?

      至於 Windows 8 ,目前還沒研究,有朝一日再來報告XDD

      刪除
  8. 很多人用RAR的原因是
    WinRAR有選項可以加容錯的redundancy
    傳大檔在網路惡劣環境有優勢

    回覆刪除
  9. >7z 的壓縮率比 rar 還要好,不過這在壓圖的場合同樣沒有任何意義。

    很棒的文章,跟我從1996年一直到現在的心得幾乎一樣,很久以前我曾經寫過MAIL給ZIP或RAR的開發者提出封裝漫畫的這種格式,當時他的回覆說這是個好點子

    不過,當然我是不知道後來 CBZ CBR的出現跟我當時的MAIL會不會有什麼關係XD

    回到正題
    回覆這文章的最主要目的是這個
    >7z 的壓縮率比 rar 還要好,不過這在壓圖的場合同樣沒有任何意義。

    原則上,這說法是部分可說是錯誤的
    7Z對圖檔壓縮有其獨到之處,問題出在"格式"
    JPG之類的壓縮破壞性圖檔格式,老實說用什麼壓縮軟體根本都不可能真的變小多少
    但是,如果是原始沒被破壞的非壓縮格式,7z極強 !
    7z還有一種"連續比對圖檔內容差異壓縮"的獨到能力,對於應付大量變動不到的CG圖壓縮率可達"恐怖"程度
    這些都不是其他壓縮格式比得上的。

    另外-其實依據我多年的心得
    目前我會比較想開發的會是,CB7PNGR 格式 或是 CBMPNG 或CBMPNGP 這樣的東西 然後配上一個獨立開發的瀏覽程程式或瀏覽器框架程式

    或是Tx7這樣的純文字格式

    原因是,用過一大堆電子書格式,我發現對圖型書籍而言那些根本都差得可以,離(純文字+圖文並茂+漫畫+多語)的終極解實在差得非常遙遠到宇宙距離,不管是EPUB和PDF都是,甚至PDF的巨肥實在是噩夢一場‧更別說那些格式對於直式文字根本是惡夢一場(EPUB是在日本開發者下完善這點的,很抱歉的現實就是,電腦漢字方面閱讀,華人的貢獻可能遠遠低於日人..."包含Adobe"的文字處理都是這麼回事...)。

    另外如果真的要用CBZ CBR CB7格式 我會建議使用 CBR +濾JPG無壓縮封裝+rr3%復原
    rr3%復原不會對容量造成什麼真正的傷害,因為與其不封裝造成的磁碟虛耗而言,那3%不見得真的有多到什麼程度。

    另想請問 LoNote
    我是找這東西找到這來的
    因為我之前是用ZIM WIKI

    想請問 LoNote 是否有類似 ZIM WIKI 的這幾點特性
    1.使用純文字檔案和附件資料夾紀錄
    2.使用WIKI與MarkDown標準
    3.ZIM 表格外掛的功能 -輸入表格方便 又能用任何純文字編輯器修改
    4.ZIM 附件瀏覽器外掛的功能 - 在每頁下方直接顯示 且也沒限制圖或附件內容一定要出現在文件內 對於我常常只在文內放一代表圖,其他多圖直接放在裡面的資料夾很方便
    5.ZIM 目錄外掛的功能 - 在頁面右上顯示文章目錄階層 對常文非常方便
    6.如ZIM 在資料夾內如自己加入文字檔 會自動更新到文章列表
    7.直接用文字檔加入樣本文件夾可自訂新頁面範本 - 對寫人物設定或重複性規格內容的東西很方便

    我本來是ZIM同時在WIN和UNUMTU用的
    但WIN版的ZIM停留在0.63 而且作者已經不想發佈win0.65...
    (0.63在win下中文之原有問題 連建立文章名稱用中文都會衝碼無法建立)

    我覺得ZIM如您另文所言,有許多地方非常獨到
    所以想找一個能替代的,著實很傷腦筋中...

    回覆刪除
    回覆
    1. 抱歉回應被廣告過濾系統吃掉了囧rz,我剛把他打撈回來。有時連我自己 po 的回應他都照吃不誤。

      極佳的補充,謝謝!
      說不定就是因為您咱們現在才有 CBZ 可用 XD

      據我所知,直到目前為止還沒有一些支援直書動態字流排版的有效方案。我聽說 HTML5 之中有包含這一部份,但是目前實作狀況還不太理想。大概是主流瀏覽器中,中文圈參與開發的較少吧?或是看橫字已經認命了。Ruby text 標籤記得也是日本人搞出來的,這方面真的要感謝日本人……嘛雖然實作依然尚未普及 (firefox 同學請別看旁邊)

      說到壓縮檔的回復功能,我個人的經驗是幾乎不曾遇到下載時部份損毀的問題。而每當有修復紀錄的RAR真的發生損毀的狀況(印象中好像有三四次),我用 RAR 的自動修復功能從沒有任何一次成功修好過,因此我對於修復紀錄一直都是抱持著無所謂的態度。當然這只是我的個人經驗,僅供參考。

      Lonote 部份我注意到你在另一邊有 PO 文,我就回在另一邊囉。

      刪除
  10. >7z 的壓縮率比 rar 還要好,不過這在壓圖的場合同樣沒有任何意義。

    很棒的文章,跟我從1996年一直到現在的心得幾乎一樣,很久以前我曾經寫過MAIL給ZIP或RAR的開發者提出封裝漫畫的這種格式,當時他的回覆說這是個好點子

    不過,當然我是不知道後來 CBZ CBR的出現跟我當時的MAIL會不會有什麼關係XD

    回到正題
    回覆這文章的最主要目的是這個
    >7z 的壓縮率比 rar 還要好,不過這在壓圖的場合同樣沒有任何意義。

    原則上,這說法是部分可說是錯誤的
    7Z對圖檔壓縮有其獨到之處,問題出在"格式"
    JPG之類的壓縮破壞性圖檔格式,老實說用什麼壓縮軟體根本都不可能真的變小多少
    但是,如果是原始沒被破壞的非壓縮格式,7z極強 !
    7z還有一種"連續比對圖檔內容差異壓縮"的獨到能力,對於應付大量變動不到的CG圖壓縮率可達"恐怖"程度
    這些都不是其他壓縮格式比得上的。

    另外-其實依據我多年的心得
    目前我會比較想開發的會是,CB7PNGR 格式 或是 CBMPNG 或CBMPNGP 這樣的東西 然後配上一個獨立開發的瀏覽程程式或瀏覽器框架程式

    或是Tx7這樣的純文字格式

    原因是,用過一大堆電子書格式,我發現對圖型書籍而言那些根本都差得可以,離(純文字+圖文並茂+漫畫+多語)的終極解實在差得非常遙遠到宇宙距離,不管是EPUB和PDF都是,甚至PDF的巨肥實在是噩夢一場‧更別說那些格式對於直式文字根本是惡夢一場(EPUB是在日本開發者下完善這點的,很抱歉的現實就是,電腦漢字方面閱讀,華人的貢獻可能遠遠低於日人..."包含Adobe"的文字處理都是這麼回事...)。

    另外如果真的要用CBZ CBR CB7格式 我會建議使用 CBR +濾JPG無壓縮封裝+rr3%復原
    rr3%復原不會對容量造成什麼真正的傷害,因為與其不封裝造成的磁碟虛耗而言,那3%不見得真的有多到什麼程度。

    另想請問 LoNote
    我是找這東西找到這來的
    因為我之前是用ZIM WIKI

    想請問 LoNote 是否有類似 ZIM WIKI 的這幾點特性
    1.使用純文字檔案和附件資料夾紀錄
    2.使用WIKI與MarkDown標準
    3.ZIM 表格外掛的功能 -輸入表格方便 又能用任何純文字編輯器修改
    4.ZIM 附件瀏覽器外掛的功能 - 在每頁下方直接顯示 且也沒限制圖或附件內容一定要出現在文件內 對於我常常只在文內放一代表圖,其他多圖直接放在裡面的資料夾很方便
    5.ZIM 目錄外掛的功能 - 在頁面右上顯示文章目錄階層 對常文非常方便
    6.如ZIM 在資料夾內如自己加入文字檔 會自動更新到文章列表
    7.直接用文字檔加入樣本文件夾可自訂新頁面範本 - 對寫人物設定或重複性規格內容的東西很方便
    8.自動完成功能(輸入到 現有文章標題的開頭字 會自動在輸入時出現可選擇清單 然後點用後也自動變成文字連結)
    9.匯出 匯出時可以將一整個特定樹下的文章內容都串在一起 變成一整篇單檔文章 (寫小說很方便)

    ZIM本來沒有的
    10.支援複製文章時,圖檔會自動變成附件,而不是直接連結(我覺得這很糟糕,因為網路文章一久,網上的圖實在非常容易不見,最後文章內只剩X燒包....)
    11 複製文章時 不會只有純文字 至少有MarkDown包含的格式和圖片
    12 建立新文章和複製成新文章時 可選要用純文字 WIKI MARK HTML 或自訂的樣板
    13.MarkDown 編輯/顯示 雙欄顯示
    14.時間軸故事點子卡片功能 (這點我是不奢求...畢竟太少有可能會有這功能的=_=...)

    我本來是ZIM同時在WIN和UNUMTU用的
    但WIN版的ZIM停留在0.63 而且作者已經不想發佈win0.65...
    (0.63在win下中文之原有問題 連建立文章名稱用中文都會衝碼無法建立)

    我覺得ZIM如您另文所言,有許多地方非常獨到
    所以想找一個能替代的,著實很傷腦筋中...

    回覆刪除
  11. >7z 的壓縮率比 rar 還要好,不過這在壓圖的場合同樣沒有任何意義。

    很棒的文章,跟我從1996年一直到現在的心得幾乎一樣,很久以前我曾經寫過MAIL給ZIP或RAR的開發者提出封裝漫畫的這種格式,當時他的回覆說這是個好點子

    不過,當然我是不知道後來 CBZ CBR的出現跟我當時的MAIL會不會有什麼關係XD

    回到正題
    回覆這文章的最主要目的是這個
    >7z 的壓縮率比 rar 還要好,不過這在壓圖的場合同樣沒有任何意義。

    原則上,這說法是部分可說是錯誤的
    7Z對圖檔壓縮有其獨到之處,問題出在"格式"
    JPG之類的壓縮破壞性圖檔格式,老實說用什麼壓縮軟體根本都不可能真的變小多少
    但是,如果是原始沒被破壞的非壓縮格式,7z極強 !
    7z還有一種"連續比對圖檔內容差異壓縮"的獨到能力,對於應付大量變動不到的CG圖壓縮率可達"恐怖"程度
    這些都不是其他壓縮格式比得上的。

    另外-其實依據我多年的心得
    目前我會比較想開發的會是,CB7PNGR 格式 或是 CBMPNG 或CBMPNGP 這樣的東西 然後配上一個獨立開發的瀏覽程程式或瀏覽器框架程式

    或是Tx7這樣的純文字格式

    原因是,用過一大堆電子書格式,我發現對圖型書籍而言那些根本都差得可以,離(純文字+圖文並茂+漫畫+多語)的終極解實在差得非常遙遠到宇宙距離,不管是EPUB和PDF都是,甚至PDF的巨肥實在是噩夢一場‧更別說那些格式對於直式文字根本是惡夢一場(EPUB是在日本開發者下完善這點的,很抱歉的現實就是,電腦漢字方面閱讀,華人的貢獻可能遠遠低於日人..."包含Adobe"的文字處理都是這麼回事...)。

    另外如果真的要用CBZ CBR CB7格式 我會建議使用 CBR +濾JPG無壓縮封裝+rr3%復原
    rr3%復原不會對容量造成什麼真正的傷害,因為與其不封裝造成的磁碟虛耗而言,那3%不見得真的有多到什麼程度。

    另想請問 LoNote
    我是找這東西找到這來的
    因為我之前是用ZIM WIKI

    想請問 LoNote 是否有類似 ZIM WIKI 的這幾點特性
    1.使用純文字檔案和附件資料夾紀錄
    2.使用WIKI與MarkDown標準
    3.ZIM 表格外掛的功能 -輸入表格方便 又能用任何純文字編輯器修改
    4.ZIM 附件瀏覽器外掛的功能 - 在每頁下方直接顯示 且也沒限制圖或附件內容一定要出現在文件內 對於我常常只在文內放一代表圖,其他多圖直接放在裡面的資料夾很方便
    5.ZIM 目錄外掛的功能 - 在頁面右上顯示文章目錄階層 對常文非常方便
    6.如ZIM 在資料夾內如自己加入文字檔 會自動更新到文章列表
    7.直接用文字檔加入樣本文件夾可自訂新頁面範本 - 對寫人物設定或重複性規格內容的東西很方便
    8.自動完成功能(輸入到 現有文章標題的開頭字 會自動在輸入時出現可選擇清單 然後點用後也自動變成文字連結)
    9.匯出 匯出時可以將一整個特定樹下的文章內容都串在一起 變成一整篇單檔文章 (寫小說很方便)

    ZIM本來沒有的
    10.支援複製文章時,圖檔會自動變成附件,而不是直接連結(我覺得這很糟糕,因為網路文章一久,網上的圖實在非常容易不見,最後文章內只剩X燒包....)
    11 複製文章時 不會只有純文字 至少有MarkDown包含的格式和圖片
    12 建立新文章和複製成新文章時 可選要用純文字 WIKI MARK HTML 或自訂的樣板
    13.MarkDown 編輯/顯示 雙欄顯示
    14.時間軸故事點子卡片功能 (這點我是不奢求...畢竟太少有可能會有這功能的=_=...)
    15. 這大概真的有點奢求.. 支援某樹下文章可以直接發佈到WordPreess和blogspot 這我試過的例如EVERNOTE+WORDPRESS外掛都不好用

    我本來是ZIM同時在WIN和UNUMTU用的
    但WIN版的ZIM停留在0.63 而且作者已經不想發佈win0.65...
    (0.63在win下中文之原有問題 連建立文章名稱用中文都會衝碼無法建立)

    我覺得ZIM如您另文所言,有許多地方非常獨到
    所以想找一個能替代的,著實很傷腦筋中...

    回覆刪除
  12. 啊 忘了說
    有個軟體可能您可以考慮開發一下

    "已損壞圖檔/壓縮檔尋找器"...

    這對有一大堆圖檔和照片又常換硬碟的人應該是需求孔急...

    回覆刪除
  13. 怪了 怎麼發的文一直發佈出去卻沒出現= =
    如果您那邊看到很多篇見諒
    這次分成兩篇看看能否正常

    >7z 的壓縮率比 rar 還要好,不過這在壓圖的場合同樣沒有任何意義。

    很棒的文章,跟我從1996年一直到現在的心得幾乎一樣,很久以前我曾經寫過MAIL給ZIP或RAR的開發者提出封裝漫畫的這種格式,當時他的回覆說這是個好點子

    不過,當然我是不知道後來 CBZ CBR的出現跟我當時的MAIL會不會有什麼關係XD

    回到正題
    回覆這文章的最主要目的是這個
    >7z 的壓縮率比 rar 還要好,不過這在壓圖的場合同樣沒有任何意義。

    原則上,這說法是部分可說是錯誤的
    7Z對圖檔壓縮有其獨到之處,問題出在"格式"
    JPG之類的壓縮破壞性圖檔格式,老實說用什麼壓縮軟體根本都不可能真的變小多少
    但是,如果是原始沒被破壞的非壓縮格式,7z極強 !
    7z還有一種"連續比對圖檔內容差異壓縮"的獨到能力,對於應付大量變動不到的CG圖壓縮率可達"恐怖"程度
    這些都不是其他壓縮格式比得上的。

    另外-其實依據我多年的心得
    目前我會比較想開發的會是,CB7PNGR 格式 或是 CBMPNG 或CBMPNGP 這樣的東西 然後配上一個獨立開發的瀏覽程程式或瀏覽器框架程式

    或是Tx7這樣的純文字格式

    原因是,用過一大堆電子書格式,我發現對圖型書籍而言那些根本都差得可以,離(純文字+圖文並茂+漫畫+多語)的終極解實在差得非常遙遠到宇宙距離,不管是EPUB和PDF都是,甚至PDF的巨肥實在是噩夢一場‧更別說那些格式對於直式文字根本是惡夢一場(EPUB是在日本開發者下完善這點的,很抱歉的現實就是,電腦漢字方面閱讀,華人的貢獻可能遠遠低於日人..."包含Adobe"的文字處理都是這麼回事...)。

    另外如果真的要用CBZ CBR CB7格式 我會建議使用 CBR +濾JPG無壓縮封裝+rr3%復原
    rr3%復原不會對容量造成什麼真正的傷害,因為與其不封裝造成的磁碟虛耗而言,那3%不見得真的有多到什麼程度。

    回覆刪除

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