Enex import misses out file extentions

Thanks to @CalebJohn I’ve got my python script (sorta) working. Joplin now imports the html with resources encoded as base64 successfully; however, the resources (images for the moment) are given a hash id and stored in .config/joplin-desktop/resources without their appropriate file extensions (.jpg, .png), so the markdown looks like this: [](:/8107653c2d4751638bade02215a41160) and Joplin renders it with just a little “J” icon. Clicking on the icon gives the right resource, but it’s displayed in an external image viewer.

My .enex file includes in the CData section <en-media> tags with both hash and type attributes, and in the <note> xml I’ve got <resource> elements that include a <mime> element as well as <resource-attributes><file-name> elements, and that file-name includes the .png file extension. So, what am I missing?

Also, there are things about the sqlite interaction that I don’t understand yet. While fooling around with these test imports I notice that if I delete a note that I just imported, the resources remain in the resources directory. And if I delete those resources manually, any subsequent import of the same .enex file does not restore the resource. Is there a way to reconcile the database entry with the contents of the resources directory?

As you can tell, I’m still fumbling around here. Any hints, guidance, or observations would be welcome.

Still fumbling around with this. Here’s some behavior I can’t understand. Any insight welcome.

Thanks to @CalebJohn’s advice, I’ve now got the debugger operating, and in /tmp/.mount_JoplinGl1Wwr/resources/app/lib/import-enex-md-gen.js I sprinkled a couple of console.info statements.

With my sample .enex file generated by EverNote, my Joplin import succeeds, and the console reports both the resource.mime line AND my string MIME SATISFIED. But with the sample .enex file generated by my script, even though the import succeeds, the image link is rendered in the MD without the preceeding ‘!’. And the console reports only the resource.mime line even though the CData section in former has:

<en-media hash="22a0b61cc3384835c649c5fd822fb276" type="image/png" />

and the latter has:

<en-media hash="0de80e9429251c00f204a38af6eca5c6" type="image/png"></en-media>

In both cases the type attribute has the same string. And import-enex-md-gen.js acknowledges both as resource.mime.

My modified addResourceTag function in import-enex-md-gen.js follows below:

function addResourceTag(lines, resource, alt = "") {
	// Note: refactor to use Resource.markdownTag
	console.info(resource.mime);
	let tagAlt = alt == "" ? resource.alt : alt;
	if (!tagAlt) tagAlt = '';
	tagAlt = tagAttributeToMdText(tagAlt);
	if (isImageMimeType(resource.mime)) {
		console.info("MIME SATISFIED");
		lines.push("![");
		lines.push(tagAlt);
		lines.push("](:/" + resource.id + ")");
	} else {
		lines.push("[");
		lines.push(tagAlt);
		lines.push("](:/" + resource.id + ")");
	}

	return lines;
}

Any thoughts?

OK. That took entirely too much trial and error, and the error, once found, was embarrassing. Sorry for the noise, but perhaps we can chalk this up as a cautionary tale:

The problem was that the isImageMimeType test (at import-enex-md-gen.js l.308) was failing because my script was calling BeautifulSoup’s prettify() routine so that I could better read my enex xml result. This meant that the resource’s mimetype string had newline characters in it. (Doh! Arrrgh!)

1 Like

Glad to see you got it working! Thanks for documenting the troubles and solution!

1 Like