Forum OpenACS Development: Re: Ain’t No ☀shine

Collapse
4: Re: Ain’t No ☀shine (response to 3)
Posted by Michael Aram on
Just to be clear: The problem does not show up, without the three-byte UTF-8 sun. So the following does work:

set v "SUN"
::xowiki::write_file /tmp/sun $v
ns_return 200 text/plain $v

Moreover, ::xowiki::write_file per se is not the culprit. It seems to be the binary translation of fconfigure. The following works as expected,

set v "☀"
set F [::open /tmp/sun w]
::fconfigure $F -translation auto
::puts -nonewline $F $v
::close $F
ns_return 200 text/plain $v

while the following does not:

set v "☀"
set F [::open /tmp/sun w]
::fconfigure $F -translation binary
::puts -nonewline $F $v
::close $F
ns_return 200 text/plain $v

Collapse
6: Re: Ain’t No ☀shine (response to 4)
Posted by Stefan Sobernig on
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