6

タブで区切られた古い MySQL データベース ダンプ ファイルの束をプロトコル バッファに変換する作業を行っていますが、問題が発生しました。MySQL テーブルには、ファイル内のint(11) unsignedprotobuf にマップしたtype のフィールドが含まれています。MySQL レコードを解析してそれらを protobuf メッセージに変換しようとするとき、(またはオーバーフローを回避するために) を使用してそのフィールドを解析したくなります。ただし、Protocol Buffers Language Guideでは、Java ではs はデータ型を使用して表されますが、最初のビットは符号ビットではなく最上位ビットとして再解釈されることが示されています。uint32.protoInteger.valueOf(String)Long.valueOf(String)uint32int

したがって、独自のString-> uint32-flavored-intパーサーを作成する前に、他の誰かがこの特定の問題を既に解決しているかどうかを尋ねる価値があると思いました。StringMySQL の表現をJavaint unsignedのプロトコル バッファに変換する正しい方法は何ですか?uint32

4

2 に答える 2

2

uint32を表すintへの文字列

として解析してから、次のようlongに変換してみintます。

int i = (int)Long.parseLong(str);

long変換に使用すると、NumberFormatException範囲を超えたためにを回避できます。その後のナローイング変換では、結果のビットの上位半分がドロップされ、プロトコルバッファに必要な表現が正確に残ります。

uint64を表す文字列から長い文字列

uint64使用するための同様の変換は、BigIntegerおそらく次のように記述できます（テストされていないコード）。

long l = (new BigInteger(str)).longValue();

これは、上記の場合と同様に、暗黙的な切り捨てに依存します。ドキュメントには次のように記載されています。

これBigIntegerが大きすぎてlongに収まらない場合は、下位64ビットのみが返されます。

uintからlongを表すint

int実際にを表すようなものuint32を正の符号で変換する場合longは、32の最上位ビットをクリアする必要があります。これらは、符号のintために、値の最上位ビットのコピーで埋められるためです。拡大変換の拡張性。

long uintValue = intValue & 0xffffffffL;
于 2013-02-21T08:29:13.187 に答える
0

エンディアンが問題にならない場合は、unsigned int を固定長のバイト配列として脅かすことができます。

于 2013-02-20T23:08:01.817 に答える