Tcl - "string map" Probleme in tcl 8.4 mit Umlauten?

Author

"string map" Probleme in tcl 8.4 mit Umlauten?

Andreas

2007-02-23, 8:12 am

Seit Jahren setze ich TCL als integrierte Skript-Sprache in einer
Softwarel=F6sung ein (Microsoft Windows, MFC-Anwendung). Vor kurzem bin
ich von TCL 8.3.5 auf TCL 8.4.14 umgestiegen. Mit dieser Version
bekommen wir aber Probleme, da sich das Verhalten des Kommandos
"string map" ge=E4ndert hat. Beispiel:

set a "=E4=F6=FC"
set x [string map {. ,} $a]

x enth=E4lt dann "=C3=A4=C3=B6=C3=BC". Der String wird dabei offensichtlich=
in
Unicode umgewandelt, wo TCL 8.3 den String noch unver=E4ndert lie=DF. In
der Shell (tclsh84.exe) wird die Umsetzung aber noch genauso wie unter
TCL 8.3 vorgenommen, also unver=E4ndert gelassen.

Die Initialisierung in der MFC-Anwendung ist vergleichbar zu der der
TCL-Shell:

Tcl_SetDefaultEncodingDir( ... );
Tcl_FindExecutable( ... );

interp =3D Tcl_CreateInterp();

Auch das Einf=FCgen der Zeile

setlocale(LC_ALL, "C");

wie sie von der main() Funktion der TCL-Shell verwendet wird, l=F6st das
Problem nicht.

Es besteht zwar die M=F6glichkeit, die TCL-Skripte wie folgt anzupassen:

set a "=E4=F6=FC"
set x [encoding convertfrom identity [string map {. ,} $a]]

..=2E. aber erstens m=FCsste ich dann sehr sehr viele Skripte anpassen und
zweitens habe ich Sorge, dass auch andere String-Funktionen unbemerkt
solche Unicode-Umwandlungen vornehmen. Es w=E4re mir also wichtig, den
Interpreter dazu zu bringen, sich genauso zu verhalten, wie die TCL-
Shell.

suchenwi

2007-02-23, 8:12 am

Innerhalb von Tcl sind seit 8.1 im Prinzip alle Strings in Unicode
(utf-8 oder ucs-16). Bein Ein- und Ausgabe wird von bzw. nach
[encoding system] gewandelt.

Eigener C-Code, der mit Tcl Daten kommuniziert, aber kein utf-8 haben
will, sollte die Funktionen

char* Tcl_ExternalToUtfDString(encoding, src, srcLen, dstPtr)
int Tcl_ExternalToUtf(interp, encoding, src, srcLen, flags, statePtr,
dst, dstLen, srcReadPtr, dstWrotePtr,dstCharsPtr)
char * Tcl_UtfToExternalDString(encoding, src, srcLen, dstPtr)
int Tcl_UtfToExternal(interp, encoding, src, srcLen, flags, statePtr,
dst, dstLen, srcReadPtr, dstWrotePtr, dstCharsPtr)

ben=FCtzen.
Der Hack mit [encoding convertfrom identity ...] geht zwar als
Notl=F6sung, sollte aber nur mit Vorsicht ben=FCtzt werden.

MartinLemburg@UGS

2007-02-23, 8:12 am

Hallo Andreas,

wie Du, so nutze ich tcl auch schon lange, schon seit tcl 7.6. Die
=C4nderungen im string Umfeld, die tcl Unicode tauglich machten habe ich
auf Skriptebene nie bemerkt. Lediglich an tcl-C(++) Schnittstellen
mu=DFte ich etwas =E4ndern und f=FCr diese explicite Konvertierung in das
System Encoding sorgen.

Dein Beispiel kann ich leider auf Skriptebene nicht nachvollziehen -
was aber auch meiner Erfahrung entspricht:

% set a "=E4=F6=FC=C4=D6=DC"
=E4=F6=FC=C4=D6=DC
% set b [string map {. ,} $a]
=E4=F6=FC=C4=D6=DC
% info patchlevel
8.4.13
% parray tcl_platform
tcl_platform(byteOrder) =3D littleEndian
tcl_platform(machine) =3D intel
tcl_platform(os) =3D Windows NT
tcl_platform(osVersion) =3D 5.1
tcl_platform(platform) =3D windows
tcl_platform(threaded) =3D 1
tcl_platform(user) =3D lemburg
tcl_platform(wordSize) =3D 4

Es w=E4re ja auch noch sch=F6ner, wenn wirklich die Einf=FChrung von Unicode
in tcl alte Skripte nicht mehr laufen lassen w=FCrde.

-------------------------- snip -

Stop, Du schriebst von tcl 8.4.14?

Tja - ich hab's nochmal mit tclkitsh 8.5a4 ausprobiert:

% set a "=E4=F6=FC=C4=D6=DC"
=E4=F6=FC=C4=D6=DC
% set b [string map {. ,} $a]
=B4=A5=E4=B4=A5=F6=B4=A5=FC=B4=A5=C4=B4=
A5=D6=B4=A5=DC

Irgendwie mu=DF ich wohl obiges zur=FCcknehmen!

Und ich mu=DF mir wohl Sorgen um unsere Anwendung machen, die
Benutzereingaben mit Umlauten zul=E4=DFt und nun Schrott herausbekommt?

So nun noch ein Test mit tclkit 8.5a4:

% set a "=E4=F6=FC=C4=D6=DC"
=E4=F6=FC=C4=D6=DC
% set b [string map {. ,} $a]
=E4=F6=FC=C4=D6=DC

Na wunderbar - in der "Wish" ist das also kein Problem?

Dann liegt es also wohl an der F=E4higkeit in der puren Shell die
Unicodes darzustellen, was das text widget der tclkit Konsole ohne
Probleme kann?

Egal - da ist noch Kl=E4rungsbedarf!

Beste Gr=FC=DFe,

Martin Lemburg
UGS - a Siemens Company - Transforming the Process of Innovation

On Feb 23, 12:10 pm, "Andreas" <andreas.prie...@intalus.de> wrote:
> Seit Jahren setze ich TCL als integrierte Skript-Sprache in einer
> Softwarel=F6sung ein (Microsoft Windows, MFC-Anwendung). Vor kurzem bin
> ich von TCL 8.3.5 auf TCL 8.4.14 umgestiegen. Mit dieser Version
> bekommen wir aber Probleme, da sich das Verhalten des Kommandos
> "string map" ge=E4ndert hat. Beispiel:
>
> set a "=E4=F6=FC"
> set x [string map {. ,} $a]
>
> x enth=E4lt dann "=C3=A4=C3=B6=C3=BC". Der String wird dabei offensichtli=
ch in
> Unicode umgewandelt, wo TCL 8.3 den String noch unver=E4ndert lie=DF. In
> der Shell (tclsh84.exe) wird die Umsetzung aber noch genauso wie unter
> TCL 8.3 vorgenommen, also unver=E4ndert gelassen.
>
> Die Initialisierung in der MFC-Anwendung ist vergleichbar zu der der
> TCL-Shell:
>
> Tcl_SetDefaultEncodingDir( ... );
> Tcl_FindExecutable( ... );
>
> interp =3D Tcl_CreateInterp();
>
> Auch das Einf=FCgen der Zeile
>
> setlocale(LC_ALL, "C");
>
> wie sie von der main() Funktion der TCL-Shell verwendet wird, l=F6st das
> Problem nicht.
>
> Es besteht zwar die M=F6glichkeit, die TCL-Skripte wie folgt anzupassen:
>
> set a "=E4=F6=FC"
> set x [encoding convertfrom identity [string map {. ,} $a]]
>
> ... aber erstens m=FCsste ich dann sehr sehr viele Skripte anpassen und
> zweitens habe ich Sorge, dass auch andere String-Funktionen unbemerkt
> solche Unicode-Umwandlungen vornehmen. Es w=E4re mir also wichtig, den
> Interpreter dazu zu bringen, sich genauso zu verhalten, wie die TCL-
> Shell.

MartinLemburg@UGS

