一般在賣場結帳時，會看到店員翻轉商品並掃描張由直線組成的條碼，掃描完成收銀機便可立即顯示出商品名稱以及售價。近一年因 COVID-19 而要求大家進入公共場所需要掃描的 QR code 也是條碼的一種，只是單位面積可以儲存的資料量更多 (資料密度更高)。以下貼出幾種常見的圖形條碼。
「一維條碼」指的就是這種條碼只由直線組合而成，常見的商品條碼就是條碼的一種。依照不同的檢查碼、線條格式等，還可以細分成很多種，但大致上就是長得像 UPC code 這樣：
由於在相同面積，一條條碼可以儲存的資料有限，所以後來做出了 PDF 417 這種以方格組成的條碼：
接著為了更複雜的需求 (快速辨識圖形方向、容忍變形、容忍圖形毀損等等)、提高資料密度，開始出現了設計不一樣的長形、方形條碼 (二維條碼)，最常見的就是 QR code：
再來還有幾個比較少見的圖形條碼，像是 Datamatrix 和 MaxiCode：
在約 15 年前有嘗試想要自己做一個縮網址服務 (現在我做加長網址服務 XD)，當時用來產生 string ID 的方法有弱點，被學弟抓出來打爆 (可以被預測下一個產生出來的 ID，然後建立 unliminted redirection)。最近摸到 crunch 這個工具，在重新思考以後，終於搞清楚向 ppt.cc 請教時得到的說明是什麼意思。
先說明有問題的作法，先建立 valid characters list，URL 有部份特出字元是 reserve character (RFC3986)，所以像是 ?、=、@ 等字元有特殊用途不能被拿來當作參數傳遞，然後做「N 進位」轉成 string ID：
<?php $char = ['a', 'b', 'c', '.....', '7', '8', '9', '0'];
例如：數字是 1 時，產生出來的 ID 是 a、數字是 116 時產生出來的 ID 是 a1。當時我是依照流水號，所以 ID 是可以被預測的，導致弱點被利用。
當時得到 ptt.cc 的回覆是「先產生完 key 再隨機選取可用的 key」。
這陣子才搞懂這個說明，先用 crunch 之類的工具把所有可用的 string 都先產生出來，然後需要時再隨機選取一個 string 來當作 key/ID 使用。這個作法有些優點：
接下來要傷腦筋的，大概就是怎麼樣有效率的從 DB 隨機取 key 了。
ps. 目前使用 3 個 digits，大概就有 20 多萬個 unique string 可用了，爽。
這幾天被感冒的一些病狀搞到實在很不舒服，誰身酸痛不說，喉嚨雖然沒有很痛，但整個乾得很難說話。
另外就是整個體力下降，本來要去公司撐的一、二天，結果出門時發現連機車都快牽不動，只好乖乖請假在家。
在網路上找到了一些區分一般感冒與流行性感冒 (流感) 差異的說明，簡單練出幾個差異比較大的症狀，如下 (Blogger 居然不支援畫表格 ….QQ)：
| 症狀 | 一般感冒 | 流感 |
|---|---|---|
| 影響範圍 | 呼吸道局部症狀 | 全身性 |
| 發病速度 | 突發、漸進式 | 突發性 |
| 發病症狀 | 喉嚨痛、打噴嚏、流鼻涕 | 喉嚨痛、肌肉酸痛、倦怠 |
| 發燒 | 少發燒、或僅體溫稍微升高 | 發高燒 |
ps. 感謝 emmet 贊助畫表格 QQ
這次自己判斷可能還沒有到流感，暫時請狂睡，外加補充水份和維他命，希望週末、週日就可以恢復正常。
另外也感謝同事幫我把工作 hold 住，不然我應該會掛彩吧
在雨蒼的 Medium 看到的文章「我們該如何反思並使黑客文化更好？從Linus變得有禮貌開始說起」：
有衝突 (conflict) 表示有不同的意見、不同的解決方案，有多個不同的解決方案是好事，但並不是每個方案都適合鎖情況。魚與熊掌不可兼得，只能找到當下較為適合的方案來使用，所以需要溝通、討論，了解每種方案的優缺點。
看到 Hinet 宣佈 2018 年底中止 Proxy 服務，另外看到 gslin 的文章說「網站都走 HTTPS 的情況下，Proxy 服務能帶來的好處愈來愈少了」，當下想不出來為什麼。
查了一下資料恍然大悟。HTTPS 主要目的就是希望所有的網路資料傳輸不會被中間人 (MITM) 竊聽，當然這個和 proxy 的目的剛好互斥，proxy 的行為就是做中間人並協助將常用檔案儲存起來讓你下次使用時可以快速取得。所以走 HTTPS 的話資料是不會進 proxy 做快取的。
ref: