因工作的需要都會將outlook的行事曆同步到google calendar上，所以自然會安裝google所提供的Google Calendar Sync這工具，當設定完成要同步行事曆時，這小工具都會跳出要選取設定檔的對話框，就算選擇『始終使用這個設定檔』也是沒有用，在搜尋許久之後才找到解決的辦法，順便寫成筆記來紀錄一下。我是使用outlook2010 64位元的版本，不過應該也是適用32位元的版本。

先開啟outlook到『檔案』中的『選項』，再到『增益集』，接著請參閱下圖，預設的Google Calendar Sync的增益集是停用的，所以『執行』它就可以了。

點選『執行』之後會出現如下的圖示，把Google Calendar Sync的框框打勾，接著按確定。

完成上述步驟之後，理論上往後Google Calendar Sync要同步時，就不會再出現要選取設定檔的選項了。

1. 無線AP跟無線網卡一定要符合802.11n
2. 加密的編碼方式一定要選擇AES，不可設定為混合模式，或TKIP模式

就是第二點讓hugo一直吃盡苦頭，所以大略查了一下為什麼一定要設定為AES不可。有興趣的可以參考一下如下的資料。

AES和TKIP的區別：

TKIP： Temporal Key Integrity Protocol（暫時密鑰集成協議）負責處理無線安全問 題的加密部分，TKIP是包裹在已有WEP密碼外圍的一層「外殼」，這種加密方式在盡可能使用WEP算法的同時消除了已知的WEP缺點，例如：WEP密碼 使用的密鑰長度為40位和128位，40位的鑰匙是非常容易破解的，而且同一局域網內所有用戶都共享同一個密鑰，一個用戶丟失鑰匙將使整個網絡不 安全。而TKIP中密碼使用的密鑰長度為128位，這就解決了WEP密碼使用的密鑰長度過短的問題。TKIP另一個重要特性就是變化每個數據包所使用的密 鑰，這就是它名稱中「動態」的出處。密鑰通過將多種因素混合在一起生成，包括基本密鑰（即TKIP中所謂的成對瞬時密鑰）、發射站的MAC地址以及數據包 的序列號。混合操作在設計上將對無線站和接入點的要求減少到最低程度，但仍具有足夠的密碼強度，使它不能被輕易破譯。WEP的另一個缺點就是「重放攻擊 （replay attacks）」，而利用TKIP傳送的每一個數據包都具有獨有的48位序列號，由於48位序列號需要數千年時間才會出現重複，因此沒有人可以重放來自 無線連接的老數據包：由於序列號不正確，這些數據包將作為失序包被檢測出來。

