mirror of
https://github.com/php/php-src.git
synced 2025-01-10 21:14:37 +08:00
fb9bf5b64b
The introduced checks were not correct in two respects: * It was checked whether the source encoding of the string matches the internal encoding, while the actually relevant encoding is the *target* encoding. * Even if the correct encoding is used, the checks are still too conservative. Just because something is not a "Unicode-encoding" does not mean that it does not map any non-ASCII characters. I've reverted the added checks and instead adjusted mbfl_convert to first try to use the provided substitution character and if that fails, perform the fallback to '?' at that point. This means that any codepoint mapped in the target encoding should now be correctly supported and anything else should fall back to '?'.
21 lines
574 B
PHP
21 lines
574 B
PHP
--TEST--
|
|
Request #69086 (enhancement for mb_convert_encoding)
|
|
--SKIPIF--
|
|
<?php extension_loaded('mbstring') or die('skip mbstring not available'); ?>
|
|
--FILE--
|
|
<?php
|
|
mb_substitute_character(0xfffd);
|
|
var_dump("?" === mb_convert_encoding("\x80", "Shift_JIS", "EUC-JP"));
|
|
mb_internal_encoding("UCS-4BE");
|
|
var_dump("\x00\x00\xff\xfd" === mb_convert_encoding("\x80", "UCS-4BE", "UTF-8"));
|
|
|
|
mb_internal_encoding("UTF-8");
|
|
mb_substitute_character(0xfffd);
|
|
var_dump("\u{fffd}" === mb_convert_encoding("\x80", "UTF-8", "EUC-JP-2004"));
|
|
|
|
?>
|
|
--EXPECT--
|
|
bool(true)
|
|
bool(true)
|
|
bool(true)
|