霧中風景

在歐美國家，雖然宅人口不比日本，但是宅人達力卻也跟日本不分軒輊，Ren’Py 這個開發已久的 AVG 引擎就是歐美人士開發的。它的製作人最近在網路上寫了篇有關於可下載 vs 網路遊玩的遊戲的文章，讀了以後才發現，最近因為 AJAX 技術的進步，所以歐美出現了好多新的日式文字冒險遊戲網路平台。在這些平台上，無論是創作者要撰寫故事，或者玩家要體驗遊戲，都是透過網頁遊覽器來完成。

將網頁作為遊戲的平台有許多好處，比如說：

1. 有收費機制的平台可以有效阻礙盜版。
2. 多人編輯與合作可透過網路完成，減少難度。
3. 因為只需要上網就能玩，再一步縮短與一般大眾的距離，增加淺在客群。

不過 Ren’Py 的製作人認為，網路遊戲平台的缺點也不少：

1. 無法下載所以無法備份，要是平台垮了，那麼這些創作就從此消失。
2. 除非平台很佛心有開放原始碼，不然在未來，也不能經由模擬器等方式讓遊戲能繼續可玩。

不過這些問題也是有些解決之道，比如說開放讓創作者下載備份檔，以及額外開發備份檔的單機播放程式。不過就算是解決了這些問題，最主要的還是在於玩家們的意願。有個創作者 Ayu 舉辦了一個網路投票，結果是絕大多數的人還是比較喜歡能下載的單機板遊戲。也許是因為有個可以保存的實體才讓我們有值得花錢的感覺吧。

在我看來，NovelStream 是裡面最成熟的一個平台，不但外觀好看又專業，而且腳本編輯器也比一般的 AVG 引擎還要友善好多，更別說是許多其他的功能（遊戲腳本版本控制、語音與讀檔功能、友善的討論社群環境）。而 vNovel Interactive 雖然目前只是展示用，但是其遊戲體驗也因流暢的圖片轉換還有語音給我很大的好感。

BASS則是讓我有些遺憾，因為這個平台算是最早出現的（三年前就有了），而且還是台灣人開發的，可惜介面沒有繼續發展，而使用客群也沒有複雜化。

這些平台都不是日本人開發的，也許網路這一塊還是日本海外發展的比較蓬勃。我比較推薦的兩個遊戲，一款是 Narcissu ，是幾年前有名的免費同人電子小說。第二個則是 Ripples，一款英文同人團體製作並配音的電子小說。兩者的完成度都很高，效果也不輸給 Flash。也許這些平台真的是未來同人遊戲的一種可能性。

今敏的遺書（譯文，謝謝網友翻譯）

看到新聞，讓我簡直不敢相信自己的眼睛。自從看了 Paprika 的首映以後過了這麼久嗎？最近看了 Inception 後還有比較一下，這麼突然就離開了，讓我十分錯楞。

無論是「千年女優」中戲與人生的對照與互相交叉的完美分鏡，「東京教父」中巧合、命運與幽默的串連，「妄想代理人」中對現代社會中的問題探討，最後還有「盜夢偵探」中夢的探討，夢想的意義等等問題，都是日本動畫界中獨特閃亮的一點。他的分鏡獨特，而且題材新彾且探討的主題比較深，但是說故事的方式是一流的通俗。（舉例來說，富野的 Z Gundam 電影的說故事方式就不大主流。）今敏導演才46歲，實在是英才早逝。他的遺書深深地表達了他對於身邊的人的謝意，自己的堅持，身為藝術家那股自信以及沒能完成作品「做夢機器」的遺憾。

在此紀念這位偉大的導演。

Paprika 盜夢偵探 紅辣椒 | 霧中風景
Tokyo Godfathers 東京教父 | 霧中風景

看著下載資料夾裡的檔案漸漸增加，但是他們的檔名格式又參差不齊，你是否有種衝動想要找天好好把它們分門歸類，但是又覺得寸金難買吋光陰。又或者你辛苦的整理了，最後卻有著浪費時間的空虛感？請試試看這款檔名整理器，本軟體希望能幫助大家省下一半的整理時間。

