咖啡戒斷症候群

這是個困擾了朋友很久的問題, 老是打電話來問我如何解決, 但是電腦不在手邊, 光憑著手機在兩邊把脈實在力有未逮!
其實網路上搜尋一下, 提到類似情形的解決方式不少, 可是朋友找了一大堆網頁一一照著做, 竟然都沒辦法解決, 這就讓人有些好奇了!

狀況是這樣:

朋友A的朋友B的電腦硬碟容量不足了, 於是朋友A就用賽門鐵克的Ghost幫朋友B把原本的Windows XP系統硬碟(IDE介面)整個複製到新的250G的SATA硬碟裡，然後重新開機就出現了ntldr is missing的訊息, 根本進不了Windowx XP畫面!

電腦不在手邊, 只好問問他操作情形跟用了哪些網路上常見的解決方案?

1. 檔案系統NTFS, Windows XP是SP2版本

2. 已經重複用Ghost複製多次, 新硬碟裝在電腦裡可以正常抓到, 資料讀寫也都正常(不會是BIOS太舊的問題)

3.可能是 ntldr壞了, 把另一台電腦的ntldr檔案複製過去! --->做過了!

4. boot.ini檔案有問題, 按照網路上的內重從自己打字做一份! --->做過了!

5. partition沒有設為起動? --->確定啟動了!

博客來網路書店剛開張的時候, 真的讓我對這台灣網路書店先鋒有著極高的敬意與佩服!

不過這幾年來, 我卻越來越少在博客來買書, 不像剛開始的時候幾乎是每天都上網逛博客來網站，三不五時就買個幾本，原因可能許多人也感覺到了，首先就是博客來的書，已經不是最便宜的了，不但不是最便宜的網路書店，很多書甚至不比實體書店便宜，其次，因為經常會針對某個主題找書，從某個時間點開始（具體忘了是哪時候），博客來以關鍵字查詢書籍的正確性「低的離譜」，經常是輸入某個關鍵字查詢書籍後，出現了一大堆無關的書籍，真正想找的書籍卻排在很後面，多按了幾頁就沒耐心繼續查了，比較了一下金石堂書店，正確性就高多了！

最近博客來在這關鍵字查詢方面好像有了些改善，不過綜合了些原因，現在會在博客來買的書通常就是每天66折的那種，或是每年一次的網路書展了!

今天突然心血來潮，上了博客來網站想要寫個書評，它的書評印象中推出也挺久了，不過一直沒去用，沒想到今天看了一下，原來在博客來寫的書評還得經過審核的！

要寫書評之前，按下"我要寫書評"按鈕後會先出現一大堆規定，大公司為了怕麻煩，列了一大堆規定約定的這也難免，不過讓人好奇的是，竟然寫完的書評還得經過5~7天之後才會出現，而且得沒有違反書評公約才會出現；雖然不難理解博客來為了怕出現一堆言不及義或胡亂攻擊的書評，不過使用這種先審核再刊登的方式，難保不會降低讀者寫書評的意願，但相反的也幫助有心想界書評操作書籍評價的人多一層屏障，同時更難免增加了審核的成本（也難怪賣的書價錢降不下來了）!

費了些功夫做了一段像是卡啦OK歌詞慢慢出現的文字, 場景測試都正常, 沒想到影片測試卻一片空白!

找了好久, 原來Flash遮色片的目標不能是動態文字, 改成靜態文字就好了!

真是太不小心了, 如果沒設定好, 動態文字還可能讓整個swf檔體積大為膨脹, 果然學藝還不夠精!

又遇到Flash的怪異現象!

做了一個Flash是黑色的背景, 在影片測試都正常, 放在網頁裡面在單機的Localhost測試也正常(就又是在Dreamweaver裡頭直接按F12測試), 但是上傳到正式的主機瀏覽後, 黑色背景卻變成白色背景, 連續讀取了好幾次網頁都還是一樣!

想了想, 在本機的傳輸速度應該很快, 放到了遠端可能因為flash還沒下載完, 所以應該是黑色背景的flash出現白色背景!

解決方式: 在Dreamweaver中, 把該Flash的背景改成黑色, 上傳到遠端正式主機測試就正常了!

如果是在Flash CS3裡頭使用發佈功能, 那麼在所發佈的 html 檔案裡頭, 確實會將那個黑色背景的 flash 檔案的背景參數設定為黑色！

不過當我另外做了一個小的黑色背景flash檔案(只有5kb的swf檔), 裡頭只有一小段文字移動動畫, 這時不管在 html 裡頭是否有設定該 flash 的背景顏色, 在近端或遠端主機都會用正常的顏色播放!

所以猜想可能的原因, 應該是先前有怪異現象的 flash檔案較大, 在flash仍在下載的過程中, 那一塊放置 flash的位置就會出現白色背景! 在近端測試的時候, 因為flash檔案讀取速度比較快(直接由硬碟讀取）, 所以不會出現白色背景, 但是當檔案是放在正式的遠端主機的時候, 因為檔案透過網路傳輸, 就可能需要較多時間讀取, 在讀取過程中就可能出現白色背景!

不過這個推測仍有問題, 出現問題的 flash 網頁, 在整個 flash 都下載完, 也就是所有的動畫都正常播放, 但是背景顏色卻還不是黑色,  所以這情形並不只是出現在 flash  仍在下載的過程!

真正怪異的是, 當我這樣猜測, 並更改flash及html檔名重新測試這個想法的時候, 遠端主機雖然出現了白色背景, 但是卻是一閃而過, 很快就出現了正常的黑色背景, 同時也看得出來 flash 檔案仍未下載完！

製作Flash動畫的時候如果有用到Flash的動態文字, 可能在發佈的時候會發生超級膨脹的情形!

明明很小的原始fla檔, 也沒用到太多點陣圖, 但是發佈之後硬是變成了好幾MB, 阿被昨天就發生了這情形, 做的的Flash動畫放到網站主機之後, 開瀏覽器要預覽硬是只能看到空白畫面, 才發現原來是檔案竟然變成了超過5MB, 剛開啟瀏覽器時根本來不及下載。

因為是從範本學習來的Flash檔案, 仔細研究, 原來是動態文字在搞鬼!

動態文字因為可以在執行過程變更內容, 所以提供了一個"內嵌字體"的功能, 如果在設計時有使用到非系統內定字型的中文字型的時候, Flash會很聰明的把該字型的整個字型檔設定為內嵌在swf裡面, 這樣在 swf 執行時不管動態文字怎麼變, 都可以有正確的字型可以顯示!

不過如果動態文字的文字內容是在一個固定的內容做變化, 例如動態文字的內容固定會取"今天四川大地震, 規模更勝台灣921大地震"（是的, 今天真的發生四川大地震）來做變化的話, 那就沒必要把整個字型檔全部放進去。

例如上例, 如果以"文鼎粗黑"作為字型, 就可以點選"內嵌字體"的按鈕, 先把Flash自動選取的文鼎粗黑中文字型檔取消, 然後在"包含下列字元"底下的文字框裡填入"今天四川大地震, 規模更勝台灣921大地震". 這樣就只會取文鼎粗黑的字型檔裡面的"今天四川大地震, 規模更勝台灣921大地震"這些文字的字型資料嵌入到 swf 檔裡面, 而不會把整個數MB的字型檔全部份進去!

原本用PHP5開發網站, 因為主機時區設定與網站不同, 所以用了date_default_timezone_set( "Asia/Taipei" ) 來設定時區, 但移轉到正式的虛擬主機時又是PHP4, date_default_timezone_set不支援, 找了找資料, 好像沒有函數可以用。

不過PHP5除了用date_default_timezone_set( "Asia/Taipei" )之外, 如果是自架主機也可以在PHP.ini設定 date.timezone = Asia/Taipei, 所以php4應該也有相對的方式, 就算不能更動主機設定,  應該也可以用追加主機設定的方式, 找了一下發現PHP4可以這樣解決:

putenv("TZ=Asia/Taipei");

在使用國外的虛擬主機的時候, 應該都會遇到timezone與網站不同情形, 整理一下：

PHP4 用
putenv("TZ=Asia/Taipei")

PHP5 用
date_default_timezone_set( "Asia/Taipei" )

也可以在 php.ini 設定: date.timezone = Asia/Taipei

2008/06/06 修正

最近設計的網站, 原本用PHP5開發, 沒想到接近完工時, 才發現客戶原有的虛擬主機空間還在用PHP4,大部分的PHP指令好像都正常, 不過今天出現了日期顯示的錯誤。

當初為了顯示月跟日(M-D), PHP5的日期顯示也是拼湊出來的, 不過總是解決了問題。

PHP5的日期輸出:

echo date_format(new DateTime($row_rsNews['date_start']),"m-d");

其中的"m-d"是輸出的格式, 輸出結果為"04-12", "05-01"......

但是date_format()在PHP4還沒出現, PHP5之後才開始支援, 所以不能使用。

所以PHP4反而用了最簡單的輸出方式, 子字串substr()函數

最近嘗試使用Adobe的Dreamweaver Developer Toolbox來開發資料庫網頁, 該工具只有英文版, 為了修改為中文訊息, 加上初次使用php來撰寫資料庫網頁, 又加上Dreamweaver CS3內定使用utf-8的網頁編碼, 結果處理過程繞了個大圈子, 簡直就是個大災難!

其實起因還是因為阿被的背景, 因為阿被的低階程式偵錯員背景, 讓阿被習慣了用補漏洞的方式處理這個問題, 加上php根基尚未紮實, 著實吃了些苦頭!

不過過程仍有許多值得紀錄, 但是既然是大災難, 就不是三言兩語可以道盡, 還是慢慢挖出回憶再記錄下來好了!

過程大概是:

1.ADDT無法顯示中文, 所以找出了存放英文訊息的檔案把訊息改成了中文。

2.改中文訊息後, 錯誤訊息變成了亂碼。

3.變成亂碼應是判斷訊息文字編碼的問題, 因此直覺的以Notepad把訊息檔讀入, 轉存為utf8編碼的unicode檔案

4.中文訊息變成正常, 但是ADDT部份功能的頁面轉換卻出現header無法修改的錯誤而無法轉換頁面。

5.為解決轉換頁面的問題, 找到了ADDT轉換頁面的部份, 把改寫轉換頁面的方式, 雖然在中文訊息正常的情況下可以轉換頁面, 但轉換頁面的速度較原本慢

6.又把訊息檔改回原本的ANSI格式(big5編碼), 並找到了輸出訊息的函數部份, 把輸出錯誤訊息的函數的輸出結果字串, 從big5編碼改成urf8編碼, 中文訊息顯示正常, 經過修改的轉換頁面函數也同時可以還原為原本寫法。

兩個PHP圖表產生元件:

PHP Charts :

http://quimby.gnus.org/circus/chart/chart-manual.php

PHP/SWF Charts :

http://www.maani.us/charts/index.php