是否可以减少DateTime.Now.Ticks.ToString("X")的长度并仍然保持唯一性?

Wil*_*ill 2 c# compression datetime timestamp

我有一些与我工作的硬件的限制,其中我只能广播(无线)26个字符.

为了克服这种限制,第一广播发送转换为十六进制(DateTime.Now.Ticks.ToString( "X" ))的时间戳,以及正在发送的消息的长度(也作为十六进制字符串).

接收软件测试标头消息,当它确认收到标题消息时,将时间戳(重新转换为a 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;
Run Code Online (Sandbox Code Playgroud)

不幸的是,每次都必须传递时间戳,它超过了分配字符长度的一半(现在为15个字符).

所以我想的是,我可以通过将十六进制字符串的字符值相加来减少它,而不是传递整个时间戳:

例如 :

DateTime.Now.Ticks.ToSTring("X").Sum( C => C ).ToString("X");
Run Code Online (Sandbox Code Playgroud)

不幸的是,一个快速的测试毫不客气地吹走了这个想法

(重复键很快):

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.
}
Run Code Online (Sandbox Code Playgroud)

所以我的问题是 - 有没有办法可靠地减少我的"钥匙"的长度,同时仍然(合理地)保证唯一性?

Cᴏʀ*_*ᴏʀʏ 8

这里有一些可以启动一些答案的东西.我并不是说这是一个最佳的解决方案,但我可以获得毫秒精度,只有11个字符, 8个字符, 7个字符的编码数据.

假设毫秒精度足够好,我们可以从一开始就降低算法的精度.刻度表示100纳秒.一毫秒内有10,000个刻度.这是算法:

从过去发生的已知大量滴答开始.这个例子使用了本世纪初.

long centuryBegin = new DateTime(2001, 1, 1).Ticks; 
// 631139040000000000
Run Code Online (Sandbox Code Playgroud)

现在拍摄当前时间戳的快照:

long currentDate = DateTime.Now.Ticks;
// 636083231371736598
Run Code Online (Sandbox Code Playgroud)

采取差异,并将精度降低到毫秒级:

long shortTicks = (currentDate - centuryBegin) / 10000L; 
// 494419137173
Run Code Online (Sandbox Code Playgroud)

现在我们只对字符串进行base64编码:

string base64Ticks = Convert.ToBase64String(BitConverter.GetBytes(shortTicks));
// lVKtHXMAAAA=
Run Code Online (Sandbox Code Playgroud)

但是,在没有详细说明原因的情况下,尾随的"AAAA ="将出现在这个字节数的任何编码数上,因此我们可以删除它!

base64Ticks = base64Ticks.Substring(0, 7);
// lVKtHXM
Run Code Online (Sandbox Code Playgroud)

您现在有一个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
Run Code Online (Sandbox Code Playgroud)

我们来看看两者之间的区别:

 636083231371736598 (original ticks)
-636083231371730000 (decoded ticks)
===================
               6598 (difference)
Run Code Online (Sandbox Code Playgroud)

并且您可以看到这使您在原始时间戳的6,598个刻度或0.6598毫秒内.差异始终<= 1 ms.

在唯一性方面,我尝试了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);
}
Run Code Online (Sandbox Code Playgroud)

其中一些工作受到这篇文章的启发:将大整数压缩成最小的字符串