本書有個小標題就是停止抱怨、積極承擔。開宗明義地告訴我們，成功應有的正確態度，就是從自省開始。的確，很多人在遇到困難、挫折時都是以抱怨來逃避或是推卸責任，這原本就是生物的自然反應，無可厚非，但是人之所以為人，就在於人有不同於其他生物的大腦，適當的抱怨是可以有效發洩情緒，畢竟壓抑著並不是一件好事，但是我們不能把這樣的理由無限上綱，而重點就在於＂適當＂二字，能夠抓住這分寸的人，往往就是成功者。作者利用了幾個方面，甚至代用幾個小故事帶我們把握這個分寸的拿捏，所有人都知道，抱怨其實於事無補，甚至更是壞了大事，但是要抓住抱怨的分際，在發洩情緒與推諉逃避之間拿捏分寸，就需要真正的學習。

抱怨不只影響自己，他帶來更大的麻煩是使得周圍的人也受到感染，這是在社會性生物中影響最大的。人是群居的動物，任何人要離群索居更非易事，在這種情況下受感染的機會大增，除了我們做到停止抱怨外，如何對於別人的抱怨做到不影響自己，這當然也是做為一個成功的人的必備要件。

如果當做一本工具書來看，書中所寫的一切相信每個人都會覺得陳腔濫調，不值一哂。從頭看到尾的結論就是，這不都是廢話嗎？我也能寫出這本書。很好，的確在正常情況下，這本書的確廢話連篇，但是當你陷入情境當中時，感性的腦主宰控制勝過理性的腦時，這些陳腔濫調都會被壓抑住，因為逃避就是生物的基本生存法則。記得在去年看過的文章中，有錢人的大腦怎麼想，就曾經探索過，有錢人的理性腦可以在這種情況下很快的取回主宰權，擺脫逃避的心理去面對困難，回到自省檢討的一方，這不正是互相呼應嗎？有錢人當然不必然是成功的人，但是在現今的社會來說，有錢似乎也是評斷是否成功的很大標準，至少不會相距太遠。

也許，把這本書擺在心裡，時時檢視自己，就算陷在情境中時我們不能擺脫逃避的本性，但是當回到理性時，我們拿回來看看知道自己當下所犯的可笑錯誤，也許下次，我們能更快的回復理性，而不再是由感性主導一切。

從共識營，到上過陳老師的「管理者應備的管理技巧」課程，再到看完這本書，整個一系列下來，好比將自己在管理學的功課重新拿出來復習一遍，並且加入其他人實戰的經驗，重新建構了屬於自己的管理學流程。

本書中幾乎完全勾勒出一個新手領導者在初接大任時所會遭遇到的挑戰及出乎預期的狀況，假設對於一個新手領導者來說，發現到所有的狀況都在掌握之中，至少在心理層面上就不會有緊張的狀況，再加上所有的狀況都有建議處理反應的方式，對於新手來說很方便就能照章行事，至少在心理層面上已經不懼怕面對未知的狀況，在所有狀況都是已知的情況下，試問還有誰會出現手足無措的狀況呢？

另外一個關於新手主管的重要課題就是如何與自己的團隊相處，作為團隊的領導者與單純作為團隊的一份子當然有很大的不同，領導者必須暸團隊成員的屬性，針對其屬性選擇不同的相處方式，最終目的當然是能容易達成共識，共同完成目標。能夠掌握到一個人的最大特質，相對的就容易取得在互動時的主導權。

本書以條列式的方式清楚的條列出新手主管預期會遇到的狀況，也因此對於新手主管來說，可以說是一本相當實用的工具書，也許在剛接下任務時，可以排除掉先期的緊張情緒。經由穩定的運行一段時間後，讓自己能夠再慢慢的恢復自己的理性來處理面對的困境。事實上，在經過初接手的適應期之後，仍有些部份是需要弄清楚的：

1、公司的沿革：公司一路走來到底是如何改變的。

2、組織架構：誰當家作主，以及決策的流程。

3、政策和程序：處事的方式。

4、公司內的閒話：哪里有爛攤子，有哪些瘡疤。

5、財務數字：你每天工作代表的金錢與意義。

經由對於這些小地方的了解，一定能讓你對於擔任主管更有幫助，且能更容易上手，按部就班執行，相信在管理的職務上更能夠掌握訣竅上下通吃。

今天的經理人每天花大量的時間開會，但是至少有50％的會議是沒有生產力且無效能的。

