PHP中的session有效期問題

http://translate.google.com.tw/translate?hl=zh-TW&sl=zh-CN&u=http://www.bloggern.com/3325.html&sa=X&oi=translate&resnum=8&ct=result&prev=/search%3Fq%3Dsession.gc_probability%26complete%3D1%26hl%3Dzh-TW%26sa%3DG%26pwst%3D1

滿好懂的

PHP中的session有效期問題

PHP中的session有效期默认是1440秒（24分钟），也就是说，客户端超过24分钟没有刷新，当前session就会失效。 PHP中的session有效期默認是1440秒（24分鐘），也就是說，客戶端超過24分鐘沒有刷新，當前session就會失效。 很明显，这是不能满足需要的。很明顯，這是不能滿足需要的。
我在前几年就遇到过这个问题，在网上一搜，出来的结果千奇百怪。我在前幾年就遇到過這個問題，在網上一搜，出來的結果千奇百怪。 有的说要设置“session_life_time”（我没有找到这个参数），有的说要调用session_set_cookie_params，有的说要设置session.cookie_lifetime，有的说要调用session_cache_expire。有的說要設置“session_life_time”（我沒有找到這個參數），有的說要調用session_set_cookie_params，有的說要設置session.cookie_lifetime，有的說要調用session_cache_expire。 但这些方法没有一个管用。但這些方法沒有一個管用。
一个已知管用的方法是，使用session_set_save_handler，接管所有的session管理工作，一般是把session信息存储到数据库，这样可以通过SQL语句来删除所有过期的session，精确地控制session的有效期。一個已知管用的方法是，使用session_set_save_handler，接管所有的session管理工作，一般是把session信息存儲到數據庫，這樣可以通過SQL語句來刪除所有過期的session，精確地控制session的有效期。 这也是基于PHP的大型网站常用的方法。這也是基於PHP的大型網站常用的方法。 但是，一般的小型网站，似乎没有必要这么劳师动众。但是，一般的小型網站，似乎沒有必要這麼勞師動眾。
在PHP的文档中明确指出，设定session有效期的参数是session.gc_maxlifetime。在PHP的文檔中明確指出，設定session有效期的參數是session.gc_maxlifetime。 可以在php.ini文件中，或者通过ini_set()函数来修改这一参数。可以在php.ini文件中，或者通過ini_set()函數來修改這一參數。 问题在于，经过多次测试，修改这个参数基本不起作用，session有效期仍然保持24分钟的默认值。問題在於，經過多次測試，修改這個參數基本不起作用，session有效期仍然保持24分鐘的默認值。
由于这个问题并不是特别重要，当时也没有继续研究下去。由於這個問題並不是特別重要，當時也沒有繼續研究下去。 一直到前不久才彻底搞明白。一直到前不久才徹底搞明白。
由于PHP的工作机制，它并没有一个daemon线程，来定时地扫描session信息并判断其是否失效。由於PHP的工作機制，它並沒有一個daemon線程，來定時地掃描session信息並判斷其是否失效。 当一个有效请求发生时，PHP会根据全局变量session.gc_probability/session.gc_divisor（同样可以通过php.ini或者ini_set()函数来修改）的值，来决定是否启动一个GC（Garbage Collector）。當一個有效請求發生時，PHP會根據全局變量session.gc_probability/session.gc_divisor（同樣可以通過php.ini或者ini_set()函數來修改）的值，來決定是否啟動一個GC（Garbage Collector）。 默认情况下，session.gc_probability ＝ 1，session.gc_divisor ＝100，也就是说有1%的可能性会启动GC。默認情況下，session.gc_probability ＝ 1，session.gc_divisor ＝100，也就是說有1%的可能性會啟動GC。
GC的工作，就是扫描所有的session信息，用当前时间减去session的最后修改时间（modified date），同session.gc_maxlifetime参数进行比较，如果生存时间已经超过gc_maxlifetime，就把该session删除。 GC的工作，就是掃描所有的session信息，用當前時間減去session的最後修改時間（modified date），同session.gc_maxlifetime參數進行比較，如果生存時間已經超過gc_maxlifetime，就把該session刪 除。
到此为止，工作一切正常。到此為止，工作一切正常。 那为什么会发生gc_maxlifetime无效的情况呢？那為什麼會發生gc_maxlifetime無效的情況呢？
在默认情况下，session信息会以文本文件的形式，被保存在系统的临时文件目录中。在默認情況下，session信息會以文本文件的形式，被保存在系統的臨時文件目錄中。 在Linux下，这一路径通常为\tmp，在Windows下通常为C:\Windows\Temp。在Linux下，這一路徑通常為\tmp，在Windows下通常為C:\Windows\Temp。 当服务器上有多个PHP应用时，它们会把自己的session文件都保存在同一个目录中。當服務器上有多個PHP應用時，它們會把自己的session文件都保存在同一個目錄中。 同样地，这些PHP应用也会按一定机率启动GC，扫描所有的session文件。同樣地，這些PHP應用也會按一定機率啟動GC，掃描所有的session文件。
问题在于，GC在工作时，并不会区分不同站点的session。問題在於，GC在工作時，並不會區分不同站點的session。 举例言之，站点A的gc_maxlifetime设置为2小时，站点B的gc_maxlifetime设置为默认的24分钟。舉例言之，站點A的gc_maxlifetime設置為2小時，站點B的gc_maxlifetime設置為默認的24分鐘。 当站点B的GC启动时，它会扫描公用的临时文件目录，把所有超过24分钟的session文件全部删除掉，而不管它们来自于站点A或B。當站點B的GC啟動時，它會掃描公用的臨時文件目錄，把所有超過24分鐘的session文件全部刪除掉，而不管它們來自於站點A或B。 这样，站点A的gc_maxlifetime设置就形同虚设了。這樣，站點A的gc_maxlifetime設置就形同虛設了。
找到问题所在，解决起来就很简单了。找到問題所在，解決起來就很簡單了。 修改session.save_path参数，或者使用session_save_path()函数，把保存session的目录指向一个专用的目录，gc_maxlifetime参数工作正常了。修改session.save_path參數，或者使用session_save_path()函數，把保存session的目錄指向一個專用的目錄，gc_maxlifetime參數工作正常了。
严格地来说，这算是PHP的一个bug？嚴格地來說，這算是PHP的一個bug？
还有一个问题就是，gc_maxlifetime只能保证session生存的最短时间，并不能够保存在超过这一时间之后session信息立即会得到删除。還有一個問題就是，gc_maxlifetime只能保證session生存的最短時間，並不能夠保存在超過這一時間之後session信息立即會得到刪除。 因为GC是按机率启动的，可能在某一个长时间内都没有被启动，那么大量的session在超过gc_maxlifetime以后仍然会有效。因為GC是按機率啟動的，可能在某一個長時間內都沒有被啟動，那麼大量的session在超過gc_maxlifetime以後仍然會有效。 解决这个问题的一个方法是，把session.gc_probability/session.gc_divisor的机率提高，如果提到100%，就会彻底解决这个问题，但显然会对性能造成严重的影响。解決這個問題的一個方法是，把session.gc_probability/session.gc_divisor的機率提高，如果提到100%，就會徹底解決這個問題，但顯然會對性能造成嚴重的影響。 另一个方法是自己在代码中判断当前session的生存时间，如果超出了gc_maxlifetime，就清空当前session。另一個方法是自己在代碼中判斷當前session的生存時間，如果超出了gc_maxlifetime，就清空當前session。