2007-02-23, 8:12 am

Hello Andreas,

like you, I also use tcl since a long time, since tcl 7.6. All the
changes about unicode string handling never caused troubles on script
level. Only on the tcl-C(++) APIs I needed to convert to the system
encoding explicitely!

So I'm not able to follow your example - which don't make me wonder,
because that's matching my experiences:

% set a "=E4=F6=FC=C4=D6=DC"
=E4=F6=FC=C4=D6=DC
% set b [string map {. ,} $a]
=E4=F6=FC=C4=D6=DC
% info patchlevel
8.4.13
% parray tcl_platform
tcl_platform(byteOrder) =3D littleEndian
tcl_platform(machine) =3D intel
tcl_platform(os) =3D Windows NT
tcl_platform(osVersion) =3D 5.1
tcl_platform(platform) =3D windows
tcl_platform(threaded) =3D 1
tcl_platform(user) =3D lemburg
tcl_platform(wordSize) =3D 4

If your problem would have reoccurred in my tcl shell, I really would
have wondered why, even because all old scripts would have to change.

-------------------------- snip -

Stop, you wrote about using tcl 8.4.14?

So - I tried again with tclkitsh 8.5a4:

% set a "=E4=F6=FC=C4=D6=DC"
=E4=F6=FC=C4=D6=DC
% set b [string map {. ,} $a]
=B4=A5=E4=B4=A5=F6=B4=A5=FC=B4=A5=C4=B4=
A5=D6=B4=A5=DC

Oh - I have to excuse, there seem to be a problem!

And I feel like detecting upcoming sorrows about our application,
which processes a lot of user inputs (with Umlaute), which could be
scrambled now?!

So - again a test, but now in the tclkit 8.5a4:

% set a "=E4=F6=FC=C4=D6=DC"
=E4=F6=FC=C4=D6=DC
% set b [string map {. ,} $a]
=E4=F6=FC=C4=D6=DC

Wonderfull - there seem to be no problem in the "wish"?

So it seemed to be about the ability to display those Unicode
characters? The tcl shell is not able, but the text widget of the
tclkit console is?

So there is still something to solve?!

Best Regards,

Martin Lemburg
UGS - a Siemens Company - Transforming the Process of Innovation

On Feb 23, 12:10 pm, "Andreas" <andreas.prie...@intalus.de> wrote:
> Seit Jahren setze ich TCL als integrierte Skript-Sprache in einer
> Softwarel=F6sung ein (Microsoft Windows, MFC-Anwendung). Vor kurzem bin
> ich von TCL 8.3.5 auf TCL 8.4.14 umgestiegen. Mit dieser Version
> bekommen wir aber Probleme, da sich das Verhalten des Kommandos
> "string map" ge=E4ndert hat. Beispiel:
>
> set a "=E4=F6=FC"
> set x [string map {. ,} $a]
>
> x enth=E4lt dann "=C3=A4=C3=B6=C3=BC". Der String wird dabei offensichtli=
ch in
> Unicode umgewandelt, wo TCL 8.3 den String noch unver=E4ndert lie=DF. In
> der Shell (tclsh84.exe) wird die Umsetzung aber noch genauso wie unter
> TCL 8.3 vorgenommen, also unver=E4ndert gelassen.
>
> Die Initialisierung in der MFC-Anwendung ist vergleichbar zu der der
> TCL-Shell:
>
> Tcl_SetDefaultEncodingDir( ... );
> Tcl_FindExecutable( ... );
>
> interp =3D Tcl_CreateInterp();
>
> Auch das Einf=FCgen der Zeile
>
> setlocale(LC_ALL, "C");
>
> wie sie von der main() Funktion der TCL-Shell verwendet wird, l=F6st das
> Problem nicht.
>
> Es besteht zwar die M=F6glichkeit, die TCL-Skripte wie folgt anzupassen:
>
> set a "=E4=F6=FC"
> set x [encoding convertfrom identity [string map {. ,} $a]]
>
> ... aber erstens m=FCsste ich dann sehr sehr viele Skripte anpassen und
> zweitens habe ich Sorge, dass auch andere String-Funktionen unbemerkt
> solche Unicode-Umwandlungen vornehmen. Es w=E4re mir also wichtig, den
> Interpreter dazu zu bringen, sich genauso zu verhalten, wie die TCL-
> Shell.