以上的想法或許讓你驚訝，但是，事實上，「開會」確已不再是企業管理的完美方式。相反地，它對經理人和員工都是一種時間和財務上的消耗：延宕每個人的工作進程，會議目標卻很少達成。

因此，如何讓你的公司更有效能、和部屬間有更好的溝通，同時提升工作品質，本書作者Scott Snair多年走訪奇異電子、嬌生公司、席爾斯百貨等企業的成功經理人，發現他們不開會卻能有效管理的成功祕訣，協助你不再陷在「不開會便無法管理、溝通」的傳統制約中。

我們經常遭遇低效無益的會議，會議本身越來越成了成本高昂而效率低下的行為。若從經濟學角度來分析，其中相當大的比重可以歸納為無謂損失。美國經濟學家斯蒂格利茨提供的“會議的機會成本”分析案例說明，企業往往會忽視一種最重要的機會成本：即高層管理者的寶貴時間。

會議是人類社會群體協調與溝通的重要途經，採用協商型會議（如公司的董事會）作為議事和決策的手段，也是促進企業與社會效率提高的重要規則。人們往往通過會議來溝通交流、增進了解、集思廣益、爭論思辯、化解沖突、形成決議，可以說，在成本適當的情況下，舉行注重實效、簡短而具有活力的會議是各種社會組織不可避免的主要協調方式之一。舉行會議的出發點，往往是為了解決突出矛盾，提高運行效率，降低社會發展成本。但當我們用“文山會海”、“會議季節”、“會議生活”、“會議式生存”之類的表述來形容、調侃有關開會的種種現象時，會議本身卻成了一種成本高昂而效率低下的行為。台上念報告、台下聽報告已成為類似每年兩會這樣重大會議的既定模式。而發展“會議經濟”、“會展經濟”、“旅遊度假式會議”已經成了許多城市和旅游名勝重要經濟增長點和收入來源。

傳統會議模式，顯然與創建“和諧社會”、“節約型社會”目標存在著一定的不協調性。由於各種會議的成本通常由公款支出和企業非生產性支出負擔，若從經濟學角度來分析思考，其中相當大的比重可以歸納為無謂損失，從而造成社會淨福利的減少。

據說日本某公司為提高開會效率，實行會議成本分析制度。每次開會，總是把一個醒目的會議成本分配表貼在黑板上。成本的算法是：會議成本=每小時平均工資的3倍×2×開會人數會議時間（小時）。之所以平均工資乘3，是因為產值高於平均工資﹔乘2是因為參加會議要中斷經常性工作，損失要以2倍來計算。因此，參加會議的人越多，成本越高。有了成本分析，態度就會更加慎重，會議效果就較為明顯。當然，要降低會議成本，除了減少會議的直接成本之外，提高會議效率，縮短會議時間，也同樣重要。

據經濟學的成本概念分析，除了會議的直接成本（如食宿、交通、場地、設備租借和會議服務、打印材料等）和間接成本（如參加會議者的小時工資）之外，還應當考慮會議的機會成本。美國經濟學家斯蒂格利茨在他的教科書中提供了一個案例材料“會議的機會成本”，並對此有簡單計算。

該案例說明，企業往往會忽視一種最重要的機會成本：即高層管理者的寶貴時間。有一專業研究機構曾調查分析了美國最大的一千家企業中的200位管理者，他們平均每天有15分鐘打電話，72分鐘在出席各種不必要的會議，32分鐘在閱讀或寫各種備忘錄。

如果將這些數字乘上48周（假設管理者每年有四周假期），那麼每位經理平均每年花60小時打電話﹔128小時用於不必要的備忘錄﹔而有288小時出席那些不必要的會議。如果能夠把這些無謂損失的時間用於其他更具效率的事情，就等於節約了大量機會成本。

當然，不是所有的會議都是無效率或者嚴重浪費社會稀缺資源的，如果我們能夠把日常的管理規則和重要事項通過網絡發布、編制規則手冊、電話電視會議甚至網絡會議等各種方式去替代會議，也能節約大量資源，避免勞民傷財式的巨大浪費。

此外我們還可以通過學習和掌握更有效率的會議形式和方法，來提高會議的實際成效。因此我們可能需要特定的會議程序和議事規則。隻有在一定的規范和程序下，會議才能起到拓寬言路、集思廣益、凝聚共識的功用，才能實施多數佔優但同時尊重和保護少數人意見的自由民主原則。我們經常遭遇低效無益的會議，內容空泛、拖泥帶水、決策先決、強奸民意，或各說各話、缺乏真實交流，教條與曲解盛行，容不得爭論與深入思考。

