summaryrefslogtreecommitdiff
path: root/doc/bugs/unicode_encoded_urls_and_recentchanges.mdwn
AgeCommit message (Collapse)Author
2008-09-26decode utf-8 in recentchanges_link parameterJoey Hess
2008-09-26update: possible solutionchrysn
2008-09-26some problem remainschrysn
2008-09-25git: Fix handling of utf-8 filenames in recentchanges.Joey Hess
Seems that the problem is that once the \nnn coming from git is converted to a single character, decode_utf8 decides that this is a standalone character, and not part of a multibyte utf-8 sequence, and so does nothing. I tried playing with the utf-8 flag, but that didn't work. Instead, use decode("utf8"), which doesn't have the same qualms, and successfully decodes the octets into a utf-8 character. Rant: Think for a minute about fact that any and every program that parses git-log, or git-show, etc output to figure out what files were in a commit needs to contain this snippet of code, to convert from git-log's wacky output to a regular character set: if ($file =~ m/^"(.*)"$/) { ($file=$1) =~ s/\\([0-7]{1,3})/chr(oct($1))/eg; } (And it's only that "simple" if you don't care about filenames with embedded \n or \t or other control characters.) Does that strike anyone else as putting the parsing and conversion in the wrong place (ie, in gitweb, ikiwiki, etc, etc)? Doesn't anyone who actually uses git with utf-8 filenames get a bit pissed off at seeing \xxx\xxx instead of the utf-8 in git-commit and other output?
2008-09-23bug report on funny characters in the namechrysn