Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

nhentai saves images as the wrong file extension #63

Closed
RitoPls opened this issue Jan 7, 2018 · 3 comments
Closed

nhentai saves images as the wrong file extension #63

RitoPls opened this issue Jan 7, 2018 · 3 comments

Comments

@RitoPls
Copy link

RitoPls commented Jan 7, 2018

It seems to occur with most or all of the comics I downloaded from nhentai. If you need an example for a test case you could use (NSFW) https://nhentai.net/g/219213/

Win8
Python 3.5
gallery-dl 1.1.1

I open up one of the PNG files it downloaded with infranview and it gives me a warning telling me to rename the file from *.png to *.jpg

It's still viewable as *.png , but the warnings gets annoying in infranview.

@mikf
Copy link
Owner

mikf commented Jan 7, 2018

nhentai advertises these files as *.png in every way possible:

  • Image URLs end in *.png: https://i.nhentai.net/galleries/1164085/4.png
  • The Content-Type header says it's a PNG file: Content-Type: image/png
  • nhentai's gallery metadata says it's a PNG file: …{"t":"p","w":1280,"h":1854}… (meaning type: png)
  • The files inside the download torrent also have *.png as filename extension

It is obviously a `.jpg file, but gallery-dl is only doing what it is being told by nhentai.

A possible solution would be to look at the first few bytes when downloading and see if the file header matches the suggested filename extension, but implementing this properly might take a bit.

@Bfgeshka
Copy link

Bfgeshka commented Jan 7, 2018

You probably do not have to read bytes and compare them manually, doesn't python have proper mime support?

@mikf
Copy link
Owner

mikf commented Jan 7, 2018

There are Python wrappers for libmagic, but they are not part of the standard library. There you only have the mimetypes module which maps MIME-types to file extensions and vice versa.

Manually supporting the 3 or 4 most common image types shouldn't be a problem, it's more about how to properly fit this into the current download implementation.

@mikf mikf closed this as completed in 6174a5c Jan 17, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants