{"id":255525,"date":"2016-06-06T16:11:14","date_gmt":"2016-06-06T08:11:14","guid":{"rendered":"http:\/\/blog.zhenglei.net\/?p=255525"},"modified":"2016-06-06T16:11:14","modified_gmt":"2016-06-06T08:11:14","slug":"which-hashing-algorithm-is-best-for-uniqueness-and-speed","status":"publish","type":"post","link":"https:\/\/blog.zhenglei.net\/?p=255525","title":{"rendered":"Which hashing algorithm is best for uniqueness and speed?"},"content":{"rendered":"

http:\/\/programmers.stackexchange.com\/questions\/49550\/which-hashing-algorithm-is-best-for-uniqueness-and-speed<\/a><\/p>\n

I tested some different algorithms, measuring speed and number of collisions.<\/p>\n

I used three different key sets:<\/p>\n

A list of 216,553 English words (in lowercase)
\n The numbers “1” to “216553” (think ZIP codes, and how a poor hash took down msn.com)
\n 216,553 “random” (i.e. type 4 uuid) GUIDs<\/p>\n

For each corpus, the number of collisions and the average time spent hashing was recorded.<\/p>\n

I tested:<\/p>\n

DJB2
\n DJB2a (variant using xor rather than +)
\n FNV-1 (32-bit)
\n FNV-1a (32-bit)
\n SDBM
\n CRC32
\n Murmur2 (32-bit)
\n SuperFastHash<\/p>\n

Results<\/p>\n

Each result contains the average hash time, and the number of collisions<\/p>\n

Hash Lowercase Random UUID Numbers
\n============= ============= =========== ==============
\nMurmur 145 ns 259 ns 92 ns
\n 6 collis 5 collis 0 collis
\nFNV-1a 152 ns 504 ns 86 ns
\n 4 collis 4 collis 0 collis
\nFNV-1 184 ns 730 ns 92 ns
\n 1 collis 5 collis 0 collis\u25aa
\nDBJ2a 158 ns 443 ns 91 ns
\n 5 collis 6 collis 0 collis\u25aa\u25aa\u25aa
\nDJB2 156 ns 437 ns 93 ns
\n 7 collis 6 collis 0 collis\u25aa\u25aa\u25aa
\nSDBM 148 ns 484 ns 90 ns
\n 4 collis 6 collis 0 collis**
\nSuperFastHash 164 ns 344 ns 118 ns
\n 85 collis 4 collis 18742 collis
\nCRC32 250 ns 946 ns 130 ns
\n 2 collis 0 collis 0 collis
\nLoseLose 338 ns – –
\n 215178 collis<\/p>\n

Notes:<\/p>\n

The LoseLose algorithm (where hash = hash+character) is truly awful. Everything collides into the same 1,375 buckets
\n SuperFastHash is fast, with things looking pretty scattered; by my goodness the number collisions. I’m hoping the guy who ported it got something wrong; it’s pretty bad
\n CRC32 is pretty good. Slower, and a 1k lookup table<\/p>\n

Do collisions actually happen?<\/p>\n

Yes. I started writing my test program to see if hash collisions actually happen – and are not just a theoretical construct. They do indeed happen:<\/p>\n

FNV-1 collisions<\/p>\n

creamwove collides with quists<\/p>\n

FNV-1a collisions<\/p>\n

costarring collides with liquid
\n declinate collides with macallums
\n altarage collides with zinke
\n altarages collides with zinkes<\/p>\n

Murmur2 collisions<\/p>\n

cataract collides with periti
\n roquette collides with skivie
\n shawl collides with stormbound
\n dowlases collides with tramontane
\n cricketings collides with twanger
\n longans collides with whigs<\/p>\n

DJB2 collisions<\/p>\n

hetairas collides with mentioner
\n heliotropes collides with neurospora
\n depravement collides with serafins
\n stylist collides with subgenera
\n joyful collides with synaphea
\n redescribed collides with urites
\n dram collides with vivency<\/p>\n

DJB2a collisions<\/p>\n

haggadot collides with loathsomenesses
\n adorablenesses collides with rentability
\n playwright collides with snush
\n playwrighting collides with snushing
\n treponematoses collides with waterbeds<\/p>\n

CRC32 collisions<\/p>\n

codding collides with gnu
\n exhibiters collides with schlager<\/p>\n

SuperFastHash collisions<\/p>\n

dahabiah collides with drapability
\n encharm collides with enclave
\n grahams collides with gramary
\n …snip 79 collisions…
\n night collides with vigil
\n nights collides with vigils
\n finks collides with vinic<\/p>\n

Randomnessification<\/p>\n

The other subjective measure is how randomly distributed the hashes are. Mapping the resulting HashTables shows how evenly the data is distributed. All the hash functions show good distribution when mapping the table linearly:<\/p>\n

Enter image description here<\/p>\n

Or as a Hilbert Map (XKCD is always relevant):<\/p>\n

Enter image description here<\/p>\n

Except when hashing number strings (“1”, “2”, …, “216553”) (for example, zip codes), where patterns begin to emerge in most of the hashing algorithms:<\/p>\n

SDBM:<\/p>\n

Enter image description here<\/p>\n

DJB2a:<\/p>\n

Enter image description here<\/p>\n

FNV-1:<\/p>\n

Enter image description here<\/p>\n

All except FNV-1a, which still look plenty random to me:<\/p>\n

Enter image description here<\/p>\n

In fact, Murmur2 seems to have even better randomness with Numbers than FNV-1a:<\/p>\n

Enter image description here<\/p>\n

When I look at the FNV-1a “number” map, I think I see subtle vertical patterns. With Murmur I see no patterns at all. What do you think?<\/p>\n

The extra * in the above table denotes how bad the randomness is. With FNV-1a being the best, and DJB2x being the worst:<\/p>\n

Murmur2: .
\n FNV-1a: .
\n FNV-1: \u25aa
\n DJB2: \u25aa\u25aa
\n DJB2a: \u25aa\u25aa
\n SDBM: \u25aa\u25aa\u25aa
\nSuperFastHash: .
\n CRC: \u25aa\u25aa\u25aa\u25aa\u25aa\u25aa\u25aa\u25aa\u25aa\u25aa\u25aa\u25aa\u25aa\u25aa\u25aa\u25aa\u25aa\u25aa\u25aa
\n Loselose: \u25aa\u25aa\u25aa\u25aa\u25aa\u25aa\u25aa\u25aa\u25aa\u25aa\u25aa\u25aa\u25aa\u25aa\u25aa\u25aa\u25aa\u25aa\u25aa\u25aa\u25aa\u25aa\u25aa\u25aa\u25aa\u25aa
\n \u25aa
\n \u25aa\u25aa\u25aa\u25aa\u25aa\u25aa\u25aa\u25aa\u25aa\u25aa\u25aa\u25aa\u25aa
\n \u25aa\u25aa\u25aa\u25aa\u25aa\u25aa\u25aa\u25aa\u25aa\u25aa\u25aa\u25aa\u25aa\u25aa\u25aa\u25aa\u25aa\u25aa\u25aa\u25aa\u25aa\u25aa\u25aa\u25aa\u25aa\u25aa\u25aa\u25aa\u25aa\u25aa
\n \u25aa\u25aa\u25aa\u25aa\u25aa\u25aa\u25aa\u25aa\u25aa\u25aa\u25aa\u25aa\u25aa\u25aa\u25aa\u25aa\u25aa\u25aa\u25aa\u25aa\u25aa\u25aa\u25aa\u25aa\u25aa\u25aa\u25aa\u25aa\u25aa\u25aa\u25aa\u25aa\u25aa\u25aa\u25aa\u25aa\u25aa\u25aa\u25aa\u25aa\u25aa\u25aa\u25aa\u25aa\u25aa\u25aa\u25aa\u25aa\u25aa\u25aa\u25aa\u25aa\u25aa\u25aa\u25aa\u25aa\u25aa\u25aa\u25aa\u25aa\u25aa\u25aa\u25aa\u25aa\u25aa\u25aa\u25aa\u25aa\u25aa\u25aa\u25aa<\/p>\n

I originally wrote this program to decide if I even had to worry about collisions: I do.<\/p>\n

And then it turned into making sure that the hash functions were sufficiently random.
\nFNV-1a algorithm<\/p>\n

The FNV1 hash comes in variants that return 32, 64, 128, 256, 512 and 1024 bit hashes.<\/p>\n

The FNV-1a algorithm is:<\/p>\n

hash = FNV_offset_basis
\nfor each octetOfData to be hashed
\n hash = hash xor octetOfData
\n hash = hash * FNV_prime
\nreturn hash<\/p>\n

Where the constants FNV_offset_basis and FNV_prime depend on the return hash size you want:<\/p>\n

Hash Size Prime Offset
\n=========== =========================== =================================
\n32-bit 16777619 2166136261
\n64-bit 1099511628211 14695981039346656037
\n128-bit 309485009821345068724781371 144066263297769815596495629667062367629
\n256-bit
\n prime: 2^168 + 2^8 + 0x63 = 374144419156711147060143317175368453031918731002211
\n offset: 100029257958052580907070968620625704837092796014241193945225284501741471925557
\n512-bit
\n prime: 2^344 + 2^8 + 0x57 = 35835915874844867368919076489095108449946327955754392558399825615420669938882575126094039892345713852759
\n offset: 9659303129496669498009435400716310466090418745672637896108374329434462657994582932197716438449813051892206539805784495328239340083876191928701583869517785
\n1024-bit
\n prime: 2^680 + 2^8 + 0x8d = 5016456510113118655434598811035278955030765345404790744303017523831112055108147451509157692220295382716162651878526895249385292291816524375083746691371804094271873160484737966720260389217684476157468082573
\n offset: 1419779506494762106872207064140321832088062279544193396087847491461758272325229673230371772250864096521202355549365628174669108571814760471015076148029755969804077320157692458563003215304957150157403644460363550505412711285966361610267868082893823963790439336411086884584107735010676915<\/p>\n

See the main FNV page for details.<\/p>\n

As a practical matter:<\/p>\n

32-bit UInt32,
\n 64-bit UInt64, and
\n 128-bit Guid can be useful<\/p>\n

All my results are with the 32-bit variant.
\nFNV-1 better than FNV-1a?<\/p>\n

No. FNV-1a is all around better. There was more collisions with FNV-1a when using the English word corpus:<\/p>\n

Hash Word Collisions
\n====== ===============
\nFNV-1 1
\nFNV-1a 4<\/p>\n

Now compare lowercase and uppercase:<\/p>\n

Hash lowercase word Collisions UPPERCASE word collisions
\n====== ========================= =========================
\nFNV-1 1 9
\nFNV-1a 4 11<\/p>\n

In this case FNV-1a isn’t “400%” worse than FN-1, only 20% worse.<\/p>\n

I think the more important takeaway is that there are two classes of algorithms when it comes to collisions:<\/p>\n

collisions rare: FNV-1, FNV-1a, DJB2, DJB2a, SDBM
\n collisions common: SuperFastHash, Loselose<\/p>\n

And then there’s the how evenly distributed the hashes are:<\/p>\n

outstanding distribution: Murmur2, FNV-1a, SuperFastHas
\n excellent distribution: FNV-1
\n good distribution: SDBM, DJB2, DJB2a
\n horrible distribution: Loselose<\/p>\n

Update<\/p>\n

Murmur? Sure, why not<\/p>\n

Update<\/p>\n

@whatshisname wondered how a CRC32 would perform, added numbers to the table.<\/p>\n

CRC32 is pretty good. Few collisions, but slower, and the overhead of a 1k lookup table.<\/p>\n

Snip all erroneous stuff about CRC distribution – my bad<\/p>\n

Up until today I was going to use FNV-1a as my de facto hash-table hashing algorithm. But now I’m switching to Murmur2:<\/p>\n

Faster
\n Better randomnessification of all classes of input<\/p>\n

And I really, really hope there’s something wrong with the SuperFastHash algorithm I found; it’s too bad to be as popular as it is.<\/p>\n

Update: From the MurmurHash3 homepage on Google:<\/p>\n

(1) – SuperFastHash has very poor collision properties, which have been documented elsewhere.<\/p>\n

So I guess it’s not just me.<\/p>\n

Update: I realized why Murmur is faster than the others. MurmurHash2 operates on four bytes at a time. Most algorithms are byte by byte:<\/p>\n

for each octet in Key
\n AddTheOctetToTheHash<\/p>\n

This means that as keys get longer Murmur gets its chance to shine.<\/p>\n

Update
\nGUIDs are designed to be unique, not random<\/p>\n

A timely post by Raymond Chen reiterates the fact that “random” GUIDs are not meant to be used for their randomness. They, or a subset of them, are unsuitable as a hash key:<\/p>\n

Even the Version 4 GUID algorithm is not guaranteed to be unpredictable, because the algorithm does not specify the quality of the random number generator. The Wikipedia article for GUID contains primary research which suggests that future and previous GUIDs can be predicted based on knowledge of the random number generator state, since the generator is not cryptographically strong.<\/p>\n

Randomess is not the same as collision avoidance; which is why it would be a mistake to try to invent your own “hashing” algorithm by taking some subset of a “random” guid:<\/p>\n

int HashKeyFromGuid(Guid type4uuid)
\n{
\n \/\/A “4” is put somewhere in the GUID.
\n \/\/I can’t remember exactly where, but it doesn’t matter for
\n \/\/the illustrative purposes of this pseudocode
\n int guidVersion = ((type4uuid.D3 & 0x0f00) >> 8);
\n Assert(guidVersion == 4);<\/p>\n

return (int)GetFirstFourBytesOfGuid(type4uuid);
\n}<\/p>\n

Note: Again, I put “random GUID” in quotes, because it’s the “random” variant of GUIDs. A more accurate description would be Type 4 UUID. But nobody knows what type 4, or types 1, 3 and 5 are. So it’s just easier to call them “random” GUIDs.
\nAll English Words mirrors<\/p>\n

http:\/\/www.filedropper.com\/allenglishwords
\n https:\/\/web.archive.org\/web\/20070221060514\/http:\/\/www.sitopreferito.it\/html\/all_english_words.html<\/p>\n

shareimprove this answer<\/p>\n

edited Nov 9 ’15 at 18:12<\/p>\n

answered Apr 23 ’12 at 12:42
\nIan Boyd
\n12.6k1911<\/p>\n

181 \t <\/p>\n

some of the collisions make awesome band names. Particularly ‘Adorable Rentability’ \u2013 mcfinnigan Apr 23 ’12 at 14:35
\n27 \t <\/p>\n

Also, I’d love to hear how you generated these results (source code and\/or tools) \u2013 Earlz Apr 23 ’12 at 17:40
\n32 \t <\/p>\n

@Earlz Development tool is Delphi. i assume you mean the images though. For “linear” map i created a square bitmap of size nxn, (where n = Ceil(sqrt(hashTable.Capacity))). Rather than simply black for list entry is occupied and white for list entry is empty, i used an HSLtoRGB function, where the hue ranged from 0 (red) to 300 (magenta). White is still an “empty list cell”. For the Hilbert map i had to hunt wikipedia for the algorithm that turns an index into an (x,y) coordinate. \u2013 Ian Boyd Apr 23 ’12 at 18:15
\n32 \t <\/p>\n

I’ve removed a number of comments that were along the lines of “+1 great answer!” – Please don’t post comments that don’t ask for clarifications or add information to the answer, if you feel it’s a great answer, upvote it \ud83d\ude09 \u2013 Yannis\u2666 Apr 28 ’12 at 20:34
\n11 \t <\/p>\n

It would be really interesting to see how SHA compares, not because it’s a good candidate for a hashing algorithm here but it would be really interesting to see how any cryptographic hash compares with these made for speed algorithms. \u2013 Michael May 25 ’12 at 15:09
\nshow 69 more comments
\nup vote 30 down vote<\/p>\n

Here is a list of hash functions, but the short version is:<\/p>\n

If you just want to have a good hash function, and cannot wait, djb2 is one of the best string hash functions i know. It has excellent distribution and speed on many different sets of keys and table sizes<\/p>\n

unsigned long
\nhash(unsigned char *str)
\n{
\n unsigned long hash = 5381;
\n int c;<\/p>\n

while (c = *str++)
\n hash = ((hash << 5) + hash) + c; \/* hash * 33 + c *\/<\/p>\n

return hash;
\n}<\/p>\n

shareimprove this answer<\/p>\n

answered Feb 19 '11 at 1:13
\nDean Harding
\n17.8k33967<\/p>\n

2 \t <\/p>\n

Actually djb2 is zero sensitive, as most such simple hash functions, so you can easily break such hashes. It has a bad bias too many collisions and a bad distribution, it breaks on most smhasher quality tests: See github.com\/rurban\/smhasher\/blob\/master\/doc\/bernstein His cdb database uses it, but I wouldn't use it with public access. \u2013 rurban Aug 20 '14 at 6:03
\nadd a comment
\nup vote 26 down vote<\/p>\n

If you are wanting to create a hash map from an unchanging dictionary, you might want to consider perfect hashing https:\/\/en.wikipedia.org\/wiki\/Perfect_hash_function – during the construction of the hash function and hash table, you can guarantee, for a given dataset, that there will be no collisions.
\nshareimprove this answer<\/p>\n

answered May 25 '12 at 3:16
\nDamien
\n26132<\/p>\n

4 \t <\/p>\n

+1 I wasn't aware of such an algorithm \u2013 Earlz May 25 '12 at 5:00
\n2 \t <\/p>\n

Here's more about (minimal) Perfect Hashing burtleburtle.net\/bob\/hash\/perfect.html including performance data, although it doesn't use the most current processor etc. \u2013 Ellie Kesselman May 29 '12 at 12:24
\n3 \t <\/p>\n

It's pretty obvious, but worth pointing out that in order to guarantee no collisions, the keys would have to be the same size as the values, unless there are constraints on the values the algorithm can capitalize on. \u2013 devios Apr 4 '13 at 20:34<\/p>\n

I improved gperf and provide a nice frontend to most perfect hash generators at github.com\/rurban\/Perfect-Hash It's not yet finished, but already better then the existing tools. \u2013 rurban Aug 20 '14 at 6:05<\/p>\n

@devios: I've recently learned that there are several hash table algorithms that guarantee no collisions, even when you use long strings as keys, strings much longer than the hash table index values generated by the hash function, without any constraints on those strings. See cs.stackexchange.com\/questions\/477\/\u2026 . \u2013 David Cary Jun 8 '15 at 17:11
\nshow 1 more comment
\nup vote 20 down vote<\/p>\n

CityHash by Google is the algorithm you are looking for. It is not good for cryptography but is good for generating unique hashes.<\/p>\n

Read the blog for more details and the code is available here.<\/p>\n

CityHash is written in C++. There also is a plain C port.<\/p>\n

About 32-bit support:<\/p>\n

All the CityHash functions are tuned for 64-bit processors. That said, they will run (except for the new ones that use SSE4.2) in 32-bit code. They won't be very fast though. You may want to use Murmur or something else in 32-bit code.<\/p>\n

shareimprove this answer<\/p>\n

edited May 29 '12 at 11:56
\nJanX2
\n1051<\/p>\n

answered May 25 '12 at 10:29
\nVipin Parakkat
\n30924<\/p>\n

6 \t <\/p>\n

Is CityHash pronounced similar to "City Sushi?" \u2013 Eric Mar 20 '13 at 21:20<\/p>\n

Have a look at SipHash too, it is meant to replace MurmurHash\/CityHash\/etc. : 131002.net\/siphash \u2013 T\u00f6r\u00f6k Edwin Oct 15 '13 at 8:47
\n1 \t <\/p>\n

Also see FarmHash, a successor to CitHash. code.google.com\/p\/farmhash \u2013 stevendaniels Mar 18 '15 at 13:15
\n1 \t <\/p>\n

xxHash claims to be 5x faster than CityHash. \u2013 Clay Bridges May 22 '15 at 15:56
\nadd a comment
\nup vote 12 down vote<\/p>\n

The SHA algorithms (including SHA-256) are designed to be fast.<\/p>\n

In fact, their speed can be a problem sometimes. In particular, a common technique for storing a password-derived token is to run a standard fast hash algorithm 10,000 times (storing the hash of the hash of the hash of the hash of the … password).<\/p>\n

#!\/usr\/bin\/env ruby
\nrequire 'securerandom'
\nrequire 'digest'
\nrequire 'benchmark'<\/p>\n

def run_random_digest(digest, count)
\n v = SecureRandom.random_bytes(digest.block_length)
\n count.times { v = digest.digest(v) }
\n v
\nend<\/p>\n

Benchmark.bmbm do |x|
\n x.report { run_random_digest(Digest::SHA256.new, 1_000_000) }
\nend<\/p>\n

Output:<\/p>\n

Rehearsal ————————————
\n 1.480000 0.000000 1.480000 ( 1.391229)
\n————————— total: 1.480000sec<\/p>\n

user system total real
\n 1.400000 0.000000 1.400000 ( 1.382016)<\/p>\n

shareimprove this answer<\/p>\n

answered Feb 19 '11 at 0:21
\nyfeldblum
\n1,32579<\/p>\n

36 \t <\/p>\n

It's relatively fast, sure, for a cryptographic hashing algorithm. But the OP just wants to store values in a hashtable, and I don't think a cryptographic hash function is really appropriate for that. \u2013 Dean Harding Feb 19 '11 at 1:10
\n6 \t <\/p>\n

The question brought up (tangentially, it now appears) the subject of the cryptographic hash functions. That's the bit I am responding to. \u2013 yfeldblum Feb 22 '11 at 13:14
\n7 \t <\/p>\n

Just to put people off the idea of "In particular, a common technique for storing a password-derived token is to run a standard fast hash algorithm 10,000 times" — while common, that's just plain stupid. There are algorithms designed for these scenarios, e.g., bcrypt. Use the right tools. \u2013 TC1 Oct 14 '13 at 13:19
\n1 \t <\/p>\n

Cryptographic hashes are designed to have a high throughput, but that often means they have high setup, teardown, .rodata and\/or state costs. When you want an algorithm for a hashtable, you usually have very short keys, and lots of them, but do not need the additional guarantees of a cryptographic has. I use a tweaked Jenkins\u2019 one-at-a-time myself. \u2013 mirabilos Dec 6 '13 at 13:57
\nadd a comment
\nup vote 9 down vote<\/p>\n

I've plotted a short speed comparasion of different hashing algorithms when hashing files.<\/p>\n

The individual plots only differ slightly in the reading method and can be ignored here, since all files were stored in a tmpfs. Therefore the benchmark was not IO-Bound if you are wondering.<\/p>\n

Linear Scale
\n Logarithmic scale<\/p>\n

Algorithms include: SpookyHash, CityHash, Murmur3, MD5, SHA{1,256,512}.<\/p>\n

Conclusions:<\/p>\n

Non-cryptographich hasfunctions like Murmur3, Cityhash and Spooky are pretty close together. One should note that Cityhash may be faster on CPUs with SSE 4.2s CRC instruction, which my CPU does not have. SpookyHash was in my case always a tiny bit before CityHash.
\n MD5 seems to be a good tradeoff when using cryptographic hashfunctions, although SHA256 may be more secure to the collision vulnerabilities of MD5 and SHA1.
\n The complexity of all algorithms is linear – which is really not surprising since they work blockwise. (I wanted to see if the reading method makes a difference, so you can just compare the rightmost values).
\n SHA256 was slower than SHA512.
\n I did not investigate the randomness of the hashfunctions. But here is a good comparasion of the hashfunctions that are missing in Ian Boyds answer. This points out that CityHash has some problems in corner cases.<\/p>\n

The source used for the plots:<\/p>\n

https:\/\/github.com\/sahib\/rmlint\/tree\/gh-pages\/plots (sorry for the ugly code)<\/p>\n","protected":false},"excerpt":{"rendered":"

http:\/\/programmers.stackexchange.com\/que … \u7ee7\u7eed\u9605\u8bfb →<\/span><\/a><\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[2],"tags":[293],"class_list":["post-255525","post","type-post","status-publish","format-standard","hentry","category-linux","tag-hash"],"_links":{"self":[{"href":"https:\/\/blog.zhenglei.net\/index.php?rest_route=\/wp\/v2\/posts\/255525","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.zhenglei.net\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.zhenglei.net\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.zhenglei.net\/index.php?rest_route=\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.zhenglei.net\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=255525"}],"version-history":[{"count":2,"href":"https:\/\/blog.zhenglei.net\/index.php?rest_route=\/wp\/v2\/posts\/255525\/revisions"}],"predecessor-version":[{"id":255527,"href":"https:\/\/blog.zhenglei.net\/index.php?rest_route=\/wp\/v2\/posts\/255525\/revisions\/255527"}],"wp:attachment":[{"href":"https:\/\/blog.zhenglei.net\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=255525"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.zhenglei.net\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=255525"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.zhenglei.net\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=255525"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}