3 ms·
To state the problem explicitly, internal storage format of strings doesn't mean you can handle all data streams seamlessly. Internal consistency is fine, but u
by fuzzix 13y ago
To state the problem explicitly, internal storage format of strings doesn't mean you can handle all data streams seamlessly. Internal consistency is fine, but ultimately your program will have I/O.
If I open an ISO-8859-15 or UCS-2 file in a Tcl program, how is this handled? Does it seamlessly detect encoding and translate to UTF-8 or is there more to this issue than what's stated in the article? Also, are the strings stored in a canonicalised form? If not, how simple is it to perform normalisation?
I brought up Perl because it's my experience of a language with excellent encoding support and helps make the point that the issue is probably more complex than just how strings are stored and manipulated internally.
- deleted 13y ago[deleted]
- mst 13y agoThis article is from 2006. Perl's unicode support is excellent now. In 2006 5.10 wasn't out yet, and anything before 5.8.5 had all sorts of odd unicode bugs. Or: Tcl got there significantly before we did.
- fuzzix 13y agoThat is a fair point, but I'm not trying argue that Perl is somehow better. I am just using it as a reference point. I'm more suggesting the article may be overstating the ease-of-use / capabilities of Tcl. To be clear, I'm not arguing against using Tcl in favour of Perl or anything else. It's just that my experience with a language with great encoding support doesn't jive with what's claimed here.
- na85 13y agoWell I think that particular clause was written for C-style language users where the unicode support is definitely subpar.