議事規則是建立在人們的常識和邏輯的基礎之上的。它旨在設定全體認可的框架，使會議能夠以高效、民主的方式來處理事務。掌握了議事規則的原理，我們就可以根據組織的需要來調適，既不過分拘泥於形式而導致效率低下，也不隨意變動而損害會議的既定程序和民主原則。一般來說，會議規模越大，意見越是多樣化，就越需要遵循較為正式的規則。

議事規則的意義，還在於能使參會者就會議方式達成一致，在權利制衡的共同框架下討論和決議。所有的成員都必需遵守議事規則，在規則面前人人平等，努力運用好各自的發言權、知情權和投票權，設法使自己的意見佔上風﹔當自己的意見不被多數人接受時，也不濫用個人或組織的權力而危害整體利益。會議主持人雖是規則的執行者，負責按程序保証會議正常運行，但同樣受會議規則約束，不能憑借個人意志與偏好對議事過程施加不當影響。

這本書是作者的個人經驗談，讀起來輕鬆愉快。因為是實際的行銷經營管理經驗，因此，也特別值得參考。作者從自己的強運帶入，並區分為工作、人氣及領導三方面來說明，當然以現階段的我來說，肯定是對作者在工作方面的強運宣言有深刻體會。

其中，對於「善用長處，別說不可能」及「困難讓人更聰明」兩個部份更是深深體會。事出必有因，千萬不要在剛開始遇見問題時就直言不可能，如此只會讓自己少了追根究底的動力，不論是來自用戶的問題，或是上司的交辦事項，如果不是出自不合理的原因，請不要讓自己錯失了這樣的追求機會，接下所有的任務，運用自己的長處，或是所有能運用的資源，請盡量去想出可能的解決機會，就如柯南道爾說的，當你把一切不可能的結論排除之後，那剩下的，不管多離奇，也必然是事實。所以別太快說不可能，間接讓自己少了一次研究動腦的機會，我們可以將不可能(impossible)，運用自己的長處，轉化為可能(I’m possible)，這全在一念之間。

困難讓人更聰明，這部份更是跟我原來想像的契合，行銷的工作在創意上其實是很重要的，那又跟我之前提到的大腦神經元的連接有關係，當原本兩件看似不相干的事情，從中發現了他的相關性，進而將兩個神經元搭上線，創意就出現了，放心吧，用進廢退說用在大腦的神經元是很快的，在演化學上用進廢退可能需要幾萬年的演化，但是在大腦的神經元，只需要幾年，就能感受到他的進化或退化。只要在遇見困難時，別太快放棄思考，我自己的經驗是，也許無法立即出現靈光一閃的情況，但是擺在腦中想，常常在睡夢中或是幾杯黃湯下肚後，兩個神經元接上後，就出現令人意想不到的解決方法。

其實作者在很多地方的想法與我還蠻接近的，如果是這樣，是否即便我現在落後一圈，我也同樣能現在急起直追，最後得勝。

成大事，立大功，每個人都想達到這樣的境界，但是要做到這樣，一定有一些必要條件，我們常常在想，成功的人他具備了什麼樣的條件，真的是他運氣好還是他有特別獨到的眼光？其實成功的定義只是完整的做完一件事，並非在於事情的大小，即使是小事，只要態度正確，完整做完，那也就是成功。「立志做好每一件小事，沒有卑微的工作，只有卑微的態度」，前美國眾議員巴登曾說：「偉大的成就往往源自微不足道的小事。每念及此，我總認為世上沒有小事。」態度決定一切，敬業的態度會讓人不論從事什麼工作，都能展現優異的成果。

亞都麗緻飯店總裁嚴長壽先生，在他還是外商公司的送件生時，就很注重外表的服飾，總是穿著襯衫西裝褲，打扮得很專業，上班也總是早到遲退。他敬業的工作態度和尊重這份工作的表現，讓他獲得到伯樂的賞識，進而晉升到經理達人的階段。所以說敬業的態度決定一切，成功並非靠幸運而成。

所以即便是小事，只要盡心力做到完整，有這種完成事情的態度就決定了你是否擁有成功的必要條件。一件大事必然是由許多的小事組合而成，雖然做的只是一些小事，但是當所有小事都完成，自然大事就能成就。許多人對於瑣碎的小事不值一哂，殊不知忽略了細節，便不足以成大事。

