MobileRead Forums - View Single Post - Converting Mobi Dictionaries to other formats

KevinH · 01-03-2011, 04:46 PM

Hi,

I looked at a Mobi dictionary I had by running strings and found it had a number of additional sections not usually found in a normal mobi book. These section types names were:

INDX, IDXT, ORDT, SPL1, SPL2, SPL3, SPL4, SPL5, SPL6

If I run "strings" on a dictionary that is a .mobi file, I find a sequences of INDX followed by selected words that span the alphabet ending with a IDXT. This looks like the first index table and that redirects you by comparison to the next layer of INDX tables which are much longer and seem to be all of the words in the dictionary in one of the segments covered in the first INDX table.

These must be generated by the missing code you noticed.

You could possibly modify mobiunpack to find and identify and dump these extra sections and use this information to put back the original code. Unfortunately, I have no idea which bytes in the header point to the number of each of these section types and their starting offset. So it would take some exploring to reverse all of this out.

The missing code related pieces are in the dictionary .mobi, but without info on how to find them and use them they are not very useful.

01-03-2011, 04:46 PM	#11
KevinH Sigil Developer Posts: 8,837 Karma: 6120478 Join Date: Nov 2009 Device: many	Hi, I looked at a Mobi dictionary I had by running strings and found it had a number of additional sections not usually found in a normal mobi book. These section types names were: INDX, IDXT, ORDT, SPL1, SPL2, SPL3, SPL4, SPL5, SPL6 If I run "strings" on a dictionary that is a .mobi file, I find a sequences of INDX followed by selected words that span the alphabet ending with a IDXT. This looks like the first index table and that redirects you by comparison to the next layer of INDX tables which are much longer and seem to be all of the words in the dictionary in one of the segments covered in the first INDX table. These must be generated by the missing code you noticed. You could possibly modify mobiunpack to find and identify and dump these extra sections and use this information to put back the original code. Unfortunately, I have no idea which bytes in the header point to the number of each of these section types and their starting offset. So it would take some exploring to reverse all of this out. The missing code related pieces are in the dictionary .mobi, but without info on how to find them and use them they are not very useful.