轉錄 Svchost.exe 吃掉 CPU 100% 資源

http://www.yannicafe.info/wp/2007/02/18/61.html

好像有用的樣子 ...

不然公司電腦慢慢 ~_~ 整個被這個檔案卡住 ...

(不知道電腦為什麼慢?滑鼠移到最右下方時間那邊點右鍵選工作管理員看處理程序!)

.sqm 刪除

這是 Msn 8.0 (Windows Live Messenger）在 c:\ 根目錄產生一堆檔案

打開 Msn -> 說明（上方功能表）-> 客戶經驗改善計畫 -> 我沒有意願

然後把檔案刪光光就好 : )

PHP、MYSQL 基本常識

[PPT]
第13章PHP 5與MySQL建立網頁資料庫
檔案類型: Microsoft Powerpoint - HTML 版在PHP程式是呼叫mysqli_query()函數來執行資料表查詢。 ... 在PHP程式呼叫mysqli_query()函數，執行參數的SQL指令來查詢資料表，如下所示： ...www1.pu.edu.tw/~jsyeh/2007Fall/DDWP/ppt/PHP-13.ppt - 類似網頁 - 加入筆記本 ==
這篇寫得很棒喔，我貼一點基本好用的常識
==

通常PHP技術建立網頁資料庫都是搭配MySQL資料庫系統，從90年代中期開始，ext/mysql擴充程式一直擔任PHP與MySQL資料庫間的橋樑，提供相關函數讓我們在PHP程式存取MySQL資料庫。

但是，PHP 5和MySQL 4.1版之後，ext/mysql擴充程式的相容性問題一一浮現，因為ext/mysql沒有辨法支援MySQL 4.1之後版本的新功能，所以Georg Richter建立一套全新支援PHP 5的MySQL擴充程式，稱為ext/mysqli，可以支援MySQL 4.1之後版本的新功能

易維護與高相容性：在ext/mysql需要使用複雜方式來使用MySQL的新功能，而ext/mysqli可以很容易作到，ext/mysqli擁有與MySQL Client Library更佳的相容性，換句話說，未來MySQL的新版功能，ext/mysqli也可以輕易支援。

更快速和更佳的安全性：ext/mysqli不只執行速度最高可比舊版ext/mysql快40倍，而且ext/mysqli支援新版MySQL的密碼雜湊（Password Hashes）和驗證程序，提供比舊版更佳的安全性。

===


當開啟資料庫連結後，如果不再需要存取MySQL資料庫，PHP程式可以呼叫mysqli_close()函數釋放資料庫連結資源佔用的記憶體，以便有效運用伺服器的記憶體資源，如下所示：
mysqli_close($link);
上述函數的參數是mysqli_connect()函數傳回的物件變數，成功關閉傳回true，否則為false。

