Замена младших символов ASCII в строке в кодировке UTF-16 с помощью функции PHP str_replace

У меня есть PHP-код, который я использую для фильтрации текста. Во время фильтрации некоторые символы ASCII, такие как амперсанд (&) и тильда (~), временно преобразуются в младшие символы ASCII (например, десятичные кодовые точки 4 и 5). Непосредственно перед созданием окончательного отфильтрованного вывода преобразование отменяется.

$temp = str_replace(array('&', '~'), array("\x04", "\x05"), $input);
... some filtering code to work with $temp ...
$out = str_replace(array("\x04", "\x05"), array('&', '~'), $temp);

Это хорошо работает с входным текстом кодировок символов, использующих 8-битные кодовые единицы, такие как UTF-8 и ISO 8859-1. Но я не уверен насчет ввода, закодированного в более крупных единицах кода, таких как UTF-16 или UTF-32. Будет ли первый шаг преобразования искажать правильность ввода текста? Будет ли какой-то конфликт на этапе реверсии из-за некоторых ранее существовавших символов ввода? Установка PHP не перегружает многобайтовые строковые функции.

Кто-нибудь может прокомментировать? Спасибо.


person user594694    schedule 15.09.2012    source источник


Ответы (1)


str_replace работает нормально, если все переданные ему строки имеют одну и ту же кодировку. Он просто выполняет двоичное сравнение/замену данных, поэтому фактическая кодировка не имеет большого значения.

Вот почему в этом списке нет mb_str_replace.

person GolezTrol    schedule 15.09.2012
comment
Под «всеми строками» вы подразумеваете, что «&» и «~» в последней строке кода примера, который я предоставляю, должны быть закодированы в кодировке UTF-16, если входной текст находится в UTF-16? То есть должен ли сам код PHP (файл PHP) быть в UTF-16? - person user594694; 15.09.2012
comment
Желательно, да. В противном случае '&' может случайно совпасть с частью символа UTF-16 во входной строке. Однако я бы рекомендовал вообще не использовать UTF-16. UTF-8 является стандартом де-факто в Интернете, а UTF-16 имеет мало преимуществ. UTF-8 хорош для размера, UTF-32 для простоты, а UTF-16 в большинстве случаев не подходит ни для того, ни для другого. - person GolezTrol; 15.09.2012
comment
Хм. Кодировка входного текста не находится под моим контролем (и я не хочу преобразовывать его в UTF-8). Спасибо. - person user594694; 16.09.2012
comment
*I want to avoid converting it to UTF-8* Почему? Вам также нужно будет иметь вывод в заданной кодировке, верно? Я думаю, что лучший способ работы - это иметь единую кодировку (предпочтительно UTF-8) для всех ваших данных. Смешивание кодировок напрашивается на неприятности. В «старые времена» смешивание кодовых страниц ANSI было проблемой (и до сих пор для многих), но теперь вы вносите совершенно новый уровень беспорядка, смешивая кодировки Unicode. Имейте в виду, что UTF-16 также создает проблемы с порядком байтов между Windows и Linux. Это еще одна причина использовать только UTF-8. - person GolezTrol; 16.09.2012