日本無料wiki試用

因為某些原因(……)最近摸了幾款日本的 Free Rental Wiki 服務(就是Wikifarm啦)語法轉換一時很不習慣

……總之來整理一下心得,希望能為搜尋路過的人指點方向(……)

Note: 本文提到的Wiki站大多出自這份清單

「無料レンタル Wiki 作成サービス」
https://freesoft-100.com/homepage/rental/wiki.html

Wiki 的要求

一般來說wiki至少要符合這兩點:

1. 編輯很簡單,不用學複雜的語法,可以直接在瀏覽器進行編輯
2. 多人共同作業

大部分的wiki也都符合上面這兩個條件

如果只是結構簡單不複雜的文件,就像你在使用筆記或書籤工具一樣,有分類/tag系統查找資料就很ok了。

不過日本的手遊卡片系統,一張卡片需要用稀有度、角色、屬性、技能…等不同的category來歸類,可能會想:

「這也可以用tag,一張卡片加上『稀有度、角色、屬性、技能』等tag,按tag即可搜尋」

我也想過這個方法,一些類型的遊戲可以這樣做是因為有相同tag的多個頁面不需要互相比較。

但是日系抽卡手遊,即使都是同類型的技能或同屬性,還是需要互相比較強度……

有類似資料庫系統的Wiki

總之,一個接近資料庫概念的功能是必須的,不然要做出「同類型卡片的比較清單」就必須反覆複製貼上。

這件事其實有個東西可以辦到,就是大家熟悉的:Google 試算表!

但是顯然 Google文件並不符合需求。雖然說符合方便多人編輯的條件,但是首先,

1. 他並不是一個正式網站,普通玩家沒辦法透過搜尋進入這個文件,除非弄一個網站並嵌入該文件,或是文件持有者到處宣傳該連結;
2. 另外,文件持有者必須維持文件權限開放,要是持有者離開這個作品圈子、關閉文件,這份文件就無法繼續留著給新人參考使用。

但也是有方法解決上述兩點問題就是。新建Google帳號使用試算表,找一個可以嵌入(iframe或embed)試算表的Wiki站。

極端來說,只要有個填寫卡片資料的大表格,並且規定表格填寫格式,再加上排序功能,其實就可以解決大多數卡片搜尋的問題了。

不過一般習慣上,Wiki站還是需要每張卡片一個頁面。

好的,總之我找了找,可以辦到「輸入一次卡片資料後用不同條件排序卡片清單」這件事的Wiki大概有這些:

  • Gamerch
  • Mediawiki engine 的 extension 如 Semantic Mediawiki, Cargo 等
  • Wikidot 的 Data Form
  • pukiwiki engine 的 tracker plugin

(如果有人知道其他的歡迎提供)

(對了,考慮到技術層面,自己申請Server架設Wiki軟體這個選項就不用提了!一般玩家沒那個技術啦!)

Gamerch

Gamerch 是日本很流行的Wiki站,眾多遊戲都用這家相信大家都很熟(X),在此先略過不提。

Mediawiki

知名的 Wikia.com (Fandom) 就是 Mediawiki engine ,所以我研究了Wikia的說明文件,發現他不開放資料庫類型的套件,所以Wikia其實沒有卡片資料庫系統。

有其他方法可以實現類資料庫系統,但使用門檻高,後述。

Wikidot

Wikidot 也是知名的 Wikifarm ,我摸了幾天的感想是他真的滿方便的,已經不只是Wiki,根本可以當成架站服務,而且 Data Form 很好很強大,但他最大的問題(對於中日韓語系使用者來說)是: url 不能有英數之外的字(就連slash也會自動轉hyphen),這代表,頁面互連不能使用 [[頁面名稱]] 這類方便的標記。不過可以用拼音應對,應該還算好解決,只是稍嫌麻煩。

Pukiwiki

Pukiwiki 是日本最流行的 wiki engine ,有很多日本的wikifarm是based on pukiwiki,實際上它的確滿好用的,而tracker功能我測試過,的確可以辦到方便的資料呼叫、排序。不過,有幾個麻煩的問題:

1. 設定很不親切,要有人先跟code奮鬥測試並設定好
2. 設定好了,也可能後續修改導致版面跑掉
3. 造成上述問題的原因是:沒有一個比較完善的說明文件,導致必須自己不斷試誤……

我最深刻有感的是,測試的時候做出來的 tracker_list 表格居然版面整個跑掉,辦不到排序功能先不提,整個表格支離破碎……然後我try了半天終於發現,設定的 config/plugin/tracker/list 的表格下面不可以有空行,有的話表格的每一列(tr)就不會合併起來,而是每一列獨立成一個表格,當然就無法排序……發現這點時我整個人哭笑不得(。)

官方說明文件太少,我又不太熟要哪裡找不知道到底是否存在的日文教學文件,覺得心好累。
(Wikidot的data form也需要自己設定好變數,但是他說明很完整,照著做一次OK!)

(根據官方Q&A,官方也不確定同一個tracker能不能負擔數千筆資料(數量太大反應會變慢),雖然手遊的話一千筆應該是足夠啦……)

清單裡列出的使用 pukiwiki engine 的 wikifarm 有這些:

  • Wicurio.com
  • WIKIWIKI.jp
  • sWIKI.jp
  • CSwiki.jp
  • WikiHouse.com
  • Gamedb.info

我有申請帳號測試 tracker 功能的是 wicurio.com 跟 wikiwiki.jp ,選這兩家是比較了各自的範例及說明之後決定的,此處先不提。

綜合以上,要開始申請Wiki之前首先要先確定這件事:

「是否需要類似資料庫的 tracker / data form ?」

可以先想想,如果不使用資料庫,編輯的麻煩程度。例如如果筆數不多(我的標準是100筆以內)或是每一筆資料不太需要互相比較的話,純手動更新也不是太麻煩。

但是如果資料量很大,那麼從前面提到的那些站下手比較好。

接著是其他要考慮的條件。

編輯器親切度

要編輯這個Wiki的成員,如果都是對標記語言不熟悉的人,那親切易懂的編輯介面就非常重要!個人覺得編輯介面親切的站:

  • Wikia
  • Wikidot
  • @Wiki
  • Wiki3
  • FC2
  • Seesaa Wiki

(沒有pukiwiki。)

對中文的支持度

特別提出這一點,是我用了 WIKIWIKI.jp 測試才發現的:這家的網頁雖然是 utf-8 ,但是它的編輯器中,非日文的字都會存成「字元參照」,就是以前大家申請日文blog的時候會出現的看似亂碼的東西,送出後在網頁顯示是正確的,只是編輯器裡面是 「Ӓ」 這樣的內容。既然顯示是正確的那其實也沒關係啦,就是,看了不順眼。(卡片的「卡」是手遊很常用到的字,不能正常顯示……)

  • wikiwiki.jp 編輯器裡的非日文漢字會被存成字元參照
  • Seesaa Wiki 的編碼不是 UTF-8 ,是 EUC-JP
  • FC2 Wiki 有奇妙的「PC版網頁是 utf-8 但是手機版自動換成 shift_jis 」這奇妙操作,導致手機瀏覽可能會有亂碼,真的很不解WHY要這樣

總之文字量大的話就不用考慮這三家了,但是假如編寫內容的中文少、以日文為主的話,這三家有各自的優點可以考慮。

是否開放自訂CSS

不是單純有樣式供更換,而是可以完全自訂。特別提出這一點也是因為……總之就是有需要。

目前我試過沒開放的: WIKIWIKI.jp

手機網頁

現在手機瀏覽比PC重要捏!尤其要做手遊Wiki的話可以肯定手機瀏覽大於電腦!

現在手機網頁版有兩種模式:

1. Responsive Layout (響應式版面設計)
2. 偵測瀏覽器切換電腦/手機版面

前面提到的Wiki站幾乎全部都是偵測瀏覽器切換的。

Responsive 的有這些:

  • @Wiki 有兩種
  • Wicurio 有兩種
  • Wikidot 有幾種
  • Wikia

但就算是手機版,有些瀏覽起來的感覺還是不太優…

我個人喜歡的是: @Wiki、Wiki3、Wicurio、Wikidot

(啊對,最前面貼的清單裡,我用手機一看沒有手機版的Wiki站就都直接被我無視惹。)

https

其實有在維護更新的站都有逐漸轉成https,畢竟安全性還是很重要的。(沒有https的站也直接被我忽略惹。)

Pukiwiki base 的那六個當中只有 wicurio.com 跟 wikiwiki.jp 是 https (就是我有申請測試的主因)。

營運穩定活躍度

不知道該下什麼標題,我是指「這個Wiki站有多少人使用」的意思。最前面的清單有些一進去就一股「空空如也」的空城之感,我就直接關掉了!

(我用 wikiwiki 測試時,它主站首頁有「最近更新」,我就一直覺得可以不要在首頁顯示我嗎…但也因此我才知道這個站滿多人的,首頁刷新很快。)

總之如果擔心「穩定性」建議還是選那幾間看起來不會倒的。

是否可以私人使用

就是可以完全私人的站,只讓幾位成員觀看並編輯

  • FC2 Wiki (進站密碼制)
  • Wicurio (成員制)
  • Wikidot (成員制)
  • Seesaa Wiki (成員制)
  • @Wiki (成員制,除了首頁、Menu必須開放)

是否可以使用 javascript

(待整理)

個人總結推薦

整體而言我會推薦的是這三家:

  • @Wiki : 功能最多,編輯方便(但網頁本身size比較大,廣告多)
  • Wiki3 : 有WYSIWYG的編輯器,版面簡潔(但相對的其他功能偏少)
  • Wicurio : 要用pukiwiki的話我喜歡這家

如果需要全私人,會推 FC2 只要一個密碼(就包容一下手機版的亂碼問題)

跟日文不熟,想要英文環境的就是 Wikidot 了不用考慮!

介面中文化最完整的是 wikia ,也可以試試看!

附錄:各Wiki站的印象

https://www.wikidot.com/
  • 功能好多好強, Data Form 好方便喔?!就是網址不能用非英數很傷……
  • 申請新開的站沒有https
https://atwiki.jp/
  • 網域卡一個伺服器編號,頁面網址採用數字編號/page/數字.html ,總之強迫症會看得很癢
  • 特殊plugin超級多,有 #table_edit 跟 #table_sorter 非常好用
  • 沒有誤刪頁面回復功能(OMG)
  • responsive的template有兩款,選擇其他樣式使用手機時有手機版(但是中小型平板沒有)。覺得這家的responsive做得最好,小手機也沒遇到左右捲軸(除了因為手動設圖片width設太大)
https://wiki3.jp/
  • 整體跟atwiki很接近(從atwiki改的?),頁面網址也是/page/數字,有幫你拔掉「 .html 」
  • WYSIWYG介面很方便,畫面也很乾淨,如果討厭自己寫語法就推薦這家
  • 每page都有預設留言板,爬文發現不能關掉,只能用眼不見為淨的方法整個 display:none
  • html結構很乾淨,plugin也很乾淨
  • 沒有 #table_edit
  • 超大型表格在手機上的預設顯示不ok,有自訂css可以改。
  • 經過各種測試,embed tweet 必須用WYSIWSG模式,一次paste一個link
  • 可以設為非公開,但是非公開就什麼事都不能做,相當於關站
https://www.wicurio.com/
  • 這家有特別強大的 #table_edit2 ,跟表格資料參照功能,如果你的站會有巨大資料的表格,推薦這家。
  • 整體來說 pukiwiki base 的 wikifarm 中最推薦,版面好看,有responsive的手機版樣式,可以自訂css
  • 它的官方首頁沒有「最近更新的Wiki」不用擔心自己的站掛在首頁
  • #table_edit 跟 #tablesort 不能同時運作,好像會有問題
  • 大表格會出界,有自訂css可以改
  • 可以全站設為私人
  • 這家的 #region 是點開才開始讀取內收的內容,很優秀!
https://wiki.fc2.com/
  • 大家熟悉的老牌服務,要不是他有奇妙的「PC版是utf-8,但是手機版自動換成shift_jis」這奇妙操作……不然也很推薦。
  • 如果你的站不需要複雜的功能,而且幾乎都用日文,剛好已有FC2ID,也是可以考慮這家。
  • 可以全站設私人(進站密碼制)
  • 介面簡單好懂好操作,適合簡單的資料or文章站
  • 沒有tablesort,沒有tableedit,沒有內建插入tweet
  • 我用iPad mini2打開上傳圖片介面無反應…
  • template選擇很少,但是css結構清楚非常好讀(不愧是…)
  • 沒有responsive的template,內建手機版堪用但是有上述的奇妙問題。
  • 不管是 #region 還是 #openclose 的結構都很乾淨
  • 不能用unicode表符!!!!(重要)
