Returns a list containing the names of all of the encodings that are currently available.
If Tk is loaded, the encoding "X11ControlChars" may be included in the list. This is not a real encoding but a kludge used to arrange for a character that has no representation in any available font to be converted to a \xnn or \unnnn string and displayed in an ISO8859-1 font. For example:
puts [encoding convertto X11ControlChars "a"]
produces "\x61". WJP 2007-05-21.
"X11ControlChars" is not a real encoding in the sense that it has no existence out in the world. You won't find any standard by that name, any font with that encoding, or any piece of text in this encoding. And therefore, it won't do a user any good to choose it in an attempt to make sense of a piece of text. So it isn't the same sort of thing as iso8859-1 or Big5. I don't deny that it has a reality of a sort, but it is something purely internal to the implementation of Tk. And being "a function used in implementing the rendering of text in Tk" does not make a function a character encoding. What it actually is is a function that arranges for an escape sequence to represent characters for which no glyph is available. WJP
MG is using Tcl/Tk 8.4.9 on Win XP, and does not have that encoding listed/available, so the above is either not completely true (it's not always available if you're using Tk), or only applies to a higher version of Tk. But I would assume that it's platform dependant...
WJP On XP, if you try to use a character for which none of your fonts has a glyph, what happens?
DKF On all windows systems (well, as far back as I remember right now) you get a nondescript box.
fhou - 2011-05-02 10:02:19
Is there any reason why the names are so different from the IANA registered names? Will -charset "[encoding system]" work in a MIME header? I answer myself: yes, if you use the mime package. It has conversion tables.
DKF: Unfortunate accident of history. This was bungled in Tcl 8.1 and nobody's fixed things since then. Sorry.