主要是依照第一碼英文的代碼, 加上後面的個別數字運算而來, 其中第一碼是申報登記戶籍的地點, 共有26個英文字, 第二碼則是性別, 之後則是流水號.
驗證方式如上面連結的說明, 利用該說明, 進行程式實作後, 可以參考這個範例:
http://sample.diary.tw/pid/
上面網址使用純 javascript 撰寫, 並也製作了產生器, 配合 html download blob 語法, 可以下載內容, 十分方便, 可以參考看看.
html download blob 語法可以參考:
http://thiscouldbebetter.wordpress.com/2012/12/18/loading-editing-and-saving-a-text-file-in-html5-using-javascrip/
較複雜的下載方式, 可以參考這個 FileSaver.js 工具:
https://github.com/eligrey/FileSaver.js
在 nodejs 專案中, 若是需要對外發起使用 application/json 的 http post , 若有中文字, 需要注意計算字串長度的問題. 一般發起的程式碼請參考:
http://tech.pro/tutorial/1091/posting-json-data-with-nodejs
不過該範例是使用英文字, 所以沒有問題, 若是要發起中文字的 json http post, 需要調整計算 Content-Length 的方式, 使用 new Buffer(str).length, 如下:
var obj_json = { name: "王大頭", age: 25 };
var json_string = JSON.stringify(obj_json);
var req = http.request({
host: 'host.example.com',
port: 80,
path: '/upload',
method: 'POST',
headers: {
'Content-Type': 'application/json',
'Content-Length': new Buffer(json_string).length
}
}, function(res) {
res.setEncoding('utf-8');
var responseString = '';
res.on('data', function(data) {
responseString += data;
});
res.on('end', function() {
console.log(responseString);
});
});
req.on('error', function(e) {
// http post error
});
req.write(json_string);
req.end();
使用 Google Chart API 來產生 QRCode 很方便, 可以參考這裡的資料:
https://developers.google.com/chart/infographics/docs/qr_codes
一般來說會用到的參數共有以下:
所以以本站網址為例, QRCode 為:
http://chart.apis.google.com/chart?cht=qr&chs=200×200&chl=http%3A//diary.tw/tim
以圖片顯示為:
Google Chart API 產生 QR Code還真的蠻方便的.
[2014/8/27]
補充, 若是需要大量產生, 可以利用這個網站服務, 一次可以免費批次產生100個QRCode, 也十分方便好用.
http://www.qrexplore.com/generate/
另外也有個線上辨識Barcode、QRCode的服務, 可以用圖片網址或是傳送圖片的方式進行, 方便大家在產生QRCode的驗證.
http://zxing.org/w/decode.jspx
在現在使用手機瀏覽網頁愈來愈普遍的時候, 著重對手機網頁的效果也愈來愈重要.
最近測試到一個問題, 被 label 包起來的多個 input box 時, 會發生即時點到後第二或第三個 input box 也會 focus 到第一個 input box 的問題. 如下面的 html
<label> <input type=text size="3">- <input type=text size="3">- <input type=text size="3"> </label>
其實這個問題的原因很單純, 因為 label 是用來強化使用者輸入便利性的標籤, 拿來包多個 input 會發生只會指向第一個 input 是因為原始的設計導致, 目前測試在桌機的 firefox 、android 原生瀏覽器、android chrome瀏覽器、iphone/ipad safari瀏覽器, 都會有這樣的現象, 但桌機的chrome, 桌機的IE11則不會, 原因可能和取得物件焦點的順序有關.
無論如何, 包多個 input 在一個 label 不是一個正確的作法, 要避免這個狀況, 就是不在把多個 input 放在一個 label 中即可.
測試網頁 http://sample.diary.tw/35/label.htm
html label標籤的用法, 可以參考這裡: http://www.w3schools.com/tags/tag_label.asp
在點對點間要測試傳輸品質及頻寬狀況, 有個好用的工具, iperf, 官方網址為:
http://iperf.fr/
這個工具不僅是可以測試一般 TCP的傳輸, 也可以測試 UDP的傳輸, 使用方式很簡單, 下載解開後, 執行檔就是 iperf.exe 同時可以擔任 client 及 server 兩個角色, 找兩台電腦(當然一台也可以), 以測試 udp 為例, 在擔任 server 的主機上下指令:
iperf -s -u
其中參數 -s 為啟動 server mode, -u 為使用 udp 傳輸.
成功起動 server 會出現以下訊息(預設為 port 5001):
————————————————————
Server listening on UDP port 5001
Receiving 1470 byte datagrams
UDP buffer size: 64.0 KByte (default)
————————————————————
然後在擔任 client 角色的機器上執行以下指令:
iperf -c [server_ip] -u -i 1
其中參數 [server_ip]為擔任 server 的 ip, 而 -i 1 是指每一秒鐘出現一個 log, 以下為結果:
————————————————————
Client connecting to localhost, UDP port 5001
Sending 1470 byte datagrams
UDP buffer size: 64.0 KByte (default)
————————————————————
[ 3] local 127.0.0.1 port 52778 connected with 127.0.0.1 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0- 1.0 sec 129 KBytes 1.06 Mbits/sec
[ 3] 1.0- 2.0 sec 128 KBytes 1.05 Mbits/sec
[ 3] 2.0- 3.0 sec 128 KBytes 1.05 Mbits/sec
[ 3] 3.0- 4.0 sec 128 KBytes 1.05 Mbits/sec
[ 3] 4.0- 5.0 sec 128 KBytes 1.05 Mbits/sec
[ 3] 5.0- 6.0 sec 128 KBytes 1.05 Mbits/sec
[ 3] 6.0- 7.0 sec 129 KBytes 1.06 Mbits/sec
[ 3] 7.0- 8.0 sec 128 KBytes 1.05 Mbits/sec
[ 3] 8.0- 9.0 sec 128 KBytes 1.05 Mbits/sec
[ 3] 9.0-10.0 sec 128 KBytes 1.05 Mbits/sec
[ 3] 0.0-10.0 sec 1.25 MBytes 1.05 Mbits/sec
[ 3] Sent 893 datagrams
[ 3] Server Report:
[ 3] 0.0-10.0 sec 1.25 MBytes 1.05 Mbits/sec 0.000 ms 0/ 893 (0%)
就可以看到傳輸測試的結果了, 預設是使用 1mpbs的頻寬, 可以利用 -b 參數下達指定頻寬, 例如 100k, 10m 都可以. 當然, 在 server 上也可以下 -i 1 的指令, 可以看到較為即時的訊息. 若是要持續性測試, 可以在 client 內下 -t [seconds]代表指定秒數即可.
在測試點與點間的網路品質及頻寬可以使用這個簡單工具來進行測試, 很方便好用.
目前最新版本(2011)下載連結: http://iperf.fr/download/iperf_2.0.5/iperf-2.0.5-2-win32.zip
[2022/2/20 14:13]
在 iOS 7.1 更新後, 原企業APP安裝會發生以下訊息:
(無法安裝應用程式, 因為 xxxx 的憑證無效), 誰看得出來這個訊息是什麼意思, 查了一下, 發生的原因原來是因為原本在網頁上的安裝連結:
itms-services://?action=download-manifest&url=http://xxx.com.tw/xxx.plist
中的後面 url 沒有走 SSL 加密通道, 也就是 https.
如何解決這個問題, 當然, 就是改為 https://xxx.com.tw/xxx.plist 即可, 但若是沒有購買 SSL 加密憑證, 如何解決呢? 可以使用第三方的網站分享連結, 而且支援 https 的, 可以利用 dropbox 的 share link.
做法如下:
1. 將原來的 plist 檔案放在 dropbox 空間, 並生成分享連結(share link), url 會像如下:
https://www.dropbox.com/s/xxxxxxxxx/xxx.plist
2. 若上面網址沒有 https, 就自行改成 https 即可, 並將 www.dropbox.com 改為 dl.dropbox.com, 如下:
https://dl.dropbox.com/s/xxxxxxxxx/xxx.plist
3. 將原來的 itms-services:// 後的 url 改成上面 url 即可, 如下:
itms-services://?action=download-manifest&url=https://dl.dropbox.com/s/xxxxxxxxx/xxx.plist
上線即完成, 不過缺點會是這樣, 在安裝時會出現 dropbox 的安裝通知, 如下:
若不介意 dl.dropboxusercontent.com 的這個訊息, 這就可以進行安裝了, 是用 dropbox 的 https 來解決這個 iOS 7.1 強迫要用 https 下載 plist 的問題.
繼續閱讀:
http://bencollier.net/2014/03/ios-enterprise-app-error-cannot-install-applications-because-the-certificate-is-not-valid/
http://www.cocoachina.com/bbs/read.php?tid=194213&fpage=0&toread=0&page=1
若是還沒有 dropbox 空間的朋友們, 也歡迎多利用這個 referral link 加入, 謝謝: https://db.tt/h1NpPka3
在資料表中, 使用 GUID做為clustered index時, 很容易因為是隨機產生的值, 而導致資料存放的離散, 可以利用這個函數來改善:
NEWSEQUENTIALID()
該函數是循序地建立 GUID, 也是唯一值, 但可以降低離散的狀況, 進而改善未能有效填滿及離散的問題.
當然, 若是 GUID欄位沒有使用在 cludtered index時, 則比較不需要擔心這個問題.
參考資料:
http://technet.microsoft.com/zh-tw/library/ms189786.aspx
以前為了要管理 iPad 設備, 不想用肥大又不好用的 iTunes, 轉而使用方便精簡的 iTools, 不過以往都是簡體中文版本, 但是功能強大又方便, 備份資料也很容易, 現在有了繁體中文版本進來了, 代理是國內的公司, 可以參考官方網站:
這次的版本還多了可以管理 Android 的設備(雖然說 Android 不像 iPad/iPhone管理那樣不方便), 不過廠商多增加這樣的設計還真是方便兩種系統都有的用戶們.
這裡有詳實的介紹, 可以參考阿祥的網路筆記本: http://axiang.cc/archives/9283
有需要的朋友們可以試看看.
在 window form中使用 webbrowser 時, 有時會遇到 javscript error 的訊息, 此時會出現需要使用者介入的操作, 程式才能繼續執行下去.
這樣對於一些自動化操作的程式會有停止無法執行的問題, 所以可以利用一個 webbrowser 的屬性 “ScriptErrorsSuppressed” 設為 True 即可抑制這個會出現的人機介面.
不過記得使用這個屬性, 後續的程式也得注意網頁程式的異常後, 如何做良好的控制, 才不會因為這個屬性設定後, 雖然程式可以繼續往下執行, 但 webbrowser 中的程式錯誤而產生非預期結果的狀況, 就不好了.
2013/12/30 起實施國道里程收費, 整理一下收費試算資料:
https://docs.google.com/spreadsheet/pub?key=0AvQRaqbi5E6EdGpzU1Z2dGZTSGZmaXRyTU13a0I2T0E&output=html
其中試算方式依照國道電子收費標準:
http://www.freeway.gov.tw/Publish.aspx?cnid=1880&p=3862
費率型式
| 費率型式 | 費率金額(元/公里) | ||
| 小型車(小客車、小貨車) | 大型車(大客車、大貨車) | 聯結車 | |
| 每日行駛里程≦20公里 | 0 | 0 | 0 |
| 標準費率(20公里<每日行駛里程≦200公里) | 1.2 | 1.5 | 1.8 |
| 長途折扣費率(每日行駛里程>200公里) | 0.9 | 1.12 | 1.35 |
另外有關收費優惠, 2014春節費率統一為 0.9元/公里, 所以在超過 80公里起, 才會比較優惠, 這個部分可以參考試算表內容.
遠通電收的部分也有提供線上試算功能, 給各位使用:
http://fare.fetc.net.tw/Default.aspx
原本想說寫個試算小程式, 看起來也就不需要了.