PHP 的 Unquoted Strings 將在 PHP 8 被移除

Twitter 上看到 PHP 的 unquoted string 被視為字串的功能將被移除:「PHP RFC: Deprecate and Remove Bareword (Unquoted) Strings」。

常見的情境是 $_GET[bar] 這樣的用法被視為與 $_GET["bar"] 相同... 超奇怪的功能,而現在這個功能已經投票通過,將會在 7.2 被列為 deprecated,到 8 就會拿掉。

這個功能本來是標示 E_NOTICE,但比較特別的是,雖然是列為 deprecated,PHP 7.2 預定會標示為 E_WARNING 而不是 E_DEPRECATED。主要是這次的兩個目標互相衝突 (可以參考原文),取比較有效的那個 (因為 PHP 8 就不會有這個問題了,所以 PHP 7.2 的過渡期以比較容易提醒使用者的那個為主)。

投票是 100% 通過 (41/41)。

CloudFront 支援將 Query String 內的特定 Key/Value 當作 Cache Key 的一部分

Amazon CloudFront 可以指定 query string 中的某個特定的 key/value 當做 cache key 的一部分了:「Announcing Query String Whitelisting for Amazon CloudFront」,對應的文件在「Configuring CloudFront to Cache Based on Query String Parameters」這邊可以查到。

先前只能針對選擇忽略掉整個 query string,或是把整個 query string 當作 cache key 的一部分,現在可以細部調整了。

最簡單的應用可以用在 css/js 的 asset 上,針對 v=\d+ 當作 cache key 的一部分,而其他的參數可以忽略,不過這好像沒什麼特別的意義。

目前想到比較有意義的應用是針對 dynamic content 多了一些籌碼可以用,像是 Slack 把整個網站放上 CloudFront 後,應該會有很多 API 是透過 query string 傳遞參數,而這次的改變讓 CloudFront 可以細部調整。

MySQL 裡搜尋 CHAR/VARCHAR (String) 欄位時要注意的事情

MySQL 表格欄位是 CHAR 或 VARCHAR 時,寫搜尋條件要記得使用 string 格式,而非數字。意思是,要避免這種 SQL query:

SELECT * FROM foo WHERE `column_string` = 123456;

原因是即使 column_string 加上了 B-tree index,也無法利用這個 index 加速查詢。

原因是,除了最明確的 '123456' 會符合外,還有很多種 case 符合:

mysql> SELECT 123456 = '0123456';
+--------------------+
| 123456 = '0123456' |
+--------------------+
|                  1 |
+--------------------+
1 row in set (0.00 sec)

mysql> SELECT 123456 = ' 123456';
+--------------------+
| 123456 = ' 123456' |
+--------------------+
|                  1 |
+--------------------+
1 row in set (0.00 sec)

這使得 index 無用武之地。

但如果欄位本身是數字 (INT/BIGINT),搜尋時用字串反而沒關係:MySQL 會先把字串轉型為數字再比較,所以會用到 index。

總而言之:

  • 可以用 INT/BIGINT 時,不要用 CHAR/VARCHAR 儲存。
  • 使用 CHAR/VARCHAR 的欄位當搜尋條件時,要用字串形式當作搜尋條件。(除非你很清楚你在做什麼)

今天上場當救援投手時解掉的問題...

關於 Non-null string 的處理...

上一篇「Filter Input & Escape Output...」有提到 Non-null UTF-8 string 的 filter,結果剛剛洗澡的時候想了想,好像寫錯了?

問題在於「到底是先 de-null 再 iconv(),還是先 iconv() 再 de-null」的問題。

這個問題其實跟 iconv() 成 UTF-8 時遇到不合法字元時怎麼實做有關,也就是 undefined behavior... 由於 \0 是合法的 UTF-8 character,所以我們假設某一種實做是當 iconv() 遇到不合法字元時會用 \0 帶進去:

先 de-null 再 iconv()

這是上一篇文章提到的方法。但在上面提到的 iconv() 實做下卻是有問題的方法。原因很簡單,de-null 後沒有 \0 的字串,卻會因為 iconv() 而產生 \0

先 iconv() 再 de-null

這邊要考慮的是最後 de-null 後會不會變成 invalid UTF-8 string。答案是不可能,因為 iconv() 轉出來後保證是 UTF-8 string (不論如何處理非 UTF-8 character 的部份),而 UTF-8 string 內的 \0 一定可以當 separator,所以切下去一定還是 UTF-8 string。(可以參考下圖關於 UTF-8 character 的規則)

所以?

可能以現在的 iconv() 實做來說,兩者都不會有問題,但寫程式的時候總是要避免 side-effect,所以後者的方法會比前者好。

Google 對字串處理的最佳化

Google Research 上看到 Google 針對字串處理最佳化問題所發的論文:「Automated Locality Optimization Based on the Reuse Distance of String Operations (PDF)」。

大原則是想辦法善用 L2/L3 cache,這沒什麼特別的,比較有趣的地方是解決方案,除了自動化的方式外,另外還有工具「提醒」撰寫程式的人,另外還有一些數據以及 code name 可以看...