amp@java

當年是從CSDN博客遷過來的，因為那里很不穩(wěn)定，那時候這里很火的；
前段時間發(fā)現(xiàn)，Blogjava的登錄頁面居然沒有驗證碼了，圖片顯示錯誤，無法登錄，預感這個地方要涼，只好到處找替代，但沒找到好用的博客，github是一個選項，但似乎不是很適合做博客。
現(xiàn)在終于又可以登錄了，不過首頁居然只剩一篇文章，我以為數(shù)據(jù)都沒了，登錄發(fā)現(xiàn)還是有的，不過太讓人不放心了。

 昨天下午開始，之前用得好好的USB鼠標，突然不能用了，找到個PS/2鼠標，卻發(fā)現(xiàn)主板沒有鼠標的PS/2口，只有鍵盤的PS/2口，真是奇葩，幸好在用的鍵盤是PS/2口的，費了九牛二虎之力，用鍵盤操作，Win+R，compmgmt.msc進入計算機管理，上下箭頭移到設備管理器，發(fā)現(xiàn)右邊的USB控制器前全是黃色嘆號，嘗試卸載再安裝，卻怎么也裝不上，重新啟動發(fā)現(xiàn)鼠標在啟動Windows前還是亮燈的，但到了顯示W(wǎng)indows徽標的時候燈就滅了，應該不是硬件問題，而是驅動問題。
為了進一步證實硬件沒問題，找了個安裝系統(tǒng)的U盤，插進去啟動，能夠正常使用鼠標，于是目標就聚焦在找回驅動上。
開始折騰：
1、首先是找官方驅動啊，我這電腦是老機，AMD7系列主板，找了半天，這個主板驅動并沒有包含USB控制器，因為USB控制器都是Windows自帶的驅動，下載了一個南橋驅動，安裝后并沒有效果；
2、Windows自帶的驅動原來都是放在C:\Windows\System32\DriverStore\FileRepository下，USB控制器相關的驅動，就在usbport.inf_amd64_xxxxxxxxxx文件夾里，xxxxxxxxx是一串16進制數(shù)字，悲催的是，安裝這個驅動時要不提示找不到指定文件，要不說第三方INF沒有簽名；
3、自己折騰搞不定，找個軟件吧，第一個想到的是驅動之家官方的驅動精靈，下載下來發(fā)現(xiàn)是個全家桶啊，什么騰訊管家，金山毒霸，瀏覽器首頁修改一應俱全，而且沒有鼠標點擊，用TAB鍵根本移動不到取消框，只好默認全部安裝了，裝完啟動，檢測，提示系統(tǒng)自帶驅動缺失，于是回車修復，但每次修復完，重新檢測還是那樣，而且沒有提示USB控制器驅動安裝有問題，有些功能用鍵盤無法操作，不知道是不是還有哪里可以操作一下，于是又搜了一下，如何用鍵盤代替鼠標，居然真的找到了！
4、按WIN鍵，輸入設置，回車，打開設置主頁：

移到“輕松使用”，進去后左邊選擇“鼠標”，在右邊啟用“使用數(shù)字小鍵盤在屏幕上移動鼠標”（按空格鍵開關），最好把三個開關都打開，如果沒有啟用CTRL鍵加速功能，鼠標移動非常慢：

好了，現(xiàn)在可以用小鍵盤移動鼠標了；
5、繼續(xù)回到驅動精靈，再次修復，還是不行啊，這個東西除了帶來一堆垃圾，什么作用都沒有！于是把它帶來的垃圾以及它自己卸載了。
6、似乎360也有一個驅動大師，于是就下載了一個，這個倒是很純潔，但是功能太弱，完全沒發(fā)現(xiàn)問題；
7、剛才搜索“安裝驅動 找不到指定的文件”時，發(fā)現(xiàn)一個論壇提到了這個，是驅動人生的論壇，好像還有解決方案，但要注冊才能下載，難道驅動人生可以解決？于是就下載了一個驅動人生，安裝的時候還是附帶全家桶，不過現(xiàn)在可以用鍵盤移動鼠標取消了，只安裝了驅動人生自己，跟剛才兩個軟件不同的是，它提示USB外設驅動沒有安裝，于是點修復，結果反反復復出現(xiàn)等待光標，就是無法完成；
8、之前又搜索到，驅動安裝的日志在C:\Windows\INF\setupapi.dev.log文件里，于是打開這個文件，發(fā)現(xiàn)Driver package failed signature verification. Error = 0xE000022F，驅動程序簽名有問題，所以不能安裝成功；
9、Windows10有個高級啟動選項是禁用強制驅動簽名，如何進入高級啟動選項呢？以前是按F8，現(xiàn)在不行了，要在設置里面，更新和安全，恢復，高級啟動，立即重啟，然后設置疑難解答，高級啟動，再重啟，就可以進入高級啟動菜單，按7進入禁止強制驅動簽名模式，重啟后再用驅動人生修復，果然成功了；
10、打開驅動人生下載目錄，DTLFolder\DriversDownLoad，發(fā)現(xiàn)它下載了USB驅動目錄是USB_10.0.10240.16384_WHQL_107049，里面文件如下：

