機器之間的Java jar執行差異

我寫了一些代碼，通過檢查每個字段對照某些正則表達式來驗證逗號分隔文件的內容 - 導致我悲傷的特定正則表達式是一個非常基本的日期正則表達式（\\d{2}/\\d{2}/\\d{2}）。如果在該字段中的數據不匹配，它應該寫出到一個單獨的文件指示它需要檢查，例如：機器之間的Java jar執行差異

private static int DATE_FIELD = 5; 
File input = new File("input.txt"); 
Pattern p = Pattern.compile("\\d{2}/\\d{2}/\\d{2}"); 
BufferedReader reader = new BufferedReader(new FileReader(input)); 
String line = reader.readLine(); 
while(line != null){ 
    String[] splitLine = line.split(",");  
    Matcher m = p.matcher(splitLine[DATE_FIELD]); 
    if(!m.matches) { 
     // write warning to separate file 
    } 
    line = reader.readLine(); 
}

此代碼被編譯爲一個較大的JAR文件的一部分，該安裝在辦公室的4臺電腦（我的和其他三臺）上。 jar文件是通過一個由單獨的程序進行的shell調用調用的，並傳入相關參數。在我們將數據導入到數據庫之前，這是QC檢查的一部分，並且日期是必填字段，因此如果日期字段留空，則應將其標記爲檢查。

我使用的正則表達式不應允許空白日期通過，並且當我在我的機器上運行它時，它會正確標記缺失的日期。但是，在我的同事機器上，空白日期不會被標記，就好像該字段沒有被檢查一樣，當文件被導入到數據庫時導致了一點悲傷。

換句話說，我們的機器之間存在一些差異，導致代碼在機器上錯誤地執行，但不是我的機器。所有的機器都有Java 8（不確定究竟是哪個版本，但它們都應該是相同的版本）。怎麼可能？

來源

2017-02-14 NAMS

我的猜測是，你不讀文件你認爲你正在閱讀，或者你沒有正確寫出警告，或者你沒有將它們寫入你認爲的文件。添加日誌記錄語句，顯示文件的絕對路徑，正在檢查的行的值等。 –

如果包含'splitLine'方法的代碼，這將有所幫助。此外，一些示例輸入將會很有用。另外，您的所有同事都使用您使用的相同操作系統嗎？這比Java版本更重要，因爲'FileReader'使用系統的默認字符集。 – VGR

@VGR'splitLine'是'java.String.split（）'的結果。但我認爲GKR幫助我確定了根本原因。 – NAMS

您需要指定要讀取的文件的編碼。 [FileReader]的構造函數一般使用平臺默認編碼。所以確定實際的編碼和使用類似new InputStreamReader(new FileInputStream(input), <encoding>)
檢查每個機器的Java版本。驗證指定的java實際上是所謂
檢查文件（S）本身的編碼（UTF-8，CP1252，或......）

來源

2017-02-14 21:57:01

因此，在TextWrangler中打開時，看起來有問題的文件顯示其編碼爲「Western（ASCII）」，而不是通常的UTF-8，這可能是我的問題的根源。但是，在執行這些代碼之前，處理過程中有幾個步驟，並且原始文件以UTF-8開頭......所以它似乎是其他地方的根源。我覺得這可能是正確的答案;我會嘗試明確定義編碼，並在經過一段時間後再回過頭來接受此問題，並且我相信問題已解決。 – NAMS

我按照上面的說法嘗試過，但仍未解決問題，需要進一步調查;然而我接受了這個答案，正如我所說的那樣，因爲這仍然可能有幫助。 – NAMS

機器之間的Java jar執行差異

回答

相關問題