===

資料表查詢結果的結果物件會佔用伺服器的記憶體空間，當不再需要查詢結果時，在PHP程式請記得自行釋放佔用的記憶體空間，以免浪費伺服器的寶貴資源。

在PHP程式是呼叫mysqli_free_result()函數釋放結果物件佔用的記憶體空間，如下所示：
mysqli_free_result($result);

宅宅的怒吼！

最近做了一個外籍新娘的網站 Case 有感而發

台灣目前仍是男生數量 >> 女生數量
因此女生要來得比男生寶貴地多

其實男生女生都一樣，最常聽到的是女生希望男生要有三高，其實我也忘了是哪三高，好像是身高、學歷、錢錢吧？

這也不能說女生市儈，男生也一樣，也希望自己女朋友是個長得正、身材好、溫柔又體貼 ...

現在的感情價值就像速食麵，很早就已經開始談戀愛，就連性也是一樣，大家合著來不合就分，很快就換下一個了 ...

可是對於一些一直都找不到伴的人 ... 常常看這些人換過一個又一個，覺得自己條件不差，「人又好」，每每都有男生或女生抱怨自己交到壞人，怎麼我那麼「好」都沒人要呀 ...

在偶然一次看到討論外籍新娘，我發現其實並不是條件差的才要找國外，事實上他們的條件都不錯呀 ...

http://www.angus.com.tw/main.asp
烏克蘭（看看就好，我並非要替這間公司打廣告 ... 這間公司好不好我不知道）

如果我有個兒子或女兒，一直交不到對象，我會跟他（她）說，好好充實自己 ... 爸爸會買一個好對象給你（妳） ... 科科～

外籍配偶就一定差嗎？也不一定吧 ... 我是抱著很樂觀的態度，有些人的眼睛真的是長在頭上，那就讓那些頂端的人去玩吧～

elf - 龍騎士四 復刻版 ( windows )

在介紹這款經典遊戲重製成 Windows 版之前，先介紹此公司首頁一進去的主打遊戲「媚肉之香」，是一款很暗黑的遊戲呀 ...

http://www.elf-game.co.jp/

很佩服能寫出這種劇情，不過在日式H-game幾乎都是大量文字的主流下，也造就了許多寫H劇本的鬼才吧，隨隨便便就讓男主角神力見人就亂上的故事應該比較少見了。（雖然大部份玩家還是下載完遊戲先裝破解檔看圖就砍了 ...）

這款遊戲的圖與動畫做得真是精細呀，仔細了解內容應該也會有多少的罪惡感吧 ...（汗）

接下來就是主題龍騎士四了，老遊戲 Dos 版就不再提了，能玩到復刻版真的只有感動呀～再加上開頭的音樂 ... 回到了小時候的時光（淚）

如果說 Dos 版難度是 10 的話（其實也不難啦，只是為了比較），這款遊戲大概就只剩 1 了 XD ...（我還沒玩到挑戰模式，以一般模式的格子戰鬥來比較）

雖然一樣是只要死一人就不能再出場，可是每個人都多了很多技能，以往只能靠恢復之泉補血，現在許多角色都有補血技了，尤其是女主角的補血，大範圍+全補 ... 根本是想死都難，還有一些輔助法術，又沒有 MP 限制，每回合都給它放賺經驗值 ...

Dos 版加減還要考慮一下走法，現在敵人 AI 降低，威力也降低，走得快的衝到前面被砍個三四下也不會死，如果種子全給一人吃，那他衝上前可以殺光全部 ...

復刻版雖然只能讓 12 人上場，不過說實在的 ... 主要角色 4 個我想就夠了 XD，選角條件就是

1. 移動力快

2. 遠距離技能

3. 輔助技能

1. 不用說了，並非戰略考量，而是走太慢敵人來不及打就死了，此關結束 ... 2. 也是，我方太強殺太快 ... 3. 的話，要是搶不到敵人，就自己放輔助技賺經驗自己爽吧 ...

H 圖重製之後，雖然圖一樣，不過解析度大增，還有 3D 的移動，外加 2D 的角色人身，實在是太感動了～日本美術的功力真是太威了 ...

MYSQL、Phpmyadmin 與網頁編碼不同步

這個問題困擾我半年了（打從開始用 Bluehost 就一直存在了）
為什麼我網頁輸進去的中文到Phpmyadmin變亂碼；然後直接從Phpmyadmin新增資料是看得到中文，但是從網頁撈出來卻也變成亂碼 ...
上網也查了，是要設定
SET NAMES ... 這條 ...
可是怎麼試就不成功

結果在今天，想說再花點時間試試，找到了一個SQL語法
SHOW VARIABLES LIKE "character_set_%";
讓我確定我的資料庫編碼是 utf8

所以之前寫 SET NAME utf-8 是錯的

再來貼一次語法到 PHP 頁面 ... mysql_query("SET NAMES utf8");
（這行加在連線與選擇 DB 之間）

暗！真的成功了，輸進去的中文，終於在 Phpmyadmin 也看得到了，這樣就可以方便備份與輸出了～耶！