除了第一個xml文件是程序自己用的外，其他都是USB驅動用到的文件，點右鍵發(fā)現(xiàn)那幾個sys文件，除了usbohci.sys和usbuhci.sys外，其他都有數(shù)字簽名，而usbuhci.sys我這里沒用到，問題就出在usbohci.sys上：


11、難道是驅動人生替換了未簽名的文件？圖謀不軌？為了驗證一下，我又下載了一個Windows10安裝光盤（版本是當前使用的1703版）：

 每次換手機，把舊手機的數(shù)據(jù)遷移到新手機就是個很麻煩的事情，幸好最近華為的“手機克隆”APP越來越強大，居然能夠把微信的聊天記錄包括圖片原封不動地遷移到新手機上，以前用微信自帶的聊天記錄轉移功能只能轉移文字信息，圖片視頻全部丟失，不知道現(xiàn)在的怎么樣。手機克隆還能把SD卡的內容也轉移過來，基本滿足了需要。
但是要把手機上的東西傳到電腦就沒那么簡單了，現(xiàn)在已經(jīng)沒有了以前的大容量存儲模式，只能選擇MTP模式，這種模式其實不是一個完整的文件系統(tǒng)，有很多限制，所以一些傳統(tǒng)的軟件讀取不到，例如FastCopy是用不了的，用Windows自帶的文件管理器來復制，開始計算時間就要等很久，中間出了個錯就前功盡棄；還有通過手機上的APP訪問電腦共享的方式，在手機上復制也可以，但是同樣會莫名其妙卡死，F(xiàn)TP同理，折騰了好久，還是覺得自己動手比較好。
MTP協(xié)議在維基百科里解釋得比較清楚：https://en.wikipedia.org/wiki/Media_Transfer_Protocol ，簡單點說就是：
1、不是以塊設備的形式訪問，跟U盤不同；
2、只能單線程訪問，不能同時進行多個操作，只能一個接一個；
3、控制權在設備上，對外展示的內容由設備決定；
4、默認不能直接對文件進行部分修改，只能復制過來修改完再復制回去，但Android對協(xié)議做了擴展，能夠修改部分文件內容；
5、在Linux上有些軟件能夠把它掛載為文件系統(tǒng)，這樣其他軟件就能像訪問普通文件系統(tǒng)一樣訪問了，但是Windows下似乎沒有。