AES：Advanced Encryption Standard(高級加密標準)，是美國國家標準與技術研究所用於加密電子數據的規範，該算法匯聚了設計簡單、密鑰安裝快、需要的內存空間少、在所有的平台上運行良好、支持並行處理並且可以抵抗所有已知攻擊等優點。 AES 是一個迭代的、對稱密鑰分組的密碼，它可以使用128、192 和 256 位密鑰，並且用 128 位（16字節）分組加密和解密數據。與公共密鑰密碼使用密鑰對不同，對稱密鑰密碼使用相同的密鑰加密和解密數據。通過分組密碼返回的加密數據的位數與輸入數據相同。迭代加密使用一個循環結構，在該循環中重複置換（permutations ）和替換(substitutions）輸入數據。

總而言之AES提供了比 TKIP更加高級的加密技術， 現在無線路由器都提供了這2種算法，不過比較傾向於AES。TKIP安全性不如AES，而且在使用TKIP算法時路由器的吞吐量會下降3成至5成，大大地影響了路由器的性能。

PDFCreator – 我想這款軟體無庸自疑應是最強大的免費轉檔軟體，可將文件轉換為pdf、png、jpg等等格式，並且有中文界面(中文語系檔)，但是很可惜的一點是在文件轉換時，並不支援unicode字元，也就是中文檔名轉換後會變成亂碼，關於此問題我有寫信去詢問官方開發者，就他們的回覆為因為pdfcreater是採用Ghostscript作為開發的核心，而Ghostscript本身為ANSI的應用程式，而目前並沒有轉換為unicode的計畫。所以官方回覆最好的辦法是將檔名命名為ANSI的格式。

CutePDF Writer – 這是一款功能非常精簡的免費軟體，只能進行將文件轉換為pdf的動作，不過重點是它支援中文的檔案名稱。在操作上也是因為精簡，所以並無任何的界面可進行設定，單純的只是將文件列印成pdf格式，如要更進階的功能建議可以參考cutepdf pro(付費版本)。在安裝過程中還需另外下載PS2PDF安裝，也支援Ghostscript，但我想如果核心一樣應該也是會有像PDFCteater相同的問題。

doPDF – 這是介於上述兩款之間的免費軟體，有簡易的使用者界面，也有支援中文語系並且有專人維護，並且也支援中文檔案名稱，在轉換的格式上僅支援pdf而已，在測試時，有發現一點小地方並不是很順手，就是我的使用習慣是將文件選擇轉換儲存位置後會將文件關閉，而dopdf的流程則是先選擇位置後，才開始進行轉換的動作(將文件送至印表機)，這造成我將文件關閉後，dopdf會無法將文件列印成pdf格式，整個卡在準備列印的程序。而另一個小缺點則是在選擇儲存位置時會有廣告的顯示。

下列將比較的三款轉檔軟體製成一張簡易的表格供大家參考。由於我的需求簡單，最後選擇CutePDF Writer來使用，畢竟我還是討厭嵌入式的廣告阿。

解決的方式一共有三種，而第一種呢我自己試後是無效，不過也貼出來參考一下。

1. 在【選項】的【外部篩選器 (External Filters)】加入【DirectVobSub (Auto-loading version】
2. 加入後在右邊的部分選取為【偏好】(Prefer)

第二種設定方式是從K-lite網站上的Q&A找到的，我有嘗試找了一下設定，不過沒找到，希望有試成功的人可以說明一下。

1. 從Codec Tweak Tool關閉DXVA

第三種設定方式比較簡單，不過我也不知道差異在哪，反正有字幕才是最重要的事。

1. 在【選項】的【內部篩選器 (Internal Filters)】中勾選【MPEG-2 Video】

「何謂UTF-8、UTF-16及UTF-32」

什麼是UTF-8？其實在Wiki中有寫到，UTF是Unicode Transformation Format的縮寫，如就字面上翻譯的話是「Unicode轉換格式」。而數字8則表示是用八個位元所組成的編碼，16就表示用十六個位元組成。如用簡單點的方式來說明這幾種格式的話，UTF-8、UTF-16及UTF-32都是用來表示Unicode的一種儲存格式。

「儲存格式」

在上述Wiki的文章內有提到，UTF-8是一種可變長度的編碼，為什麼說是可變長度，下列我將用一張表格來進行介紹UTF格式在不同編碼規則中所需的儲存大小。因Unicode所包含的範圍實在太廣，所以還是以中文的範圍進行說明。

基本上UTF-8不管在哪一個範圍，都會有長度上的變動，或許有人會問到，那儲存成UTF-8或UTF-16有什麼差別呢？下面將做一個簡單的示範來說明差異性，在純文字檔案格式內，儲存一百個相同字型並屬於Unicode Extension A的範圍，儲存成UTF-8及16格式，如下圖所示，UTF-8及16的header分別為3 byte及2 byte，所以兩者果然差了100 byte。

「BE、LE、BOM？！」

本以為沒人會看，所以想偷懶一下，既然有人問到了，就順便把它加進文章來，BE是Big-Endian的縮寫，而LE是Little-Endian的縮寫，這兩個縮寫代表什麼意思呢？以下我們將以「堃」為例，堃的unicode碼為5803，如將文件儲存成LE格式的話則會顯示「03 58」，也就是預設Windows的儲存格式，如存成BE則為「58 03」，像IBM、HP大型主機的格式。

BOM是byte-order mark的縮寫，中文叫「位元組順序記號」，想知道詳細的部份，可以參考Wiki，簡單說的話呢，BOM就是用來表示文件是儲存成何種Unicode格式的，因為UTF-8沒有順序的問題，所以我將就UTF-16做說明，如將文件儲存成UTF-16 (LE有BOM)時，並用二進位編輯器開啟時，會看到前會帶了「FE FF」的記號，而無BOM格式，就是將前端的記號拿掉，而這功能主要是用在傳輸時判斷來源檔案格式用的。

「效能」

可能有人會想做這種測試有什麼意義呢？如果我們把數千億筆的資料放到database裡可就有很大的差別了，同時也出現另一個問題，由於UTF-8是可變長度，所以「有可能」會使用較少的儲存空間，但也是因為為可變長度，所以資料庫的效能也較UTF-16及UTF-32來的差。

「murmur」

在寫完這篇文章後的不久，hugo也要離開目前所就職的公司，一切相關的知識都是從這裡開始，也從來沒想過有天會打滾在各種語系編碼當中，最後我還是要感謝一下教授我各種唬爛專業知識的ya老闆。最後如果您對於此文章有任何的問題及指教，都歡迎留言給我。

「何謂Big5」

以下轉載自Wiki

「五大碼」(Big5) 是在1984年，台灣13家廠商製作開發五大中文套裝軟體，由中華民國財團法人資訊工業策進會為五大中文套裝軟體所設計的中文內碼，所以就稱為Big5中文內碼，雖然五大套裝軟體並沒有成功，但隨著採用Big5碼的國喬中文系統及倚天中文系統先後在台灣市場獲得成功，使得Big5碼深遠地影響正體中文電腦內碼，直至今日^[2][3]。「五大碼」的英文名稱「Big5」後來被人按英文字序譯回中文，以致現在有「五大碼」和「大五碼」兩個中文名稱。

但因在制定編碼時沒有考量到人名、地名等常用字，所以像是堃、峯、喆、綉等字在以Big5為編碼的系統上是無法顯示的，如早期的Windows98。

「何謂Unicode」

以下轉載自Wiki

Unicode是由於傳統的字元編碼方式的侷限性而產生的，例如 ISO 8859 所定義的字元雖然在不同的國家中廣泛地使用，可是在不同國家間卻經常出現不相容的情況。很多傳統的編碼方式都具有一個共通的問題，即其容許電腦進行雙語環境式的處理（通常使用拉丁字母以及其本地語言），但卻無法同時支援多語言環境式的處理（指可同時處理混合多種語言的情況）。

Unicode試圖將字位（字素，graphemes）與類字位字元加以認定與編碼，而非以不同的字形（glyphs）來加以區分。然而在漢字的個案來看，這樣方式有時會引起一字多形的認定爭議（詳見中日韓統一表意文字主題）。

看上述的解釋其實有點複雜，以較簡單的方式說明則是「Unicode整合了各國不同之語系並給與標準化」，其中當然也包括了正體中文，簡體中文等。

「Big5與Unicode的差異」

接下來有了基本的認知後，應該就可以知道Unicode是一個比較大的字集，因為收錄了各國的字型，但其中的CJK，其中也包含了原本Big5所收納的字數，如下圖所示。

而這些差異字就高達7,399字，這些字也包含了大部份的人名罕字及地址罕字等。簡單講這也就是big5跟unicode的主要差異性。

這是hugo第一次寫關於中文字碼的文章，盡量是以簡單的方式來說明，雖然可能乏味了點，不過如果想更進一步的了解都可以留言給我

[正文]

現在有蠻多公司內部都會採用些gateway端的產品來阻擋使用者瀏覽網頁，或上上MSN，美其名當然是可以減少中毒的機會，但實則為希望員工可以乖乖專心上班增加效率，不過休息是為了走更長遠的路，短暫的摸魚也是工作項目之一呀！。所以這篇文章的目的主要是提供個小技巧，讓上班的時間更充滿愉快。

首先，要在外部的網路上有一台Linux或Windows的主機並且連接到internet，在這邊就以Windows為例，在主機上安裝OpenSSH，在安裝好之後，接著請在電腦管理裡的「本機使用者和群組」裡加入一個使用者，成員隸屬選user就可以了。然後開啟command mode切換到路徑"c:\program files\OpenSSH\bin\"底下，並打入

"mkgroup -l ..\etc\group"
"mkpasswd -l -u [username] ../etc/passwd"

預設SSHD的port是22，如果想修改的話可修改路徑底下"c:\program files\OpenSSH\bin\"的sshd_config此檔案。在一般的公司來說，都會開放port 80 & 443，所以可以把port改為443，設定完成之後可在command mode下打入net start opensshd來啟動sshd的服務，如此SSH Server就完成了。

主要的SSH服務有了，剩下的工作就是如何從公司內部連至SSH主機了，在Client端我個人是使用Tunnelier，安裝過程很簡單，只要下一步就可以安裝到完了，開啟程式會如下圖所示：

程式畫面

在Host的地方打入您所架設SSH主機的真實IP位置，Port的位置為22(default)，如您更改為443也請填上443，Username及Password請填入剛才在本機上所新增的使用者帳號及密碼(Initial Method選擇到Password模式)，都設定完成後，按下左下方的「Login」按鈕，一切都正常無誤的話，在下方的對話框會顯示顯示Authentication completed

驗證成功

到這邊就算成功了80%了，在回到程式的介面，切換至Services頁面，把SOCKS/HTTP Proxy Forwarding的選項勾選起來，剩下的選項都不需做其它設定。接著是最重要的一個步驟，開啟上班的好伙伴「MSN」，點選工具→選項→連線→進階設定，在SOCKS的地方填上127.0.0.1：1080 然後按下測試，正確的話應該會顯示如下圖所述的訊息，然後您只需要輕輕的按下「登入」，您就可以在公司內部百無禁忌的瀏覽網頁及MSN了，休閒是必要的，但班還是要認真上呀。

連線測試

• 安裝Python (Python的版本限定為2.5.x版)
• 安裝Google App Engine SDK
• 建立GAE的application
• 下載proxy的主要程式fetchServer

將下載的程式碼解壓至GAE SDK的目錄底下，並修改app.yaml檔案

application: your_application_name
version: 1
runtime: python
api_version: 1

handlers:

- url: /fetch.py
  script: fetch.py

將第一行的your_application_name替換成剛所建立的GAE名稱，然後再程式碼的目錄內建立一批次檔，內容是

appcfg.py update ../fetchServer

這樣便可將程式碼上傳到GAE內，首次上傳的話會尋問帳號及密碼。我想到這步驟應該是不會有太大的問題，而且也成功了一半。接著下載使用者端介面GAppProxy，開啟介面，並選擇「Use FetchServer」填入您的GAE網址，如下。

http://your_application_name.appspot.com/fetch.py

輸入好之後先按SAVE，並關閉程式，然後再開啟一次，並先按hide隱藏在系統列，最後的步驟就是要設定瀏覽器的proxy設定了，將Proxy的IP設定為127.0.0.1，Port是8000然後儲存，要測試是否work可以到What IP這網頁來做檢測，如果正確，則IP的位置應該會與原本的不一樣，並且在HTTP Referer的位址會顯示GAE的網址，如下圖所示：

不過在使用上還是有一些問題存在，在官方的開發網頁也提到登入到某些網站時會造成無法登入的狀況，不過就一般「瀏覽」的狀況是沒有問題的，有了好用的proxy當然要測試一下特殊的功能，有在下載免空的朋友應該都知道zshare是很難下載的，我有嘗試透過此proxy要下載，不過結果是令人失望的，有辦法截取到檔案名稱，但是無法下載，或許在之後的版本可解決此問題。懶的架的人可以使用hugo的GAE網址

http://the-voice-proxy.appspot.com/fetch.py

「Plugin」

其實1.5最大的不同是在於它有加入了一些plugin，在安裝時會先尋問是否要安裝security的plugin，主要是增強安全性方面的部份，在第一次執行的時候會出現下列視窗，來確認有哪部份是需要加強的。

在安裝完security plugin後，它很聰明的就會幫你判斷檔案到底安不安全，當然此部份比較限於系統本身的檔案，像MSN它就沒辦法判定了。

另外在網站上也有提供plugin下載，我簡略的翻譯一下，介面如下圖

•Kernel Info^Beta：關於系統核心物件的信息(不支援64位元的OS)

•System Info^Beta：更多關於作業系統的detail信息

•WMI Browser^Beta：可觀看系統WMI的瀏覽器

使用方式：解壓縮後放在plugin資料夾內即可

「Main」

主程式的介面並沒有太大的變動，在Monitoring底下多了一個「Modules」，這部份是顯示關於目前系統會載入的dll檔。

另外我也覺得有一個很棒的功能是在Main底下「build system report」，可以建立非常詳盡的報告。

「Bug」

其實目前主要的問題還是中文字型會被切掉，在回報給作者之後，他的回覆是在內部的版本己經修正，一併放在stable版本release，這點我抱持的懷疑的態度，因為我在之前的1.4版就有提出此問題了。

「整體」

就整體的使用層面來看，SE真的要比系統自帶的工作管理員要強大上許多，連啟用時吃的資源都相對的較少，不過因為1.5版啟動時要載入外掛，所以開啟的時間會比taskmgr稍慢個三秒左右。而且在某些功能還可以直接抓取reg的位置，讓人省掉搜尋的時間，我覺得目前可以加強的部份是Uninstall的選項，個人比較喜歡像Your Uninstaller般在刪除後，會再次掃瞄registry來確定是否有移除乾淨。整體而言，SE真的是一個不錯的工具，而且重點他是「免費」的，而且我已經使用它來取代工作管理員了。

在工作上的有遇到外字轉PDF的問題，至於要怎麼轉就不在此篇的討論範圍內，此文章主要討論如何判定PDF的正確性，其實最簡單的方式就是開啟PDF並按「Ctrl + D」來檢示內容，如下圖所示

一份正確的PDF必定會把字型內嵌進去，在客戶那邊有遇到一個問題，就是字型沒有嵌入進去，如下所示，

但開啟PDF一樣可以看到正確的字碼，但要如何的判斷此份PDF文件是否正常? 正確的PDF文件是可以copy & paste的，只要copy PDF的一段文字，並貼在notepad上，如可顯示copy的文字，這表示至少此PDF文件還算正常，在我客戶的例子是沒辦法正確的貼上，這時就要使用ultraedit來看一下PDF的「字碼」是否正確了，從PDF挑了「訊」這個字，訊的big5碼是「B054」，Unicode碼是「8A0A」，我在同一份PDF裡面挑了兩個不同位置的「訊」字，理論上就算位置的不同，但字碼還是一樣要相同，奇妙的事情發生了，如下圖所示，

訊字是用4 byte所顯示，而且兩個訊字的碼位都不同，在UTF-8的格式裡面，只有Ext.B字面才會用到4-6 byte，UTF-16也是在Ext.B才會用到4 byte，由此可以看出此份PDF確實是有問題的。

後來尋問了一下客戶是用什麼方式轉PDF的，對方告知是用ReportViewer來轉存的，搜尋了微軟，發現如下兩篇文章文章一、文章二，更可以確定目前ReportViewer轉存PDF是有問題的。