https://wikiwiki.jp/
  • 編輯區的非日文漢字會被存成字元參照符引用(日站的老問題……顯示上沒問題)
  • embed tweet非常方便,如果需求只是twitter matome中文字不多,而且只有自己要編輯,網路又沒被擋的話,這家可以考慮。(日本以外的網路普遍被擋,只有花店ok,其他電信的4G都被擋)
  • 不能自訂css
  • 手機版的廣告會超出寬度所以滑起來不太順
  • 有table_edit
  • 預設禁止日本海外投稿,需要手動解除規制,但是解除了還是常常被擋…(系統可能資訊不足,台灣的IP資料不夠多)
  • #tracker_plus
  • 不能設為私人隱藏
http://seesaawiki.jp/
  • 網頁編碼是EUC-JP,基本上就不適合中文站
  • 但是介面很順,表格優秀,也有很方便embed tweet的語法,如果預計不使用中文的話還是可以考慮啦…
  • 有其他種類的網域可以選(限公開wiki)(可以設為私人隱藏)
  • 相對較多的template可以選
  • 有每page下方的留言區,也有一塊揭示板

end

最後必須說,要確定建wiki站的目的是什麼。wiki就是要開放給不特定多數人一起編輯的。

如果是個人要簡單架站,那就沒有做wiki的必要,可以申請blog、Tumblr,或簡易建站工具(weebly、wix之類)。如果要幾個朋友一起共筆,可以申請blog共用帳號或是設定共同作者。

另外,如果不是共筆,要做資料整理還有其他各種服務。例如:

  • 要做連結收集,有matome站,有bookmark站可以用。
  • 要存圖片資料,有圖片空間,有線上相簿。

確定要做Wiki形式,也務必要規劃好架構跟內容(有其他人一起做的話要討論完備喔)不然真的……累!

