最近有人提出一個狀況，他在php5中去撈資料庫（資料庫為 sybase）中的數字，會有問題。舉例來說，資料庫存放的內容為 71.10 ，但經由php5所寫的程式，去取得出來的數值卻是71.09999999999999。妙的是…一樣的程式放到php4的環境去執行，卻是正常的，取得71.1。 原以為他所撈取欄位的資料型態為float，才導致這狀況。但瞭解狀況後，發現該欄位的資料型態為decimal (5,2)。也就是說不應該會有這樣的情況！ php5連sybase，已經改用sybase_ct。因此，一開始認為這樣的問題，應該是sybase_ct本身的bug。其實，在sybase_ct的bug資料中也有提到這樣的狀況 - BUG #29064 。不過，該問題卻是已經解決… 在後續的問題釐清中，也發現原以為sybase_ct是個獨立的extension，和之前的freetds無關。事實上，sybase_ct還是需要freetds。另外，sybase_ct會吃freetds的設定。也就是會吃freetds設定檔（freetds.conf）中[global]的設定值。 換句話說，當我們使用如下的php程式去開啟sybase連線時，sybase_ct會去吃freetds設定檔（freetds.conf）中[global]內的設定值。 $conn = sybase_connect('123.123.123.123:5000','id','pwd','big5','test_php'); 然而，在freetds的設定檔（freetds.conf），預設中會有下列設定 [global] # TDS protocol version tds version = 4.2 這個tds版本代號有其含意，詳細可參考 Choosing a TDS protocol version 內的說明，視自己所用的資料庫採用不同的設定值。 居於上述兩點，解法就很簡單了。因為他是採用sybase，因此可以將此預設版本設定為5.0。問題就解決了。 [global] # TDS protocol version tds version = 5.0 參考資料 TDS版本說明 freetds

五分山稜線 農曆年前在圖書館翻到一本Taipei Walker。當月的主題是介紹鐵道附近的景點。在平溪線部分，裡面有張稜線的照片，吸引了我們的注意。 原本就想說趁者農曆年假找一天、找個地方去登高望遠。看到這稜線很漂亮，就決定去這照片上的地點-五分山。 這些年來五分山很熱門，不過並非因為登山活動熱門，而是因為單車活動。上次騎106線道時遇到另外一隊車隊，他們的終點就是五分山。 兔年的農曆假期期間，真是非常難得…台北居然是好天氣。選了某天一早，搭乘火車到八堵改成平溪線。說到平溪線，除了大家所熟悉的鐵道風景外。其實，他的火車有個特色，就是在列車駕駛（艙）旁有乘客的座位。坐在該處，可以直接看前方的風景。也因此，此處的座位非常的熱門～照以往的經驗，就算搭乘很早的車班，也不一定坐的到。 八堵車站轉平溪線 坐在火車頭（尾）才能這樣拍照 有道是…南蜂炮北天燈，平常假日的平溪，人潮就不少了。農曆年間更因為天燈活動吸引更多的人潮。早上抵達十分火車站時，由於時間尚早，只有三三兩兩的遊客。在我們回程時，遊客明顯變多。車廂內更是擠滿者遊客。應該和當天晚上於菁硐提早舉辦放天燈活動有關。 一早，只有稀疏的遊客 橫跨鐵軌的榕樹 由十分火車站通往五分山步道，首先朝台灣煤礦博物館的方向前去。在抵達台灣煤礦博物館售票處之前有條往上的岔路（差路口有棟紅色房舍）。該產業道路走到底則是台灣煤礦博物館。五分山步道的入口處則是在小客車停車場的後方。由於登山口沒有明顯的指標，也沒注意到登山布條，因此還走錯路。後來是詢問台灣煤礦博物館內的工作人員才知道登山口位置。 台灣煤礦博物館 施放天燈的旺季，沿途看到不少墜地的天燈 進入登山口後就開始一路的陡上階梯，走者走者不經又想起由滿月圓到北插天山途中的那段陡上階梯 XD 。這樣的陡上階梯直到嶺頭福德公才稍微改變，之後的步道才稍微有點上下起的起伏。不過，仍是以上坡為主！ 持續的上陂階梯 這嶺頭福德公廟剛好座落於通往暖暖的岔路旁，是一座石頭砌的古廟。由旁邊基隆市政府的解說牌以及廟內的新立的石碑可以瞭解為何為何此處有座土地公廟。原來此土地公廟介於暖暖和十分寮的中界點，為開墾十分寮時第一座石頭砌的土地公廟。旁邊通往暖暖的岔路是為淡蘭古道暖暖支線，是由暖暖東行越五分山鞍部抵達平溪十分寮，所以又稱為十分古道或

近來，先後有A、B兩位同事問我關於 Google Analytics 中的referral的事情。 首先，是A同事在問，在去年某段時間內， Google Analytics 中所呈現公司網站自己本身的referral，為何數值大幅下降？回想了一下那個時間點所做的事情…當時為了提升網頁呈現效能，開始作了一連串的處理。跟流量或和此最有相關性的，莫過於 cookieless domain 。由於時間點一致，就以為referral數值大幅下降和那時的處理有關。 這幾天，B同事來問，為何公司網站自身會被計算成referral？我想說referral應該就是HTTP_REFERER，也因此，認為在 Google Analytics 中出現自己網站沒有什麼問題。不過，他覺得並非如此，並給了我份參考資料 - 為什麼我的網站會在報表中顯示為推薦網站？ 。文中提到下列四點… Tracking across multiple domains or subdomains Redirects Splash Pages Frames 由於B同事的詢問，才知道B同事之前已經改用新的 Google Analytics 追蹤碼。配合該文章的解說，沒想到卻點出了A同事所提問題的真正原因。也就是因為當時B同事改用了新的 Google Analytics 追蹤碼，才讓referral大幅下降！（因為上述第一點） 另外，也由該文件的說明，讓我瞭解 Google Analytics 的定義和我所想的不同。因此，他覺得公司網站自身會被計算成referral，是否和Redirects有關？ 為了回答B同事的疑問，我也很好奇 Google Analytics 怎麼計算referral？找了一下 Google Analytics 對於Redirects的判斷，在 Google Analytics (分析) 如何處理重新導向的流量？ 這份資料中有解釋。在文中，也提及要如何處理 - 因為Redirects導致referral 的改變。有興趣瞭解referral在判斷上為何會有差異？可以參考這份詳細的說明 - How Does Google Analytics handle 301 and 302 Redirects? 。 講到此，自然要提及何謂轉址？以及在http中是怎麼作的？http status 中301和302的