Mobiperl Mobiperl - Perl tools for handling MobiPocket files

[EbokJunkie]

@tears0fshad0w
Look here.

[pdurrant]

Originally Posted by tears0fshad0w

I did calibre. It didn't work. There was still the default blue cover.

Change the cover in the calibre database. Then do a save to disk. Calibre doesn't change the cover of the file in the database, only in exported copies.

[hfpop]

Mobi2mobi.exe does not recognize non-ascii characters in its parameters, including the filenames. For example, even if I have the file "fișier.mobi", trying mobi2mobi fișier.mobi says file not found. This happens under windows 8.1 from command line.

[eschwartz]

What do you need mobi2mobi for? Much of its functionality is also present in, say, calibre.

Or Java Mobi Metadata Editor, which also handles AZW3 IIRC.

[hfpop]

Originally Posted by eschwartz

What do you need mobi2mobi for? Much of its functionality is also present in, say, calibre.

Or Java Mobi Metadata Editor, which also handles AZW3 IIRC.

Calibre is 200 MB. Java itselfis 200 MB. Mobi2mobi compiled as exe is 2 MB.

Now that we have seen this, could you please answer the question or admit you do not know the answer?

Thank you.

[DaleDe]

Originally Posted by hfpop

Calibre is 200 MB. Java itselfis 200 MB. Mobi2mobi compiled as exe is 2 MB.

Now that we have seen this, could you please answer the question or admit you do not know the answer?

Thank you.

Actually there is likely no good answer. The shell used from the command line has a restricted list of characters for filenames. You can try renaming the file but if you use the command line even that is not likely to work. The shell is not unicode compliant. You could try making a shortcut to Mobi2mobi and then dragging the file to the shortcut. This will bypass the command line but it still might not work. Sorry

Dale

[DaleDe]

I did a search and found the following:

Try:

chcp 65001

which will change the code page to UTF-8. Also, you need to use Lucida console fonts. There are limitations using this code page. Scripts may just stop working and other problems may occur.

Dale

[hfpop]

@DaleDe: yes, I got as well the solution with chcp 65001. This solves all problems with file interaction in the script file, except correctly passing the non-english characters to the perl script.

Maybe some string change before calling the mobi2mobi script would solve the problem.

File rename is indeed a (partial) solution. The major problem remains: mobi2mobi is supposed to write title and author metadata. Which will be incorrect since the non-english characters are not played right.

[DaleDe]

Good that you have a partial solution. I am not sure which Perl was used to compile this program. It may be that it is not unicode compliant. Seach unicode Perl to see a list of ideas. Perhaps there is a solution I am not aware of.

There is also a wiki page on Mobiperl that has pointers to download sites and other data. You may need to build your own version if you can solve the Perl issue.

Dale

[eschwartz]

Originally Posted by hfpop

Calibre is 200 MB. Java itselfis 200 MB. Mobi2mobi compiled as exe is 2 MB.

Now that we have seen this, could you please answer the question or admit you do not know the answer?

Thank you.

Being as I happen to use calibre extensively, for a variety of reasons, I have never used mobi2mobi and thus cannot offer help in that regard. But perhaps the issue is simply the lack of proper unicode support in CMD... which is a slightly difficult thing to work around. Which I guess would mean it would work properly on linux/osx, and perhaps Cygwin as well.

I can however offer solutions for using calibre to do rather a lot.

... As DaleDe said, there might not really be a solution.

...

There is a Windows GUI version of mobi2mobi, which *might* circumvent issues arising from CMD.

[j.p.s]

After considering a number of options, I've decided to use this package to learn more about the mobi format. As part of preparation, I've imported the extracted tar files into a git repository and uploaded that to github. I did the import with a script that I wrote for that purpose which is attached here.

The repository is at https://github.com/jps-e/mobi-perl.git

On creation of the bare repo at github, I was surprised to learn that the default primary branch is now main. I wend with the flow and renamed the branch on my local repo before pushing it to github. That seemed to work out OK. I also named the repo mobi-perl instead of mobiperl to leave that name available in case something went horribly wrong or tompe wants to make his own and I want to clone or fork it. topme hasn't posted since 2016 or logged in since 2017.

(The script took 0.8 seconds to import the 22 tar files.)

[JSWolf]

Originally Posted by j.p.s

After considering a number of options, I've decided to use this package to learn more about the mobi format. As part of preparation, I've imported the extracted tar files into a git repository and uploaded that to github. I did the import with a script that I wrote for that purpose which is attached here.

The repository is at https://github.com/jps-e/mobi-perl.git

On creation of the bare repo at github, I was surprised to learn that the default primary branch is now main. I wend with the flow and renamed the branch on my local repo before pushing it to github. That seemed to work out OK. I also named the repo mobi-perl instead of mobiperl to leave that name available in case something went horribly wrong or tompe wants to make his own and I want to clone or fork it. topme hasn't posted since 2016 or logged in since 2017.

(The script took 0.8 seconds to import the 22 tar files.)

What is it that these programs do (other than Mobiheader) that Calibre with KindleUnpack cannot do? What is it you want to do that would not be better served by writing plugins for Calibre?

[j.p.s]

All my questions below are rhetorical. This thread is reserved to mobiperl tools. KindleUnpack has its own thread and Calibre has its own forum and numerous subforums.

I welcome comments regarding the details of my implementation or any errors I may have made.

Part of my motivation for this is preserving the package and its history even though KF experts consider it obsolete and no longer good for anything (even though they found it valuable as a learning tool in its time). For me, I think it is better for my learning than anything else I know about.

Originally Posted by JSWolf

What is it that these programs do (other than Mobiheader) that Calibre with KindleUnpack cannot do?

What does Calibre with KindleUnpack do that KindleUnpack can't do by itself?

I am interested in learning the details of amazon book structure, except KFX. I use and like KindleUnpack a lot, but I've looked at some of its source with a goal of controlling its verbosity and that was hopeless. That, combined with its large number of output products by default and options only exist to make more of them, make it too overwhelming for my purpose at hand. In addition, it is written in a language that I am unlikely to progress beyond baby talk.

In contrast, mobils is relatively compact and already does a good bit of what I am looking for and written in a language I am much more comfortable with.

What is it you want to do that would not be better served by writing plugins for Calibre?

I have less than 0 interest in learning how to write a Calibre plugin, much less actually doing so.

Why do you think a Calibre plugin would be remotely appropiate for what I am trying to do?

[pdurrant]

You might find the one-file mobiunpack.py interesting to look at too.

https://www.mobileread.com/forums/at...4&d=1342902594

I probably have earlier versions around somewhere if you'd like.

[Edit: mobiunpack.py 0.02 from 2009 attached]

[Wow - it got a lot bigger from Nov. 2009 to Oct. 2011!]

[JSWolf]

Originally Posted by j.p.s

Why do you think a Calibre plugin would be remotely appropiate for what I am trying to do?

Because Most non-KFX eBooks from Amazon are in KF8 (unless you have a K1, K2, or KDXG) you won't be able to download Mobi from Amazon) and these tools handle Mobi format. The KindleUnpack plugin handles KF8 (as well as Mobi) and to learn more about Amazon eBook formats, you should be learning about KF8. These Pearl tools will not help you do that.