Hello again, mindblaster.  Thank you for the follow up.

First of all, there was a bug in BookMacster – in my testing, it incorrectly exported 1 out of 8 non-ASCII characters.  7 out of 8 is not good enough for a computer    We do have a version which works like a charm, correctly exporting 8 out of 8 and, I think, all non-ASCII characters now.  But that is BookMacster version 2.9.19 which we have not published yet.  So if it it (BookMacster 2.9.15) works like a charm now, it must be that you somehow removed the non-working non-ASCII characters from your bookmark names.

Indeed, the problem we found was that BookMacster 2.9.18 and earlier would attempt to encode all non-ASCII characters in names, and those in the higher Unicode planes were not being encoded correctly.  In our fixed version, BookMacster 2.9.19 encodes only the five HTML control characters in names, as Safari and Firefox do when you Export Bookmarks to HTML.  So now, all characters get exported correctly.

So, I'm happy you found this bug, and yes we did fix it, but you don't have the fix yet.

Regarding your workflow: Importing and exporting between Chrome and BookMacster via an intermediate HTML file as you described, although useful for one-time organizational purposes, is indeed not the way that BookMacster is usually used.  In the submenu File > Export to only that Choose File (Advanced) menu item which you are using is tucked way down at the bottom, below the browser names Chrome, Firefox, Safari, etc.  These browser-name menu items export to the browsers directly, no HTML file involved, which is usually what you want to do.  By default, it replaces the bookmarks in the browser with those in BookMacster, all in one step.  It does not put them in a special Imported folder, leaving you to reorganize them manually.  If the latter is what you want, then OK go the HTML file route.  But the direct export (and, similarly, import) is what most users want most of the time.

Hello, adrian.

Thank you for contacting us.  I just tested this with a sample of 8 of non-ASCII characters and found that 7 of them, éñ↓↑ⓧ⌘♭, were exported correctly but one of them () was not.  I entered a requirement to try and fix this for the next version.  If you can send us or post a list of non-ASCII characters which are not exported correctly, we'll be sure to check those.