git.oblomov.eu Git - ikiwiki/blob - doc/bugs/unicode_encoded_urls_and_recentchanges.mdwn

   1 it appears that unicode characters in the title that are unicode letters are spared the __ filename encoding but instead saved in their utf8 encoding. (correct me if i'm wrong; didn't find the code that does this.) -- see below for examples.
   2
   3 > Filenames can have any alphanumerics in them without the __ escaping.
   4 > Your locale determines whether various unicode characters are considered
   5 > alphanumeric. In other words, it just looks at the \[[:alpha:]] character
   6 > class, whatever your locale defines it to be. --[[Joey]]
   7
   8 this is not a problem per se, but (at least with git backend) the recent changes missinterpret the file name character set (it seems to read the filenames as latin1) and both display wrong titles and create broken links.
   9
  10 the problem can be shown with an auto-setup'd ikiwiki without cgi when manually creating utf8 encoded filenames and running ikiwiki with LANG=en_GB.UTF-8 .
  11
  12 > Encoding issue, I figured out a fix. [[done]] --[[Joey]]
  13
  14 >> the link text works now, but the link goes to
  15 >> `ikiwiki.cgi?page=uml%C3%A4ute&do=recentchanges_link`, which fails with
  16 >> "missing page". it seems that bestlink can't handle utf8 encoded texts. (the
  17 >> same happens, by the way, when using meta-redir to a page with high bytes in
  18 >> the name.)
  19 >>
  20 >>> The problem is that all cgi inputs have to be explicitly decoded to
  21 >>> utf-8, which I've now done for `recentchange_link`.
  22 >>>> thanks a lot, i think that closed the bug.
  23 >>>
  24 >>> I cannot, however, reproduce a problem with meta redir. Here it
  25 >>> generated the following html, which redirected the browser ok:
  26 >>>     <meta http-equiv="refresh" content="0; URL=./../â/" />
  27 >>>> sorry, my fault -- it was the blank which needed to be replaced by an
  28 >>>> underscore, not the high byte character
  29 >>
  30 >> update: i've had a look at the git options; you could run git with '-z' (NUL
  31 >> termination) in the `git_commit_info` function; this would require some
  32 >> changes in `parse_diff_tree`, but otherwise completely eliminate the
  33 >> problems with git escaping.
  34 >>
  35 >>> If you would like to develop a patch to that effect, I'd be glad to
  36 >>> drop the current nasty code.
  37 >>>> i'll have a look, but i'm afraid that's above my current perl skills.
  38 >>>> --[[chrysn]]