我使用的某些硬件有限制,我只能广播(无线)26 个字符。
为了克服这个限制,第一个广播传输一个转换为十六进制的时间戳(DateTime.Now.Ticks.ToString( "X")
),以及正在传输的消息的长度(也作为十六进制字符串)。
接收软件测试标题消息,当它确认收到一个消息时,将时间戳(重新转换为 long
)存储在字典中:
/*************************************************************************
* _pendingMessages.Add( DateTime.Now.Ticks, Tuple.Create( MessageLength, string.Empty ) );
* T.Item1 = Message Length
* T.Item2 = Message ( when Message.Length == Length, Pop Message )
*************************************************************************/
private static Dictionary<long, Tuple<long, string>> _pendingMessages;
不幸的是,每次都必须传递时间戳,而且它...超过了分配的字符长度的一半(现在是 15 个字符)。
所以我在想,与其传递整个时间戳,不如通过对十六进制字符串的字符值求和来减少它:
例如:
DateTime.Now.Ticks.ToSTring("X").Sum( C => C ).ToString("X");
不幸的是,一个快速测试毫不客气地打消了这个想法
(复制键相当快):
Dictionary<string, long> _dctTest = new Dictionary<string, long>( );
while ( true ){
long dtNow = DateTime.Now.Ticks;
string strKey = dtNow.ToString("X").Sum( C => C ).ToStrings("X");
_dctTest.Add( strKey, dtNow ); //<=====Explodes after less than a second.
}
所以我的问题是 - 有什么方法可以可靠地减少“ key ”的长度,同时仍然(合理地)保证唯一性?
最佳答案
这里有一些东西可以启动一些答案。我并不是说这是一个最佳解决方案,但我可以只用 11 个字符 8 个字符 7 个字符 编码数据为您提供毫秒精度。
假设毫秒精度足够好,我们可以从一开始就降低算法的精度。一个刻度代表 100 纳秒。一毫秒有 10,000 个刻度。这是算法:
从过去发生的已知大量滴答开始。此示例使用世纪初。
long centuryBegin = new DateTime(2001, 1, 1).Ticks;
// 631139040000000000
现在拍摄当前时间戳的快照:
long currentDate = DateTime.Now.Ticks;
// 636083231371736598
取差,将精度降低到毫秒级:
long shortTicks = (currentDate - centuryBegin) / 10000L;
// 494419137173
现在我们只是对字符串进行 base64 编码:
string base64Ticks = Convert.ToBase64String(BitConverter.GetBytes(shortTicks));
// lVKtHXMAAAA=
但是,无需详细说明原因,结尾的“AAAA=”将出现在该字节数的任何编码数字上,因此我们可以将其删除!
base64Ticks = base64Ticks.Substring(0, 7);
// lVKtHXM
您现在有一个 7 字符的字符串 lVKtHXM
用于传输。 在另一边:
// Decode the base64-encoded string back into bytes
// Note we need to add on the "AAAA=" that we stripped off
byte[] data = new byte[8];
Convert.FromBase64String(base64Ticks + "AAAA=").CopyTo(data, 0);
// From the bytes, convert back to a long, multiply by 10,000, and then
// add on the known century begin number of ticks
long originalTicks = (BitConverter.ToInt64(data, 0) * 10000L) + centuryBegin;
// 636083231371730000
让我们检查一下两者之间的区别:
636083231371736598 (original ticks)
-636083231371730000 (decoded ticks)
===================
6598 (difference)
而且您可以看到,这使您可以在原始时间戳的 6,598 个滴答声或 0.6598 毫秒以内。差异总是 <= 1 毫秒。
就唯一性而言,我在 100,000 次虚假传输上进行了尝试,每次尝试之间休眠 1 毫秒,并且没有冲突。
为了完善这篇文章,这里有一些您可能会使用的辅助方法:
public static string EncodeTransmissionTimestamp(DateTime date)
{
long shortTicks = (date.Ticks - 631139040000000000L) / 10000L;
return Convert.ToBase64String(BitConverter.GetBytes(shortTicks)).Substring(0, 7);
}
public static DateTime DecodeTransmissionTimestamp(string encodedTimestamp)
{
byte[] data = new byte[8];
Convert.FromBase64String(encodedTimestamp + "AAAA=").CopyTo(data, 0);
return new DateTime((BitConverter.ToInt64(data, 0) * 10000L) + 631139040000000000L);
}
部分作品的灵感来自这篇文章:Compress large Integers into smallest possible string
关于c# - 是否可以减少 DateTime.Now.Ticks.ToString ("X"的长度)并仍然保持唯一性?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/39261767/