什麼樣的態度會是我們成功的絆腳石呢？作者說到了找藉口、惰性、被動，這些都會成為阻礙我們成功的障礙，只要我們把握了正確的態度，不找藉口，積極主動，認真負責，其實不要說成功需要機會，應該問我們是不是已經做好準備，當成功的機會到來我們就能一把抓住，成功永遠都是屬於準備好的人。

用心對待顧客，用心對待員工，用心經營，用心管理，用心服務「心」成為企業運營過程中的一條牽引線。

這裏的「心」需要的是自覺的「心」，是企業所有的員工在自己的崗位上能自覺地去用心做好自己的本職工作。

想起聽到過的一種說法：如果員工都把高品質地完成自己的工作當成是一種習慣，那麼整個公司的運行效率將會大大地提高，也就是說，在做一件事情的時候，做好才是理所當然的，做不好則是違背了自己的習慣，會感覺到不自在、不舒服、難受。就像刷牙，每天醒後和睡前刷牙是我們認同的良好衛生習慣，如果我們哪一天不刷我們就會覺得不舒服、不自在。把將事情做好變成一種習慣，自然就可以利用人的惰性來輕鬆搞定每件事。

有句話說，「認真做事只能把事做對，用心做事才能把事做好」。不管是在車間還是在辦公室，將「做好的事情當成自己的習慣」都應當被提倡。工作不是辛苦地完成任務，而是在滿足自己的良好習慣。如果我們的「心」能達到這一層次，那麼「心」經營就有可能實現，「心」滿意也自然會隨之而來。

時代的發展已經要求企業不只是向顧客提供產品，更要向他們提供服務，不只是滿足他們對產品和服務的需求，更要使他們享受需求被滿足的過程。

在這本書中，石滋宜點出企業若要生存和發展就必須顧客滿意這一簡明而深刻的道理。怎樣才能讓顧客滿意呢？就是用心去經營，站在顧客立場上，從顧客的心理出發設計、研發、生產產品，提供服務。

在新加坡東方旅館（Oriental Hotel）的咖啡廳，有四位客人在非常吵雜的環境下談生意，聲調越來越高。有一位女性服務人員注意到他們很難聽到對方的聲音，於是她就打電話給客房部，要求撥一間空的房間給這四位客人，客房剛好有空，她請客人到房間內談事情，房間完全免費使用。這位服務人員僅僅是旅館最基層的人，但她就可以立即做出這樣的決定。是《經濟日報》副刊刊載洪秀鑾小姐所寫的一篇文章。

還有一個例子是石滋宜先生說過的，美國聖路易靠近機場附近有家旅館。這家旅館在每個房間裡放了一張紙條，上面用顯著的字寫著：「如果您對於我們的旅館有任何不滿意之處，請告訴我們，我們將加以改善：如果還是不滿意，您可以不必付錢」。第二天要退房時，櫃台小姐的第一句話就是問滿意不滿意，我說這樣問是認真的嗎?她說當然是認真的，而且要是不滿意的話，可以不用付錢。我想這種以顧客為主的用心，客人也會感受到的，即使有一點不滿意，也不會太介意了。所以，愈能在事前主動積極地提供服務，愈是可以做好顧客抱怨的預防處理。

企業惟有用「心」經營，才能獲得顧客發自「心底」的滿意。只有感動顧客，企業才能擁有自己的市場。並能長盛不衰。

今後的市場是感動消費的市場，今後的時代是感動消費的時代！

在php的程式當中，針對資料庫的連接有兩種函數，分別是mysql_connect及mysql_pconnect兩種函數，針對這兩種函數做一個說明及介紹，並比較兩種函數在實際上的作用與影響，並讓工程師認識兩種函數的用法。

首先是這兩種函式的差別到底在哪裡呢？相信工程師都很容易知道標準答案就是：mysql_pconnect是持續性的連接，PHP會重複使用已經存在的資料庫連線。沒有錯，這是這兩個函式之間最大的差別，但是再追問下去，什麼時候要用mysql_connect什麼時候用mysql_pconnect？mysql_close何時使用？為什麼DATABASE上有一堆SLEEP的PROCESS？明明用mysql_pconnect為何每次RESOURCE ID都不同？相信能說明的人就少了許多。

