trac-admin wiki export fails on non-ASCII chars

[erickheit+trac@…]

Running trac-admin to export a single page from the wiki fails with the following error when the page contains non-ASCII:

Command failed: 'ascii' codec can't encode characters in position 1321-1324: ordinal not in range(128)

Changing LC_TYPE does not affect this output (it is usually set to en_US.ISO_8859-1, and the chars in question are indeed in the Latin-1 set). I can see that the text is stored as UTF-8 in the database, and that is indeed what I expected on output.

trac-admin wiki dump does what I expect (produces text files in UTF-8 encoding) but is too unwieldy for my purposes (I have a subversion post-commit hook that checks code for the use of global config vars and edits a wiki entry to remind developers to document them)

trac-admin tells me its version: Welcome to trac-admin 0.10.3

uname tells me FreeBSD 6.1-RELEASE #0

sqlite3 -version tells me 3.3.8

[Christian Boos]

What was the command-line used exactly?

Was it:

trac-admin $tracenv wiki export pagename

or:

trac-admin $tracenv wiki export pagename filename

Which one failed (and what was the pagename)?

(btw, I suspect we have to use unicode_quote in wiki dump)

[anonymous]

Hmm, I feel foolish I didn't try that. If given a filename, it appears to do the right thing (emit the page in UTF8).

trac-admin $tracenv wiki import pagename filename also does what I expect; it accepts files coded in UTF8 and stores and displays them correctly. Without a filename, it just lists the help page for trac-admin wiki

I first discovered this in a page called 'PPlus_Glossary'; but since you don't have acces to that page, I can't image why it would be helpful. I can reproduce the problem by entering any non-ascii chars; for example adding 'fóó bær' to any wiki pages seems to trigger the error.

[Christian Boos]

I asked for the pagename to check if by any chance the pagename itself contained exotic characters ;-) But that would have triggered a different error message. So I think the problem is simply with the print statement we're using when no filename is given.

[osimons]

I can't see any problems with this using current 0.11b1+.

It does not seem like an error that is ever likely to get a special fix for 0.10.x, it is quite trivial, and it has usable workarounds by using a temporary file. I'm +1 on closing as 'worksforme' with recommended solution to upgrade.

[Christian Boos]

There have been lots of unicode fixes in the trac wiki dump/load commands, so this is most likely a duplicate of e.g. #6180.

[Christian Boos]

Hum, maybe I was too quick to close this one as duplicate of #6180, as that ticket deals with problems with the encoded page names, not with encoded comments.

Anyway, I was never able to reproduce the problem here either.