Recently in Web Category

wkhtmltopdf is a command line web to PDF/Image tool.
wkhtmltopdf https://google.com output.pdf
wkhtmltoimage https://google.com output.png
Linux 版本中文有問題, Windows 版本中文正常, 輸出效果還不錯

HTML5 data- 開頭是特殊屬性, data- 之後只能用小寫, 通常用來傳遞變數

例:
<button data-id='1234'>Click</botton>

jQuery 可以用 $(this).data("id")); 來取得 1234

fiddler HTTP/HTTPS Debugging Proxy using MITM
Chrome、IE、Opera test OK
Firefox need set proxy to 127.0.0.1:8888 manually

Opera 的開發版 已內建 VPN 功能,
只要在設定 / 隱私 & 安全 Enable VPN 即可, 目前只有三個點美國、加拿大和德國
不過 Opera 已被中國 奇虎360 收購, 很容易讓人有陰謀論的聯想
流量都會經過 VPN 的結點, 可以用中間人的手法來竊取傳輸內容, 遇到敏感關鍵字, 把頁面內容置換這都是可以辦到的

If you are looking for solution, I found it's not possible to use UTF-8 realm in HTTP Basic access authentication.

在 UTF-8 環境下, 使用 Apache + 下面的 .htaccess, 用瀏覽器看, 在登入畫面會看到亂碼
AuthName 中文測試
AuthType Basic
AuthUserFile .htpasswd
require valid-user

查了 Server 端送出的 Header, WWW-Authenticate: Basic realm="中文測試", 是正常沒有編碼的
但是 charset 錯誤, Content-Type: text/html; charset=iso-8859-1
即使有加 AddDefaultCharset UTF-8, Apache 在認證畫面仍是送出 charset=iso-8859-1
原本我以為這是問題的原因, 於是我修改了 Apache source modules/mappers/mod_negotiation.c
把 default charset iso-8859-1 改成 UTF-8, 重編之後,
認證畫面已送出 Content-Type: text/html; charset=UTF-8,
但是瀏覽器(Firefox, Chrome, Opera, IE)看到的一樣是亂碼, 表示瀏覽器在認證畫面根本不看 charset
又去查 RFC 2617, 也沒有提到跟 charset 有關的東西
瀏覽器在認證畫面根本不看 charset 的話, 就是看瀏覽器預設處理方式
經測試,
Firefox, Chrome, Opera 是用 iso-8859-1 (英語/西歐語系)
中文版 IE 是用 Big5, 在 AuthName 使用 Big5 編碼用 IE 看是唯一可以看到正常字元的組合
結論是在 HTTP 基本認證使用 UTF-8 realm 是不可行的

試了好幾個服務, 最後的選擇是...
Web Reader: Feedly 速度快, 介面比較 Fancy
App Reader: gReader 支援 The Old Reader 及 Feedly, 比 Google 官方版本 App 還好用!

2013-07-09 Update: 本來是用 The Old Reader, 不過它太慢了, 有時甚至還會 Timeout, 還是改用 Feedly 比較順

HTML5 可以簡單地使用 video tag 把影片嵌入網頁中, 在這之前, 通常是使用 Flash 或 Silverlight 來達成
可惜的是 OGG, MP4, WebM 三種格式中, 沒有一種格式是被所有瀏覽器支援,
至少要準備 MP4 + OGG 或 MP4 + WebM 才行
轉檔軟體推薦使用 Miro, 其底層是使用 ffmpeg 來轉檔

HTML5 Video Tag 各瀏覽器支援度

範例: 影片取自 Firefox What's New

雖然 HTML5 Video Tag 已經很方便了, 基於以下理由, 還是覺得把影片放 YouTube 更方便
1. 不用自已轉檔
2. 不佔用自已的空間
3. 不怕頻寬問題