本軟體的主要功能是整理資料夾與壓縮檔的檔名，而不是為同一套檔案更名編號，這是跟其他更名軟體不一樣的地方。

下載 UniformRenamer（0825更新：提高程式效率）

使用教學

本軟體的使用步驟如下：

1. 編寫重新命名的方法（上半邊視窗），或者下載別人的來用。
2. 選擇要批次大量重新命名的資料夾（下半邊視窗）。
3. 按按鈕預覽新的命名。
4. 選擇要修改的檔案後，按「更改選取檔案名稱」批次一起命名。

建立更名規則

更名規則是一連串更改檔名的步驟。檔名整理器依順序執行每個步驟後，就能把舊檔名轉換成新檔名。

舊檔名 –> 步驟1 刪除XXX –> 步驟2 替換 XXX –> 步驟3 複製 XXX –> 新檔名

更名規則的第一行是命名格式，也就是新檔名的格式。在執行步驟的時候，舊檔名的資訊就會轉移到新檔名上。
更名規則的第二行以後每一行都是一個步驟。步驟有三種：刪除、替換以及複製。

範例

在這個範例中，我要把以下左邊的檔名轉換成右邊的檔名。

(一般コミック) (漢化) [田中太郎] 世界末日 第01巻  –> [田中太郎] 世界末日 – 1 [中]

要套用的更名如下

<剩餘檔名> - <集數> <中文>
delete	(一般コミック)
replace	<中文>	[中]	(繁體)	[漢化]
copy	<集數>	* 第0?(\d*)巻
copy	<剩餘檔名>	* (.*)

第一行是新檔名格式。你會發現這裡面的項目對應到之後的步驟，比如說<中文>就對應到第三行。
這些步驟會把資料從舊檔名轉移到新檔名中對應到的位置。

有了新檔名格式後，就要分別指定各個步驟。以下是三種步驟的的用途及欄位說明，欄位與欄位要有 tab 作分隔。

規則表的第二行是「刪除」，能把不要的文字從舊檔名刪除，讓檔名更好處理。欄位說明如下：

可以在 delete 步驟中設定數個要刪除的文字，只要用 tab 分隔即可。

規則表的第三行是「替代」，欄位說明如下：

範例中的這項規則能夠偵測有沒有「(漢化)」這個字樣，如果有的話，代表這檔案是中文的。於是「[中]」就會被放在新檔名格式中「<chinese>」的位置。

規則表的第四行是「複製」，通常搭配正規式（regular expression）來搜尋文字。欄位說明如下：

範例中，我想要搜尋漫畫的集數，但是不想要原本檔名中一些累贅的字（第、0、巻）。
在這個例子中，我只想要 0 後面的數字，所以就用 (\d*) 把該數字抓出來，放在新檔名格式中「<集數>」的位置。
在本軟體中，正規式的前面要加上 "* "，以便與一般文字作區隔。
之前的刪除與替代中的搜尋目標也能使用正規式。

最後一行也是個複製規則，把所有剩下來的東西放進新檔名格式中「<剩餘檔名>」的位置。在正規式中，
「(.*)」即是代表選取全部的字元（即是剩下來的舊檔名）。

相信透過這三種規則的組合，以及正規式的威力，就能夠做出你想要的各種檔名，節省手動更名的時間。

以下是目前我的規則檔，各位可以複製貼上試試看。

<reg_remain><reg_vol><reg_vol2> <chinese><english>
delete	[comic]	[Comic]	[漫畫]
delete	(一般コミック)
delete	[PNG]
delete	* \[全.冊\]	* \(全\d*集\)
delete	* \[\d*p\]	* \(全\d*集\)

replace	<chinese>	[C]	* (\[中.\])	(繁體)	[BIG5]
replace	<english>	[E]	(英)

copy	<reg_vol>	* 第0?(\d*)巻
copy	<reg_vol2>	* \[?[Vv]ol.0?(\d*)\]?
copy	<reg_delete>	* \[\d*p\]

copy	<reg_remain>	* (.*)

結尾

