Ok, for some reason you refuse to test it with an iso-8859-8 file, I have to accept that ...
I was just thinking that aolserver *might* have a problem with windows specific encodings, and that you *might* narrow the cause of your problem by testing it with iso-8859-8. Looking into the lib/tcl8.3/encoding/ directory of aolserver I see that the windows encodings are there, so *propably* they work the same ...
Anyway, maybe you want to check if aolserver has correctly transformed the characters internally to unicode from the file by trying an adp like this:
set s "string with weird characters"
length:<%=[string length $s] %>
bytelength: <%=[string bytelength $s]%>
It should produce a higher value for bytelength. At least it does for me when I insert some german umlauts in the string.