> Oh, no, I understand how UTF8 works. If we're already checking that
> log messages are valid UTF8, then that just means my condition is
> already met. I'm not crazy, I'm just behind the times :-).
> The problem is that we're not doing that check before we send a log
> message from server to client.
> We should, and if the string is not
> UTF8... then what?
We already fail if the message is not valid UTF-8:
$ LANG=en_GB.UTF-8 svn commit -m `printf "\xe5"`
svn: Commit failed (details follow):
svn: Valid UTF-8 data
followed by invalid UTF-8 sequence
> Escape any funny chars? I thought we had code for
> doing this, too, already written for some other purpose...
> /me rummages around
> Aha, I'm thinking of svn_utf_cstring_from_utf8_fuzzy(), which is not
> quite the same thing. That function converts a UTF8 string with
> multibyte characters into another UTF8 string with only single-byte
> characters (that is, an ASCII string, with the old multibyte chars
> represented using special 7-bit escape codes).
> Whereas the function we're talking about would convert a mixed
> UTF8/non-UTF8 string to a purely UTF8-string, converting the non-UTF8
> characters to (presumably) some sort of escape codes, probably the
> same kind as svn_utf_cstring_from_utf8_fuzzy() uses.
> *Now* am I sounding crazy? :-)
One of us is confused, or perhaps is just terminology.
There is no "mixed UTF8/non-UTF8 string" and there are no "non-UTF8"
characters that need to be "converted". There may be ASCII control
codes in the log message, and if these are not valid XML then they
need to be rejected or escaped, but the only place that UTF-8 comes in
is that ASCII control codes are encoded unchanged in UTF-8.
It looks like we have the same problem with paths in the entries file:
$ svn mkdir wc/`printf "\x18"`
$ svn st wc
svn: XML parser failed in 'wc'
svn: Malformed XML: not well-formed (invalid token) at line 13
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Tue Nov 30 00:27:38 2004