clones/php-src
1
0
Fork 0
mirror of https://github.com/php/php-src.git synced 2024-10-01 14:56:10 +00:00
Code Issues Packages Projects Releases Wiki Activity
a2f8c9c1ae
php-src/ext/standard/tests/strings/get_html_translation_table_variation1.phpt

317 lines
6.4 KiB
Plaintext
Raw Normal View History

New testcases for get_html_translation_table() function
2007-10-08 15:21:13 +00:00
--TEST--
Test get_html_translation_table() function : usage variations - unexpected table values
--FILE--
<?php
- Added a 3rd parameter to get_html_translation_table. It now takes a charset hint, like htmlentities et al. - Fixed bug #49407 (get_html_translation_table doesn't handle UTF-8). - Fixed bug #25927 (get_html_translation_table calls the ' &#39; instead of &#039;). - Fixed tests for get_html_translation_table and unified the Windows and non-Windows versions of the tests.
2010-10-12 02:51:11 +00:00
/* Prototype : array get_html_translation_table ( [int $table [, int $quote_style [, string charset_hint]]] )
New testcases for get_html_translation_table() function
2007-10-08 15:21:13 +00:00
* Description: Returns the internal translation table used by htmlspecialchars and htmlentities
* Source code: ext/standard/html.c
*/
/*
* test get_html_translation_table() with unexpected value for argument $table
*/
echo "*** Testing get_html_translation_table() : usage variations ***\n";
// initialize all required variables
$quote_style = ENT_COMPAT;
// get an unset variable
$unset_var = 10;
unset($unset_var);
// a resource variable
$fp = fopen(__FILE__, "r");
// array with different values
$values = array (
// array values
array(),
array(0),
array(1),
array(1, 2),
array('color' => 'red', 'item' => 'pen'),
// boolean values
true,
false,
TRUE,
FALSE,
// string values
"string",
'string',
// objects
new stdclass(),
// empty string
"",
'',
// null vlaues
NULL,
null,
// resource var
$fp,
// undefined variable
@$undefined_var,
// unset variable
@$unset_var
);
// loop through each element of the array and check the working of get_html_translation_table()
Merge branch 'pull-request/341' * pull-request/341: (23 commits) typofixes
2013-06-10 21:20:18 +00:00
// when $table argument is supplied with different values
New testcases for get_html_translation_table() function
2007-10-08 15:21:13 +00:00
echo "\n--- Testing get_html_translation_table() by supplying different values for 'table' argument ---\n";
$counter = 1;
for($index = 0; $index < count($values); $index ++) {
echo "-- Iteration $counter --\n";
$table = $values [$index];
- Added a 3rd parameter to get_html_translation_table. It now takes a charset hint, like htmlentities et al. - Fixed bug #49407 (get_html_translation_table doesn't handle UTF-8). - Fixed bug #25927 (get_html_translation_table calls the ' &#39; instead of &#039;). - Fixed tests for get_html_translation_table and unified the Windows and non-Windows versions of the tests.
2010-10-12 02:51:11 +00:00
$v = get_html_translation_table($table, ENT_COMPAT, "UTF-8");
if (is_array($v) && count($v) > 100)
var_dump(count($v));
- Completed rewrite of html.c. Except for determine_charset, almost nothing remains. - Fixed bug on determine_charset that was preventing correct detection in combination with internal mbstring encoding "none", "pass" or "auto". - Added profiles for entity encode/decode for HTMl 4.01, XHTML 1.0, XML 1.0 and HTML 5. Added the constants ENT_HTML401, ENT_XML1, ENT_XHTML and ENT_HTML5. - htmlentities()/htmlspecialchars(), when told not to double encode, verify the correctness of the existenting entities more thoroughly. It is checked whether the numerical entity represents a valid unicode code point (number is between 0 and 0x10FFFF). If using the flag ENT_DISALLOWED, it is also checked whether that numerical entity is valid in selected document. In HTML 4.01, all the numerical entities that represent a Unicode code point (< U+10FFFFFF) are valid, but that's not the case with other document types. If the entity is not valid, & is encoded to &amp;. For named entities, the check is also more thorough. While before the only check would be to determine if the entity was constituted by alphanumeric characters, now it is checked whether that entity is necessarily defined for the target document type. Otherwise, & is encoded to &amp;. - For html_entity_decode(), only valid numerical and named entities (as defined above for htmlentities()/htmlspecialchars() + !double_encode) are decoded. But there is in this case one additional check. Entities that represent non-SGML or otherwise invalid characters are not decoded. Note that, in HTML5, U+000D is a valid literal character, but the entity &#x0D is not valid and is therefore not decoded. - The hash tables lazily created for decoding in html_entity_decode() that were added recently were substituted by static hash tables. Instead of 1 hash table per encoding, there's only one hash table per document type defined in terms of unicode code points. This means that for charsets other than UTF-8 and ISO-8859-1, a conversion to unicode code points is necessary before decoding. - On the encoding side, the ad hoc ranges of entities of the translation tables, which mapped (in general) non-unicode code points to HTML entities were replaced by three-stage tables for HTML 4 and HTML 5. This mapping tables are defined only in terms of unicode code points, so a conversion is necessary for charsets other than UTF-8 and ISO-8859-1. Even so, the multi-stage table is much faster than the previous method, by a factor of 5; the conversion to unicode is a small penalty because it's just a simple table lookup. XML 1.0/htmlspecialchars() uses a simple table instead of a three-stage table. - Added the flag ENT_SUBSTITUTE, which makes htmlentities()/htmlspecialchars() replace the invalid multibyte sequences with U+FFFD (UTF-8) or &#FFFD; (other encodings). - Added the flag ENT_DISALLOWED. Implements FR #52860. Characters that cannot appear literally are replaced by U+FFFD (UTF-8) or &#FFFD; (otherwise). An alternative implementation would be to encode those characters into numerical entities, but that would only work in HTML 4.01 due to limitations on the values of numerical entities in other document types. See also the effects on htmlentities()/htmlspecialchars() with !double_encode above.
2010-10-24 15:01:02 +00:00
elseif (is_array($v)) {
asort($v);
- Added a 3rd parameter to get_html_translation_table. It now takes a charset hint, like htmlentities et al. - Fixed bug #49407 (get_html_translation_table doesn't handle UTF-8). - Fixed bug #25927 (get_html_translation_table calls the ' &#39; instead of &#039;). - Fixed tests for get_html_translation_table and unified the Windows and non-Windows versions of the tests.
2010-10-12 02:51:11 +00:00
var_dump($v);
- Completed rewrite of html.c. Except for determine_charset, almost nothing remains. - Fixed bug on determine_charset that was preventing correct detection in combination with internal mbstring encoding "none", "pass" or "auto". - Added profiles for entity encode/decode for HTMl 4.01, XHTML 1.0, XML 1.0 and HTML 5. Added the constants ENT_HTML401, ENT_XML1, ENT_XHTML and ENT_HTML5. - htmlentities()/htmlspecialchars(), when told not to double encode, verify the correctness of the existenting entities more thoroughly. It is checked whether the numerical entity represents a valid unicode code point (number is between 0 and 0x10FFFF). If using the flag ENT_DISALLOWED, it is also checked whether that numerical entity is valid in selected document. In HTML 4.01, all the numerical entities that represent a Unicode code point (< U+10FFFFFF) are valid, but that's not the case with other document types. If the entity is not valid, & is encoded to &amp;. For named entities, the check is also more thorough. While before the only check would be to determine if the entity was constituted by alphanumeric characters, now it is checked whether that entity is necessarily defined for the target document type. Otherwise, & is encoded to &amp;. - For html_entity_decode(), only valid numerical and named entities (as defined above for htmlentities()/htmlspecialchars() + !double_encode) are decoded. But there is in this case one additional check. Entities that represent non-SGML or otherwise invalid characters are not decoded. Note that, in HTML5, U+000D is a valid literal character, but the entity &#x0D is not valid and is therefore not decoded. - The hash tables lazily created for decoding in html_entity_decode() that were added recently were substituted by static hash tables. Instead of 1 hash table per encoding, there's only one hash table per document type defined in terms of unicode code points. This means that for charsets other than UTF-8 and ISO-8859-1, a conversion to unicode code points is necessary before decoding. - On the encoding side, the ad hoc ranges of entities of the translation tables, which mapped (in general) non-unicode code points to HTML entities were replaced by three-stage tables for HTML 4 and HTML 5. This mapping tables are defined only in terms of unicode code points, so a conversion is necessary for charsets other than UTF-8 and ISO-8859-1. Even so, the multi-stage table is much faster than the previous method, by a factor of 5; the conversion to unicode is a small penalty because it's just a simple table lookup. XML 1.0/htmlspecialchars() uses a simple table instead of a three-stage table. - Added the flag ENT_SUBSTITUTE, which makes htmlentities()/htmlspecialchars() replace the invalid multibyte sequences with U+FFFD (UTF-8) or &#FFFD; (other encodings). - Added the flag ENT_DISALLOWED. Implements FR #52860. Characters that cannot appear literally are replaced by U+FFFD (UTF-8) or &#FFFD; (otherwise). An alternative implementation would be to encode those characters into numerical entities, but that would only work in HTML 4.01 due to limitations on the values of numerical entities in other document types. See also the effects on htmlentities()/htmlspecialchars() with !double_encode above.
2010-10-24 15:01:02 +00:00
} else {
var_dump($v);
}
- Added a 3rd parameter to get_html_translation_table. It now takes a charset hint, like htmlentities et al. - Fixed bug #49407 (get_html_translation_table doesn't handle UTF-8). - Fixed bug #25927 (get_html_translation_table calls the ' &#39; instead of &#039;). - Fixed tests for get_html_translation_table and unified the Windows and non-Windows versions of the tests.
2010-10-12 02:51:11 +00:00
$v = get_html_translation_table($table, $quote_style, "UTF-8");
if (is_array($v) && count($v) > 100)
var_dump(count($v));
- Completed rewrite of html.c. Except for determine_charset, almost nothing remains. - Fixed bug on determine_charset that was preventing correct detection in combination with internal mbstring encoding "none", "pass" or "auto". - Added profiles for entity encode/decode for HTMl 4.01, XHTML 1.0, XML 1.0 and HTML 5. Added the constants ENT_HTML401, ENT_XML1, ENT_XHTML and ENT_HTML5. - htmlentities()/htmlspecialchars(), when told not to double encode, verify the correctness of the existenting entities more thoroughly. It is checked whether the numerical entity represents a valid unicode code point (number is between 0 and 0x10FFFF). If using the flag ENT_DISALLOWED, it is also checked whether that numerical entity is valid in selected document. In HTML 4.01, all the numerical entities that represent a Unicode code point (< U+10FFFFFF) are valid, but that's not the case with other document types. If the entity is not valid, & is encoded to &amp;. For named entities, the check is also more thorough. While before the only check would be to determine if the entity was constituted by alphanumeric characters, now it is checked whether that entity is necessarily defined for the target document type. Otherwise, & is encoded to &amp;. - For html_entity_decode(), only valid numerical and named entities (as defined above for htmlentities()/htmlspecialchars() + !double_encode) are decoded. But there is in this case one additional check. Entities that represent non-SGML or otherwise invalid characters are not decoded. Note that, in HTML5, U+000D is a valid literal character, but the entity &#x0D is not valid and is therefore not decoded. - The hash tables lazily created for decoding in html_entity_decode() that were added recently were substituted by static hash tables. Instead of 1 hash table per encoding, there's only one hash table per document type defined in terms of unicode code points. This means that for charsets other than UTF-8 and ISO-8859-1, a conversion to unicode code points is necessary before decoding. - On the encoding side, the ad hoc ranges of entities of the translation tables, which mapped (in general) non-unicode code points to HTML entities were replaced by three-stage tables for HTML 4 and HTML 5. This mapping tables are defined only in terms of unicode code points, so a conversion is necessary for charsets other than UTF-8 and ISO-8859-1. Even so, the multi-stage table is much faster than the previous method, by a factor of 5; the conversion to unicode is a small penalty because it's just a simple table lookup. XML 1.0/htmlspecialchars() uses a simple table instead of a three-stage table. - Added the flag ENT_SUBSTITUTE, which makes htmlentities()/htmlspecialchars() replace the invalid multibyte sequences with U+FFFD (UTF-8) or &#FFFD; (other encodings). - Added the flag ENT_DISALLOWED. Implements FR #52860. Characters that cannot appear literally are replaced by U+FFFD (UTF-8) or &#FFFD; (otherwise). An alternative implementation would be to encode those characters into numerical entities, but that would only work in HTML 4.01 due to limitations on the values of numerical entities in other document types. See also the effects on htmlentities()/htmlspecialchars() with !double_encode above.
2010-10-24 15:01:02 +00:00
elseif (is_array($v)) {
asort($v);
var_dump($v);
} else {
- Added a 3rd parameter to get_html_translation_table. It now takes a charset hint, like htmlentities et al. - Fixed bug #49407 (get_html_translation_table doesn't handle UTF-8). - Fixed bug #25927 (get_html_translation_table calls the ' &#39; instead of &#039;). - Fixed tests for get_html_translation_table and unified the Windows and non-Windows versions of the tests.
2010-10-12 02:51:11 +00:00
var_dump($v);
- Completed rewrite of html.c. Except for determine_charset, almost nothing remains. - Fixed bug on determine_charset that was preventing correct detection in combination with internal mbstring encoding "none", "pass" or "auto". - Added profiles for entity encode/decode for HTMl 4.01, XHTML 1.0, XML 1.0 and HTML 5. Added the constants ENT_HTML401, ENT_XML1, ENT_XHTML and ENT_HTML5. - htmlentities()/htmlspecialchars(), when told not to double encode, verify the correctness of the existenting entities more thoroughly. It is checked whether the numerical entity represents a valid unicode code point (number is between 0 and 0x10FFFF). If using the flag ENT_DISALLOWED, it is also checked whether that numerical entity is valid in selected document. In HTML 4.01, all the numerical entities that represent a Unicode code point (< U+10FFFFFF) are valid, but that's not the case with other document types. If the entity is not valid, & is encoded to &amp;. For named entities, the check is also more thorough. While before the only check would be to determine if the entity was constituted by alphanumeric characters, now it is checked whether that entity is necessarily defined for the target document type. Otherwise, & is encoded to &amp;. - For html_entity_decode(), only valid numerical and named entities (as defined above for htmlentities()/htmlspecialchars() + !double_encode) are decoded. But there is in this case one additional check. Entities that represent non-SGML or otherwise invalid characters are not decoded. Note that, in HTML5, U+000D is a valid literal character, but the entity &#x0D is not valid and is therefore not decoded. - The hash tables lazily created for decoding in html_entity_decode() that were added recently were substituted by static hash tables. Instead of 1 hash table per encoding, there's only one hash table per document type defined in terms of unicode code points. This means that for charsets other than UTF-8 and ISO-8859-1, a conversion to unicode code points is necessary before decoding. - On the encoding side, the ad hoc ranges of entities of the translation tables, which mapped (in general) non-unicode code points to HTML entities were replaced by three-stage tables for HTML 4 and HTML 5. This mapping tables are defined only in terms of unicode code points, so a conversion is necessary for charsets other than UTF-8 and ISO-8859-1. Even so, the multi-stage table is much faster than the previous method, by a factor of 5; the conversion to unicode is a small penalty because it's just a simple table lookup. XML 1.0/htmlspecialchars() uses a simple table instead of a three-stage table. - Added the flag ENT_SUBSTITUTE, which makes htmlentities()/htmlspecialchars() replace the invalid multibyte sequences with U+FFFD (UTF-8) or &#FFFD; (other encodings). - Added the flag ENT_DISALLOWED. Implements FR #52860. Characters that cannot appear literally are replaced by U+FFFD (UTF-8) or &#FFFD; (otherwise). An alternative implementation would be to encode those characters into numerical entities, but that would only work in HTML 4.01 due to limitations on the values of numerical entities in other document types. See also the effects on htmlentities()/htmlspecialchars() with !double_encode above.
2010-10-24 15:01:02 +00:00
}
New testcases for get_html_translation_table() function
2007-10-08 15:21:13 +00:00
$counter ++;
}
// close resource
fclose($fp);
echo "Done\n";
?>
--EXPECTF--
*** Testing get_html_translation_table() : usage variations ***
--- Testing get_html_translation_table() by supplying different values for 'table' argument ---
-- Iteration 1 --
Switch default_charset, if not specified, from ISO-8859-1 to UTF-8 I have been wanting to make this change for years, but there is a small chance of BC issues, so it shouldn't go into a minor release.
2010-03-23 18:08:06 +00:00
Warning: get_html_translation_table() expects parameter 1 to be long, array given in %s on line %d
New testcases for get_html_translation_table() function
2007-10-08 15:21:13 +00:00
NULL
Switch default_charset, if not specified, from ISO-8859-1 to UTF-8 I have been wanting to make this change for years, but there is a small chance of BC issues, so it shouldn't go into a minor release.
2010-03-23 18:08:06 +00:00
Warning: get_html_translation_table() expects parameter 1 to be long, array given in %s on line %d
New testcases for get_html_translation_table() function
2007-10-08 15:21:13 +00:00
NULL
-- Iteration 2 --
Switch default_charset, if not specified, from ISO-8859-1 to UTF-8 I have been wanting to make this change for years, but there is a small chance of BC issues, so it shouldn't go into a minor release.
2010-03-23 18:08:06 +00:00
Warning: get_html_translation_table() expects parameter 1 to be long, array given in %s on line %d
New testcases for get_html_translation_table() function
2007-10-08 15:21:13 +00:00
NULL
Switch default_charset, if not specified, from ISO-8859-1 to UTF-8 I have been wanting to make this change for years, but there is a small chance of BC issues, so it shouldn't go into a minor release.
2010-03-23 18:08:06 +00:00
Warning: get_html_translation_table() expects parameter 1 to be long, array given in %s on line %d
New testcases for get_html_translation_table() function
2007-10-08 15:21:13 +00:00
NULL
-- Iteration 3 --
Switch default_charset, if not specified, from ISO-8859-1 to UTF-8 I have been wanting to make this change for years, but there is a small chance of BC issues, so it shouldn't go into a minor release.
2010-03-23 18:08:06 +00:00
Warning: get_html_translation_table() expects parameter 1 to be long, array given in %s on line %d
New testcases for get_html_translation_table() function
2007-10-08 15:21:13 +00:00
NULL
Switch default_charset, if not specified, from ISO-8859-1 to UTF-8 I have been wanting to make this change for years, but there is a small chance of BC issues, so it shouldn't go into a minor release.
2010-03-23 18:08:06 +00:00
Warning: get_html_translation_table() expects parameter 1 to be long, array given in %s on line %d
New testcases for get_html_translation_table() function
2007-10-08 15:21:13 +00:00
NULL
-- Iteration 4 --
Switch default_charset, if not specified, from ISO-8859-1 to UTF-8 I have been wanting to make this change for years, but there is a small chance of BC issues, so it shouldn't go into a minor release.
2010-03-23 18:08:06 +00:00
Warning: get_html_translation_table() expects parameter 1 to be long, array given in %s on line %d
New testcases for get_html_translation_table() function
2007-10-08 15:21:13 +00:00
NULL
Switch default_charset, if not specified, from ISO-8859-1 to UTF-8 I have been wanting to make this change for years, but there is a small chance of BC issues, so it shouldn't go into a minor release.
2010-03-23 18:08:06 +00:00
Warning: get_html_translation_table() expects parameter 1 to be long, array given in %s on line %d
New testcases for get_html_translation_table() function
2007-10-08 15:21:13 +00:00
NULL
-- Iteration 5 --
Switch default_charset, if not specified, from ISO-8859-1 to UTF-8 I have been wanting to make this change for years, but there is a small chance of BC issues, so it shouldn't go into a minor release.
2010-03-23 18:08:06 +00:00
Warning: get_html_translation_table() expects parameter 1 to be long, array given in %s on line %d
New testcases for get_html_translation_table() function
2007-10-08 15:21:13 +00:00
NULL
Switch default_charset, if not specified, from ISO-8859-1 to UTF-8 I have been wanting to make this change for years, but there is a small chance of BC issues, so it shouldn't go into a minor release.
2010-03-23 18:08:06 +00:00
Warning: get_html_translation_table() expects parameter 1 to be long, array given in %s on line %d
New testcases for get_html_translation_table() function
2007-10-08 15:21:13 +00:00
NULL
-- Iteration 6 --
- Added a 3rd parameter to get_html_translation_table. It now takes a charset hint, like htmlentities et al. - Fixed bug #49407 (get_html_translation_table doesn't handle UTF-8). - Fixed bug #25927 (get_html_translation_table calls the ' &#39; instead of &#039;). - Fixed tests for get_html_translation_table and unified the Windows and non-Windows versions of the tests.
2010-10-12 02:51:11 +00:00
int(252)
int(252)
New testcases for get_html_translation_table() function
2007-10-08 15:21:13 +00:00
-- Iteration 7 --
array(4) {
["&"]=>
string(5) "&amp;"
[">"]=>
string(4) "&gt;"
- Completed rewrite of html.c. Except for determine_charset, almost nothing remains. - Fixed bug on determine_charset that was preventing correct detection in combination with internal mbstring encoding "none", "pass" or "auto". - Added profiles for entity encode/decode for HTMl 4.01, XHTML 1.0, XML 1.0 and HTML 5. Added the constants ENT_HTML401, ENT_XML1, ENT_XHTML and ENT_HTML5. - htmlentities()/htmlspecialchars(), when told not to double encode, verify the correctness of the existenting entities more thoroughly. It is checked whether the numerical entity represents a valid unicode code point (number is between 0 and 0x10FFFF). If using the flag ENT_DISALLOWED, it is also checked whether that numerical entity is valid in selected document. In HTML 4.01, all the numerical entities that represent a Unicode code point (< U+10FFFFFF) are valid, but that's not the case with other document types. If the entity is not valid, & is encoded to &amp;. For named entities, the check is also more thorough. While before the only check would be to determine if the entity was constituted by alphanumeric characters, now it is checked whether that entity is necessarily defined for the target document type. Otherwise, & is encoded to &amp;. - For html_entity_decode(), only valid numerical and named entities (as defined above for htmlentities()/htmlspecialchars() + !double_encode) are decoded. But there is in this case one additional check. Entities that represent non-SGML or otherwise invalid characters are not decoded. Note that, in HTML5, U+000D is a valid literal character, but the entity &#x0D is not valid and is therefore not decoded. - The hash tables lazily created for decoding in html_entity_decode() that were added recently were substituted by static hash tables. Instead of 1 hash table per encoding, there's only one hash table per document type defined in terms of unicode code points. This means that for charsets other than UTF-8 and ISO-8859-1, a conversion to unicode code points is necessary before decoding. - On the encoding side, the ad hoc ranges of entities of the translation tables, which mapped (in general) non-unicode code points to HTML entities were replaced by three-stage tables for HTML 4 and HTML 5. This mapping tables are defined only in terms of unicode code points, so a conversion is necessary for charsets other than UTF-8 and ISO-8859-1. Even so, the multi-stage table is much faster than the previous method, by a factor of 5; the conversion to unicode is a small penalty because it's just a simple table lookup. XML 1.0/htmlspecialchars() uses a simple table instead of a three-stage table. - Added the flag ENT_SUBSTITUTE, which makes htmlentities()/htmlspecialchars() replace the invalid multibyte sequences with U+FFFD (UTF-8) or &#FFFD; (other encodings). - Added the flag ENT_DISALLOWED. Implements FR #52860. Characters that cannot appear literally are replaced by U+FFFD (UTF-8) or &#FFFD; (otherwise). An alternative implementation would be to encode those characters into numerical entities, but that would only work in HTML 4.01 due to limitations on the values of numerical entities in other document types. See also the effects on htmlentities()/htmlspecialchars() with !double_encode above.
2010-10-24 15:01:02 +00:00
["<"]=>
string(4) "&lt;"
["""]=>
string(6) "&quot;"
- Added a 3rd parameter to get_html_translation_table. It now takes a charset hint, like htmlentities et al. - Fixed bug #49407 (get_html_translation_table doesn't handle UTF-8). - Fixed bug #25927 (get_html_translation_table calls the ' &#39; instead of &#039;). - Fixed tests for get_html_translation_table and unified the Windows and non-Windows versions of the tests.
2010-10-12 02:51:11 +00:00
}
array(4) {
New testcases for get_html_translation_table() function
2007-10-08 15:21:13 +00:00
["&"]=>
string(5) "&amp;"
Switch default_charset, if not specified, from ISO-8859-1 to UTF-8 I have been wanting to make this change for years, but there is a small chance of BC issues, so it shouldn't go into a minor release.
2010-03-23 18:08:06 +00:00
[">"]=>
string(4) "&gt;"
- Completed rewrite of html.c. Except for determine_charset, almost nothing remains. - Fixed bug on determine_charset that was preventing correct detection in combination with internal mbstring encoding "none", "pass" or "auto". - Added profiles for entity encode/decode for HTMl 4.01, XHTML 1.0, XML 1.0 and HTML 5. Added the constants ENT_HTML401, ENT_XML1, ENT_XHTML and ENT_HTML5. - htmlentities()/htmlspecialchars(), when told not to double encode, verify the correctness of the existenting entities more thoroughly. It is checked whether the numerical entity represents a valid unicode code point (number is between 0 and 0x10FFFF). If using the flag ENT_DISALLOWED, it is also checked whether that numerical entity is valid in selected document. In HTML 4.01, all the numerical entities that represent a Unicode code point (< U+10FFFFFF) are valid, but that's not the case with other document types. If the entity is not valid, & is encoded to &amp;. For named entities, the check is also more thorough. While before the only check would be to determine if the entity was constituted by alphanumeric characters, now it is checked whether that entity is necessarily defined for the target document type. Otherwise, & is encoded to &amp;. - For html_entity_decode(), only valid numerical and named entities (as defined above for htmlentities()/htmlspecialchars() + !double_encode) are decoded. But there is in this case one additional check. Entities that represent non-SGML or otherwise invalid characters are not decoded. Note that, in HTML5, U+000D is a valid literal character, but the entity &#x0D is not valid and is therefore not decoded. - The hash tables lazily created for decoding in html_entity_decode() that were added recently were substituted by static hash tables. Instead of 1 hash table per encoding, there's only one hash table per document type defined in terms of unicode code points. This means that for charsets other than UTF-8 and ISO-8859-1, a conversion to unicode code points is necessary before decoding. - On the encoding side, the ad hoc ranges of entities of the translation tables, which mapped (in general) non-unicode code points to HTML entities were replaced by three-stage tables for HTML 4 and HTML 5. This mapping tables are defined only in terms of unicode code points, so a conversion is necessary for charsets other than UTF-8 and ISO-8859-1. Even so, the multi-stage table is much faster than the previous method, by a factor of 5; the conversion to unicode is a small penalty because it's just a simple table lookup. XML 1.0/htmlspecialchars() uses a simple table instead of a three-stage table. - Added the flag ENT_SUBSTITUTE, which makes htmlentities()/htmlspecialchars() replace the invalid multibyte sequences with U+FFFD (UTF-8) or &#FFFD; (other encodings). - Added the flag ENT_DISALLOWED. Implements FR #52860. Characters that cannot appear literally are replaced by U+FFFD (UTF-8) or &#FFFD; (otherwise). An alternative implementation would be to encode those characters into numerical entities, but that would only work in HTML 4.01 due to limitations on the values of numerical entities in other document types. See also the effects on htmlentities()/htmlspecialchars() with !double_encode above.
2010-10-24 15:01:02 +00:00
["<"]=>
string(4) "&lt;"
["""]=>
string(6) "&quot;"
New testcases for get_html_translation_table() function
2007-10-08 15:21:13 +00:00
}
- Added a 3rd parameter to get_html_translation_table. It now takes a charset hint, like htmlentities et al. - Fixed bug #49407 (get_html_translation_table doesn't handle UTF-8). - Fixed bug #25927 (get_html_translation_table calls the ' &#39; instead of &#039;). - Fixed tests for get_html_translation_table and unified the Windows and non-Windows versions of the tests.
2010-10-12 02:51:11 +00:00
-- Iteration 8 --
int(252)
int(252)
New testcases for get_html_translation_table() function
2007-10-08 15:21:13 +00:00
-- Iteration 9 --
array(4) {
- Added a 3rd parameter to get_html_translation_table. It now takes a charset hint, like htmlentities et al. - Fixed bug #49407 (get_html_translation_table doesn't handle UTF-8). - Fixed bug #25927 (get_html_translation_table calls the ' &#39; instead of &#039;). - Fixed tests for get_html_translation_table and unified the Windows and non-Windows versions of the tests.
2010-10-12 02:51:11 +00:00
["&"]=>
string(5) "&amp;"
New testcases for get_html_translation_table() function
2007-10-08 15:21:13 +00:00
[">"]=>
string(4) "&gt;"
- Completed rewrite of html.c. Except for determine_charset, almost nothing remains. - Fixed bug on determine_charset that was preventing correct detection in combination with internal mbstring encoding "none", "pass" or "auto". - Added profiles for entity encode/decode for HTMl 4.01, XHTML 1.0, XML 1.0 and HTML 5. Added the constants ENT_HTML401, ENT_XML1, ENT_XHTML and ENT_HTML5. - htmlentities()/htmlspecialchars(), when told not to double encode, verify the correctness of the existenting entities more thoroughly. It is checked whether the numerical entity represents a valid unicode code point (number is between 0 and 0x10FFFF). If using the flag ENT_DISALLOWED, it is also checked whether that numerical entity is valid in selected document. In HTML 4.01, all the numerical entities that represent a Unicode code point (< U+10FFFFFF) are valid, but that's not the case with other document types. If the entity is not valid, & is encoded to &amp;. For named entities, the check is also more thorough. While before the only check would be to determine if the entity was constituted by alphanumeric characters, now it is checked whether that entity is necessarily defined for the target document type. Otherwise, & is encoded to &amp;. - For html_entity_decode(), only valid numerical and named entities (as defined above for htmlentities()/htmlspecialchars() + !double_encode) are decoded. But there is in this case one additional check. Entities that represent non-SGML or otherwise invalid characters are not decoded. Note that, in HTML5, U+000D is a valid literal character, but the entity &#x0D is not valid and is therefore not decoded. - The hash tables lazily created for decoding in html_entity_decode() that were added recently were substituted by static hash tables. Instead of 1 hash table per encoding, there's only one hash table per document type defined in terms of unicode code points. This means that for charsets other than UTF-8 and ISO-8859-1, a conversion to unicode code points is necessary before decoding. - On the encoding side, the ad hoc ranges of entities of the translation tables, which mapped (in general) non-unicode code points to HTML entities were replaced by three-stage tables for HTML 4 and HTML 5. This mapping tables are defined only in terms of unicode code points, so a conversion is necessary for charsets other than UTF-8 and ISO-8859-1. Even so, the multi-stage table is much faster than the previous method, by a factor of 5; the conversion to unicode is a small penalty because it's just a simple table lookup. XML 1.0/htmlspecialchars() uses a simple table instead of a three-stage table. - Added the flag ENT_SUBSTITUTE, which makes htmlentities()/htmlspecialchars() replace the invalid multibyte sequences with U+FFFD (UTF-8) or &#FFFD; (other encodings). - Added the flag ENT_DISALLOWED. Implements FR #52860. Characters that cannot appear literally are replaced by U+FFFD (UTF-8) or &#FFFD; (otherwise). An alternative implementation would be to encode those characters into numerical entities, but that would only work in HTML 4.01 due to limitations on the values of numerical entities in other document types. See also the effects on htmlentities()/htmlspecialchars() with !double_encode above.
2010-10-24 15:01:02 +00:00
["<"]=>
string(4) "&lt;"
["""]=>
string(6) "&quot;"
New testcases for get_html_translation_table() function
2007-10-08 15:21:13 +00:00
}
array(4) {
- Added a 3rd parameter to get_html_translation_table. It now takes a charset hint, like htmlentities et al. - Fixed bug #49407 (get_html_translation_table doesn't handle UTF-8). - Fixed bug #25927 (get_html_translation_table calls the ' &#39; instead of &#039;). - Fixed tests for get_html_translation_table and unified the Windows and non-Windows versions of the tests.
2010-10-12 02:51:11 +00:00
["&"]=>
string(5) "&amp;"
New testcases for get_html_translation_table() function
2007-10-08 15:21:13 +00:00
[">"]=>
string(4) "&gt;"
- Completed rewrite of html.c. Except for determine_charset, almost nothing remains. - Fixed bug on determine_charset that was preventing correct detection in combination with internal mbstring encoding "none", "pass" or "auto". - Added profiles for entity encode/decode for HTMl 4.01, XHTML 1.0, XML 1.0 and HTML 5. Added the constants ENT_HTML401, ENT_XML1, ENT_XHTML and ENT_HTML5. - htmlentities()/htmlspecialchars(), when told not to double encode, verify the correctness of the existenting entities more thoroughly. It is checked whether the numerical entity represents a valid unicode code point (number is between 0 and 0x10FFFF). If using the flag ENT_DISALLOWED, it is also checked whether that numerical entity is valid in selected document. In HTML 4.01, all the numerical entities that represent a Unicode code point (< U+10FFFFFF) are valid, but that's not the case with other document types. If the entity is not valid, & is encoded to &amp;. For named entities, the check is also more thorough. While before the only check would be to determine if the entity was constituted by alphanumeric characters, now it is checked whether that entity is necessarily defined for the target document type. Otherwise, & is encoded to &amp;. - For html_entity_decode(), only valid numerical and named entities (as defined above for htmlentities()/htmlspecialchars() + !double_encode) are decoded. But there is in this case one additional check. Entities that represent non-SGML or otherwise invalid characters are not decoded. Note that, in HTML5, U+000D is a valid literal character, but the entity &#x0D is not valid and is therefore not decoded. - The hash tables lazily created for decoding in html_entity_decode() that were added recently were substituted by static hash tables. Instead of 1 hash table per encoding, there's only one hash table per document type defined in terms of unicode code points. This means that for charsets other than UTF-8 and ISO-8859-1, a conversion to unicode code points is necessary before decoding. - On the encoding side, the ad hoc ranges of entities of the translation tables, which mapped (in general) non-unicode code points to HTML entities were replaced by three-stage tables for HTML 4 and HTML 5. This mapping tables are defined only in terms of unicode code points, so a conversion is necessary for charsets other than UTF-8 and ISO-8859-1. Even so, the multi-stage table is much faster than the previous method, by a factor of 5; the conversion to unicode is a small penalty because it's just a simple table lookup. XML 1.0/htmlspecialchars() uses a simple table instead of a three-stage table. - Added the flag ENT_SUBSTITUTE, which makes htmlentities()/htmlspecialchars() replace the invalid multibyte sequences with U+FFFD (UTF-8) or &#FFFD; (other encodings). - Added the flag ENT_DISALLOWED. Implements FR #52860. Characters that cannot appear literally are replaced by U+FFFD (UTF-8) or &#FFFD; (otherwise). An alternative implementation would be to encode those characters into numerical entities, but that would only work in HTML 4.01 due to limitations on the values of numerical entities in other document types. See also the effects on htmlentities()/htmlspecialchars() with !double_encode above.
2010-10-24 15:01:02 +00:00
["<"]=>
string(4) "&lt;"
["""]=>
string(6) "&quot;"
New testcases for get_html_translation_table() function
2007-10-08 15:21:13 +00:00
}
-- Iteration 10 --
Switch default_charset, if not specified, from ISO-8859-1 to UTF-8 I have been wanting to make this change for years, but there is a small chance of BC issues, so it shouldn't go into a minor release.
2010-03-23 18:08:06 +00:00
Warning: get_html_translation_table() expects parameter 1 to be long, string given in %s on line %d
New testcases for get_html_translation_table() function
2007-10-08 15:21:13 +00:00
NULL
Switch default_charset, if not specified, from ISO-8859-1 to UTF-8 I have been wanting to make this change for years, but there is a small chance of BC issues, so it shouldn't go into a minor release.
2010-03-23 18:08:06 +00:00
Warning: get_html_translation_table() expects parameter 1 to be long, string given in %s on line %d
New testcases for get_html_translation_table() function
2007-10-08 15:21:13 +00:00
NULL
-- Iteration 11 --
Switch default_charset, if not specified, from ISO-8859-1 to UTF-8 I have been wanting to make this change for years, but there is a small chance of BC issues, so it shouldn't go into a minor release.
2010-03-23 18:08:06 +00:00
Warning: get_html_translation_table() expects parameter 1 to be long, string given in %s on line %d
New testcases for get_html_translation_table() function
2007-10-08 15:21:13 +00:00
NULL
Switch default_charset, if not specified, from ISO-8859-1 to UTF-8 I have been wanting to make this change for years, but there is a small chance of BC issues, so it shouldn't go into a minor release.
2010-03-23 18:08:06 +00:00
Warning: get_html_translation_table() expects parameter 1 to be long, string given in %s on line %d
New testcases for get_html_translation_table() function
2007-10-08 15:21:13 +00:00
NULL
-- Iteration 12 --
Switch default_charset, if not specified, from ISO-8859-1 to UTF-8 I have been wanting to make this change for years, but there is a small chance of BC issues, so it shouldn't go into a minor release.
2010-03-23 18:08:06 +00:00
Warning: get_html_translation_table() expects parameter 1 to be long, object given in %s on line %d
New testcases for get_html_translation_table() function
2007-10-08 15:21:13 +00:00
NULL
Switch default_charset, if not specified, from ISO-8859-1 to UTF-8 I have been wanting to make this change for years, but there is a small chance of BC issues, so it shouldn't go into a minor release.
2010-03-23 18:08:06 +00:00
Warning: get_html_translation_table() expects parameter 1 to be long, object given in %s on line %d
New testcases for get_html_translation_table() function
2007-10-08 15:21:13 +00:00
NULL
-- Iteration 13 --
Switch default_charset, if not specified, from ISO-8859-1 to UTF-8 I have been wanting to make this change for years, but there is a small chance of BC issues, so it shouldn't go into a minor release.
2010-03-23 18:08:06 +00:00
Warning: get_html_translation_table() expects parameter 1 to be long, string given in %s on line %d
New testcases for get_html_translation_table() function
2007-10-08 15:21:13 +00:00
NULL
Switch default_charset, if not specified, from ISO-8859-1 to UTF-8 I have been wanting to make this change for years, but there is a small chance of BC issues, so it shouldn't go into a minor release.
2010-03-23 18:08:06 +00:00
Warning: get_html_translation_table() expects parameter 1 to be long, string given in %s on line %d
New testcases for get_html_translation_table() function
2007-10-08 15:21:13 +00:00
NULL
-- Iteration 14 --
Switch default_charset, if not specified, from ISO-8859-1 to UTF-8 I have been wanting to make this change for years, but there is a small chance of BC issues, so it shouldn't go into a minor release.
2010-03-23 18:08:06 +00:00
Warning: get_html_translation_table() expects parameter 1 to be long, string given in %s on line %d
New testcases for get_html_translation_table() function
2007-10-08 15:21:13 +00:00
NULL
Switch default_charset, if not specified, from ISO-8859-1 to UTF-8 I have been wanting to make this change for years, but there is a small chance of BC issues, so it shouldn't go into a minor release.
2010-03-23 18:08:06 +00:00
Warning: get_html_translation_table() expects parameter 1 to be long, string given in %s on line %d
New testcases for get_html_translation_table() function
2007-10-08 15:21:13 +00:00
NULL
-- Iteration 15 --
array(4) {
- Added a 3rd parameter to get_html_translation_table. It now takes a charset hint, like htmlentities et al. - Fixed bug #49407 (get_html_translation_table doesn't handle UTF-8). - Fixed bug #25927 (get_html_translation_table calls the ' &#39; instead of &#039;). - Fixed tests for get_html_translation_table and unified the Windows and non-Windows versions of the tests.
2010-10-12 02:51:11 +00:00
["&"]=>
string(5) "&amp;"
New testcases for get_html_translation_table() function
2007-10-08 15:21:13 +00:00
[">"]=>
string(4) "&gt;"
- Completed rewrite of html.c. Except for determine_charset, almost nothing remains. - Fixed bug on determine_charset that was preventing correct detection in combination with internal mbstring encoding "none", "pass" or "auto". - Added profiles for entity encode/decode for HTMl 4.01, XHTML 1.0, XML 1.0 and HTML 5. Added the constants ENT_HTML401, ENT_XML1, ENT_XHTML and ENT_HTML5. - htmlentities()/htmlspecialchars(), when told not to double encode, verify the correctness of the existenting entities more thoroughly. It is checked whether the numerical entity represents a valid unicode code point (number is between 0 and 0x10FFFF). If using the flag ENT_DISALLOWED, it is also checked whether that numerical entity is valid in selected document. In HTML 4.01, all the numerical entities that represent a Unicode code point (< U+10FFFFFF) are valid, but that's not the case with other document types. If the entity is not valid, & is encoded to &amp;. For named entities, the check is also more thorough. While before the only check would be to determine if the entity was constituted by alphanumeric characters, now it is checked whether that entity is necessarily defined for the target document type. Otherwise, & is encoded to &amp;. - For html_entity_decode(), only valid numerical and named entities (as defined above for htmlentities()/htmlspecialchars() + !double_encode) are decoded. But there is in this case one additional check. Entities that represent non-SGML or otherwise invalid characters are not decoded. Note that, in HTML5, U+000D is a valid literal character, but the entity &#x0D is not valid and is therefore not decoded. - The hash tables lazily created for decoding in html_entity_decode() that were added recently were substituted by static hash tables. Instead of 1 hash table per encoding, there's only one hash table per document type defined in terms of unicode code points. This means that for charsets other than UTF-8 and ISO-8859-1, a conversion to unicode code points is necessary before decoding. - On the encoding side, the ad hoc ranges of entities of the translation tables, which mapped (in general) non-unicode code points to HTML entities were replaced by three-stage tables for HTML 4 and HTML 5. This mapping tables are defined only in terms of unicode code points, so a conversion is necessary for charsets other than UTF-8 and ISO-8859-1. Even so, the multi-stage table is much faster than the previous method, by a factor of 5; the conversion to unicode is a small penalty because it's just a simple table lookup. XML 1.0/htmlspecialchars() uses a simple table instead of a three-stage table. - Added the flag ENT_SUBSTITUTE, which makes htmlentities()/htmlspecialchars() replace the invalid multibyte sequences with U+FFFD (UTF-8) or &#FFFD; (other encodings). - Added the flag ENT_DISALLOWED. Implements FR #52860. Characters that cannot appear literally are replaced by U+FFFD (UTF-8) or &#FFFD; (otherwise). An alternative implementation would be to encode those characters into numerical entities, but that would only work in HTML 4.01 due to limitations on the values of numerical entities in other document types. See also the effects on htmlentities()/htmlspecialchars() with !double_encode above.
2010-10-24 15:01:02 +00:00
["<"]=>
string(4) "&lt;"
["""]=>
string(6) "&quot;"
New testcases for get_html_translation_table() function
2007-10-08 15:21:13 +00:00
}
array(4) {
- Added a 3rd parameter to get_html_translation_table. It now takes a charset hint, like htmlentities et al. - Fixed bug #49407 (get_html_translation_table doesn't handle UTF-8). - Fixed bug #25927 (get_html_translation_table calls the ' &#39; instead of &#039;). - Fixed tests for get_html_translation_table and unified the Windows and non-Windows versions of the tests.
2010-10-12 02:51:11 +00:00
["&"]=>
string(5) "&amp;"
New testcases for get_html_translation_table() function
2007-10-08 15:21:13 +00:00
[">"]=>
string(4) "&gt;"
- Completed rewrite of html.c. Except for determine_charset, almost nothing remains. - Fixed bug on determine_charset that was preventing correct detection in combination with internal mbstring encoding "none", "pass" or "auto". - Added profiles for entity encode/decode for HTMl 4.01, XHTML 1.0, XML 1.0 and HTML 5. Added the constants ENT_HTML401, ENT_XML1, ENT_XHTML and ENT_HTML5. - htmlentities()/htmlspecialchars(), when told not to double encode, verify the correctness of the existenting entities more thoroughly. It is checked whether the numerical entity represents a valid unicode code point (number is between 0 and 0x10FFFF). If using the flag ENT_DISALLOWED, it is also checked whether that numerical entity is valid in selected document. In HTML 4.01, all the numerical entities that represent a Unicode code point (< U+10FFFFFF) are valid, but that's not the case with other document types. If the entity is not valid, & is encoded to &amp;. For named entities, the check is also more thorough. While before the only check would be to determine if the entity was constituted by alphanumeric characters, now it is checked whether that entity is necessarily defined for the target document type. Otherwise, & is encoded to &amp;. - For html_entity_decode(), only valid numerical and named entities (as defined above for htmlentities()/htmlspecialchars() + !double_encode) are decoded. But there is in this case one additional check. Entities that represent non-SGML or otherwise invalid characters are not decoded. Note that, in HTML5, U+000D is a valid literal character, but the entity &#x0D is not valid and is therefore not decoded. - The hash tables lazily created for decoding in html_entity_decode() that were added recently were substituted by static hash tables. Instead of 1 hash table per encoding, there's only one hash table per document type defined in terms of unicode code points. This means that for charsets other than UTF-8 and ISO-8859-1, a conversion to unicode code points is necessary before decoding. - On the encoding side, the ad hoc ranges of entities of the translation tables, which mapped (in general) non-unicode code points to HTML entities were replaced by three-stage tables for HTML 4 and HTML 5. This mapping tables are defined only in terms of unicode code points, so a conversion is necessary for charsets other than UTF-8 and ISO-8859-1. Even so, the multi-stage table is much faster than the previous method, by a factor of 5; the conversion to unicode is a small penalty because it's just a simple table lookup. XML 1.0/htmlspecialchars() uses a simple table instead of a three-stage table. - Added the flag ENT_SUBSTITUTE, which makes htmlentities()/htmlspecialchars() replace the invalid multibyte sequences with U+FFFD (UTF-8) or &#FFFD; (other encodings). - Added the flag ENT_DISALLOWED. Implements FR #52860. Characters that cannot appear literally are replaced by U+FFFD (UTF-8) or &#FFFD; (otherwise). An alternative implementation would be to encode those characters into numerical entities, but that would only work in HTML 4.01 due to limitations on the values of numerical entities in other document types. See also the effects on htmlentities()/htmlspecialchars() with !double_encode above.
2010-10-24 15:01:02 +00:00
["<"]=>
string(4) "&lt;"
["""]=>
string(6) "&quot;"
New testcases for get_html_translation_table() function
2007-10-08 15:21:13 +00:00
}
-- Iteration 16 --
array(4) {
- Added a 3rd parameter to get_html_translation_table. It now takes a charset hint, like htmlentities et al. - Fixed bug #49407 (get_html_translation_table doesn't handle UTF-8). - Fixed bug #25927 (get_html_translation_table calls the ' &#39; instead of &#039;). - Fixed tests for get_html_translation_table and unified the Windows and non-Windows versions of the tests.
2010-10-12 02:51:11 +00:00
["&"]=>
string(5) "&amp;"
New testcases for get_html_translation_table() function
2007-10-08 15:21:13 +00:00
[">"]=>
string(4) "&gt;"
- Completed rewrite of html.c. Except for determine_charset, almost nothing remains. - Fixed bug on determine_charset that was preventing correct detection in combination with internal mbstring encoding "none", "pass" or "auto". - Added profiles for entity encode/decode for HTMl 4.01, XHTML 1.0, XML 1.0 and HTML 5. Added the constants ENT_HTML401, ENT_XML1, ENT_XHTML and ENT_HTML5. - htmlentities()/htmlspecialchars(), when told not to double encode, verify the correctness of the existenting entities more thoroughly. It is checked whether the numerical entity represents a valid unicode code point (number is between 0 and 0x10FFFF). If using the flag ENT_DISALLOWED, it is also checked whether that numerical entity is valid in selected document. In HTML 4.01, all the numerical entities that represent a Unicode code point (< U+10FFFFFF) are valid, but that's not the case with other document types. If the entity is not valid, & is encoded to &amp;. For named entities, the check is also more thorough. While before the only check would be to determine if the entity was constituted by alphanumeric characters, now it is checked whether that entity is necessarily defined for the target document type. Otherwise, & is encoded to &amp;. - For html_entity_decode(), only valid numerical and named entities (as defined above for htmlentities()/htmlspecialchars() + !double_encode) are decoded. But there is in this case one additional check. Entities that represent non-SGML or otherwise invalid characters are not decoded. Note that, in HTML5, U+000D is a valid literal character, but the entity &#x0D is not valid and is therefore not decoded. - The hash tables lazily created for decoding in html_entity_decode() that were added recently were substituted by static hash tables. Instead of 1 hash table per encoding, there's only one hash table per document type defined in terms of unicode code points. This means that for charsets other than UTF-8 and ISO-8859-1, a conversion to unicode code points is necessary before decoding. - On the encoding side, the ad hoc ranges of entities of the translation tables, which mapped (in general) non-unicode code points to HTML entities were replaced by three-stage tables for HTML 4 and HTML 5. This mapping tables are defined only in terms of unicode code points, so a conversion is necessary for charsets other than UTF-8 and ISO-8859-1. Even so, the multi-stage table is much faster than the previous method, by a factor of 5; the conversion to unicode is a small penalty because it's just a simple table lookup. XML 1.0/htmlspecialchars() uses a simple table instead of a three-stage table. - Added the flag ENT_SUBSTITUTE, which makes htmlentities()/htmlspecialchars() replace the invalid multibyte sequences with U+FFFD (UTF-8) or &#FFFD; (other encodings). - Added the flag ENT_DISALLOWED. Implements FR #52860. Characters that cannot appear literally are replaced by U+FFFD (UTF-8) or &#FFFD; (otherwise). An alternative implementation would be to encode those characters into numerical entities, but that would only work in HTML 4.01 due to limitations on the values of numerical entities in other document types. See also the effects on htmlentities()/htmlspecialchars() with !double_encode above.
2010-10-24 15:01:02 +00:00
["<"]=>
string(4) "&lt;"
["""]=>
string(6) "&quot;"
New testcases for get_html_translation_table() function
2007-10-08 15:21:13 +00:00
}
array(4) {
- Added a 3rd parameter to get_html_translation_table. It now takes a charset hint, like htmlentities et al. - Fixed bug #49407 (get_html_translation_table doesn't handle UTF-8). - Fixed bug #25927 (get_html_translation_table calls the ' &#39; instead of &#039;). - Fixed tests for get_html_translation_table and unified the Windows and non-Windows versions of the tests.
2010-10-12 02:51:11 +00:00
["&"]=>
string(5) "&amp;"
New testcases for get_html_translation_table() function
2007-10-08 15:21:13 +00:00
[">"]=>
string(4) "&gt;"
- Completed rewrite of html.c. Except for determine_charset, almost nothing remains. - Fixed bug on determine_charset that was preventing correct detection in combination with internal mbstring encoding "none", "pass" or "auto". - Added profiles for entity encode/decode for HTMl 4.01, XHTML 1.0, XML 1.0 and HTML 5. Added the constants ENT_HTML401, ENT_XML1, ENT_XHTML and ENT_HTML5. - htmlentities()/htmlspecialchars(), when told not to double encode, verify the correctness of the existenting entities more thoroughly. It is checked whether the numerical entity represents a valid unicode code point (number is between 0 and 0x10FFFF). If using the flag ENT_DISALLOWED, it is also checked whether that numerical entity is valid in selected document. In HTML 4.01, all the numerical entities that represent a Unicode code point (< U+10FFFFFF) are valid, but that's not the case with other document types. If the entity is not valid, & is encoded to &amp;. For named entities, the check is also more thorough. While before the only check would be to determine if the entity was constituted by alphanumeric characters, now it is checked whether that entity is necessarily defined for the target document type. Otherwise, & is encoded to &amp;. - For html_entity_decode(), only valid numerical and named entities (as defined above for htmlentities()/htmlspecialchars() + !double_encode) are decoded. But there is in this case one additional check. Entities that represent non-SGML or otherwise invalid characters are not decoded. Note that, in HTML5, U+000D is a valid literal character, but the entity &#x0D is not valid and is therefore not decoded. - The hash tables lazily created for decoding in html_entity_decode() that were added recently were substituted by static hash tables. Instead of 1 hash table per encoding, there's only one hash table per document type defined in terms of unicode code points. This means that for charsets other than UTF-8 and ISO-8859-1, a conversion to unicode code points is necessary before decoding. - On the encoding side, the ad hoc ranges of entities of the translation tables, which mapped (in general) non-unicode code points to HTML entities were replaced by three-stage tables for HTML 4 and HTML 5. This mapping tables are defined only in terms of unicode code points, so a conversion is necessary for charsets other than UTF-8 and ISO-8859-1. Even so, the multi-stage table is much faster than the previous method, by a factor of 5; the conversion to unicode is a small penalty because it's just a simple table lookup. XML 1.0/htmlspecialchars() uses a simple table instead of a three-stage table. - Added the flag ENT_SUBSTITUTE, which makes htmlentities()/htmlspecialchars() replace the invalid multibyte sequences with U+FFFD (UTF-8) or &#FFFD; (other encodings). - Added the flag ENT_DISALLOWED. Implements FR #52860. Characters that cannot appear literally are replaced by U+FFFD (UTF-8) or &#FFFD; (otherwise). An alternative implementation would be to encode those characters into numerical entities, but that would only work in HTML 4.01 due to limitations on the values of numerical entities in other document types. See also the effects on htmlentities()/htmlspecialchars() with !double_encode above.
2010-10-24 15:01:02 +00:00
["<"]=>
string(4) "&lt;"
["""]=>
string(6) "&quot;"
New testcases for get_html_translation_table() function
2007-10-08 15:21:13 +00:00
}
-- Iteration 17 --
Switch default_charset, if not specified, from ISO-8859-1 to UTF-8 I have been wanting to make this change for years, but there is a small chance of BC issues, so it shouldn't go into a minor release.
2010-03-23 18:08:06 +00:00
Warning: get_html_translation_table() expects parameter 1 to be long, resource given in %s on line %d
New testcases for get_html_translation_table() function
2007-10-08 15:21:13 +00:00
NULL
Switch default_charset, if not specified, from ISO-8859-1 to UTF-8 I have been wanting to make this change for years, but there is a small chance of BC issues, so it shouldn't go into a minor release.
2010-03-23 18:08:06 +00:00
Warning: get_html_translation_table() expects parameter 1 to be long, resource given in %s on line %d
New testcases for get_html_translation_table() function
2007-10-08 15:21:13 +00:00
NULL
-- Iteration 18 --
array(4) {
- Added a 3rd parameter to get_html_translation_table. It now takes a charset hint, like htmlentities et al. - Fixed bug #49407 (get_html_translation_table doesn't handle UTF-8). - Fixed bug #25927 (get_html_translation_table calls the ' &#39; instead of &#039;). - Fixed tests for get_html_translation_table and unified the Windows and non-Windows versions of the tests.
2010-10-12 02:51:11 +00:00
["&"]=>
string(5) "&amp;"
New testcases for get_html_translation_table() function
2007-10-08 15:21:13 +00:00
[">"]=>
string(4) "&gt;"
- Completed rewrite of html.c. Except for determine_charset, almost nothing remains. - Fixed bug on determine_charset that was preventing correct detection in combination with internal mbstring encoding "none", "pass" or "auto". - Added profiles for entity encode/decode for HTMl 4.01, XHTML 1.0, XML 1.0 and HTML 5. Added the constants ENT_HTML401, ENT_XML1, ENT_XHTML and ENT_HTML5. - htmlentities()/htmlspecialchars(), when told not to double encode, verify the correctness of the existenting entities more thoroughly. It is checked whether the numerical entity represents a valid unicode code point (number is between 0 and 0x10FFFF). If using the flag ENT_DISALLOWED, it is also checked whether that numerical entity is valid in selected document. In HTML 4.01, all the numerical entities that represent a Unicode code point (< U+10FFFFFF) are valid, but that's not the case with other document types. If the entity is not valid, & is encoded to &amp;. For named entities, the check is also more thorough. While before the only check would be to determine if the entity was constituted by alphanumeric characters, now it is checked whether that entity is necessarily defined for the target document type. Otherwise, & is encoded to &amp;. - For html_entity_decode(), only valid numerical and named entities (as defined above for htmlentities()/htmlspecialchars() + !double_encode) are decoded. But there is in this case one additional check. Entities that represent non-SGML or otherwise invalid characters are not decoded. Note that, in HTML5, U+000D is a valid literal character, but the entity &#x0D is not valid and is therefore not decoded. - The hash tables lazily created for decoding in html_entity_decode() that were added recently were substituted by static hash tables. Instead of 1 hash table per encoding, there's only one hash table per document type defined in terms of unicode code points. This means that for charsets other than UTF-8 and ISO-8859-1, a conversion to unicode code points is necessary before decoding. - On the encoding side, the ad hoc ranges of entities of the translation tables, which mapped (in general) non-unicode code points to HTML entities were replaced by three-stage tables for HTML 4 and HTML 5. This mapping tables are defined only in terms of unicode code points, so a conversion is necessary for charsets other than UTF-8 and ISO-8859-1. Even so, the multi-stage table is much faster than the previous method, by a factor of 5; the conversion to unicode is a small penalty because it's just a simple table lookup. XML 1.0/htmlspecialchars() uses a simple table instead of a three-stage table. - Added the flag ENT_SUBSTITUTE, which makes htmlentities()/htmlspecialchars() replace the invalid multibyte sequences with U+FFFD (UTF-8) or &#FFFD; (other encodings). - Added the flag ENT_DISALLOWED. Implements FR #52860. Characters that cannot appear literally are replaced by U+FFFD (UTF-8) or &#FFFD; (otherwise). An alternative implementation would be to encode those characters into numerical entities, but that would only work in HTML 4.01 due to limitations on the values of numerical entities in other document types. See also the effects on htmlentities()/htmlspecialchars() with !double_encode above.
2010-10-24 15:01:02 +00:00
["<"]=>
string(4) "&lt;"
["""]=>
string(6) "&quot;"
New testcases for get_html_translation_table() function
2007-10-08 15:21:13 +00:00
}
array(4) {
- Added a 3rd parameter to get_html_translation_table. It now takes a charset hint, like htmlentities et al. - Fixed bug #49407 (get_html_translation_table doesn't handle UTF-8). - Fixed bug #25927 (get_html_translation_table calls the ' &#39; instead of &#039;). - Fixed tests for get_html_translation_table and unified the Windows and non-Windows versions of the tests.
2010-10-12 02:51:11 +00:00
["&"]=>
string(5) "&amp;"
New testcases for get_html_translation_table() function
2007-10-08 15:21:13 +00:00
[">"]=>
string(4) "&gt;"
- Completed rewrite of html.c. Except for determine_charset, almost nothing remains. - Fixed bug on determine_charset that was preventing correct detection in combination with internal mbstring encoding "none", "pass" or "auto". - Added profiles for entity encode/decode for HTMl 4.01, XHTML 1.0, XML 1.0 and HTML 5. Added the constants ENT_HTML401, ENT_XML1, ENT_XHTML and ENT_HTML5. - htmlentities()/htmlspecialchars(), when told not to double encode, verify the correctness of the existenting entities more thoroughly. It is checked whether the numerical entity represents a valid unicode code point (number is between 0 and 0x10FFFF). If using the flag ENT_DISALLOWED, it is also checked whether that numerical entity is valid in selected document. In HTML 4.01, all the numerical entities that represent a Unicode code point (< U+10FFFFFF) are valid, but that's not the case with other document types. If the entity is not valid, & is encoded to &amp;. For named entities, the check is also more thorough. While before the only check would be to determine if the entity was constituted by alphanumeric characters, now it is checked whether that entity is necessarily defined for the target document type. Otherwise, & is encoded to &amp;. - For html_entity_decode(), only valid numerical and named entities (as defined above for htmlentities()/htmlspecialchars() + !double_encode) are decoded. But there is in this case one additional check. Entities that represent non-SGML or otherwise invalid characters are not decoded. Note that, in HTML5, U+000D is a valid literal character, but the entity &#x0D is not valid and is therefore not decoded. - The hash tables lazily created for decoding in html_entity_decode() that were added recently were substituted by static hash tables. Instead of 1 hash table per encoding, there's only one hash table per document type defined in terms of unicode code points. This means that for charsets other than UTF-8 and ISO-8859-1, a conversion to unicode code points is necessary before decoding. - On the encoding side, the ad hoc ranges of entities of the translation tables, which mapped (in general) non-unicode code points to HTML entities were replaced by three-stage tables for HTML 4 and HTML 5. This mapping tables are defined only in terms of unicode code points, so a conversion is necessary for charsets other than UTF-8 and ISO-8859-1. Even so, the multi-stage table is much faster than the previous method, by a factor of 5; the conversion to unicode is a small penalty because it's just a simple table lookup. XML 1.0/htmlspecialchars() uses a simple table instead of a three-stage table. - Added the flag ENT_SUBSTITUTE, which makes htmlentities()/htmlspecialchars() replace the invalid multibyte sequences with U+FFFD (UTF-8) or &#FFFD; (other encodings). - Added the flag ENT_DISALLOWED. Implements FR #52860. Characters that cannot appear literally are replaced by U+FFFD (UTF-8) or &#FFFD; (otherwise). An alternative implementation would be to encode those characters into numerical entities, but that would only work in HTML 4.01 due to limitations on the values of numerical entities in other document types. See also the effects on htmlentities()/htmlspecialchars() with !double_encode above.
2010-10-24 15:01:02 +00:00
["<"]=>
string(4) "&lt;"
["""]=>
string(6) "&quot;"
New testcases for get_html_translation_table() function
2007-10-08 15:21:13 +00:00
}
-- Iteration 19 --
array(4) {
- Added a 3rd parameter to get_html_translation_table. It now takes a charset hint, like htmlentities et al. - Fixed bug #49407 (get_html_translation_table doesn't handle UTF-8). - Fixed bug #25927 (get_html_translation_table calls the ' &#39; instead of &#039;). - Fixed tests for get_html_translation_table and unified the Windows and non-Windows versions of the tests.
2010-10-12 02:51:11 +00:00
["&"]=>
string(5) "&amp;"
New testcases for get_html_translation_table() function
2007-10-08 15:21:13 +00:00
[">"]=>
string(4) "&gt;"
- Completed rewrite of html.c. Except for determine_charset, almost nothing remains. - Fixed bug on determine_charset that was preventing correct detection in combination with internal mbstring encoding "none", "pass" or "auto". - Added profiles for entity encode/decode for HTMl 4.01, XHTML 1.0, XML 1.0 and HTML 5. Added the constants ENT_HTML401, ENT_XML1, ENT_XHTML and ENT_HTML5. - htmlentities()/htmlspecialchars(), when told not to double encode, verify the correctness of the existenting entities more thoroughly. It is checked whether the numerical entity represents a valid unicode code point (number is between 0 and 0x10FFFF). If using the flag ENT_DISALLOWED, it is also checked whether that numerical entity is valid in selected document. In HTML 4.01, all the numerical entities that represent a Unicode code point (< U+10FFFFFF) are valid, but that's not the case with other document types. If the entity is not valid, & is encoded to &amp;. For named entities, the check is also more thorough. While before the only check would be to determine if the entity was constituted by alphanumeric characters, now it is checked whether that entity is necessarily defined for the target document type. Otherwise, & is encoded to &amp;. - For html_entity_decode(), only valid numerical and named entities (as defined above for htmlentities()/htmlspecialchars() + !double_encode) are decoded. But there is in this case one additional check. Entities that represent non-SGML or otherwise invalid characters are not decoded. Note that, in HTML5, U+000D is a valid literal character, but the entity &#x0D is not valid and is therefore not decoded. - The hash tables lazily created for decoding in html_entity_decode() that were added recently were substituted by static hash tables. Instead of 1 hash table per encoding, there's only one hash table per document type defined in terms of unicode code points. This means that for charsets other than UTF-8 and ISO-8859-1, a conversion to unicode code points is necessary before decoding. - On the encoding side, the ad hoc ranges of entities of the translation tables, which mapped (in general) non-unicode code points to HTML entities were replaced by three-stage tables for HTML 4 and HTML 5. This mapping tables are defined only in terms of unicode code points, so a conversion is necessary for charsets other than UTF-8 and ISO-8859-1. Even so, the multi-stage table is much faster than the previous method, by a factor of 5; the conversion to unicode is a small penalty because it's just a simple table lookup. XML 1.0/htmlspecialchars() uses a simple table instead of a three-stage table. - Added the flag ENT_SUBSTITUTE, which makes htmlentities()/htmlspecialchars() replace the invalid multibyte sequences with U+FFFD (UTF-8) or &#FFFD; (other encodings). - Added the flag ENT_DISALLOWED. Implements FR #52860. Characters that cannot appear literally are replaced by U+FFFD (UTF-8) or &#FFFD; (otherwise). An alternative implementation would be to encode those characters into numerical entities, but that would only work in HTML 4.01 due to limitations on the values of numerical entities in other document types. See also the effects on htmlentities()/htmlspecialchars() with !double_encode above.
2010-10-24 15:01:02 +00:00
["<"]=>
string(4) "&lt;"
["""]=>
string(6) "&quot;"
New testcases for get_html_translation_table() function
2007-10-08 15:21:13 +00:00
}
array(4) {
- Added a 3rd parameter to get_html_translation_table. It now takes a charset hint, like htmlentities et al. - Fixed bug #49407 (get_html_translation_table doesn't handle UTF-8). - Fixed bug #25927 (get_html_translation_table calls the ' &#39; instead of &#039;). - Fixed tests for get_html_translation_table and unified the Windows and non-Windows versions of the tests.
2010-10-12 02:51:11 +00:00
["&"]=>
string(5) "&amp;"
New testcases for get_html_translation_table() function
2007-10-08 15:21:13 +00:00
[">"]=>
string(4) "&gt;"
- Completed rewrite of html.c. Except for determine_charset, almost nothing remains. - Fixed bug on determine_charset that was preventing correct detection in combination with internal mbstring encoding "none", "pass" or "auto". - Added profiles for entity encode/decode for HTMl 4.01, XHTML 1.0, XML 1.0 and HTML 5. Added the constants ENT_HTML401, ENT_XML1, ENT_XHTML and ENT_HTML5. - htmlentities()/htmlspecialchars(), when told not to double encode, verify the correctness of the existenting entities more thoroughly. It is checked whether the numerical entity represents a valid unicode code point (number is between 0 and 0x10FFFF). If using the flag ENT_DISALLOWED, it is also checked whether that numerical entity is valid in selected document. In HTML 4.01, all the numerical entities that represent a Unicode code point (< U+10FFFFFF) are valid, but that's not the case with other document types. If the entity is not valid, & is encoded to &amp;. For named entities, the check is also more thorough. While before the only check would be to determine if the entity was constituted by alphanumeric characters, now it is checked whether that entity is necessarily defined for the target document type. Otherwise, & is encoded to &amp;. - For html_entity_decode(), only valid numerical and named entities (as defined above for htmlentities()/htmlspecialchars() + !double_encode) are decoded. But there is in this case one additional check. Entities that represent non-SGML or otherwise invalid characters are not decoded. Note that, in HTML5, U+000D is a valid literal character, but the entity &#x0D is not valid and is therefore not decoded. - The hash tables lazily created for decoding in html_entity_decode() that were added recently were substituted by static hash tables. Instead of 1 hash table per encoding, there's only one hash table per document type defined in terms of unicode code points. This means that for charsets other than UTF-8 and ISO-8859-1, a conversion to unicode code points is necessary before decoding. - On the encoding side, the ad hoc ranges of entities of the translation tables, which mapped (in general) non-unicode code points to HTML entities were replaced by three-stage tables for HTML 4 and HTML 5. This mapping tables are defined only in terms of unicode code points, so a conversion is necessary for charsets other than UTF-8 and ISO-8859-1. Even so, the multi-stage table is much faster than the previous method, by a factor of 5; the conversion to unicode is a small penalty because it's just a simple table lookup. XML 1.0/htmlspecialchars() uses a simple table instead of a three-stage table. - Added the flag ENT_SUBSTITUTE, which makes htmlentities()/htmlspecialchars() replace the invalid multibyte sequences with U+FFFD (UTF-8) or &#FFFD; (other encodings). - Added the flag ENT_DISALLOWED. Implements FR #52860. Characters that cannot appear literally are replaced by U+FFFD (UTF-8) or &#FFFD; (otherwise). An alternative implementation would be to encode those characters into numerical entities, but that would only work in HTML 4.01 due to limitations on the values of numerical entities in other document types. See also the effects on htmlentities()/htmlspecialchars() with !double_encode above.
2010-10-24 15:01:02 +00:00
["<"]=>
string(4) "&lt;"
["""]=>
string(6) "&quot;"
New testcases for get_html_translation_table() function
2007-10-08 15:21:13 +00:00
}
Done
Reference in New Issue Copy Permalink