MartinLemburg@UGS

2007-02-23, 8:12 am

Hello again,

I'll continue in English, ok?

I extended the example a bit and let it run on tcl 8.4.13, on tclkitsh
8=2E5a4, on tclkit 8.5a4:

tcl shell 8.4.13:
% set a "=E4=F6=FC=C4=D6=DC"
=E4=F6=FC=C4=D6=DC
% set b [string map {. ,} $a]
=E4=F6=FC=C4=D6=DC
% string length $b
6
% format %c [scan [string index $b 0] %c]
=E4
% scan [string index $b 0] %c
228
% set fid [open f:/umlautTest.txt w];
file9cc228
% puts $fid $b;
% close $fid;
% set fid [open f:/umlautTest.txt r];
file9cc368
% set c [read $fid];
=E4=F6=FC=C4=D6=DC

% close $fid

tclkitsh 8.5a4:
% set a "=E4=F6=FC=C4=D6=DC"
=E4=F6=FC=C4=D6=DC
% set b [string map {. ,} $a]
=B4=A5=E4=B4=A5=F6=B4=A5=FC=B4=A5=C4=B4=
A5=D6=B4=A5=DC
% string length $b
6
% format %c [scan [string index $b 0] %c]
=B4=A5=E4
% scan [string index $b 0] %c
65412
% set fid [open f:/umlautTest.txt w];
filea277a8
% puts $fid $b;
% close $fid;
% set fid [open f:/umlautTest.txt r];
file9e1b08
% set c [read $fid];
??????

% close $fid

tclkit 8.5a4:
(bin) 1 % set a "=E4=F6=FC=C4=D6=DC"
=E4=F6=FC=C4=D6=DC
(bin) 2 % set b [string map {. ,} $a]
=E4=F6=FC=C4=D6=DC
(bin) 3 % string length $b
6
(bin) 4 % format %c [scan [string index $b 0] %c]
=E4
(bin) 5 % scan [string index $b 0] %c
228
(bin) 6 % set fid [open f:/umlautTest.txt w];
filee9b6b8
(bin) 7 % puts $fid $b;
(bin) 8 % close $fid;
(bin) 9 % set fid [open f:/umlautTest.txt r];
filee9b9e0
(bin) 10 % set c [read $fid];
=E4=F6=FC=C4=D6=DC

(bin) 11 % close $fid

What's going on with the tclkitsh 8.5a4?
Why the written text file contains not the data, that should have been
in there "=E4=F6=FC=C4=D6=DC"?

Best regards,

Martin Lemburg
UGS - a Siemens Company - Transforming the Process of Innovation

