Re: mb_ereg_replace problem with non a-z characters

Hi, On 2005/01/19, at 23:40, McAjvar wrote:

i've tried both functions, ereg_replace and mb_ereg_replace and it still only works on windows. another friend of mine also tried the sample script in my previous mail on fedora core 2, i386 architecture. he has apache 2, php version 4.3.8 (or newer, don't know exactly). so now i've tested this on windows and it worked. freebsd i386 - no go. dragonflybsd amd64 - no go. fedora core 2 i386 - no go. please tell me if you need any detailed info on any if the machines (although i can promptly reply only for the freebsd (and win) box as it is mine, the others aren't).

Hmm, I've been using Linux and glibc for the development of mbstring for years and I've never been in a situation like yours. Could you send me a short and self-contained script with which I can reproduce the problem?

2. Run the one-liner below on a shell prompt and include the outout in the reply to this mail: ( echo "#include <stdio.h>"; echo "#include <ctype.h>"; echo 'main() { int i; for (i = 0; i < 256; i++) { printf("%d", isalnum(i) ? 1: 0); } printf("\n"); }' ) > /var/tmp/test.c && gcc -o /var/tmp/test /var/tmp/test.c && /var/tmp/test && rm /var/tmp/test.c /var/tmp/test

this is the output on freebsd: 00000000000000000000000000000000 00000000000000001111111111000000 01111111111111111111111111100000 01111111111111111111111111100000 00000000000000000000000000000000 00000000000000000000000000000000 00000000000000000000000000000000 00000000000000000000000000000000 i'll provide output from dragonflybsd later.

Nothing seems to be going wrong with it.

If http_input equals to internal_encoding then you don't need to turn on encoding_translation.

i've tried again with this turned off, just to be sure i didn't mess up here, but still the same - without the "foreign" characters in mb_ereg_replace output.

Actually this had little to do with your problem. It was just FYI stuff. Regards, Moriyoshi