可以 Release 了。
Posts tagged with bbs2html
我本來以為今天會沒有進度，沒想到今天就完成了 XD
昨天晚上其實有成功的將 .DIR 讀出來，我用回 TextReader ，一個字元、一個字元的讀取，當讀到 \x0 時，就替換成空白，這時我還以為是 string 中不能有 \x0 字元。今天我實際測試才發現不是 string 中不能有 \x0 ，而是「畫面顯示」到這裡就會停止，所以 EmEditor 開啟這些含 \x0 檔案時會先詢問是否要把 00H 替換成空白，不然它就打不開了，如果我直接將 string 儲存成檔案， \x0 甚至還會忠實的儲存。
因此今天的第一個步驟是想辦法正確的區分項目與項目， .DIR 檔案中只有一行字串，每 256 bytes 為一個項目，之間沒有可用的分隔字元。但是 TextReader 沒辦法依照 byte 讀取，它是以字元或行為單位，我試著自己計算 byte 試了很久才想到，用 BinaryReader 不就好了…… orz
改用 BinaryReader 後進度就很快，順利的寫完了 .DIR 轉換 HTML 的部份。最後將 .DIR 轉換 HTML 改成遞迴，再整合之前寫好的 UAO 轉換和 ANSI 色碼轉換， bbs2html 終於大功告成！1
本程式相較於 bbs2hh 的優點：
- 連加密文都會轉出來，既然原始檔都有了，轉換又何須略過。
所以… 當你看到哪個板的精華區有加密的… 就可以把它的備份下載回來讀…沒板主權限是不能打包的啦～ - 支援底線、閃爍（Firefox only）及反相色碼。
- 正確轉換 Unicode 補完計畫中的新增字，以 UTF-8 儲存。2
今天再驗算了一次 UAO 字碼表，發現有幾組 Big5 碼轉成 Unicode 後會變成同一個，表列如下：
- A27E、F9FA 都會被轉換成 ╭
- A2A1、F9FB 都會被轉換成 ╮
- A2A2、F9FC 都會被轉換成╰
- A2A3、F9FD 都會被轉換成 ╯
- A2A4、F9F9 都會被轉換成 ═
- A2A5、F9E9 都會被轉換成 ╞
- A2A7、F9EB 都會被轉換成 ╡
- A2CC、A451 都會被轉換成 十
- A2CE、A4CA 都會被轉換成 卅
不過這些字元本來照 UAO 對照表轉出來就是這樣，所以我也沒辦法處理。
ANSI code 轉 HTML 到這裡已經完全完成了，接下來的工作就是解析 .DIR 檔案。由於此檔案內使用 NULL 字元，而 C# 好像讀取文字檔案遇到 NULL 就會停止… 因此今天沒有進度。
今天參考這篇文章中 ToNum() 的作法寫成了 UAO-Big5 → Unicode 的轉換，程式如下：
private static string uao_b2u(string big5_text)
{
StringBuilder ret = new StringBuilder();
string big5 = "\xEEB8\xEEB9\xEEBA\xEEBB\xEEBC"; //Big5 字碼表，實際程式中非常長……
string unicode = "\x4E17\x4E22\x4E2C\x4E55\x4E62"; //對應的 Unicode 字碼表
for ( int i = 0 ; i < big5_text.Length ; i++ )
{
int index = big5.IndexOf( big5_text[i] );
if ( index >= 0 )
{
ret.Append( unicode[index] );
}
else
{
ret.Append( big5_text[i] );
}
}
return ret.ToString();
}
效率不差，讀取圖中的檔案（6280字）並轉換為 Unicode 一點也沒有延遲感。
接下來紀錄製作過程。
首先，我昨天就知道 C# 會自動轉換非 Big5 字區的文字，因此今天必須想辦法找出這些文字轉換後的新位置。起初我用平移的方法，這種方法是錯誤的，只能符合一部分文字，後來我想到我可以製作一個包含所有 UAO 新增文字的檔案，交給 C# 去讀，然後我就能知道到底會被轉成什麼了。
想法很簡單，但是要怎麼製作這個檔案花了我兩段時間——我花了一段時間才突然想到可以用 Hex editor 來編輯文字檔，然後再花了一段時間尋找支援貼上功能的 Hex editor ，最後找到了 PSPad 。尋找的過程很盲目，我只是記得免費又強大的文字編輯軟體有 Notepad++ 、 PSPad 這些，就一個一個去試，運氣很好的在第二個就試到 :)
轉兩次的風險是可能有些字元會轉到 65535 以外… 不過我沒有遇到這個問題。有一些字元在製作上面的檔案時就發生了奇怪的問題——存檔後會自動被轉成 0x003F ，但很幸運的是，發生這些問題的字元都是一些不重要的字元，如下所示：
␀ ␁ ␂ ␃ ␄ ␅ ␆ ␇ ␈ ␉ ␊ ␋ ␌ ␍ ␎ ␏ ␐ ␑ ␒ ␓ ␔ ␕ ␖ ␗ ␘ ␙ ␚ ␛ ␜ ␝ ␞ ␟ ␡
最後一個步驟則是刪除重複轉換的字元（在自動轉換時已經轉好的字元），雖然不會造成轉換錯誤，但我想這樣多少能提昇一些效率吧！經過刪減後，現在只有 6011 5956 個字元需要轉換1。
-
剛才重新作了一次「製作字碼表 → 轉換 → 刪除重複區段」步驟，將表刪到只剩 5956 個字元，這次採取程式自動刪除，因此應該是相當完美的結果。 ↩
今天作了作者、看板、標題、時間等資訊（以下簡稱文首）的處理，以及引文的標注，轉換的部份已經差不多了。文首的 HTML 結構還會再改，我在文首實作了 hCard ，這樣感覺還滿酷的，既然要轉換成 HTML ，當然要順便作一些 BBS 上作不到的事情囉！
目前成果大概是長這樣，我還沒寫輸出檔案的部份，所以這個檔案是用程式將 ANSI code 轉成 HTML 後，手動貼上記事本的 :p
接下來作了讀取檔案， BSS 的原始檔都是 Big5 編碼，因此讀取時需要處理 Big5 轉 Unicode ，這個部份我查了很久以後，才發現不需要這麼麻煩，只要在讀取檔案時告訴 C# 這個檔案是什麼編碼， C# 就會自動轉換成 Unicode 了…… 程式碼如下：
TextReader input = new StreamReader( openFileDialog1.FileName, Encoding.GetEncoding( "big5" ) );
UAO 的部份還需要自行轉換，首先我去找了各種 Big5 字碼轉換表，開心的寫出接近兩萬個的 Chaining… 然後 Visual C# 就當掉了 XD
接下來我先寫 5 個 chaining 來測試看看，結果果然如我意料之中，不能直接使用上面的表格，因為讀取檔案時的自動轉換連 UAO 部份都一起轉了…… 不過反正我也還沒想到方法解決那兩萬個 chaining1 ，所以關於表格位置改變的問題可以晚一點再思考2。
另外今天發現了新問題， BBS 的檔案結構我看不太懂耶… 為什麼要這樣亂放檔案啦… 好奇的人可以用系站的功能自己下載一個 archive 來看看，這個功能位於「信件典藏盒 → 打包資料」，將檔案副檔名改成 uue 後就可以解壓縮。
