Question

我对我正在使用的某些硬件有限制，其中我只能广播（无线）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.
}

所以我的问题是 - 有没有办法可靠地减少我的“钥匙”的长度，同时仍然（合理地）保证唯一性？

Answer 1

这可以启动一些答案。我并没有声称这是一个最佳解决方案，但我可以获得毫秒精度，只有 ~~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毫秒。

就唯一性而言，我尝试了10万个假传输，在每次尝试之间睡眠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

是否可以减少DateTime.Now.Ticks.ToString（“X”）的长度并仍然保持唯一性？

1 个答案: