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

[steppe]

Hi. thanks for the update.

[dimasic]

Thanks for great handy tool.

But there's a problem. Windows 7 x32, KindleUnpack 0.61, 0.62 From GUI shell the tool works perfectly, but when it is started from command line AND filename contains cyrillic symbols, it says that "'utf8' codec can't decode byte 0xcb in position 0: invalid continuation byte". Renamed with latin characters file will be unpacked pretty well, so the problem only with filename handling. Is it possible to do something with it?

[KevinH]

Hi,
Even in command line mode, kindleunpack makes calls to get the command line using Windows Wide calls to get a full unicode version of all arguments, which it then converts to utf-8 internally. So I am surprised you are having trouble. What shell and what encoding are you using to invoke the command line? Are you by any chance using a bat file? If so you will need to use cp65001 on the same line you use to invoke kindleunpack.

Thanks,

KevinH

Originally Posted by dimasic

Thanks for great handy tool.

But there's a problem. Windows 7 x32, KindleUnpack 0.61, 0.62 From GUI shell the tool works perfectly, but when it is started from command line AND filename contains cyrillic symbols, it says that "'utf8' codec can't decode byte 0xcb in position 0: invalid continuation byte". Renamed with latin characters file will be unpacked pretty well, so the problem only with filename handling. Is it possible to do something with it?

[dimasic]

The command line codepage is cp866, the shell is cmd.exe. As I said, when invoking from command line / bat file, it gets the error. Even if the directory path of the MOBI file contains cyrillic, but the filename itself in latin chars, then it's all OK. Is it necessary to convert filename? For example, the kindlestrip tool, written on python too, works well. Without conversion or something like that.

[KevinH]

Hi,
You should just be able to fix your bat file to change to cp65001 on the same line you invoke kindleunpack.py

Something similar to the following should work in your bat file

chcp 65001 > nul && start /min python kindleunpack.py %*

The problem is without the chcp 65001, python will default to mbcs codec that can not represent all chars from every language and some chars then get mangled inside the python interpreter before ever reaching this program.

Changing to utf-8 (cp-65001) first allows all chars from every language to be represented and properly passed to Windows so hat Windows wide calls can be made to get all arguments.

Please give something similar to this a try and you should be able to get the command line to work properly on Windows. If not, enable debug mode from the command line and post a full debug output here in case the problem is occurring someplace other than right at the command line interface.

Please let me know the result.

Thanks,

KevinH

Originally Posted by dimasic

The command line codepage is cp866, the shell is cmd.exe. As I said, when invoking from command line / bat file, it gets the error. Even if the directory path of the MOBI file contains cyrillic, but the filename itself in latin chars, then it's all OK. Is it necessary to convert filename? For example, the kindlestrip tool, written on python too, works well. Without conversion or something like that.

[KevinH]

Hi,

You are right it is a bug. In kindleunpack.py, near the end of the file, you will see the following code block:

    argv=utf8_argv()
    progname = os.path.basename(argv[0])
    try:
        opts, args = getopt.getopt(sys.argv[1:], "hdrs")
    except getopt.GetoptError, err:
        print str(err)
        usage(progname)
        sys.exit(2)

    if len(args)<1:
        usage(progname)
        sys.exit(2)

    for o, a in opts:
        if o == "-d":
            DUMP = True
        if o == "-r":
            WRITE_RAW_DATA = True
        if o == "-s":
            SPLIT_COMBO_MOBIS = True
        if o == "-h":
            usage(progname)
            sys.exit(0)

    if len(args) > 1:
        infile, outdir = args
    else:
        infile = args[0]

Please change this line:

opts, args = getopt.getopt(sys.argv[1:], "hdrs")

To look like this and see if that fixes your issue?

opts, args = getopt.getopt(argv[1:], "hdrs")

So that it will get the utf-8 encoded command line and not the python broken internal sys.argv command line.

Hope this fixes the issue!

Thanks,

KevinH

[dimasic]

Oh, thank you! Now it works with any symbol set.