從一開始用 mysql_connect建立的連線，用完即丟，乾淨俐落。不過，因為在建立資料庫連線時，需要耗費一些時間與系統資源；若使用mysql_pconnect的話，同一部 web server 再向 MySQL server 請求連線時，可以直接使用先前用完閒置的連線，而不必重建。所以使用 mysql_pconnect來建立連線，可以節省時間，同時也能降低伺服器的負擔。這是php語法中使用這兩種函式的原意，但是在實際使用上，某些場合中，mysql_pconnect反而是不適用的。為什麼這樣呢？就是在如果一部web server對應一部mysql server，而web server會對mysql server中的兩個以上資料庫進行存取動作時，pconnect反而會降低效能而失去了使用pconnect的原意。我找到一個簡單的例子來比喻這種情形。從 web server 那邊提出資料存取需求時，有時是針對第 1 個資料庫（DB1），有時則是針對第 2 個資料庫（DB2）。若我們也將 MySQL 與 web server 的「同時連線數」都調整為 200，這樣一來，就好像 MySQL 這邊有 200 位「服務生」，但同時經營兩個「吧台」（DB1 與 DB2），而「顧客」可能多達 200 位。

　一開始，DB1 這個「吧台」比較熱門，MySQL 派了 150 位「服務生」上場接待；同樣地，當「顧客」離開之後，這 150 位「服務生」仍守著 DB1 而不下場休息。後來，DB2 那邊也熱鬧起來了，「顧客」越來越多，MySQL 得加派「服務生」上場，有幾個能派？答案是 50 個！

　為什麼「服務生」的人力調配會捉襟見肘？那是因為 web 那邊使用了 mysql_pconnect來建立連線。「服務生」一開始被指定到哪個「吧台」工作，就會持續在那邊停留，絕不「轉台」。

可想而知，假如還有DB3、DB4……等等，情況就更糟糕了。沒有錯，事實上就是如此，所以說pconnect的原意是希望增加主機的效能，但是實際上使用的情況來說，只對一個web server對應一個mysql資料庫存取時有效果，可想而知，以虛擬主機來說，並沒有這樣的環境來適合pconnect函式使用，反而還是比較適用於connect函式。到此我們可以得到一個結論就是，在虛擬主機上，反而是使用connect的函式可以更適用並節省主機效能。

再來，從php的官方網站可以查詢到，pconnect這個函式是不會在查詢完成後就關閉，而是會等待一定時間，這個時間可以由MYSQL上的wait_timeout設定，而且mysql_close並無法關閉pconnect所開啟的連線，只能關閉connect所開啟的資料庫連線。當然如果沒有CLOSE在經過TIMEOUT時間之後也是會被DB DROP掉。因此主機上的設定可以把timeout的時間縮短，來讓已派出去的服務生下場休息，而不用空等再沒人的吧台上。關於這一點，我已經檢查過公司所有linux主機的mysql中的timeout設定，均已修正為20-30秒，以避免用戶使用了pconnect函式帶來的主機上的負擔。

最後，我們來看看幾個常用的php的套件，xoops，OSC，phpBB，等等程式，他的設定中，如何變更使用connect或是pconnect。

Xoops：

進入xoops的安裝主目錄中，可以看到其下有個mainfile.php的檔案，開啟它，找到define(‘XOOPS_DB_PCONNECT’, ‘0′);這一行，如果設定為0就不使用pconnect，相反的如果設定為1就是要使用pconnect。簡單吧！

OSC：

其實OSC在安裝時就已經會提示是否要使用pconnect，若工程師協助安裝時，可以注意一下這部分不要使用pconnect，就是保持連接這一項不要勾選就好。

假如已經裝完了要怎麼改呢？來吧，我們進到OSC的主目錄下，編輯includes/configure.php這個檔案，找到define(‘USE_PCONNECT’, ‘false’);這一行，沒錯，false就是不使用pconnect了，如果是true呢，當然就是使用pconnect囉。

phpBB：

進到phpBB的安裝目錄中，在db/裡面可以找到幾個資料庫連接的程式，看用戶在安裝時他是選用連接到哪一種資料庫我們就修改哪個檔案，其實基本上我們直接進到mysql.php及mysql4.php中去修改好了，兩個檔案長得差不多，進去編輯它，找到function sql_db($sqlserver, $sqluser, $sqlpassword, $database, $persistency = true)這一行，把$persistency = true改成$persistency = false就好了。

