問題タブ [ushort]

65535 より大きい整数値を ushort にパックするためのシステムを考案しようとしています。説明させてください。

SQL Server の IDENTITY 列を使用して Int32 値を生成するシステムがあり、Int32 ID を ushort にオーバーフローさせる運用中のクライアント API によって制限されています。幸いなことに、クライアントには、これらの ID を持つものの約 20 程度のインスタンス (パッケージと呼びましょう) しかなく、ローカルの兄弟間でそれらを一意にする必要があるだけです。一般的に受け入れられている解決策は、クライアントに送信する前に Int32 ID を ushort に変換することです (キャストではなく、変換を意味します)。ただし、このアプローチには問題があります。

1. 65535 未満の一部の ID は、有効期限が切れていないため、任意の時点で特定のクライアントで引き続き有効である可能性があります。
2. ID の衝突は発生しません。つまり、パッケージ ID 1 がクライアントに送信された場合、65536 に適用されたときに ushort を作成するために Int32 から 65535 が削除された回数を追跡するアルゴリズムも 1 になり、衝突が発生します。
3. 返されたときに、ushort を Int32 に再構築できる必要があります。

この問題を解決するために利用できるのは、エコーされる単一の符号付きバイト フィールドであり、127 の値で遊ぶことができます (0 ～ 9 を別の目的で使用しているため、実際には 117 です)。これを「バイトフィールド」と呼びます。

3 つの異なる翻訳ルーチンについて説明しました。

1. 乗法: ushort を作成するために Int32 から 65535 を削除した回数をバイト フィールドに格納します。これには、上で詳述した衝突の問題があります。
2. シリアル化されたセッション状態: クライアントごとに、そのクライアントに関する事実に基づいてセッション ID を生成します。次に、クライアントがサーバーに再度アクセスしたときに、パッケージのインベントリを既知のデータベース ID に変換できるように、1 から配信されたパッケージの数までの 1:1 変換テーブルを保存します。シリアル化されたセッション状態をデータベースにバックアップし、1 秒間に数百から数千のトランザクションをサポートしたいため、これにはオーバーヘッドの問題があります。
3. バイト フィールドが、Int32 を受け取り、それを ushort に変換する変換アルゴリズムの ID である、さまざまなアルゴリズム アプローチ。明らかに、これらの多くは単純な乗法 (変換できる ID の上限を増やすため) になりますが、いくつかは、より小さな境界 (32768 など) を使用して、数値を加算/減算して、数値にできるだけ近づける乗法でなければなりません。兄弟間で一意であることを保証できる番号。このアプローチはプロセッサを集中的に使用しますが、スケーラビリティを維持しながら衝突を回避できるようにする必要があります (ただし、このアプローチでは、アップグレードにより ushort の問題が自然に解消される前に上限に達することはありません)。

したがって、私の質問は次のとおりです:上記の私のアプローチよりも良い方法はありますか?そうでない場合は、特定の数値がより大きい場合に1〜65535の数値を生成するアルゴリズム(アプローチ#3の場合)に関して何を探す必要がありますか? 0 で、一方向ハッシュであってはなりませんか?

明確化: ushort の上限が最大の問題というわけではありません。クライアント API が ushort を使用しているため、クライアントのバイト フィールドを組み合わせてより大きな値を取得することはできません (クライアント API はアップグレードできませんが、最終的には存在しなくなります) ）。

現時点では、データの配列を取得する方法として C# 文字列を受け入れている非常に苦痛なライブラリがあります。どうやら、これにより pinvokes のマーシャリングが容易になります。

では、ushort 配列をバイト単位で文字列にするにはどうすればよいでしょうか。私はもう試した：

私はこのようにそれを行うことができますが、それはまともな時間に近いものではありません.

ここで何をすべきですか？安全ではないですか？ある種の IntPtr 中間体を通過しますか?

C++ の char* である場合、これは非常に簡単になります...

編集：関数呼び出しは

ここで、VL は DICOM タイプの「値の長さ」であり、関数自体は SWIG によって C++ ライブラリへのラッパーとして生成されます。マネージド/アンマネージド境界を比較的簡単に越えることができるため、選択された表現は文字列のようですが、プロジェクト (これは GDCM) の C++ コード全体で、char* は単にバイト バッファーとして使用されます。したがって、イメージ バッファー ポインターを設定する場合、C++ ではかなり単純ですが、C# ではこの奇妙な問題に悩まされています。

これはハッキングであり、おそらく最善の方法は SWIG ライブラリを正しく動作させることであることを私は知っています。私は本当にそれを行う方法がわかりません.C＃側での簡単な回避策があれば、それを望んでいます。

Javaに変換しようとしているC＃のアプリケーションがあります。C＃アプリには、ushort型の変数がいくつかあります。Javaに同等のものはありますか？

ありがとうございました

単語 shortとushortC#の違いは何ですか? どちらも16ビットです！

値の範囲が 0 から short の最大値までの short の配列があります。結果の短い値の範囲が 0 ～ 65535 になるように、データを (TYPE_USHORT として表示するために) スケーリングします。スケーリングされた値の一部を出力する必要がありますが、方法がわかりません。データは配列と BufferedImage にあります。

int 値を 16 ビットの unsigned char 型 (USHORT) に変換しようとしています。例では、41104 は ushort では A909 ですが、C# では (MSDN の記事BitConverter.GetBytes Yöntem (UInt16)の助けを借りて) 次のようにコード サンプルを試しました。

A909 値を 41104 の ushort として取得するにはどうすればよいですか?

私はこれを持っていますbyte[]: 00 28 00 60 00 30 10 70 00 22 FF FF。

バイトの各ペアを単語に結合したい: 0028 0060 0030 1070 0022 FFFF.

また、単語配列を文字列に変換したい: "0028 0060 0030 1070 0022 FFFF"(を使用せずにbyte[])。

SLaks コードを修正したところ、次のように動作します。

C＃のアプリケーションは、サードパーティのTcpサーバーと連携して、データを送信し、応答メッセージを受信したいと考えています...コマンドの構文には、UShort、ULONG、BYTEタイプのデータがあり、アプリで送信する必要のあるサンプルコマンドは次のとおりです。

次に、アプリでデータを次のように送信します

//またはバイトを送信します

そして私はサーバー経由で着信メッセージを次のように読みます

しかし、戻り値は私が探しているものではありませんサーバーにデータを送信することで私のコードに何か問題がありますか？書き込みデータの読み取りに関する推奨事項は大歓迎です...

raw-bytes 値を Java 型に変換する際に問題があります。データグラム ソケットでバイト配列としてバイトを受信して​​います。どのバイトが何を意味するかは正確に知っていますが、それらを適切に変換する方法がわかりません (つまり、オフセットは知っていますが、受け取ったと思うものが正しいかどうかはわかりません;))。

たとえば、16 ビットの unsigned short を Java int 型に変換したいとします。私はウェブでいくつかの例を見つけました.1つは次のとおりです。

もう1つは同じですが、最後の行は次のとおりです。

もちろん、それは異なる結果をもたらします。どちらが正しいですか？同じことを行う方法の有効な例も教えてください。

前もって感謝します！

形式のuhort[]値があります0-65536。しかし、このグレースケール値がバイト形式で必要です!

ushort 値をバイト値に変換するにはどうすればよいですか?

ありがとう