KindleUnpack (MobiUnpack): Extracts text, images and metadata from Kindle/Mobi files

[DiapDealer]

For anybody who's interested... I made an experimental calibre plugin version of mobi_unpack. You simply select a folder where you want to unpack to (or a permanent folder can be set in the configuration) and click "unpack". It also supports extracting PDFs from print replica ebooks and splitting KF8/MOBIs built by newer versions of Kindlegen.

Let me know if anyone runs into any trouble (and be sure to restart calibre after installing the plugin before configuring/using it).

By all means, unzip the file to inspect the code if you're into that sort of thing, but otherwise the zip file is all ready to install as a plugin in calibre. You'll need a relatively new(ish) version of calibre to use it (>= 0.8.18)

And unless there are massive structural changes to the current mobi_unpack code, it should be a matter of simply dropping the latest mobi_unpack files into the plugin (like I just did with v0.38).

Have fun.

P.S. - I'll start my own thread for this if there's an interest.

EDIT: Plugin updated to incorporate the latest version of mobi_unpack
EDIT: (2/20/2012) Plugin updated to incorporate mobi_unpack's v0.40 bug-fixes.
EDIT: (2/29/2012) Plugin updated to incorporate mobi_unpack's v0.41 bug-fixes.
EDIT: (3/8/2012) I've created a thread for the calibre plugin version of mobi_unpack in the appropriate calibre subforum. You can find it here.

[KevinH]

Deleted since out of date

[thomass]

Originally Posted by DiapDealer

For anybody who's interested... I made an experimental calibre plugin version of mobi_unpack.

Thanks for the plugin. works great

[KevinH]

deleted since announced a now out of date version

[KevinH]

Hi All,

A new bug fix release is available:

So we now have a Mobi_Unpack_v045.zip.

See this post for the archive and usage information:

https://www.mobileread.com/forums/sho...&postcount=297

Have Fun!

Kevin

[frostschutz]

Thanks.

Mobi_Unpack.pyw does not run natively in Linux (when trying to start it directly) because it uses DOS style \r\n line terminators, so it keeps looking for a "/usr/bin/python\r" which naturally does not exist. So it has to be started with "python Mobi_Unpack.pyw" or loaded and saved with Unix style \n newlines.

I'll test this in more detail when I get my next mobi book.

[DiapDealer]

Just dos2unix Mobi_Unpack.pyw. It'll fix it right up.

[KevinH]

Hi,

Thanks for that info. Interestingly, a feature of most unzip programs is the ability to do automatic end of line conversions since there is no way for a cross-platform script file to have only one set of line ending across all platforms.

On my command line version of unzip this is done using the -a option.

So will you please try by grabbing the .zip again and unzipping it using the command line:

unzip -a Mobi_Unpack_v041.zip

and see if that same problem still happens. On my machine, unzip recognizes that python scripts are text files and converts the \r\n to just \n line endings automagically.

Please let me know what you find out.

KevinH

Originally Posted by frostschutz

Thanks.

Mobi_Unpack.pyw does not run natively in Linux (when trying to start it directly) because it uses DOS style \r\n line terminators, so it keeps looking for a "/usr/bin/python\r" which naturally does not exist. So it has to be started with "python Mobi_Unpack.pyw" or loaded and saved with Unix style \n newlines.

I'll test this in more detail when I get my next mobi book.

[frostschutz]

I don't use unzip -a because it could be damaging. After all there could be a perfectly good reason why a particular file uses/needs this style of newlines.

In the lib folder most files use unix newlines, except for scrolltextwidget.py and subasyncio.py. I don't think there is any intentional reason for it, merely an oversight.

Windows Python should be able to handle Unix \n newlines fine.

[KevinH]

Hi,

Originally Posted by frostschutz

I don't use unzip -a because it could be damaging. After all there could be a perfectly good reason why a particular file uses/needs this style of newlines.

In the lib folder most files use unix newlines, except for scrolltextwidget.py and subasyncio.py. I don't think there is any intentional reason for it, merely an oversight.

Windows Python should be able to handle Unix \n newlines fine.

Using unzip -a on Mobi_Unpack_vXXX.zip is perfectly safe as it is a pure python implementation (all text files) and includes no binary files. That is why unzip has the -a option to begin with. And that is why I suggested you to use it.

Multiple people have developed these scripts on multiple platforms using multiple text editors and they will continue to do so. So some python files may end up as having \r\n at various points in time depending on what platform they were edited on last. So as I explained all you need do is unpack them properly using unzip -a and all will be well. Or use dos2unix as DiapDealer suggested.

KevinH

[frostschutz]

In other words, it won't be fixed. That's all right, then. Sorry for bringing it up.

[KevinH]

Hi,

No, that is not what I said. I said "unpack it properly" and you won't have issues. The next version will convert to only newlines but I can't guarantee it will stay that way in the future because of the number of different people and editors used so unpacking it properly is the safest bet.

[DiapDealer]

That's the beauty of scripts: everyone's free to "fix" them in whatever way they see fit... even things that aren't truly broken.

[frostschutz]

Originally Posted by KevinH

I said "unpack it properly" and you won't have issues.

We're talking at cross purpose then; if your purpose is to help me get it running, you don't need to - I know how to fix newlines, so you don't have to tell me about unzip, dos2unix, etc.

My purpose was to point out a minor problem in your software which has to be fixed on your end. I know how to fix it my self - others may not. And while unzip is able to convert newlines with an option, this just is not done usually. No one even thinks of it because files are supposed to be correct in the archive in the first place.

It's unfortunate that Linux has problems with \r in the shebang line, as Python itself does not care either way about it. Part of the blame lies also with coreutils (/usr/bin/env) as it prints out the filename verbatim, causing the error message:

/usr/bin/env: python\r: No such file or directory.

To show up as:

: No such file or directory.

instead, since the \r throws the cursor back to the beginning of the line and the following text overwrites the beginning of the message.

Without /usr/bin/env you get an error message such as this:

bash: ./Mobi_Unpack.pyw: /usr/bin/python^M: bad interpreter: No such file or directory

So the \r has been replaced with ^M which gives the user a more useful error message.


As it is, Python source code just has to be using Unix newlines to be cross platform. Any one who works with or edits Python code should be aware of it (any proper coding editor would not turn \n into \r\n unasked anyway). Windows \r\n is Windows only, unfortunately.

[DiapDealer]

I've created a thread for the calibre plugin version of mobi_unpack in the appropriate calibre subforum. You can find it here. When mobi_unpack is updated, I'll try to update the plugin accordingly, as soon as possible.