On Feb 23, 12:54 pm, "MartinLemburg@UGS" <martin.lemburg....@gmx.net>
wrote:[color=darkred]
> Hello Andreas,
>
> like you, I also use tcl since a long time, since tcl 7.6. All the
> changes about unicode string handling never caused troubles on script
> level. Only on the tcl-C(++) APIs I needed to convert to the system
> encoding explicitely!
>
> So I'm not able to follow your example - which don't make me wonder,
> because that's matching my experiences:
>
> % set a "=E4=F6=FC=C4=D6=DC"
> =E4=F6=FC=C4=D6=DC
> % set b [string map {. ,} $a]
> =E4=F6=FC=C4=D6=DC
> % info patchlevel
> 8.4.13
> % parray tcl_platform
> tcl_platform(byteOrder) =3D littleEndian
> tcl_platform(machine) =3D intel
> tcl_platform(os) =3D Windows NT
> tcl_platform(osVersion) =3D 5.1
> tcl_platform(platform) =3D windows
> tcl_platform(threaded) =3D 1
> tcl_platform(user) =3D lemburg
> tcl_platform(wordSize) =3D 4
>
> If your problem would have reoccurred in my tcl shell, I really would
> have wondered why, even because all old scripts would have to change.
>
> -------------------------- snip -
>
> Stop, you wrote about using tcl 8.4.14?
>
> So - I tried again with tclkitsh 8.5a4:
>
> % set a "=E4=F6=FC=C4=D6=DC"
> =E4=F6=FC=C4=D6=DC
> % set b [string map {. ,} $a]
> =B4=A5=E4=B4=A5=F6=B4=A5=FC=B4=A5=C4=B4=
A5=D6=B4=A5=DC
>
> Oh - I have to excuse, there seem to be a problem!
>
> And I feel like detecting upcoming sorrows about our application,
> which processes a lot of user inputs (with Umlaute), which could be
> scrambled now?!
>
> So - again a test, but now in the tclkit 8.5a4:
>
> % set a "=E4=F6=FC=C4=D6=DC"
> =E4=F6=FC=C4=D6=DC
> % set b [string map {. ,} $a]
> =E4=F6=FC=C4=D6=DC
>
> Wonderfull - there seem to be no problem in the "wish"?
>
> So it seemed to be about the ability to display those Unicode
> characters? The tcl shell is not able, but the text widget of the
> tclkit console is?
>
> So there is still something to solve?!
>
> Best Regards,
>
> Martin Lemburg
> UGS - a Siemens Company - Transforming the Process of Innovation
>
> On Feb 23, 12:10 pm, "Andreas" <andreas.prie...@intalus.de> wrote:
>
>
>
lich in[color=darkred]
>
>
>
>
>
>
>
>
>

suchenwi

2007-02-23, 7:14 pm

I see no problem in tclkit8.5a4 on Win XP:

(bin) 16 % set a =C4=D6=DC
=C4=D6=DC
(bin) 17 % string map {. ,} $a
=C4=D6=DC
(bin) 18 % info pa
8=2E5a4

Donal K. Fellows

2007-02-23, 7:14 pm

QW5kcmVhcyBMZWl0Z2ViIHdyb3RlOgo+IEp1c3Qg
YXMgYSBzaWRlbm90ZTogIFRoaXMgcHJvYmxl
bSBpcyAqbm90KiBzcGVjaWZpYyB0byB3aW5kb3dz
IQo+Cj4gSSBzdGFydCBhIHRlcm1pbmFsIChh
IG5vbi11dGY4IG9uZSksIGFuZCBzdGFydCB0Y2xr
aXQtOC41YTQ6Cj4gICAlIHNldCBhICLDpMO2
w7zDhMOWw5wiCj4gICDDpMO2w7zDhMOWw5wKPiAg
ICUgc2V0IGIgW3N0cmluZyBtYXAgey4gLH0g
JGFdCj4gICDDg8Kkw4PCtsODwrzDg+KAnsOD4oCT
w4PFkwo+IHNvLCBpdCBnZXRzIGVjaG9lZCB3
cm9uZ2x5LgoKTG9va3MgbGlrZSB0Y2xraXQgZG9l
c24ndCBoYXZlIHRoZSByaWdodCBlbmNvZGlu
ZyBhbmQgaXMgZmFsbGluZyBiYWNrCm9uIHRoZSAn
aWRlbnRpdHknIGVuY29kaW5nIChub3QgZ29v
ZCEpCgpEb25hbC4K

MartinLemburg@UGS

2007-02-23, 7:14 pm

In the English version of this originally German thread I just posted
the encoding of ...

... tcl shell 8.4.13
... tclkitsh 8.5a4
... tclkit 8.5a4

All those three tcl interpreters use cp1252.

I don't have a "normal" tcl 8.5 shell or wish, so I can't try with
those, but others perhabs can?

Best regards,

Martin Lemburg
UGS - a Siemens Company - Transforming the Process of Innovation

On Feb 23, 4:21 pm, "Donal K. Fellows" <donal.k.fell...@man.ac.uk>
wrote:
> Andreas Leitgeb wrote:
>
=83=C5=93[color=darkred]
>
> Looks like tclkit doesn't have the right encoding and is falling back
> on the 'identity' encoding (not good!)
>
> Donal.

Sponsored Links