1

私がクライアント向けに開発しているアプリの場合、バージョン管理された更新の一部として新しいデータが再入力される、ゴルフ コースの大規模な SQLite データベースがあります。つまり、データベースに既に存在するレコードに新しいデータが追加されます。

これらの更新の一部は、カンマ区切りの .txt ファイルとして自動的にエクスポートされる数値データとテキスト データの混合物です (ただし、.rtf としてエクスポートすることもできますが、.txt の方がはるかに作業しやすいと思います）。このような出力 .txt ファイルの例は、この Pastebin リンク にあります。

.txt ファイルの読み取りを処理し、各行から各値を取得するコードは次のとおりです。

// Insert records from csv file into database
        BufferedReader reader = new BufferedReader(new InputStreamReader(in_s));
        try {
            String line;
            while ((line = reader.readLine()) != null) {
                String[] RowData = line.split(", ");
                int numEntries = RowData.length;
                if(numEntries == 5) {
                    // Course Insertion Row
                    //                      "Scenic Hills CC - WHITE", 70.0, 124, "Pensacola", "FL"
                    courseHelper.createCourse(RowData[0], Double.valueOf(RowData[1]), Integer.parseInt(RowData[2]), RowData[3], RowData[4]);
                    mCurrentLine++;
                }
                else {
                    // Hole Insertion Row
                    //                      1, 1, 4, 416
                    holeHelper.createHole(Integer.parseInt(RowData[0]), Integer.parseInt(RowData[1]), Integer.parseInt(RowData[2]), Integer.parseInt(RowData[3]));
                    mCurrentLine++;

                }                   
            }
        }

コースデータベースの更新を自分で処理しようとするクライアントは、技術に精通しておらず、更新ごとに新しい.txtファイルを送信する方法を使用することを主張しています.

ただし、受け取った .txt ファイルの一部が大きくなったため、100 行ごとに約 2 行で「java.lang.NumberFormatException: '6' を整数として解析できません」タイプのエラーが発生し始めました。ファイルの長さは、.txt ファイルのどの行で例外が発生したかに基づいて、6 以外のさまざまな数値で表されます。

Bless Hex Editor で .txt ファイルを開くと、NumberFormatException を引き起こすすべての行の先頭で、ASCII 以外の文字 (16 進数では EF BB) が先頭の整数の直前にあることに気付きました。明らかに、この非 ASCII 文字がparseInt()メソッドをクラッシュさせています。

その長い説明の後、2 つの主な質問があります。

  1. これらの非ASCII文字の配置がファイル全体で疑似ランダムに見える場合でも、根本的な問題を修正する最良の方法は何ですか?
  2. #1 の適切な修正が不可能な場合、関連するアクティビティで読み込まれる前に .txt ファイルを "サニタイズ" する良い方法は何でしょうか?

提供されたヘルプは大歓迎です。ありがとう！

4

2 に答える 2

1

バイトオーダーマーク（http://en.wikipedia.org/wiki/Byte_order_mark）である可能性があります。EF BBは、テキストストリームの先頭でUTF-8エンコーディングを識別するBOMの一部のように見えます。

クライアントがこれらのファイルをどのように作成しているかを尋ねます。複数のファイルを1つの大きなファイルにマッシュアップするプロセスが何であれ、複数のBOMを誤って最終ストリームに吐き出す可能性があります。

これらのファイルを生成するプロセスを修正できない場合は、その周りにコーディングすることができます。数値形式の例外をキャッチし、ストリームを巻き戻して（可能/必要な場合）、同じ2バイトが原因であるかどうかをテストしてみてください。その場合、それらの2バイトを破棄し、次の整数を解析します。

于 2012-10-12T02:33:07.937 に答える
0

parseIntBOM ( if (str.startsWith("\uFEFF"))) を検出して削除するラッパー関数を作成します。

于 2012-10-12T06:50:42.507 に答える