本程式目前沒有經過嚴密測試，如有出錯請多多包涵，謝謝使用也請多多提供意見，不管是說明檔（我覺得這份就寫得很爛），規則的建立方法，甚至你想要更改程式（還蠻想試試看多人的Open Source的感覺）等等都行。

謝謝大家提供的名字，最後我決定使用 Uniform Renamer 這個很保守的名字 :)

目前我想不出好的程式名稱，所以在此徵求程式命名。目前募集到的名字有：

• Re2
• Magic Renamer
• Renamer Renamer
• Renamer Zombie
• iRenamer
• Renaman
• Chat Renamer
• Standardize Renamer
• Unify Renamer / uRenamer
• Reg Renamer
• AutoChange ComicNamer

剩下

原本打算每幾集就寫篇簡短的感受的，不過因為種種關係只好留到現在一次看完。劇情輕鬆流暢，完全捨去能成為單元劇的元素（描述每個人怎樣滿足離去的），直接切入最後結局。而笑點也很恰當的穿插在劇情中。最後安排的畢業典禮我十分喜歡，把離別的悲傷加成不少。雖然最後的結局有些令人驚愕，而且設定也不是十分完善，但是就娛樂度而言，有動作有音樂有笑點真的很棒，是款值得推薦的佳作。

總分：4（頗有新意的佳作）
劇情：4.5（在大方向上及重要場面表現很恰當，而一般生活的笑點也不缺）
畫面：4.5（上色精美，動作場面的動感以及特效也十足）
音樂：4.5（搭稱情景）

在這一篇文章 Falsehoods Programmers Believe About Names: MicroISV on a Shoestring 提到了程式設計師對於名字所保持的錯誤認知，我覺得很有趣，簡單的翻譯了各點。這張清單有些玩笑，也有些項目是使用西歐語系的人們才會有的問題。

1. 每個人都只有一個正式的名字
2. 每個人都只使用一個名字
3. 每個人，在這個時間點，只有一個正式的名字
4. 每個人，在這個時間點，只有使用一個名字
5. 每個人有正好 N 個名字（N可以是任何數量）
6. 每個人的名字都能放進某個訂定數量的空位中
7. 每個人的名字都不會改變
8. 每個人的名字雖然會變，但是只會在特別的一些時候時會變。
9. 每個人的名字都是用 ASCII 編碼寫的。
10. 每個人的名字都是只由一個編碼寫的。
11. 每個人的名字都能對應到 Unicode 字元
12. 人名是有區分（英文）大小寫。
13. 人名沒有區分（英文）大小寫。
14. 有些人的名字有前綴或後綴，但是你能夠安全地忽略這些。
15. 人名不會含有數目字
16. 人名不會全都是（英文）大寫
17. 人名不會全都是（英文）小寫
18. 人名可以排序。所有系統只要使用一樣的排序方法排同批名字，就會得到相同的排序結果。
19. 每個人的姓跟名必須是不同的。
20. 每個人與親戚都使用一樣姓氏。
21. 每個人的人名都是獨一無二的。
22. 每個人的人名幾乎都是獨一無二的。
23. 好吧但是人名應該夠多元，所以不會有百萬個人同用一個名字。
24. 我的系統永遠不用管中國來的名字。
25. 或者是日本名字。
26. 或是韓國名字。
27. 或者是愛爾蘭，英國，美國，西班牙，墨西哥，巴西，秘魯，俄國，瑞典，波札那，南非，千里達，海地，法國，或者是克林貢帝國。這些都有常見卻奇特的命名方式。
28. 那個克林貢帝國只是個玩笑對吧？
29. 你那該死的文化相對論！在我的社會中，人們至少同意了一套名命標準。
30. 世界上有個能夠無損地把名字轉換後再反轉回來的演算法。（對，只要你的演算法能傳回輸入值。你得一顆星星。）
31. 我可以安全地假設這本髒話字典中不包涵任何人的名字。
32. 每個人的名字都是出生時拿到的。
33. OK，也許不是出生時，但至少很接近出生時。
34. 好啦，好啦，在出生後一年內。
35. 五年內？
36. 你在開玩笑，對吧？
37. 當兩個不同的系統有同一人的資料時，會用這個人的同一個名字。
38. 在一個設計優良的系統中，兩個不同的資料輸入端拿到一個人的名字時，一定會輸入在位元上都相同的字串。
39. 那些名字能把我系統弄壞的人是奇怪的異類。他們應該有個像是「田中太郎」一樣可接受的名字。（譯註：這是在英文句子裡插入日文的常用名字，反而變得不常用）
40. 每個人都有名字。

