It turns out that this behaviour stems from the algorithm that Dropbox uses to detect the character set encoding of uploaded text files. On the Dropbox developer forum, Dropbox confirmed that they scan only the first few hundred bytes of the file, looking for UTF-8 character sequences that are not ISO-8859-1 (ie ASCII) sequences. If it doesn't find any such character sequences, then it defaults to ISO-8859-1 encoding.
The work around is to ensure that UTF-8 encoded HTML files stored in Dropbox have a sequence of UTF-8 characters right at the top of the file. Accordingly, I've modified TiddlyWiki in the Sky to include a "utf8 beacon": http://dropbox.tiddlywiki.com/ I'd be interested if Wolfgang and FrD could try their experiments again with the new code. This still leaves the problem that storing an existing TiddlyWiki document over http from Dropbox will currently be interpreted as ISO-8859-1. The quick fix is to manually insert something like this at the start of the <head> section of the document: <meta name="utf8beacon" content="éçñøåá—" /> One possibility is that TWITS could automatically insert the beacon each time it saves a file, meaning that one could "fix" TiddlyWiki files by running them through TWITS. I'll think about it further and explore the options, Best wishes Jeremy On Wed, Oct 3, 2012 at 2:10 PM, Jeremy Ruston <[email protected]>wrote: > OK, so it seems like things are in quite a strange situation: > > - Wolfgang has a TW that views correctly on the usual Dropbox public > URI, but doesn't view correctly in TWITS > - FrD has a TW that views correctly in TWITS, but doesn't view > correctly on the Dropbox public URI > > Can I just confirm that in both cases you are using the same type of > Dropbox URI to get at the file? It seems as though there is different > behaviour between files in public folders vs. files browsed via the > website by a logged in user. Wolfgang's URI starts > https://dl.dropbox.com/u/ which I believe is a public folder URI. FrD, > can you confirm the structure of the URI that you are using? > > The underlying issue here is that Dropbox isn't always able to give > the browser the correct character encoding information for HTML files. > I think I need to do some more structured experimentation to > understand what's going on. > > Many thanks, > > Jeremy > > On Wed, Oct 3, 2012 at 1:15 PM, wolfgang <[email protected]> wrote: > >> In my french version of FF (15.0.1) : > >> Menu : Affichage => Encodage des caractères => Unicode (UTF-8) > > > > Thanks, but this seems not to help in my case. > > > > > >> OK, it's possible that you were trying it while I was still fixing it, > >> I'd be grateful if you could give it another try. Unfortunately you'll > >> need to revert to an earlier version of the file. > >> > >> Cheers > >> > > > > That is the wired thing, because I didn't save the file there isn't a > > earlier version. It's the TW in which I made first tests with TableEditor > > (unfortunately no time yet, to test it's much more powerful later > versions > > further) If you access it through the regular public link the TW renders > > fine: https://dl.dropbox.com/u/241006/sheets.html > > > > But opened through http://dropbox.tiddlywiki.com/ all special > characters, or > > plugins with any, fail. Attached a screenshot of this case. > > > > > > > > -- > Jeremy Ruston > mailto:[email protected] > -- Jeremy Ruston mailto:[email protected] -- You received this message because you are subscribed to the Google Groups "TiddlyWiki" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/tiddlywiki?hl=en.