[KevinH]

Hi,

Thanks for letting me know that did the trick. I will include it in the next update but that may be a while away since neither the gui nor the calibre plugin uses the command line interface.

Take care,

Kevin

[MastroMicio]

Hi,

I have a problem with the KindleUnpack/MobiUnpack drag&drop applescript. The mobi file I'd like to unpack is a custom-made non-drm book I create with kindlegen from an ePub file. The problem is that if I drag the mobi file over the MobiUnpack applescript and drop it, I can see the script opening and closing on the dock but no folder appears close to the mobi file. Isn't the folder of the unpacked book supposed to appear in the same folder the two files are? Am I doing something wrong? I was used to use those scripts while ago and maybe I forgot how to use them properly (or maybe they don't work on the last OSX?..btw I have OSX 10.8.4).

Thanks in advance to everyone. Sorry for bothering you with my issues.

[KevinH]

Hi,

Try simply double-clicking on that applescript (instead of dragging and dropping something on it) and see if it allows you to set or change preferences. Perhaps there is a preference where you tell it where to put the unpacked files? I am not too sure but Paul will know for sure.

If not, then it may be a bug in KindleUnpack somehow? You can try running it via the command line or by simply double-clicking the KindleUnpack.pyw app and following along. Once there you can see a log file and turn on debug and raw flags so that we can see what is happening.

Thanks,

KevinH

Originally Posted by MastroMicio

Hi,

I have a problem with the KindleUnpack/MobiUnpack drag&drop applescript. The mobi file I'd like to unpack is a custom-made non-drm book I create with kindlegen from an ePub file. The problem is that if I drag the mobi file over the MobiUnpack applescript and drop it, I can see the script opening and closing on the dock but no folder appears close to the mobi file. Isn't the folder of the unpacked book supposed to appear in the same folder the two files are? Am I doing something wrong? I was used to use those scripts while ago and maybe I forgot how to use them properly (or maybe they don't work on the last OSX?..btw I have OSX 10.8.4).

Thanks in advance to everyone. Sorry for bothering you with my issues.

[pdurrant]

Originally Posted by MastroMicio

Hi,

I have a problem with the KindleUnpack/MobiUnpack drag&drop applescript. The mobi file I'd like to unpack is a custom-made non-drm book I create with kindlegen from an ePub file. The problem is that if I drag the mobi file over the MobiUnpack applescript and drop it, I can see the script opening and closing on the dock but no folder appears close to the mobi file. Isn't the folder of the unpacked book supposed to appear in the same folder the two files are? Am I doing something wrong? I was used to use those scripts while ago and maybe I forgot how to use them properly (or maybe they don't work on the last OSX?..btw I have OSX 10.8.4).

Thanks in advance to everyone. Sorry for bothering you with my issues.

My guess would be security settings. Try running the AppleScript by just double-clicking it. You should get an information dialog. If you get a warning that you can't run this application because of your security settings, hold down the control key and double-click it again. That should give you an option to open it anyway.

[MastroMicio]

Problem solved!
Thank you sooooooo much!! You guys are life savers!

[NiLuJe]

Hello again!

I'm still using a stripped down KindleUnpack in the Kindle ScreenSavers hack, and one user just ran into a weird thing: a JPEG file with no EXIF or JFIF header, used as the cover.

imghdr doesn't handle those, so it gets discarded as an unknown resource. FWIW, GIMP chokes on it too, but ImageMagick handles it fine. Since I'm using IM, I amended the imghdr check with another one, right after:

                # imghdr only checks for JFIF or Exif JPEG files. Apparently, there are some with only the magic JPEG bytes out there... ImageMagick handle those, so, do it too.
                if imgtype is None and data[0:2] == chr(0xFF) + chr(0xD8):
                    imgtype = "jpeg"

Has anyone ever encountered JPEG files like that before?

[kovidgoyal]

https://github.com/kovidgoyal/calibr...tils/imghdr.py

[NiLuJe]

Ha ! Should have checked Calibre ;-)

Thanks !