不過有人開發(fā)了一個在Windows下通過JNI實現(xiàn)的Java庫jmtp，項目托管在Google Code，被墻了，但是GitHub有人fork了一個，可以下載下來，我下載的是https://github.com/reindahl/jmtp
里面包含了C++的代碼和Java的代碼，以及兩個已經(jīng)編譯好的dll文件，分別用于Win32和Win64，把其中一個dll文件放在工程目錄下，再把Java源代碼加入工程中即可使用，文檔比較簡陋，但是看test目錄下的MtpTest.java，基本可以摸到如何使用了，這個協(xié)議比較簡單，其實沒什么功能，我要的只是把文件復制到電腦上。
根據(jù)MtpTest.java，稍微修改一下，做個遞歸復制即可把手機上的所有文件復制到電腦上：
其中發(fā)現(xiàn)有點問題：
1、Android設備文件名里是可以包含冒號（:）的，但Windows是不可以的，所以復制到這些文件的時候會有問題，于是遇到目錄名這樣就把它改為中文的冒號（：），但是遇到文件名這樣就不行了，因為這個庫的copy函數(shù)只需要指定目標目錄，不需要指定目標文件名，所以這些文件只能放棄；
2、Android手機的MTP協(xié)議是由“媒體存儲”這個系統(tǒng)APP控制的，有時候手機上可以看到的文件，通過MTP訪問卻怎么也看不到，重啟手機也不行，應該就是這個APP沒有更新數(shù)據(jù)，需要把它的系統(tǒng)數(shù)據(jù)清除掉，等它重建完重新訪問就可以看到了，不過這個重建時間非常長，可以查看它數(shù)據(jù)占用的空間，剛清除之后會發(fā)現(xiàn)它占用的空間會不斷增長，到了不增長的時候就是重建完了，就可以正常訪問了；
3、這個庫有時候還有點bug，有一次發(fā)現(xiàn)它讀取到的文件和文件夾都沒有了最后一個.后面的部分，所以總是卡住，重新插拔一下手機數(shù)據(jù)線又沒問題了；
4、為了避免復制了半天結果發(fā)現(xiàn)不完整，又要重來，最好在復制前先統(tǒng)計一下文件大小，看看跟手機上看到的占用存儲空間是不是一致，對于MTP設備上的文件，可以通過getSize函數(shù)得到大小，把上面復制操作改為大小累加即可，速度比復制快一些，不過由于小文件太多，也不會快很多。

把手機里的文件復制到電腦后，通過一些簡單的分析，發(fā)現(xiàn)有很多其實是垃圾來的，也可以為手機空間清理提供參考，因為在電腦上分析起來比在手機上方便一些。例如一些視頻APP的緩存，居然超過1G，占用了寶貴的內部存儲空間，之前一直都沒發(fā)現(xiàn)，通過電腦里的按文件大小搜索才發(fā)現(xiàn)。

09款老速騰，不支持USB和AUX，要聽歌除了CD以外，就是刻錄在CD上的MP3了，以前不知道用什么軟件刻錄了一張碟，能夠完美地顯示中文文件名和ID3信息，前幾天用ImgBurn刻了一張，發(fā)現(xiàn)中文是亂碼，開始以為是ID3信息顯示亂碼，于是下載了一個Mp3Tag，把所有ID3信息都清除，結果顯示文件名依然亂碼，重新寫入ID3信息，發(fā)現(xiàn)ID3可以正常顯示，但文件名還是亂碼。
于是就把原來那張可以正常顯示中文的碟拿來研究一下，發(fā)現(xiàn)它的ID3標簽只是ID3v1，而后來重新寫入的ID3是ID3v2.3，兩個都可以正常顯示中文，說明ID3信息是正常的，文件名亂碼不是這個問題。
但是不知道用什么軟件來顯示光盤的文件系統(tǒng)，只能一次次摸索。
幸好有一張CD-RW可以反復嘗試。
ImgBurn默認是使用ISO9660+UDF，而ISO 9660則使用最老的ISO 9660文件系統(tǒng)，也就是1988版本，文件名默認是不支持中文的，不知道是不是這個原因，于是就把文件系統(tǒng)改為ISO 9660+Joliet，如下圖：

并且把ISO 9660標準改為1999：

可能是因為字符編碼那里改為了ASCII，所以就好了。
后來又嘗試只使用UDF文件系統(tǒng)，結果認不出碟。



所以，目前能夠使用中文的環(huán)境其實就是：
ImgBurn使用ISO 9660 1999標準；
ID3使用v1或v2.3都可以。

最近新部署了一個信息系統(tǒng)，廠家居然沒有升級方案，所有數(shù)據(jù)都要重新輸入，包括用戶、角色等都要重新配置，真是操蛋。要是一個個錄入簡直是日狗了，這些用戶在其他信息系統(tǒng)早已存在，但是每個都復制粘貼提交一遍也不是辦法，于是就想用程序自動完成這些操作。步驟如下：
1、從其他信息系統(tǒng)的數(shù)據(jù)庫導出用戶信息，也可以直接從其他信息系統(tǒng)的界面把所有用戶信息復制下來放在一個文本文件里，反正就是準備好數(shù)據(jù)源；
2、在需要錄入用戶信息的系統(tǒng)中，用人工操作的方式登錄系統(tǒng)，并錄入一個用戶，同時用Wireshark抓包，查看整個過程要提交一些什么樣的表單數(shù)據(jù)；
3、在程序中用httpclient提交同樣的數(shù)據(jù)，完成登錄，并從第1步的數(shù)據(jù)源中讀取用戶信息，然后循環(huán)提交錄入用戶所需的數(shù)據(jù)，完成用戶的錄入；
4、新系統(tǒng)沒有默認的用戶角色，是需要一個個修改的，是根據(jù)用戶的ID來確定當前修改的用戶，并且提交一個角色ID來進行設定，因此需要首先獲取用戶的ID，然后根據(jù)該ID來提交角色ID，而用戶ID是通過用戶列表頁面獲取到的，因此還需要通過正則表達式來獲取所有用戶的ID，然后循環(huán)提交角色ID，完成角色設定。

