似乎由 7/21 開始, MS 的 server 伺服有些更改, 在 MSNP15 的使用上, 並不會在 USR 指令登入之後送出 SBS 的指令, 這會造成 phpmsnclass 在登入後等待 SBS 的指令而無後續的動作.

所以目前把程式修改一下, 直接在 USR 回應後就處理後續的動作, 不再依靠 SBS 指令處理.

改了之後看起來是正常了. 有使用的朋友, 請更新到 r38 或之後的版本.

在之前有提過有人寫了一個 FPDF UTF-8 簡繁中文支援的方案 (作者不是我), 不過, 有使用者反應會造成 AliasNbPages 沒有作用. 剛剛 trace 了一下, 發現在 chinese-unicode.php 裡頭, 就直接把字串轉成 unicode 內碼的十六進位字串了, 所以後來原本的 FPDF 在轉換 AliasNbPages 這個變數時, 自然不會有任何的作用.

舉例來說, 一般內定的 AliasNbPages 是用 {nb} 這個字串, 會變成 007b006e0062007d 的內容, 而在原本的 FPDF 依然是找 {nb}, 自然不會轉換. 因此我們需要針對 chinese-unicode.php 來特別處理這個部份.

你可以在 chinese-unicode.php 的 function PDF_Unicode() 之後,  加上一個 function Uni_putpages() 如下:

function Uni_putpages()
{
    if(!empty($this->AliasNbPages)) {
        //Replace number of pages
 
        // find the pages alias already converted to hex string
        $search = '';
        $len = strlen($this->AliasNbPages);
        for ($i = 0; $i < $len; $i++)
            $search .= sprintf("%04x", ord($this->AliasNbPages[$i]));
 
        // replace the pages alias with page number (hex format)
        $replace = '';
        $total_pages = ''.$this->page.'';
        $len = strlen($total_pages);
        for ($i = 0; $i < $len; $i++)
            $replace .= sprintf("%04x", ord($total_pages[$i]));
 
        // replace it now
        for ($n = 1; $n <= $this->page; $n++)
            $this->pages[$n] = str_replace($search, $replace, $this->pages[$n]);
    }
}

然後在使用時, 在最後產生 PDF 之前, 記得呼叫這個 function, 如:

$pdf->Uni_putpages();
$pdf->Output();

這樣子應該就可以把頁數轉換出來了.

不過這樣子的處理, 並不保證那個轉換不會造成別的問題. 以內定的 {nb} 來說, 因為只是單純比對 007b006e0062007d 來轉換, 雖然機率不大, 還是有可能會轉錯的. 如果有碰到, 還想避免這個問題, 可以考慮弄個比較複雜的 alias 來使用吧.

更新 phpmsnclass 版本為 1.9. (閱讀全文)

在 php 官方的說明文件中, 提到要使用 ftp_ssl_connect() 必須要有 openssl 的支援才可以. 而且在 Windows 下頭, 必須要自行重新編譯一個內建 openssl 支援的版本才可以. (閱讀全文)

MySPAM v0.0.5 推出. 其實也沒改到什麼, 這些修正好像都至少有半年了. 與前一版本的差異如下:

• + 新增對同一主機多網域帳號的支援. 登入時請使用 user@domain 的方式登入即可.
• ! 檢查信件第一行是否為 'From xxx@xxx.xxx.xx' 這個非 header 的內容 (某些 postfix 有這行?), 如有就略過.
• ! 如果沒有 SIZE 環境變數, 就自行計算信件大小.

在經過之前所提過的修正之後, 的確可以在 Excel 的欄位中正確的使用 unicode 了. 不過最近在 Study-Area 有人提到 Worksheet 的名稱與列印的 Header 與 Footer 都不能使用 unicode. 試了一下, 果然不能正確使用. (閱讀全文)

話說前一陣子在 php 裡頭用到了 chmod 這個函式, 依據以往在 linux 下頭使用 chmod 指令的經驗, 加上使用 php 時, 並沒有做型別檢查的功能, 很自然的就會認為這個函式如同其他 php 的函式一般, 可以用數字也可以用字串來表示要更改的屬性. 而且, 的確在一開始的使用上, 做一些 o+w 或 o-w 之類的動作時, 都十分的正常, 一點都沒有懷疑這會有問題.

不過... 前幾天碰到了一個 g+s 的動作, 發現.... 一跑到這兒, 整個屬性反而被改成 000 了, 也就是被清空了. 這是怎麼回事呢?

想了很久, 也測了一些寫法, 最後, 終於在官方的 chmod 說明中看到, 這個 mode 參數, 只能是整數, 對於前述的字串參數來說, 是不對的. (說到這兒, 既然不允許, 是不是應該全部都失敗會比較好一些, 不要讓人誤以為可以使用, 結果... 只有某些情形下會不能用)

回頭把程式改了一下, 先取出屬性再做一堆 OR 運算, 自己弄出類似的結果, 然後再去把屬性改成自行運算後的結果, 這樣子果然就正常了. 有用到 chmod 的人, 自己注意一下吧.

一般來說, 我們在使用 php 去檢查使用者的帳號密碼時, 都是直接用該組帳號密碼去執行 ldap_bind() 的動作, 如果成功的話, 表示密碼是對的, 如果失敗的話, 表示密碼是錯的. (唯一的例外是... 如果密碼是空字串, 也會成功, 所以用這個方法要先檢查密碼是不是空的) 如:

if ($password !== '' && ldap_bind($id, "uid=$user,dc=example,dc=com", $password))
    echo "password correct!\n";
else
    echo "wrong password!\n";

但是, 如果要修改密碼時, 又該如何呢? 我們可以用下面的方式:

if (ldap_mod_replace($id, "uid=$username,dc=example,dc=com", 
        array('userpassword' => "{MD5}".base64_encode(pack("H*",md5($newpass)))
    echo "succeded\n";
else
    echo "failed";

就是先用該使用者 (或有權限改密碼的帳號) bind 之後, 去更改 userpassword 這個屬性. 使用 md5 的方式去設定密碼.

更新 phpmsnclass 版本為 1.8.  (閱讀全文)

以前, 在 FPDF 的中文支援中, 並不支援 UTF-8 編碼, 所以每次要產生 pdf 檔案時, 都要用 iconv 轉成 BIG5 或 GB 來使用. 如果同一段文字有簡體也有繁體時, 這個轉換就會有問題 (不過還好我們之前的案子, 還沒碰到這個問題, 系統把兩種編碼分開來用, 並沒有衝突的情形發生). 後來, 有人改了一個 unicode 版本的 FPDF, 雖然有支援 UTF-8 了, 但是... 作法是把字型檔也整個編入 pdf 檔案中, 結果.... 是可以使用沒錯, 但是... 原本幾 KB 的 pdf 檔案, 變成幾 MB, 根本沒有實用性. (閱讀全文)

首先, TLS 是在 Protocol Version 3 才有提供, 所以必須在 ldap_connect() 之後, 使用 ldap_set_option() 設定使用 protocol version 3 才可以. 如果這樣子處理, 並沒有辦法正確的執行 ldap_bind(), 則必須在你 client 端的 ldap.conf 中, 加上 TLS_REQCERT 這個參數, 其值為 nerver 或 allow 才可以. 如果沒有 ldap.conf, 也可以利用環境變數 LDAPTLS_REQCERT 來設定, 或直接使用 putenv() 來設定這個變數. (閱讀全文)