Zeroplex 生活隨筆

不多說，連結是：https://term.ptt.cc

---

這次會讓我比較興奮的是從 telnet 通訊協定，換上 HTTPS + websocket，這樣帳號密碼傳送就安全很多了。

其實叫早之前也是可以使用 SSH 連線：

ssh bbs@ptt.cc

ssh bbsu@ptt.cc   # UTF-8 版本

---

翻了一下 source code，這次網頁有用心處理編碼轉換問題，一開始就載入了 big5 <-> UTF-8 對應表。接下來就全部使用 websocket 連線了。

今天又遇到相同的問題，解法有很多種，可以從 SQL 下手，也可以在 table schema 就先做好設定。

SQL 強制區分大小寫

假設原本的 SQL 為：
SELECT * FROM users WHERE name = 'john' ;

這樣會撈出「John」、「john」等結果。那麼可以要求 MySQL 使用 binary 的辨識方法去做搜尋：

SELECT * FROM users WHERE binary name = 'johhn';

這樣一來，查詢時 name 欄位就會區分大小寫來做查詢。

修改 table schema

如果在設計 table 時，就確定查詢一定要區分大小寫時，可以在 create table 就先將欄位設定好：

CREATE TABLE users (
    name varchar(100) binary
)

這樣之後下 query 時，只要遇到 name 欄位，就自動會區分大小寫。

修改 collation type

一般常用的 collation 是「utf8_general_ci」，該 collation 最後面的「ci」其實是「Case Insensitive」的意思，也就是不區分大小寫。

如果要讓該 table 的所有欄位都區分大小寫，可以將 collation 的 postfix 改為「cs」或是「bin」，例如：

CREATE TABLE user (
    name varchar(100)
) COLLATE utf8_general_bin ;

以上三個區分大小寫的方法 scope 差異頗大的，可以挑比較適合當下情況的方法來使用。

KRACK 問題不是僅針對特定 WPA 戰點的問題，而是通訊協定上面的問題，基本上各家廠商都需要為了這個漏洞進行修補。

BleepingComputer 網站上的作者，已經至各大 wifi 供應商搜尋官方回應以及解決 KRACK 的動作，可以看到 Cisco、D-Link、DrayTek、MikroTik、Netgear、TP-Link、Zyxel 幾乎都有動作了：https://www.bleepingcomputer.com/news/security/list-of-firmware-and-driver-updates-for-krack-wpa2-vulnerability/

補充：Github 這邊有更詳細的整理


至於 ASUS 呢？官方討論區一堆人在問，但是官方完全沒有回應。這可能會是以後我買 wifi AP 的一個評分項目 .....

T 客邦看到「破功確認！KRACK破解 WPA2 原理已公開，你家的無線路由器還安全嗎？」，是在於 wifi 路由器和 client 做金鑰交換時，原本擔心擔心環境中的訊號傳遞不好，所以在金鑰交換協議上制定在雙方都沒有確認金鑰交換成功時，可以再次跑一次金鑰交換的流程。

比較尷尬的是，這份金鑰交換的協議並沒有制定怎麼樣才算交換成功，而中止流程。所以駭客只要發出金鑰交換的訊號，client 以為要再次跑流程時就會中招。

看起來目前的解決方法，就是先降低 wifi 訊號強度，讓只有 wifi client 所在環境才收的到訊號，讓偽造的金鑰交換訊號沒辦法進入 wifi 使用環境範圍內。再來就是等 wifi 的通訊協定更新了。

gslin 這邊提到，走 wifi 最安全的方法還是用 VPN。總之，電磁波是任何人都可以收到的，有無線網路至少、至少都要使用有 HTTPS 的加密通訊。

最近用手機追新聞有感，分享一下心得。

由於行動裝置的使用量漸漸超越了桌上型電腦，而行動裝置為了攜帶方便體積本身就小，連帶的螢幕也較桌上型電腦小很多，因此不少網路服務也跟著建立行動裝置專用的網頁，像是自由時報就有針對行動裝置客製化網頁：



有留意的話可以發現行動版網頁的網址和供一般電腦瀏覽的網址是不一樣的，如了全幅廣告不說，網頁寬度、排版方式都看電腦版不同。

這時如果覺得文章不錯，透過行動裝置分享道社交平台上，別人如果是使用電腦開啟時，則會出現這樣的畫面：


別人就會變成使用超大螢幕來看超小版面的新聞，而且還有全幅蓋版廣告喔 XD

如果有 sense 一點的人，可能會想試著把網址「http://m.ltn.com.tw」改成「http://www.ltn.com.tw」嘗試開啟一般網頁版來閱讀，可惜自由時報沒有這個設計，改完網址只會顯示 404 找不到網頁 (但蘋果日報將網址改為 www 開頭以後是可以正常瀏覽的，這個設計頗為貼心)。

那什麼樣的設計才能同時滿足行動裝置以及一般電腦呢？可以參考 Wikipedia。

Wikipedia 使用 Responsive Web Design (RWD) 來讓瀏覽器自動判斷裝置、螢幕大小，並自動更換成適合閱讀的版面。即使網址相同，在不同裝置上可以呈現不同的畫面，讓使用者方便閱讀。

只是一自己的經驗，要設計一個讓不同行動裝置都可以正常瀏覽、顯示符合需求的 CSS，費工又費時，就看業者到底想要給使用者什麼樣的體驗了。

curl 在 PHP 中是以 extension 形式存在，所以只能透過 resource reference 去操作 curl 行為，沒辦法透過 debug 工具摸清楚 curl 在背景到底做了哪些事情。

手癢用 memory_get_usage() 看了一下 curl 在 init、exec 以及 close 這幾個狀態的記憶體使用量，來猜測 curl 到底怎麼運作。

echo memory_get_usage() . "\n"   // 236136;

$ch = curl_init();
var_dump($ch);                   // resource(4) of type (curl)
echo memory_get_usage() . "\n";  // 237472

在 init_curl() 以後，會先在記憶體中 allocate 並放一些資料，所以吃掉大概 1 KB 左右的記憶體，再將 curl 的 reference 傳出來給 $ch。

這件事情應該要從 FreeBSD 6 左右的 make build world && make install world 開始說起。每次 build world 以後，新版的 tool chain 設定檔可能都會有小部份的更新，可能是多幾個功能可以設定，或是把一些舊的功能拔掉，這時 install world 時為了擔心使用者改過的 config 檔直接被覆蓋掉，都會先做一次 diff 讓使用者確定設定檔更新以後不後搞垮系統。但有半數以上的 diff，均為 config 中開發人員的註解，像是「2005/xx/xx 最後更新」之類的，單單處理這類的 diff 就可以耗掉數十分鐘。

現在大家在寫程式時，應該都有習慣將 source code 放進 version control system (VCS) 中，方便做版本管理以及除錯。VCS 除了能夠協助開發者幫不同的修改留下記錄以外，也支援版本之間的比較、建立補丁 (patch) 等功能，讓開發者可以專心在功能的開發上。

既然 VCS 已經協助開發者記錄了這麼多東西，那有哪些是開發者已經不需要寫在 source code 裡面的呢？

• 日期：大多數的 VCS 在開發者 commit 時就會記錄日期，開發者有修改時不必特別在程式中註解修改日期，只要 commit 時將 commit message 寫好讓其他人看得到、搜尋的到即可。
  
• 作者：每個開發人員在 VCS 都會被視為不同的 commitor，所以哪個 commit 是誰送、甚至哪一行是誰修改的都有記錄。把修改原因寫清楚比較重要。
  
• 註解掉不使用的程式碼：因為 VCS 會保留從古到今所有的程式碼異動，所以大可不用擔心程式碼刪除以後無法還原，若發現某一段程式已經不再使用了，就放心的把他刪掉吧，萬一誤砍了還是可以透過 VCS 復原回來。(如果 VCS 做不到這個功能就換一個吧 XD)
  
• 與專案無關的 binary：大多數 icons、font、design files 都會與專案的版本一起演進，放進 VCS 是應該的。但與專案週期不同、或為一次性用途的 binary 檔案，如週年慶的活動圖片設計、影片等，就不適合放進 VCS，若真的有版本管理需要，應該另外開一個 repository。
  
• symbolic link：恩 .... 有事嗎？