其他的套件相信工程師們都能舉一反三找到正確的設定檔案，我就不再舉例說明了。

    初入社會的小伙子，滿懷著衝勁，在學校學了這麼多年，總想把很多理想及抱負施展開來，但是短短的工作幾年，很多人都會發現，當初的衝勁沒了，原來的抱負如今已不復見，反而充滿的是更多的抱怨，責備。是不是只要是身處團隊就存在這些問題？其實男生大部分都當過兵，當兵的時候都知道所有的回答只有「是，長官！」雖然不是很民主的行為，但也因此所有的工作都必須自己想辦法克服，那時候從來沒有想過抱怨，責難，也不會去想為什麼這倒楣事會到我頭上，更奇怪的是，所有事情居然也都能如期完成，現在怎麼都不是這樣呢？軍中生活不也是一樣的是一個團隊嗎？

    當然兩種環境不能混為一談，但是如作者所言，當兵時因為服從的關係自然無法產生小媳婦心態，所以沒有這樣的困擾，那是否說明現在的環境下，如果摒棄了小媳婦心態，一樣可以把事情做得很好呢？無限上綱一下，大陸近幾年的進步發展，不也是因為他的不民主而呈現出來的嗎？因為不容許異樣的聲音，可以很容易的進行各種的建設及發展。挺有意思的！

    拖延，也是一種常見的弊病，團隊越大，拖延所產生的影響就越大，有行軍過的人都知道，行軍時最怕的就是拖隊伍，前面只要一拖，後面的人幾乎就得一路用跑的才能趕上，行軍的隊伍越長，這樣的現象就越明顯，怪了，在當兵的時候就知道的事怎麼到了現在還是沒法想到。   

    團隊中也會常常聽見，為什麼某某部門不能做的更好，為什麼某某人沒有把事情處理完…沒錯，我們的確可以常常聽見這樣的抱怨與責難，但是這對於團隊來說是不利的，要記得，所有人都在同一條船上，不管是某某部門或是某某人，都是同一個團隊的，在團隊中忌諱的是個人英雄主義，同樣的，對於想個人化的想法也是非常不利的。每個人都知道我們無法改變別人，能改變的只有自己，是這樣沒錯吧！今天約會遲到了，常常聽見的理由是台北的交通真差，又塞車了，我們會說，知道會塞車是不是提前出門就好了呢？沒錯，既然我們不能改變會塞車的事實，我們可以改變的就是提早出門，對啊！山不轉路轉，路不轉人轉，改變自己來迎合現狀，上述的問題都不復存在。

    有個朋友，我相當的喜歡跟佩服，他從來只看人的優點，天啊，這多棒啊！去過他家之後，我發現這是他家庭教育帶給他的觀念，他們全家人都只是欣賞人的優點，常在想，這個世界在他眼中看起來會是多麼美好，與他共事至今從來沒有過任何的責難，有他在的團隊運作都是和諧的，一直以來都是一樣的處事態度，從不吝惜給他人的優點做出讚美，我相信，這樣的態度是團隊中最需要的。

最近將自己架設的論壇及部落格的資料庫存取改為UTF8的編碼方式，由於本身伺服器用的MySQL是5.0的版本，同樣的支援多語系的編碼方式，與公司新主機PLESK的主機同樣的擁有相同的特性，所以將處理的過程分享出來，若以後有用戶也有相同情況時也能瞭解處理的步驟。

  主要處理的概念很容易，首先就是將MySQL資料庫的預設編碼改成UTF8，接著將原來的資料庫匯出，經過編碼的轉換後再匯入MySQL，最後就是修改php程式的部分，將程式中在連接資料庫做讀取及寫入的動作時使用UTF8的編碼。如此便完成整個的轉換。以下就整個修改的部分詳細說明。

1.修改MySQL預設編碼

雖然MySQL4.1版之後支援多語系編碼，但由於是老外寫的程式，所以預設用的編碼還是使用latin1，我們要將預設編碼修改成我們要的語系UTF8，修改/etc/my.cnf檔案，加入如下：

[mysqld]
default-character-set=utf8

接著記得重新啟動MySQL才會生效。

2.匯出資料庫

由於原來MySQL預設編碼為latin1，所以要先以latin1的編碼將資料庫完整的匯出，除非原來的程式在讀寫資料庫時有另外設定自己的編碼方式（目前看到包括phpBB2，wordpress，xoops等等都沒有做這樣的設定，仍使用資料庫預設編碼做存取的動作），使用的指令如下：

mysqldump –uxxxx –pxxxxxx –-default-character-set=latin1資料庫名稱 > 資料庫備份檔

這樣匯出的檔案就能直接在主機上使用vi等等編輯軟體看見裡面的中文均能正確顯示。

3.修改匯出資料並重新匯入

直接修改匯出的資料，將其中包含latin1的部分全部置換成utf8，包括最開頭的「SET NAMES latin1」改為「SET NAMES utf8」，再來就是建立每個表格時的「ENGINE=MyISAM DEFAULT CHARSET=latin1;」改為「ENGINE=MyISAM DEFAULT CHARSET=utf8;」，接著存檔後將修改後的備份檔案匯回資料庫當中。指令如下：

mysql –uXXXX –pXXXXXX 資料庫名稱 < 修改過的資料庫備份檔

至此，我們已經將資料庫中的資料都改成utf8的編碼方式了。

4.修改程式

最後，當然要將程式的部分也必須修改成使用utf8編碼來存取資料庫，否則你會發現，網頁上的資料呈現出來的全是亂碼。因為資料庫已經是utf8的編碼，而程式使用latin1的編碼來讀出utf8的文字，當然會看到一堆亂碼。程式的部分就不多說，用wordpress來舉例說明即可，我的方式是在wordpress的目錄中編輯wp-includes/wp-db.php這個檔案，在 $this->select($dbname); 這一行前面加上mysql_query(『SET NAMES ‘UTF8′』); 即可。

利用一個週末的時間來將自己的php及MySQL全面更換為UTF8的編碼，主要就是希望在論壇及部落格部分能夠對於繁簡中文能有更好的支援，雖然MySQL部分已經跟上潮流支援UTF8編碼，但是奇怪的是在程式的部分還未能跟上腳步使用UTF8編碼，不過這部分應該也不會太久了。

接到用戶反應在p1上面的webmail無法正常瀏覽html格式信件，經測試確實存在此問題，所以針對問題尋找發生原因，發現到只要在郵件的表頭部份沒有加上”MIME-VERSION : 1.0”，這樣的html郵件便會無法正常顯示，因此針對郵件的編碼進行了相關的了解並分享。

在原來e-mail的格式中只能傳送ASCII的文字資訊，ASCII為7位元的代碼，因此在傳送中文字等等的8位元字符便會出現問題，也因此需要將8位元字符集利用編碼的方式編成7位元的ASCII碼，以解決在傳送中文信件時出現的編碼混亂問題。至於編碼的方式大體來說有UU、MIME、BINHEX三種編碼標準

一、UU 編碼（unix-to-unix encoding)

uuencode和uudecode原來是早期unix系統使用的編解碼程式，其內部所用演算法為Base64，後來被改寫成為在DOS下運行的可執行程式。

UU 使用方法為：在進行郵件發送前，在dos方式下先用 uuencode.exe程式將原文件編碼成ASCII檔，然後再進行發送。收件人在接到後再用uudecode.exe程式將檔還原。

這是 DOS 下的編碼程式。在windows下類似的程式還有wincode和winzip等， wincode的使用原理同DOS下的uuencode、uudecode相同，只是利用了 windows 的介面，從而使操作更為簡便。wincode程式除支援 UU 編碼外，同時支援 mime，Binhex等編碼格式，應用範圍頗為廣泛。

UU 編碼並非只能對中文進行編碼，任何你要寄出的檔包括 .exe 等二進位檔都可按照編碼——> 發送——> 收信——> 解碼還原的步驟進行傳送。

二、MIME（Multipurpose Internet Mail Extention）標準的編碼

UU 編碼解決了 E-MAIL 只能傳送 ASCII 檔的問題，但我們可以從編解碼的過程看出其運用並不很方便，因而隨後又發展出一種新的編碼標準即 MIME（ Multipurpose Internet Mail Extention ）譯作“多媒體郵件傳送模式”。顧名思義，這種編碼標準支援傳送多媒體檔，可在一封電子郵件中附加各種格式的檔一起發送。

其實 MIME 定義的是一種編碼規格，亦或可以說是一類編碼的統稱，能夠符合 MIME 標準的編碼方式並非一種，而只要符合 MIME 規格便可順利傳送，在 MIME 定義下有兩種編碼方式 Base64 和 QP ( Quote-Printable ），QP 的規則是對資料中的 7 位元無須重複編碼，僅將 8 位元資料轉成 7 位元， QP 編碼適用於非 ASCII 碼的文字內容，例如我們的中文檔。而Base64 的規則是將整個檔重新編碼成 7 位元，通常適用於傳送二進位檔。

採用 MIME 標準編碼的 E-MAIL 軟體一般能自動判別你的郵件是採用何種編碼，然後自動選擇用 QP 或 Base64 來解碼。

MIME 標準現已成為 Internet 電子郵件編碼的主流。它的好處是以物體作為包裝方式，可將多種不同檔一起打包後傳送。發信人只要將要發的檔選好，它在傳送時即時編碼，收信人在收信時同時也是即時解碼還原。先決條件是雙方的郵件軟體都必須具有這項功能。使用這種方式發、收信雙方所要做的工作非常簡單，只須選定——> 寄出，其他的全部由電子郵件軟體自動完成。由於 MIME 的方便、可靠性，愈來愈多的電子郵件採用這種方式，我們最常見的 Netcape Mail , Internet Mail 等都是採用 MIME 方式。

三、BINHEX 編碼較少見，主要用在 MAC 機上， PC 機上很少見，在此不做講解

UUENCODE 編碼判斷及解決

由於 UUENCODE 內部所用演算法為 Base64 ，其格式為：

begin 644 gx.zip Mig)0;….

…

end

其格式特徵為在亂碼之前會有“ begin xxx ”後緊跟被編碼的原始檔案名稱，然後跟編碼信件內容，在最後一行為“ end ”。

具體方法有：

（1）、將 Uuencode “亂碼”郵件轉寄到自己的郵箱中，再使用能夠支援UU 解碼的電子郵件接收程式 ( 如 Eudora 、 OutLook Express 等）來接收該郵件。

（2）、通過剪輯板將 Uuencode “亂碼”存入文字檔案，改檔案名尾碼為UUE ，然後使用 Winzip 解碼。

（3）、將 Uuencode “亂碼”存入一個檔，然後在 DOS 下用 uudecode.exe 程式將檔解碼。

（4）、將 Uuencode “亂碼”存入一個檔，然後在 Windows 下用 Wincode 解碼。

Wincode 除支援 UU 編碼外也支援 MIME、Binhex 等編碼格式。

MIME 方式編碼判斷及亂碼解決方法

（一）、 Base64 encode 編碼判斷

Base64 大體格式為：

MIME-Version：1.0

Content-type:text/plain;Charset=』us-ascii』

Content-transfer-encoding;base64

….

在亂碼前一般有以下幾部分“ 信頭”：Content – type（內容及類型），Charset（字元集）及Content-Transfer-encoding（內容傳輸編碼方式）從以上資訊非常好判斷，解決方法有：

（1）、將 Base64 encode “亂碼”郵件存成一個文字檔案，改檔案名尾碼為 .UUE，然後使用 Winzip 解碼。

（2）、將 Base64 encode “亂碼”郵件存成一個檔，將檔尾碼改為 .EML，由 OutLook Express 打開，就可以自動解碼。

（二）、QP 編碼判斷

QP 編碼大體格式如下：

=A1A=B1Z=A6N=A1I=AT=DA

….

採用 QP 編碼的信件也很容易判斷，只要亂碼內容有很多符號“= ”就可判斷為 QP 編碼，QP 亂碼解決方法有：

（1）、將 QP-encode “亂碼”郵件轉寄到自己的郵箱中，然後用支援 QP 解碼的電子郵件接收程式（如 Netscape mail、Eudora、Out Look Express、Becky 等）來接收該郵件。

（2）、使用Winzip對Quoted-Printable解碼。必須注意:

　　(a) 在郵件信頭中檢查、添加這樣兩行:

　　　　Mime-Version : 1.0

　　　　Content-Transfer-Encoding: quoted-printable ;

　　(b) 信頭中間不要空行，信頭和信體之間要有一個空行。改尾碼名為UUE，即可雙擊啟動Winzip得到解碼。

由於一般人使用outlook/outlook express收發信件較多，而中文地區的outlook中針對郵件編碼的部分已經預先設定好編碼方式，因此若信件表頭中沒有指定編碼方式的信件仍可正常解碼出來看見正確的中文字，也因此有相當多的郵件因此在表頭不遵循規範指定編碼方式，才會產生在plesk的webmail中無法正常顯示html格式的信件。