花了不少時間才搞定，有幾個地方需要注意：
1、如果表單數(shù)據(jù)不包含中文，直接把表單的Name和Value加在HttpPost的URL的?后面即可，不需要專門建立NameValuePair，如下所示：

但是，如果表單數(shù)據(jù)包含中文，例如姓名，用這種方式提交的表單數(shù)據(jù)會出現(xiàn)亂碼，即使通過URLEncoder進行編碼后再發(fā)也不行，必須建立NameValuePair，再加到HttpPost的Entity里面，如下所示：

2、用于網(wǎng)頁內容查找的正則表達式的使用方式一般為：

今天遇到一個非常奇怪的問題，有臺裝XP的電腦，插上USB鍵盤沒反應，還以為是鍵盤壞了，又找來兩個不同型號的鍵盤，依然不行，又以為是USB接口壞了，結果在電腦啟動的時候又可以按F2進入BIOS，這樣就只有一個原因，Windows的驅動沒裝上了。
幸好這電腦還有傳統(tǒng)的PS/2口，而且插上就能識別，否則連Windows都進不去，因為按Ctrl+Alt+Del沒反應。
進去之后提示安裝USB鍵盤驅動，到最后一步提示安裝失敗，原因是拒絕訪問。
上網(wǎng)搜了一下，安裝驅動拒絕訪問的其中一個原因是注冊表有個鍵的權限設置有問題，改過來即可，但是我打開注冊表，連那個鍵都沒找到，不是這個原因。
不過從這個解決方案中也知道了驅動安裝的日志是在Windows目錄下的setupapi.log文件里面，于是打開那個文件，發(fā)現(xiàn)每次安裝都有兩個拒絕訪問的錯誤，但并沒有說是注冊表拒絕訪問，在拒絕訪問之前，還提到一個叫MlCoInst.dll的文件沒有簽名。
上網(wǎng)搜MlCoInst.dll，沒有找到任何結果，在System32目錄下找到它，看屬性，果然沒有簽名，是個三無文件，不知道為什么每次安裝驅動都要調用它。
日志里面還提到了“共同安裝程序”，似乎和CoInst有點關聯(lián)，于是又查了一下，原來安裝驅動的時候可以通過調用“共同安裝程序”來實現(xiàn)某些目的，例如修改驅動程序的簽名狀態(tài)，欺騙操作系統(tǒng)，這樣就可以只安裝一次驅動即可，不用每次插入都安裝一次。
于是嘗試把MlCoInst.dll刪除，提示刪除失敗。
在注冊表里面搜索MlCoInst.dll，把所有找到的鍵值都刪除，再次插拔鍵盤，順利安裝完畢，刪除MlCoInst.dll，也成功了，果然是它的問題。

這個應該是某個USB設備的驅動引進來的，而且修改了usb.inf，每次安裝任何USB設備都要調用它，但它可能與Windows的簽名機制有沖突，所以導致安裝失敗，真是坑爹！

做GUI程序的時候，通常有個后臺工作線程在努力工作，但是中間又需要一些暫停，而關閉程序的時候，必須立即結束那個線程，退出程序，也有的時候需要停止后臺線程，但不關閉程序。例如，做一個目錄監(jiān)控程序，發(fā)現(xiàn)目錄中有文件的時候，執(zhí)行一定的操作，執(zhí)行完之后沒有文件了，就要暫停一下，過幾秒或幾分鐘再次檢測，這時候就要對線程進行暫停操作，如果在暫停的時候，用戶要關閉程序，就必須馬上停止線程，如果用戶需要暫停檢測，按下某個按鈕后，需要讓線程馬上停止，但再次按下某個按鈕，線程又必須馬上開始。

以前我都是通過檢測停止標記和用Thread.sleep(time)來完成的，后臺線程的每次循環(huán)都要檢查停止標記，如果發(fā)現(xiàn)停止標記已設定，就不再循環(huán)，退出線程，在線程內部，如果需要暫停，就執(zhí)行Thread.sleep(time)。通過把線程的setDaemon(true)方法，還可以讓線程作為后臺線程，當圖形界面關閉后，線程也自動退出。

但是，這種方式有個問題，如果我需要在圖形界面上點擊按鈕來停止線程，但并不退出程序，而點擊按鈕的時候線程正處于sleep狀態(tài)，就對它沒有任何辦法，只能讓它醒過來再操作，如果sleep的時間比較長，例如1分鐘，那么點擊按鈕之后，用戶最多要等1分鐘才能把線程停下來。當然，Thread對象有個interrupt方法，但是已經(jīng)被標記為過期，一般不建議使用了。感謝評論中watchzerg的提醒，Thread的interrupt()并沒有標記為過期，可以按照他的說法來操作，更為簡單。

怎么讓線程能暫停，又能隨時叫醒呢？原來Java里最原始的對象Object就自帶此功能。

每個Object都有wait(time)和notify()方法，前者就是讓擁有該Obejct的線程處于暫停狀態(tài)，后者則讓線程馬上喚醒，通過這兩個方法，就能夠滿足上述的所有要求。

首先，建立一個同步對象：
Object syncObj = new Object();

然后在線程中需要暫停的地方，調用該對象的wait(time)方法：

Eclipse有個功能就是把整個項目打包成一個可執(zhí)行的Jar文件，里面包含了所有項目引用了的庫，如果電腦上安裝了JRE，直接雙擊就可以啟動，看起來很方便，如下圖所示：

可以選擇把所有類庫打包進去，也就是Jar里面還包含一堆Jar：

還可以生成ant腳本：


生成的jar文件，可以直接通過java -jar xx.jar啟動，簡單快捷。


然而，這樣導出來的可執(zhí)行jar，啟動速度卻非常慢，這跟包的大小有關。有個項目導出來的包有40MB，結果啟動需要近一分鐘，在性能差的電腦上，甚至要幾分鐘，就是你執(zhí)行完命令后，沒有任何界面顯示，但是查看任務管理器發(fā)現(xiàn)java進程的CPU占用率在浮動，說明正在努力啟動，過了一段時間之后界面突然顯示出來，簡直讓人崩潰。可是在Eclipse里面運行，卻是一點就開。

我開始嘗試縮小導出的包。但是Eclipse的導出對話框并沒有提供需要打包哪些庫的選項，都是默認把所有庫都打包進去，但是它可以生成ant腳本，可以通過編輯ant腳本的方式來減少不必要的庫。經(jīng)過多次嘗試，終于把40MB的包縮成了17MB，啟動速度快了一些，但是依然需要半分鐘以上。

后來覺得，能不能不打包直接運行呢？于是把導出來的包用壓縮軟件解壓，再把里面包含的jar包繼續(xù)解壓，最后得到一堆沒有壓縮的class文件，再通過指定classpath的方式，直接運行程序入口class，發(fā)現(xiàn)啟動速度和在Eclipse里面一樣，一點就開。

打包的好處是部署簡單，只需要一個文件，但帶來的缺點實在不能忍，打散的方式部署起來稍微難一點，但是啟動速度夠快，對普通用戶來說，這個才是最重要的。

當然，還有一種方式是像Eclipse那樣，啟動時顯示一個圖片，底下一個進度條顯示啟動進度，不過這樣也加大了工作量，而且每次都要等那進度條，實際上也很煩。

     摘要: JMF太老了，各種問題得不到解決，Oracle也沒再升級過，如果能找到新東西，最好能把它扔掉。最近OpenCV比較火，還有人用Java封裝了OpenCV，成立了JavaCV項目，通過改造VideoInput這個基于C語言的項目，能夠用Java來調用攝像頭，JMF可以扔掉了。如果想測試，非常簡單，把那些編譯好的jar文件放入Build Path即可，如果是在Windows X86環(huán)境下，則只需要把帶...  閱讀全文