最近在try 時發現Date 型態如果default not null 那存入default value 會為'0000-00-00'
但在JAVA 透過JDBC取得data 時會出現以下錯誤訊息
Caused by: java.sql.SQLException: Value '0000-00-00' can not be represented as java.sql.Date
我想問題是出現因為 java.sql.Date: since January 1, 1970 00:00:00.000 GMT 所以無法解析轉換吧!!
找了一下解法，在http://twpug.net/docs/mysql-5.1/connectors.html 這篇文章有提到
具有全0組分的Datetimes（0000-00-00 …）：在Java中，無法可靠地資料表示這些值。從結果集讀取它們時，Connector/J 3.0.x總是會將其轉換為NULL。
預設情況下，遇到這類值時，Connector/J 3.1將拋出異常，這是因為，根據JDBC和SQL標準，這是最正確的行為方式。可以使用「zeroDateTimeBehavior」配置屬性改變該行為。允許的值包括：「exception」，（預設值），用代碼為「S1009」的SQLState拋出SQLException；「convertToNull」，返回NULL而不是數據；以及「round」，對日期進行捨入處理，使之成為最接近的值，即「0001-01-01」。
從Connector/J 3.1.7開始，能夠使用「noDatetimeStringSync=true」（預設值為「假」），將ResultSet.getString()與該行為分離開，從而能夠以字串的形式提取未被改變的全0值。請注意，這也會阻止使用任何時區轉換功能，因此，驅動程式將禁止同時啟用noDatetimeStringSync和useTimezone。
所以在連線參數加上zeroDateTimeBehavior=convertToNull&noDatetimeStringSync=true就可以排除啦!!
參考資料來源:http://twpug.net/docs/mysql-5.1/connectors.html
今天在使用Dreamweaver 時 只要copy 文字就會出現 SpryWdget.htm 設定錯誤排除法
重啟動還是一樣，去找了一下是何原因，可能是有設定檔損毀吧
有查到如何排除法
(1)先將Dreamweaver關閉；
(2)找出「Configuration資料夾」(位置在 C:\Documents and Settings\USERNAME\Application Data\Adobe\Dreamweaver 9\Configuration)裡的檔案：「WinFileCache-AD76BB20.dat」；
(3)把這個dat檔刪除。
這樣就排除了，看來是暫存檔出問題了!!
資料來源:
http://benlibra.blogspot.com/2008/04/sprywidgethtm.html
在網路上如何確認你下載的檔案是原作者的版本
或是在傳輸的過程中沒有遺失封包或被hacker從中加入什麼
所以可以用檢驗碼的方式來確認
目前最常在網路上被使用的就是MD5的檔案驗證機制，因為MD5加密後只要不同的data就會產生不同的驗證碼及不可逆的特性 不過近來已經有人稱可破解及找到碰撞可能，雖然出現了小瑕疵，不過因為使用方便及安全性還是足夠(破解可能性還是不普及)所以還是可以使用
以下是MD5的說明:
http://zh.wikipedia.org/wiki/MD5
http://a-010.cyut.edu.tw/~vote/md5.php
以下是Java的程式碼，傳入檔案進行MD5的驗證
File file = new File(“d:/1.dat”);
FileInputStream fs = new FileInputStream(file);
BufferedInputStream bi = new BufferedInputStream(fs);
ByteArrayOutputStream bo = new ByteArrayOutputStream();
byte[] b = new byte[bi.available()];
int i;
while ((i = bi.read(b, 0, b.length)) != -1)
{
bo.write(b, 0, i);
}
bo.close();
System.out.print(Md5.MD5(new String(bo.toByteArray())));
public final static String MD5(String s)
{
char hexDigits[] = {'0', '1', '2', '3', '4', '5', '6', '7', '8', '9', 'a', 'b', 'c', 'd', 'e', 'f'};
try
{
byte[] strTemp = s.getBytes();
MessageDigest mdTemp = MessageDigest.getInstance(“MD5”);
mdTemp.update(strTemp);
byte[] md = mdTemp.digest();
int j = md.length;
char str[] = new char[j * 2];
int k = 0;
for (int i = 0; i < j; i++)
{
byte byte0 = md[i];
str[k++] = hexDigits[byte0 >>> 4 & 0xf];
str[k++] = hexDigits[byte0 & 0xf];
}
return new String(str);
}
catch (Exception e)
{
return null;
}
}
程式來源:
http://www.j2megame.org/index.php/content/view/749/125.html
原作者的程式產出的MD5好像與網路上有提供的好像有差異
暫時先不去深入瞭解
反正功用達到就好~^^
台北的路可是差的很，很久前就在網路上看過日本如何整修鋪路，這轉信及被人張貼在網路上已經非常多啦
如果想再回味一下，請大家連到下面連結觀看
Mobile01-日本人如何整修路面
而台北市 郝市長 最近好像說已定好高標準的『道路養護施工標準作業流程』要先找幾條路試辦 希望未來全面實施
個人覺得應該立即全面施行吧? 路應該原本就是要平的，除非是原本的規範中可接受路不平，如果廠商施工偷工減料，這應該就是有問題吧!!
以下這是報導:
中國時報-路不平 郝：北市之恥 幾年內改善(97-7-4)
看來台北市已有覺醒，而住在台北縣的人們怎辦? 台北縣的路可比台北市慘上數十倍呀~~是大家習慣了還是覺得還能接受? 以下是報導:
爛自由時報-爛路票選 中和景平路列榜首(97-4-12)
報導中工務局說一個月內改善，真怪了我天天在走爛路，怎麼沒覺得有改善呢? 想提升台北縣的競爭力，我想道路為首要，周縣長，那位郝市長都有形式上的宣示，那你呢? 應該比照辦理吧!! 為了縣民也為了你的將來吧!!
新莊為了捷運 施工了近十年了，人們不應該只是習慣應該有權要更好的生活品質吧!!
找了一堆資料，偶然發現有這樣的系統 路見不平報馬仔系統
看來，還是要靠廣大老百性的力量，上網報馬仔吧!!
不過小弟尚未試用過，不知成效如何? 如有人先試了就分享一下有其功效嗎?
不然就待改天小弟試了 再與各位分享!!
ping 指令可測試與目的地主機的連線反應速度，而tracert可以測試與目的地主機之間的連線路徑。
以下為ping指令的使用方式
C:\>ping 192.168.1.168
Ping 192.168.1.168 具有 32 位元組的資料:
回覆自 192.168.1.168: 位元組=32 時間=1ms TTL=128
回覆自 192.168.1.168: 位元組=32 time<1ms TTL=128
回覆自 192.168.1.168: 位元組=32 time<1ms TTL=128
回覆自 192.168.1.168: 位元組=32 time<1ms TTL=128
192.168.1.168 的 Ping 統計資料:
封包: 已傳送 = 4，已收到 = 4, 已遺失 = 0 (0% 遺失)，
大約的來回時間 (毫秒):
最小值 = 0ms，最大值 = 1ms，平均 = 0ms
TTL代表尚可經過的節點數，經一個網路設備就減一，time代表回應速度，單位為毫秒，值越小就代表回應速度越快。 time值在200以內：極好 time值在200~300以內：順暢 time值在300~500：尚可 time值在500~1000：小LAG。 time值在1000以上：LAG頗嚴重了，打字都要1秒以上才會出現!
如果出現 Request timed out：表示封包遺失，這就嚴重了，會發生無法連線或連線時不穩定的現象。
Tracert（追蹤路由）是路由追蹤實用程序，用於確定 IP 數據報訪問目標所採取的路徑。Tracert 命令用 IP 生存時間 (TTL) 字段和 ICMP 錯誤消息來確定從一個主機到網絡上其他主機的路由。
Tracert 工作原理
通過向目標發送不同 IP 生存時間 (TTL) 值的「Internet 控制消息協議 (ICMP)」回應封包，Tracert 診斷程序確定到目標所採取的路由。要求路徑上的每個路由器在轉發封包之前至少將封包上的 TTL 遞減 1。封包上的 TTL 減為 0 時，路由器應該將「ICMP 已超時」的消息發回源系統。
Tracert 先發送 TTL 為 1 的回應封包，並在隨後的每次發送過程將 TTL 遞增 1，直到目標響應或 TTL 達到最大值，從而確定路由。通過檢查中間路由器發回的「ICMP 已超時」的消息確定路由。某些路由器不經詢問直接丟棄 TTL 過期的封包，這在 Tracert 實用程序中看不到。
Tracert 命令按順序顯示出返回「ICMP 已超時」消息的路徑中的近端路由器接口列表。如果使用 -d 選項，則 Tracert 實用程序不在每個 IP 地址上查詢 DNS。
在下例中，封包必須通過兩個路由器（10.0.0.1 和 192.168.0.1）才能到達主機 172.16.0.99。主機的預設網關是 10.0.0.1，192.168.0.0 網絡上的路由器的 IP 地址是 192.168.0.1。
C:\>tracert 172.16.0.99 -d
Tracing route to 172.16.0.99 over a maximum of 30 hops
1 2s 3s 2s 10,0.0,1
2 75 ms 83 ms 88 ms 192.168.0.1
3 73 ms 79 ms 93 ms 172.16.0.99
Trace complete.
用 tracert 解決問題
可以使用 tracert 命令確定封包在網絡上的停止位置。下例中，可以確定 192.168.10.99 主機沒有有效路徑。這可能是路由器配置的問題，或者是 192.168.10.0 網絡不存在（錯誤的 IP 地址）。
C:\>tracert 192.168.10.99
Tracing route to 192.168.10.99 over a maximum of 30 hops
1 10.0.0.1 reports:Destination net unreachable.
Trace complete.
Tracert 實用程序對於解決大網絡問題非常有用，此時可以採取幾條路徑到達同一個點。
Tracert 命令行選項
Tracert 命令支持多種選項，如下表所示。
tracert [-d] [-h maximum_hops] [-j host-list] [-w timeout] target_name
-d
指定不將 IP 地址解析到主機名稱。
-h maximum_hops
指定躍點數以追蹤到稱為 target_name 的主機的路由。
-j host-list
指定 Tracert 實用程序封包所採用路徑中的路由器接口列表。
-w timeout
等待 timeout 為每次回復所指定的毫秒數。
近期留言