難道研究PHP的人都是傻瓜嗎？

2020-03-22 19:41:09

字體：大中小

來源：轉載

供稿：網友

抱怨你的工具，并不會讓你的事情做得更好。我前一篇的「PHP 開發迷思（叁） PHP 很糟糕？」，有網友寫了一篇「 PHP 很爛」來回應。我想說的是：對他來說， PHP 的確很糟，所以真的不適合他；因為他引用了別人停留在三四年前的 PHP 的觀念來證明他對 PHP 的看法。還有，他看到的都是爛 PHP 程序。不可否認， PHP 的確在先天上有所不足，只因為它誕生的太早，很多包袱無法輕易擺脫。即便 PHP 6 將會擺脫這些束縛，但時間點似乎太晚？所以呢？難道研究 PHP 的人都是傻瓜嗎？當然不是。我不想為 PHP 平反什么，我也不認為我能改變多少人對 PHP 的看法。這裡我只想把這些人認為 PHP 爛的地方做個說明，剩下的就交給大家自行評斷。版本問題從 PHP 誕生以來有十五年了，真正被大家重視而開始運用的第 4 版則有十年了。然而隨著 PHP 5 的誕生，以及 2008 年 PHP 4 不再被官方維護，大部份的主機商也已經部署了 PHP 5 作為主要執行環境；雖然現階段 PHP 5 還是會讓 PHP 4 的程序能夠執行，但是開發者的觀念如果沒有一起隨著更新，那才是災難的開始。語言的設計本來就沒辦法一開始考慮周詳， Java 如此， Python 也是如此，它們在重大改版時，部份語法及相關的核心組件上本來就會有所改變。而開發者如果沒有適時去了解在新版本上的使用差異，那么跟抱怨一把生銹的斧頭很難砍倒一棵大樹有什么差別？UnicodeUnicode 在最近這幾年才開始被臺灣的開發者所重視，在那之前 BIG5 大概是他們的惡夢吧。先不管 PHP ，我們來看一下別的語言怎么處理 Unicode 。Ruby：就我粗淺的了解， Ruby 本身也不完整支援處理 Unicode ，但還是可以處理。Python：在 2.x 版也是透過 unicode 類別來處理，在 3.0 核心有直接支援。那么 PHP 呢？的確 PHP 本身沒有很方便的方法來處理 Unicode ，但是不表示它不能用其他方法來處理：mbstring：多位元組的字串處理iconv：轉換編碼PHP 6 以后則是直接把 unicode 放到核心函式裡。當然 PHP 先天的限制，會讓它在處理 Unicode 字串上無法像 Ruby 和 Python 那么直覺；但不表示我們不能透過其他方法將它封裝起來，方便后續的開發。在資料庫上的 Unicode 問題也是如此， PHP 本身不處理這些，它只是透過 client 來取得資料庫回傳的資料，這在每個語言對資料庫的實作都是一樣的。Magic Quotes一開始 PHP 有 magic_quotes 只是為了方便處理要塞入資料庫的字串，因為當時 PHP 開發者對于程序與資料庫之溝通非常不熟悉。然而，這只是資料分層處理的觀念。事實上我們根本不該對接收下來的資料做假設，如果輸入的資料是「許功蓋（BIG5）」，就讓它保持「許功蓋（BIG5）」；等到要存入資料庫時，再讓真正的資料操作函數（或物件）去處理它（像是 PDO：：quote ），而不是再用 addslashes（）或 stripslashes（）這種別扭的方式來存取資料庫。而從資料庫取得資料時也是一樣，因為我們用正確的方法塞入，所以它也會回傳我們正確的資料，這在所有語言都是一樣的！所以后來的 PHP 5.3 版本就將 magic_quotes 廢棄， PHP 6 則直接不支援。而在這之前的版本所開發出來的程序，也都是該以 magic_quotes 保持關閉的狀態來開發；遇到不確定 magic_quotes 是否開啟時，可以參考官方手冊的建議來取消它對程序的影響。SQL Injection某網友說：「填 shutdown 就能打掛一票網站，九成可能都是 PHP 寫的」，又說「我知道 SQL （Injection）是跨語言的問題，但是 PHP 就是偏偏特別容易寫出有洞的程序像這樣 SELECT * FROM User WHERE id = $user_id 然后就毀了?！刮覀€人倒認為，有九成以上會有 SQL Injection 問題的，可能是傳統的 ASP 網站。（這邊 ASP 只是舉例，不表示真的九成以上都是這樣；事實上沒有引用一個正確的統計數字，這都只是嘴炮而已，請塬諒我用這么粗俗的字眼）html教程

鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。

上一篇：PHP實例教程(4)-構建基于PHP的微博客服務

下一篇：詳解php魔術方法(Magic methods)的使用方法