summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authordkf <donal.k.fellows@manchester.ac.uk>2003-06-24 21:26:02 (GMT)
committerdkf <donal.k.fellows@manchester.ac.uk>2003-06-24 21:26:02 (GMT)
commit7241bfce6c54be2e146d6c63dfa67d7113688c72 (patch)
treea0e82082a8f8e6a7d1cff05f27996c4d80c47f02
parentb20771db513c20f371c108101f155a4524fd3e32 (diff)
downloadtcl-7241bfce6c54be2e146d6c63dfa67d7113688c72.zip
tcl-7241bfce6c54be2e146d6c63dfa67d7113688c72.tar.gz
tcl-7241bfce6c54be2e146d6c63dfa67d7113688c72.tar.bz2
Documented that [source] always used the system encoding.
-rw-r--r--ChangeLog5
-rw-r--r--doc/encoding.n20
2 files changed, 17 insertions, 8 deletions
diff --git a/ChangeLog b/ChangeLog
index 3ff8da1..bd4b240 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,10 @@
2003-06-24 Donal K. Fellows <fellowsd@cs.man.ac.uk>
+ * doc/encoding.n: Corrected the docs to say that [source] uses the
+ system encoding, which it always did anyway (since 8.1) [Bug 742100]
+
+2003-06-24 Donal K. Fellows <fellowsd@cs.man.ac.uk>
+
* generic/tclHash.c (Tcl_HashStats): Prevented occurrence of
division-by-zero problems. [Bug 759749]
diff --git a/doc/encoding.n b/doc/encoding.n
index 5fad056..fcbb67f 100644
--- a/doc/encoding.n
+++ b/doc/encoding.n
@@ -4,7 +4,7 @@
'\" See the file "license.terms" for information on usage and redistribution
'\" of this file, and for a DISCLAIMER OF ALL WARRANTIES.
'\"
-'\" RCS: @(#) $Id: encoding.n,v 1.3 2000/09/07 14:27:47 poenitz Exp $
+'\" RCS: @(#) $Id: encoding.n,v 1.4 2003/06/24 21:26:02 dkf Exp $
'\"
.so man.macros
.TH encoding n "8.1" Tcl "Tcl Built-In Commands"
@@ -59,13 +59,17 @@ characters as singe bytes and Japanese characters as two bytes. This
makes it easy to embed literal strings that correspond to non-ASCII
characters by simply typing the strings in place in the script.
However, because the \fBsource\fR command always reads files using the
-ISO8859-1 encoding, Tcl will treat each byte in the file as a separate
-character that maps to the 00 page in Unicode. The
-resulting Tcl strings will not contain the expected Japanese
-characters. Instead, they will contain a sequence of Latin-1
-characters that correspond to the bytes of the original string. The
-\fBencoding\fR command can be used to convert this string to the
-expected Japanese Unicode characters. For example,
+current system encoding, Tcl will only source such files correctly
+when the encoding used to write the file is the same. This tends not
+to be true in an internationalized setting. For example, if such a
+file was sourced in North America (where the ISO8859-1 is normally
+used), each byte in the file would be treated as a separate character
+that maps to the 00 page in Unicode. The resulting Tcl strings will
+not contain the expected Japanese characters. Instead, they will
+contain a sequence of Latin-1 characters that correspond to the bytes
+of the original string. The \fBencoding\fR command can be used to
+convert this string to the expected Japanese Unicode characters. For
+example,
.CS
set s [encoding convertfrom euc-jp "\\xA4\\xCF"]
.CE