之後的回應還加了幾條：

• 人名不會含有標點符號
• 人名不會含有除了單引號外的標點符號
• 每個人在不同國家的名字都一樣
• 每個人只能有一個社會地位稱謂（在德國，有兩個學位的人會用兩個 Dr 表示）
• 每個人都有姓跟名
• 名字一定有兩個字母以上

還有一些奇怪名字的人

• Nicholas If-Jesus-Christ-Had-Not-Died-For-Thee-Thou-Hadst-Been-Damned Barbon（奇特的宗教性質中間名）
• 那個原本叫做 Prince 的人（原本叫做 Prince 的知名音樂家，自己後來改名為一個不能發音的符號，導致大家開始這樣稱呼他）
• Nǃxau 演上帝也瘋狂的主角
• Ángel Agustín María Carlos Fausto Mariano Alfonso del Sagrado Corazón de Jesús Lara y Aguirre del Pino
• Standing beside the road waiting for a bus

在 Slashdot 上的討論中，有幾個人提到了解決的方法：不要把名字特別區分為姓跟名分開來儲存，而是讓使用者直接輸入完整的姓名，存在一個 Unicode 的文字欄位中。此外也提供另一個文字欄位，讓使用者輸入他的日常生活常用名。而系統可以在法律需要時使用完整姓名，而在一般問候時使用常用名稱。

雖然這張清單有很多都是極端的例子，不過我覺得最重要的，還是「人名不會含有除了單引號外的標點符號」這條。有像是 O’Raily 之類名字的人，常常會因為 SQL injection 的因故，而不能在網站上使用自己正確的名字。程式設計師在處理姓名時，還是應該使用正確的方式好好處理標點符號，而不是直接把他們拒絕掉。

這幾天，我一直在嘗試著寫一個簡單的程式，能夠在解壓縮 7Zip 中的 BMP 時順便將之轉成 JPG。在記憶體中作轉換可以有效節省硬碟讀取次數跟所需的硬碟空間。在各種嘗試下的抵達了終點，可是才發現有個很重要的問題無法解決，所有心血算是白費了。

我首先是想直接修改 7Zip 本身，不過自己身為 C++ 的新手，實在無法瞭解要怎樣才能修改。而想嘗試使用 7z.dll ，卻無法理解 dll 要怎樣使用。最後連 LZMA 的 source 都看過了，還是覺得霧煞煞。幸好偶然發現有個叫做 C# (.NET) Interface for 7-Zip Archive DLLs ，之後更發現了繼承其精神的 SevenZipSharp ，讓工程大有突破。

在研究 SevenZipSharp 以後，我決定還是使用 C# 來當開發的工具。C#就像是 Java ，提供了很完整的資料庫，開發小型的圖形化程式十分方便。終於，克服了重重 bugs ，終於開發出了能夠解壓縮 bmp 又順便轉換成 jpg 的程式。

可惜的是，當我測試某個有 1000 張 bmp 的 7z 檔案時，發現解壓縮需要好幾個小時。這才發現，原來我使用的這個 ExtractFile 函式，因為一次只會解壓縮一個檔案，而因為 7Z 是種 solid 壓縮檔，所以解壓縮一個檔案就必須把這個檔案之前的所有檔案都算一遍。原本解壓縮時 7Zip 有最佳化，會依序解壓縮並保持計算過的進度，所以時間上不會很緩慢，但是這個 SevenZipSharp 的 API 沒有作到這麼完善，等於說解壓縮這個測試檔就要花 500 倍的時間。而要修改 API 本身對我來說還是太困難，所以自己的心血算是白費了。

唉，實在是山窮水盡疑無路，目前的柳暗花明又一村還遙遙無期。