最後記得至少要找一個懂CSS的人,不然……很不方便(。

在 fandom (wikia) 使用類資料庫

以下引述路人丙大大於此篇blog留言之內容:

wikia(fandom)的類資料庫系統必須用LUA實做

不好意思內容有點多需要時間整理一下(找藉口),還請容我長篇大論一下,也給日後不小心手滑(?)點進來的人做為參考。

先來個前提:

目前大多數wikia中文遊戲站台的架構是來自於zh.pad.wikia.com,當時接手的某遊戲(神○控)也是。
(可參考這篇文章
zh.community.wikia.com

PAD的基本架構是:資料模版→各種顯示用(含數據處理)模版→呼叫用模版
(還是要把箭頭反過來?算了看得懂就好。)

這種做法在單一資料頁面當然沒問題,但問題是清單列表和條件篩選呢?很難搞啊~(就是您一開始提到的)
1.資料分散在各個頁面,沒辦法一次全部叫出來
2.就算能把他一次叫出來(下述),wikitext也沒辦法處理太大量的數據

一般的解法是這樣:
1.不管了,複製貼上硬幹
 大多數站台的作法,神○之塔(zh.tos)也是這種作法
2.另外建一個列表(行話叫索引),以後有需要就直接呼叫這個清單來決定要叫哪些資料出來
 如白貓(zh.shironekoproject)的角色圖鑑(索引檔是Template:角色陣列)
3.一開始就直接做成單一資料檔,後面用JavaScript處理
 如黑貓(zh.nekowiz)的題庫搜尋器(但是他們沒作列表,因為這是拿來作弊用的不需要全部列出)
4.我也曾經試過做成單一資料檔的方式,但光是要把資料陣列(3000*20的樣子,忘了)倒出來就已經炸了,更別說還要再做其它處理
 (也不過才3000筆資料而已啊~真不耐命~╮(╯_╰)╭)

大多數遊戲類站台都不會有詳細的數值列表
除非是完全不使用模版的複製貼上,不然要列出數值列表是非常消耗資源的,資料稍微多一點就直接炸了,例如:
1.○魔之塔的寵物圖鑑(寵物圖鑒001-050)就直接炸給你看了,這一頁才50個而已啊啊啊啊啊啊
2.艦娘(zh.kancolle)的艦娘性能表稍微好一點,但才399隻船就快爆了
3.白貓的一般限定角色總覽,只有大頭就已經在爆炸邊緣
主因就是如上面哆啦王所提到的套嵌過多模版造成巨大的資源消耗。
(各頁面的資源耗用可右鍵→檢視原始碼→搜尋NewPP段落)

所以篩選器呢?
嗯~通常是用JS解決:
1.放在表格的標題欄
 如艦娘的艦娘性能表,但因為不是每個人都會想到標題欄可以點,所以這種做法比較不直覺就是了。
2.上面另外開一區開關
 如白貓的角色搜尋器,簡單明瞭。

===莫名其妙的分隔線===

回到正題,當初就是因為○女控資料量有點大,照原本的方式(wikitext)根本無法處理這麼龐大的表格,而且還有其他問題要處理(卡片進化的數值計算,你知道的),所以必須找個方法解決,資訊人(我)的解法就是資料庫、資料庫和資料庫啊~

但用某個會中箭的地方想也知道:官方不可能會開資料庫讓你用的啦~
所以您說的沒錯,wikia沒有卡片資料庫系統,真的沒有。

但是幸好wikia也跟隨維基百科開始提供LUA擴展,所以就把腦筋動到上面。當然一開始也是不太順利(文長恕刪,就是您提到的說明文件問題),不過最後還是搞定了。

程式語言通常會有個東西叫陣列(array),很可惜的是LUA沒有陣列這種東西,但是有個類似的東西叫表(table)。
我的做法就是把資料做成table,讓之後所有有需要的頁面運用,有點類似JSON的玩法這樣,或是你可以把他想成是資料庫中的資料表。

底下用比較單純的C*SS來說明
主要的幾個資料檔:module:card.data(卡片)、module:skill.data(技能)、module:chara.data(角色)、module:music.data(歌曲)
兩個輸出用模組:module:info(單一的資料頁)、module:list(各種清單)

以我什麼都沒有的某人的個人頁面為例:
最上面右邊的個人資料是chara.data,左邊大頭照是由card.data載入所有卯○的卡片之後隨機抽取一張。
底下兩個列表是用list讀取對應的資料檔之後篩選輸出。(所以不會跑出沒有○月的資料)
卡片或歌曲的資料頁也是類似的做法,只是更加單純。(就是讀出對應的資料而已,沒有篩選的動作)

至於各種列表應該不用多做說明,就是資料讀進來再這樣那樣之後就可以輸出了。(喂)
嗯?動態篩選器?啊我懶得做啊~(逃)
(排序是系統本身就有的功能)

這種類資料庫的好處:
1.只要更新少數幾個檔就行了,省事1。(部分遊戲可以直接抽出數據檔來轉檔,像是CG*S)
2.資料檔更新後所有相關頁面會自動更新,省事2。(同上,而且也不用怕營運偷偷改了哪張卡,我承認這是為了偷懶XD)
3.無須另外維護索引檔,不用怕東漏西漏。(資料檔裡面有就是有,沒有就是沒有)
當然新頁(新卡、新裝備等)還是得手動開啦,這點每個站都一樣。
不過也是有用LUA做,但仍然把資料單獨放置的,像是艦娘英文站(kancolle.wikia.com),所以他們的性能列表依舊是人工編輯而不是自動產生。
LUA門檻是比較高,但是高效好用,可以做到很多wikitext做不到的事,只要你會寫程式的話。

LUA的資料檔一般來說會有兩種樣子:
1.就是一堆亂七八糟(X)、眼花撩亂(O)的數字,像上面那三個
 啊就直接複製貼上啊~咬我啊~
 用excel之類的做成資料表再貼回去也是可以的
2.像music.data那樣(人)比較好讀的
 嗯~稍微人性一點~不過這是好幾張表彙整出來的
 (live_data、live_detail、music_data等)

當然不管哪一種,多人協作的話當然就是事先約定好什麼欄位是什麼東西,然後寫一份規格書或教學文件讓大家照著作。
只有一個人的話就‧‧‧啊~隨便啦~

底下用看起來比較人性化的汁波蜜來解說:


[1021] = {'つ○み',7,4,

['DEBUT'] = {8,11,71000,183,42,10,97000,109},

['REGULAR'] = {14,14,91000,349,49,16,140000,166},

['PRO'] = {18,16,140000,667,53,22,240000,325},

['MASTER'] = {26,19,190000,792,63,27,440000,440},

['info'] = 'THE IDOLM@STER CINDERELLA GIRLS for BEST5!\n\n塩見周子(CV:ルゥ ティン)\n前川みく(CV:高森奈津美)\n高垣楓(CV:早見沙織)\n相葉夕美(CV:木村珠莉)\n一ノ瀬志希(CV:藍原ことみ)\n\n\n作詞:桜アス恵\n作曲・編曲:滝澤俊輔(TRYTONELABO)',

['vocalist'] = {220,127,197,263,126},

['youtube'] = 'kSp6SqZ-8QY',

['goods'] = 'COCC-17056.html',

},

轉成範例的話:
(註:資料分行是為了方便人看,對機器來說分不分行都是一樣的。)


[樂曲ID] = {

'樂曲名',

排序用號碼, --就是單純排序用,沒有對應到其它東西

type, --cu/co/pa/all

['DEBUT'] = {歌曲等級,消耗體力,目標能力值,金錢,經驗值,親密度,S RANK分數,note數},

['REGULAR'] = {同上},

['PRO'] = {同上},

['MASTER'] = {同上},

['info'] = '樂曲情報',

['vocalist'] = {id1,id2,id3, ... ,id999}, --好像沒這麼多人

['youtube'] = '水管ID',

['goods'] = '商品頁',

},

原則上就是像這樣貼出範例請他們照著填,然後請他們貼到資料表的尾端。
如果怕有人貼錯的話,也可以在資料表中加空行把每一筆資料的界線明確化

因為是用ID調資料,所以不用管他在哪個位置。列表的話是一次全部載入再做處理,所以也不用管。
唯一要確保的就是資料格式要正確,位置只會影響載入順序(ID重複時以最後載入的為準)。

修改現存資料的話就是
1.全部複製到筆記本(或其它文字編輯器)
2.Crtl+F ID
3.要改的改一改
4.全部貼回去
5.如果是類似CSV的形式那就試算表改好直接整個貼回去就好
上面的例子直接對照該曲的情報頁看來的話,大部分應該不用解釋,比較會有問題的就是您提到的代碼轉換的部分

至於要怎麼讓人知道哪個號碼是誰,就是另外提供一個對照表供人查閱
(事實上我也不會去記那麼多東西,要用再查就好了。)

當然用ID的好處就是日後有需要的話只要改角色資料檔就行了,不過應該不會有人改夫姓才是。(老婆是大家的,一起用啊~)

萬一沒辦法抽資料怎麼辦?那就只好自己設計囉~
好學園就是完全自己來的東西,裡面能弄到的就是各種ID而已。
這時候就是看自己方便啦(基本上還是以易懂易維護為原則),用武器為例的話:


[8141001] = {'神器リコリスα','神器彼岸花α',4,267,486,['rtm']={0,0,1},17071901,

['make']={250000,{8140001,1},{'wm4302',10},{'wm2821',20}},

['next']={8142001},

['main']={{'蓄:變(炎)'},{'給傷',7},{'連傷',6}},

['sub']={{'連傷',2},{'受傷',-2}},

},

rtm是三種音節的比例,之後會自動換算成百分比圖形化顯示。
進化材料(make)部分,因為除特殊品之外就固定那幾種,而且ID有固定的編碼規則,所以就直接用ID這樣可以少打幾個字
附加性能(main、sub)部分因為用數字ID比較不直覺,所以用縮寫的方式,當然一樣只要確定沒有會重複的縮寫(唯一性)就行了。
next(下一階段)是用來串進化樹用的,這是wikitext做不出來的東西(應該),這裡先不談。
因為姆咪比較複雜難懂,所以就先各種跳過,大概就是這樣。

參考用的站點:
https://battlegirl.fandom.com/zh/
https://cgss.fandom.com/zh/

我本來想補充一些東西的不過懶了還是改天再說……話說這篇幅一半都不是我寫的欸這樣可以嗎