Hi Michael!
I admit, I might not get the problem here, fully. Maybe it is an unwanted interaction between file I/O (the way xowiki::write_file works, defaulting to binary with requiring the caller to handle the input?) and ns_return which sniffs for the internal representation of a Tcl_Obj.
But, for me, your example runs just fine when treating the Tcl_Obj (the value of v) properly, as Tcl intends:
set v "\u2600"; # ☀
set v [encoding convertto utf-8 $v]
::xowiki::write_file /tmp/sun $v
set v [encoding convertfrom utf-8 $v]
ns_return 200 text/plain $v
Maybe we can clarify first what is surprising to you?
* ::xowiki::write_file should properly deal with the re-coding (stringrep -> bytearray)? This can become hairy when the provenance of the data is not clear. Better leave it with the caller, and document it?
* I am a little distant to NaviServer internals right now, so I am not an authority here, but for my taste, ns_return (w/ and w/o -binary) is maybe too bold to sniff on the byterarray nature (mainly, because it makes a huge difference whether it is a said pure bytearray without stringrep or a bytearray with stringrep).
HTH,
Stefan
