在爬文測試過後，發現有幾個前提要先釐清：

1. 文件上常被提到的指令：
   a.  LangEngine   on|off
   b. LangPath  /path/to/your/locale
   c. LangDefault
   d. UseEncoding   on|off|local_charset client_charset
   e. UseUTF8  on|off    <--- 這指令在 1.3.3 並不支援
2. 編譯時的關鍵參數 --enable-nls  (Native Language Support, default=no)
   但在 FreeBSD 用 ports 安裝時，預設是打開的。
3. 系統端的使用字集 Charset
   現在越來越多系統是採用 unicode 了，這部份可以自訂，但目前我的習慣還是用 Big5。
4. 用戶端的使用字集
   雖然 unicode 推行很久了，但很多時候微軟的程式還是以當地字集來運作，對繁體中文使用者來說，那就是big5。而是否支援unicode則是個別軟體的問題。
5. 越來越多 FTP Client 支援自訂字集
   例如 FileZilla，而早期的 client 則是以用戶端的字集決定。

那麼，亂碼究竟是怎麼產生的？簡單來說，就是當 FTP Client 無法判別檔名字集時，它就會變成亂碼，或像 FileZilla 一樣自動隱藏。

因此，在 proftpd 1.3.3 之後，如果你啟用了 nls 功能，它就預設以 UTF-8 來處理所有的訊息，然後再依 UseEncoding 的設定來作 iconv。

這時，只要使用不支援自訂字集的 FTP Clients, 像早期的 FTP 程式或透過檔案總管，那麼它就會誤把 big5 的檔名解讀為 utf8，造成亂碼。

解決方式：

1. 重新編譯 proftpd
   把 NLS 功能關掉，讓 proftpd 用原生字集去運作。
2. 將 FileZilla 的字集強制設為 big5，確保檔名在雙向傳輸時不被誤解。（其實有點像是為了向下相容，配合其他舊程式的運作。）
   事實上，如果讓字集以自動偵測或強制使用 UTF-8，FileZilla 都能正確顯示檔案。（因為 proftpd 會如實顯示主機上的實體檔名，而 FileZilla 都能判讀。）
   但為了具備一致性，所以改成 big5 比較保險。
3. 以其它程式上傳，例如 UltraEditor，它也是用原生字集去運作的。所以檔名也都正常。

缺點：

1. 如果你是想跨區交換檔案，例如台灣和大陸分公司，那麼一邊用 big5，一邊用 gb2312，那一定是自找麻煩。這種情況下，應該以 utf8 方式運作才是王道。
2. 相反的，如果你想利用utf8來解決檔名亂碼的問題，那就不能用那些老掉牙的程式來傳檔，攪亂一池春水。這時，應該以能支援 utf8 的程式或 web-based 的介面來解決檔名編碼的問題。

日前，和許多版主（解答王）一樣，我也收到了 Google 的小禮物，才注意到 Google 不僅在其他很多服務（Search, YouTube, Gmail, Docs,...）有在動，連 AdSense 也動起來了。所以，這次的意見反饋活動，我就很有興趣參加。當天，我們那場是三位站長和 AdSense 的區域負責人對談。

詳細的過程和內容，很難一一記錄下來，只有挑重點講。但從站長的角度看 Google，我個人覺得：

1. Google 正在進行大規模的重整
   這個觀察主要來自許多 Google products 的轉變，有一些產品的變化可以說是非常大。因此我也很期待 AdSense 這塊能有更大的突破。
2. Google 畢竟是技術根基紮實的公司，相對的 Product manager 的角色和經營團隊的規模相對精簡。這表示，對 Google products 有任何意見時，應該與 PM 有良好的互動，協助他們將使用端的意見傳達給開發團隊，才能經過決策付諸實現。否則一切都是空談，得等他們主動大改版。
3. GA 的產品終究離不開趨勢。
   曾經一度很紅的 Feeds，在 SNS 平台風行之後，已經很快的退出市場主流了。很少人還在用 RSS Feeds 訂閱內容，反而是加好友或成為 follower，就能主動得知相關訊息了。這突顯了一件事，RSS Feeds 是訂報模式的網路版，而加好友、成為追隨者，那是直達天聽的訊息取得模式。
   就發展來說，這二者的成熟度差異是不言可喻的。那麼 RSS Feeds 大概就只剩下作好 SEO 的用途而已....
   另外，Ads for mobile, Video, Affiliate Network, 這些更貼近趨勢的運作模式也並沒有被忽略，只是因為區域發展的不同，而在審查時有不同的條件。
4. Googe 的雲端能否共享？
   這個問題有點大，會問的原因是近來台灣政府在主推雲端服務，姑且不論這是否只是口號，但已有的具體作為是未來將有很多由公部門匯整的資源會免費公開讓大家取用。試圖由資訊→服務包裝→創造商機來落實雲端概念的美好想像。
   那麼，Google 作為全球最大的平台和通路，是不是也可能開放 API 以外的資源呢？這值得思考。
5. 期許
   這二年來，網路的變化很大。如果用網路的時間不長的人可能無法想像，過去的網路或網站是如何的「故步自封」，而現今的網路是如何四通八達。那麼，作為 AdSense 發佈商，你的網路收益是否還能居高不下，或者再創新猶呢？我想很多人恐怕不太樂觀....
   關鍵會在那裡？個人覺得答案還是跟上述的一樣：GA 的產品終究離不開趨勢。
   過去，GA 的運作是以 page 為基本單位的，每一頁的內容決定播送的廣告，那是 WEB 1.0 的概念。
   現在，再談 WEB 2.0 都已經算是老梗了，那 GA 是否開放發佈商在新的網站架構中投放廣告？顯然還沒有。
   但他們自己有沒有作？其實老早就在作，像是 gmail, youtube。
   那麼，能不能開放？其實跟能不能把關有絕對的關聯性。如果能輕易作到把關，有錢賺何樂而不為？反之，遲遲不開放，似乎是有遇到超乎想像的難題。對此，只能給予期許.....我個人的期許是，至少要符合時代趨勢，讓廣告可以作更彈性的調控，讓廣告能更貼近網站的設計模式。
   另外，對於影片廣告也應該用更開放的態度，讓影片拍攝者更容易獲得利益，這或許是 YouTube 的轉機。
6. 小提醒
   近來不知道是不是金融體系有危機感，原本方便領錢的西聯匯款硬是少了非常多的據點，增加了很多領錢的麻煩。這表示，原本看似完美的付款模式，有可能因為服務通路的成本考量或其他決策，而造成不便。這種事情雖然不急，但終究是個隱憂。所以 GA 團隊還是該開始留意，是否有更完美的運作模式，唯有不斷的進步，才是立於不敗、永續發展的保證。

以上，期待這次的互動分享除了讓 Google 能更了解發佈商的想法外，也希望讓發佈商朋友們知道 GA 目前的概況。
我還是相信 Google AdSense 的存在能讓網路更加精彩，只是這必須透過不斷的努力、修正，才不會褪色停擺。
期待日後有更多關於 AdSense 和關於 Google 的訊息。

近日，美國《塑形》雜志刊出了紐約營養和健身專家總結的“看電視減肥12招”，不妨一試。

1. 如果你家客廳空間允許，可以跳跳繩，跳兩分鐘休息1分鐘，重復4次，能消耗111千卡熱量。雙腿跳也能達到同樣效果。
2. 高抬腿跳，跳躍時單腿向高處抬起再放下，每條腿做10次，可以消耗42千卡熱量。
3. 站在沙發前，慢慢下蹲，臀部快接近坐墊時停住，保持姿勢1分鐘，重復4次，可以消耗80千卡熱量。
4. 側臥在地板上，舉腿5分鐘，可以消耗50千卡熱量。
5. 雙臂畫圈1分鐘，重復兩次以上，消耗20千卡熱量。
6. 原地小跑，1分鐘就能消耗30千卡熱量。
7. 舉啞鈴等重物，雙手舉過頭頂，肘部與耳朵齊平，動作重復3組能消耗17千卡熱量。
8. 坐在健身球上，練腹肌1分鐘，重復4次，消50千卡熱量。
9. 把健身球當板凳，坐在上面1小時，消耗38千卡熱量。
10. 距離電視前1.5米處站立，弓步壓腿5分鐘，耗熱37千卡。
11. 做仰臥起坐1分鐘，重復兩次，耗熱35千卡。
12. 在沙發上，雙腿高舉並快速蹬腿1分鐘，像蹬自行車一樣，可以消耗30千卡熱量。

DEHP為塑膠製品常用的一種塑化劑，一般的塑膠製品中可發現少量DEHP存在，食品則禁止添加DEHP。

DEHP屬於環境荷爾蒙，會影響內分泌系統的正常運作，成功大學環境醫學研究所教授李俊璋說，DEHP為動物致癌物，但對人類影響還未有科學證據證明。國家衛生研究院主任劉紹興表示，DEHP對人體沒有急毒性，半衰期很短，只要不吃、不喝，就會排出體外。

DEHP可透過飲水、食物鏈等途徑而進入人體，國人每日自食物攝入DEHP的量約為1.029mg（毫克）。

DEHP屬於第四類毒性物質，僅需蒐集資料，記錄後向主管機關報備。塑化劑的種類很多，台灣目前每年進口約兩百萬噸，國內自製也有二十萬噸，如南亞麥寮廠。

（整理：記者鍾麗華、陳炳宏／自由時報）

DEHP 是什麼？

鄰苯二甲酸二辛酯（DEHP或DOP），是使用最廣、產量最大的增塑劑。進入人體和動物體內會有類似雌性荷爾蒙的作用，會干擾內分泌，影響生殖能力。 有研究指出，孕婦體內的鄰苯二甲酸酯濃度愈高，產下的男嬰生殖器官陰莖短小、先天畸型、尿道下裂與隱睪症的風險就愈高。若在成年男性體內鄰苯二甲酸酯濃度愈高，精子的數量就會愈少，品質跟活動力也愈差。

1. CPU
   目前越來越多 CPU 已經採多核設計，也就是一顆可抵好幾顆。所以對於運算需求較高的主機而言，選擇多核的 CPU 是無庸置疑的。但若是模擬出來的假多核，如 intel 的 hyper thread 技術，就不見得有多大的實質助益。
2. RAM
   記憶體方面也有這樣的趨勢，由原本的單一通道，提昇到雙通道，甚至三通道。這就像高速公路的車道，數量越多，車流的容許量越大。對於資料量大的主機，就必須特別注意這點，像是資料庫很大，或影音系統。
3. 硬碟
   現在硬碟的容量越來越大，已經有單顆 3T 的產品問市了。然而，讀取的速度雖然也跟著加快，但最關鍵的寫入速度還是不盡理想，而成為最大的瓶頸。為了提昇硬碟的效率，多數人是採用 RAID、SAN 或 NAS 來處理。後二者要花的錢很多，在這裡暫不討論。但就 RAID 而言，並不是架了 RAID 就會變快，例如是架 RAID 0(合併)和 RAID 1(鏡射) 來說，寫入的動作並沒有被分擔掉，所以有架沒架都一樣慢。
   那麼，可以怎麼作呢？
   筆者的作法是用二顆硬碟，以主從的概念來使用。例如要進行系統壓縮備份時，由 A 備份到 B，那麼一讀一寫，速度會快很多。這樣作還有一個好處，就是硬碟磁區的混亂程度會最低。因為在單顆硬碟上作備份時，會把前方讀寫速度較快的空間佔掉，而造 成後續資料被寫入速度較慢的後段磁區。即使你把這些前方的大檔刪掉，後方的檔案也不會被移到前方。這表示硬碟讀取頭就必須有大幅度的擺盪才能讀到資料，這 都會影響到效率。
4. 網路卡
   現在雖然已經進步到 Gigabit 的網卡，但是如果硬碟讀取速度不夠，還是會受限。
   另外，當系統在進行大量資料傳輸時，網卡的頻寬還是可能被佔滿，而造成不同伺服器的延遲問題。
   針對這部份的作法是採用雙網卡，甚至多網卡的作法，再依實際需求來規劃網卡的用法。
   例如雙網卡的狀態，可以一張網卡對外，另一張對內供內網使用，這樣就可以避免內外網搶頻寬的現象發生。
5. 主從式主機架構
   也就是大家常聽到的 n-Tier 架構，它的概念也大同小異，就是簡單四個字：分工合作。
   目前來講，當網站越長越大之後，可以先考慮架設 CDN(Content Delivery Network)主機來負責網站檔案的傳輸，這些檔案通常變動性較低，但讀取頻率極高。
   等需求再大一些，就可以考慮架設專屬的資料庫伺服器，因為資料庫是整個系統的核心不能損?，獨立出來將有助於系統的穩定性，資源調配上也較明確。
   之後，就可以考慮架設 AP 伺服器，讓多台主機來處理使用者的需求，再結合 Load balance 的設定，把需求分配給不同的 AP 伺服器處理。概念上可以看成大賣場的結帳櫃台，人多時就全開，人少時就只保留部份櫃台即可。
6. 雲端系統
   國外的 Amazon 和 Google 等業者都有提供系統龐大、收費低廉的雲端系統可供租用，當需求大到無法自行解決時，雲端系統也是值得考慮的選項之一。但在使用上，還是要評估系統的距離，遠在天邊的網路系統往往不比隔壁的主機來得快。

總結來說，效能的瓶項往往來自通道數量和傳輸方式。盡可能增加通道量，控制行進方式，就能提高系統運作效能。