php-src/ext/standard/tests/strings/get_html_translation_table_basic6.phpt

250 lines
5.1 KiB
Plaintext
Raw Normal View History

- 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
--TEST--
Test get_html_translation_table() function : basic functionality - HTML 5/Windows-1251
--FILE--
<?php
function so($a,$b) { return ord($a) - ord($b); }
echo "*** Testing get_html_translation_table() : basic functionality - HTML 5/Windows-1251 ***\n";
echo "-- with table = HTML_ENTITIES, ENT_COMPAT --\n";
$table = HTML_ENTITIES;
$tt = get_html_translation_table($table, ENT_COMPAT | ENT_HTML5, "Windows-1251");
uksort( $tt, 'so' );
var_dump( count($tt) );
print_r( $tt );
echo "-- with table = HTML_ENTITIES, ENT_QUOTES --\n";
$table = HTML_ENTITIES;
$tt = get_html_translation_table($table, ENT_QUOTES | ENT_HTML5, "Windows-1251");
var_dump( count($tt) );
echo "-- with table = HTML_ENTITIES, ENT_NOQUOTES --\n";
$table = HTML_ENTITIES;
$tt = get_html_translation_table($table, ENT_NOQUOTES | ENT_HTML5, "Windows-1251");
var_dump( count($tt) );
echo "-- with table = HTML_SPECIALCHARS, ENT_COMPAT --\n";
2018-10-14 16:03:31 +00:00
$table = HTML_SPECIALCHARS;
- 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
$tt = get_html_translation_table($table, ENT_COMPAT, "Windows-1251");
uksort( $tt, 'so' );
var_dump( count($tt) );
print_r( $tt );
echo "-- with table = HTML_SPECIALCHARS, ENT_QUOTES --\n";
$table = HTML_SPECIALCHARS;
$tt = get_html_translation_table($table, ENT_QUOTES | ENT_HTML5, "Windows-1251");
uksort( $tt, 'so' );
var_dump( $tt );
echo "-- with table = HTML_SPECIALCHARS, ENT_NOQUOTES --\n";
$table = HTML_SPECIALCHARS;
$tt = get_html_translation_table($table, ENT_NOQUOTES | ENT_HTML5, "Windows-1251");
uasort( $tt, 'so' );
var_dump( $tt );
echo "Done\n";
?>
--EXPECT--
*** Testing get_html_translation_table() : basic functionality - HTML 5/Windows-1251 ***
-- with table = HTML_ENTITIES, ENT_COMPAT --
int(157)
Array
(
[ ] => &Tab;
[
] => &NewLine;
[!] => &excl;
["] => &quot;
[#] => &num;
[$] => &dollar;
[%] => &percnt;
[&] => &amp;
[(] => &lpar;
[)] => &rpar;
[*] => &ast;
[+] => &plus;
[,] => &comma;
[.] => &period;
[/] => &sol;
[:] => &colon;
[;] => &semi;
[<] => &lt;
[=] => &equals;
[>] => &gt;
[?] => &quest;
[@] => &commat;
[[] => &lbrack;
[\] => &bsol;
[]] => &rsqb;
[^] => &Hat;
[_] => &lowbar;
[`] => &grave;
[fj] => &fjlig;
- 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
[{] => &lbrace;
[|] => &vert;
[}] => &rcub;
[<5B>] => &DJcy;
[<5B>] => &GJcy;
[<5B>] => &sbquo;
[<5B>] => &gjcy;
[<5B>] => &bdquo;
[<5B>] => &hellip;
[<5B>] => &dagger;
[<5B>] => &Dagger;
[<5B>] => &euro;
[<5B>] => &permil;
[<5B>] => &LJcy;
[<5B>] => &lsaquo;
[<5B>] => &NJcy;
[<5B>] => &KJcy;
[<5B>] => &TSHcy;
[<5B>] => &DZcy;
[<5B>] => &djcy;
[<5B>] => &OpenCurlyQuote;
[<5B>] => &rsquo;
[<5B>] => &OpenCurlyDoubleQuote;
[<5B>] => &rdquo;
[<5B>] => &bull;
[<5B>] => &ndash;
[<5B>] => &mdash;
[<5B>] => &trade;
[<5B>] => &ljcy;
[<5B>] => &rsaquo;
[<5B>] => &njcy;
[<5B>] => &kjcy;
[<5B>] => &tshcy;
[<5B>] => &dzcy;
[<5B>] => &nbsp;
[<5B>] => &Ubrcy;
[<5B>] => &ubrcy;
[<5B>] => &Jsercy;
[<5B>] => &curren;
[<5B>] => &brvbar;
[<5B>] => &sect;
[<5B>] => &IOcy;
[<5B>] => &copy;
[<5B>] => &Jukcy;
[<5B>] => &laquo;
[<5B>] => &not;
[<5B>] => &shy;
[<5B>] => &reg;
[<5B>] => &YIcy;
[<5B>] => &deg;
[<5B>] => &plusmn;
[<5B>] => &Iukcy;
[<5B>] => &iukcy;
[<5B>] => &micro;
[<5B>] => &para;
[<5B>] => &CenterDot;
[<5B>] => &iocy;
[<5B>] => &numero;
[<5B>] => &jukcy;
[<5B>] => &raquo;
[<5B>] => &jsercy;
[<5B>] => &DScy;
[<5B>] => &dscy;
[<5B>] => &yicy;
[<5B>] => &Acy;
[<5B>] => &Bcy;
[<5B>] => &Vcy;
[<5B>] => &Gcy;
[<5B>] => &Dcy;
[<5B>] => &IEcy;
[<5B>] => &ZHcy;
[<5B>] => &Zcy;
[<5B>] => &Icy;
[<5B>] => &Jcy;
[<5B>] => &Kcy;
[<5B>] => &Lcy;
[<5B>] => &Mcy;
[<5B>] => &Ncy;
[<5B>] => &Ocy;
[<5B>] => &Pcy;
[<5B>] => &Rcy;
[<5B>] => &Scy;
[<5B>] => &Tcy;
[<5B>] => &Ucy;
[<5B>] => &Fcy;
[<5B>] => &KHcy;
[<5B>] => &TScy;
[<5B>] => &CHcy;
[<5B>] => &SHcy;
[<5B>] => &SHCHcy;
[<5B>] => &HARDcy;
[<5B>] => &Ycy;
[<5B>] => &SOFTcy;
[<5B>] => &Ecy;
[<5B>] => &YUcy;
[<5B>] => &YAcy;
[<5B>] => &acy;
[<5B>] => &bcy;
[<5B>] => &vcy;
[<5B>] => &gcy;
[<5B>] => &dcy;
[<5B>] => &iecy;
[<5B>] => &zhcy;
[<5B>] => &zcy;
[<5B>] => &icy;
[<5B>] => &jcy;
[<5B>] => &kcy;
[<5B>] => &lcy;
[<5B>] => &mcy;
[<5B>] => &ncy;
[<5B>] => &ocy;
[<5B>] => &pcy;
[<5B>] => &rcy;
[<5B>] => &scy;
[<5B>] => &tcy;
[<5B>] => &ucy;
[<5B>] => &fcy;
[<5B>] => &khcy;
[<5B>] => &tscy;
[<5B>] => &chcy;
[<5B>] => &shcy;
[<5B>] => &shchcy;
[<5B>] => &hardcy;
[<5B>] => &ycy;
[<5B>] => &softcy;
[<5B>] => &ecy;
[<5B>] => &yucy;
[<5B>] => &yacy;
)
-- with table = HTML_ENTITIES, ENT_QUOTES --
int(158)
-- with table = HTML_ENTITIES, ENT_NOQUOTES --
int(156)
-- with table = HTML_SPECIALCHARS, ENT_COMPAT --
int(4)
Array
(
["] => &quot;
[&] => &amp;
[<] => &lt;
[>] => &gt;
)
-- with table = HTML_SPECIALCHARS, ENT_QUOTES --
array(5) {
["""]=>
string(6) "&quot;"
["&"]=>
string(5) "&amp;"
["'"]=>
string(6) "&apos;"
["<"]=>
string(4) "&lt;"
[">"]=>
string(4) "&gt;"
}
-- with table = HTML_SPECIALCHARS, ENT_NOQUOTES --
array(3) {
["&"]=>
string(5) "&amp;"
2015-01-14 09:22:58 +00:00
["<"]=>
string(4) "&lt;"
[">"]=>
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
}
Done