If you say this works fine for English, I guess I'll take your word for that -- though I don't really get this part of the "preinsert" sub:

    return undef if ($fields{$fieldref} !~ /$tags{untaint}/);
    $untaint = $1;
    print STDERR "recieved $1\n";
[download]

Just what does "$1" contain at this point? I don't see any parens in the regex, so I would assume that it isn't assigning anything to $1.

Anyway, it's not clear that the resulting garbage has anything to do with unicode. You say the input is "regular win-1255 encoding", but in what form? Parameters containing bytes with the 8th-bit set? Parameters containing things like "õ" (cp1255 for "final tsadi", visible to latin1 users as õ, "o with tilde" -- I'm sure it wouldn't be anything like "ץ" (unicode for final tsadi: ץ). For that matter, is there any chance that you are actually getting a "\xFE" with each Hebrew character or each Hebrew word token? (that's the CP1255 code for "right-to-left mark")

When you say "There's a table XML descriptor, and it's just fine," what does that mean? What evidence makes you sure that Hebrew characters come out of this "just fine"?

What version of Perl is being used here? (5.6 or 5.8?) In what OS environment? (These things do make a difference in terms of behavior relating to unicode.)

BTW, I fully agree with the earlier reply about quoting. You should be using a parameterized sql statement (i.e. with "?" where the string values should go), a "prepare" step, and an "execute" with the values provided to fill in the "?" placeholders.

update: changed the "rendering" of Hebrew characters; also wanted to add that even in 5.8, the DBI module may be somewhat "external to" (not fully tied in with) Perl-internal unicode character storage; e.g. if you have a database containing utf8 character data, and fetch that data into perl5.8 using DBI, perl won't necessarily recognize it as utf8, unless/until you "decode" the string as utf8 data.