Remove unnecessary PHPDoc-alike blocks from tests

Closes GH-5759

Convert CRLF line endings to LF

This patch simplifies line endings tracked in the Git repository and
syncs them to all include the LF style instead of the CRLF files.

Newline ch

Convert CRLF line endings to LF

This patch simplifies line endings tracked in the Git repository and
syncs them to all include the LF style instead of the CRLF files.

Newline characters:
- LF (\n) (*nix and Mac)
- CRLF (\r\n) (Windows)
- CR (\r) (old Mac, obsolete)

To see which line endings are in the index and in the working copy the
following command can be used:
`git ls-files --eol`

Git additionally provides `.gitattributes` file to specify if some files
need to have specific line endings on all platforms (either CRLF or LF).

Changed files shouldn't cause issues on modern Windows platforms because
also Git can do output conversion is core.autocrlf=true is set on
Windows and use CRLF newlines in all files in the working tree.

Unless CRLF files are tracked specifically, Git by default tracks all
files in the index using LF newlines.

show more ...

Fix CRLF line-endings in tests

Also fix a single instance of CRLF in ibase_query.c.

- 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 interna

- 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.

show more ...

- 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).
- Fixe

- 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.

show more ...

- 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).
- Fixe

- 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.

show more ...

- Revamp of the decoding portion of html.c.
- Dramatic improvements on the performance of html_entity_decode and htmlspecialchars_decode, as the
string is now traversed only once. Speedups

- Revamp of the decoding portion of html.c.
- Dramatic improvements on the performance of html_entity_decode and htmlspecialchars_decode, as the
string is now traversed only once. Speedups of 20 to 25 times with Windows release builds and a
~250 characters string (for 2nd and subsequent calls).
- Consistent behavior on html_entity_decode. For instance, the entity in "&&lt;" would be decoded,
but not "&&#233;". Not anymore. The code path for "basic" and non-basic entities is now mostly
shared.
- Code of html_entity_decode and htmlspecialchars_decode is now shared.
- [DOC] More consistent behavior of htmlspecialchars_decode. Instead of translating only &lt;, &gt;,
&amp;, &quot;, &#039; and &#39;, now e.g. &#34;, &apos;, &#0039;, &#x27;, etc. are also decoded.
- [DOC] Previous translation of unicode code points in numerical entities was seriously broken. When
the code points for some character were not the same in unicode and the target encoding, the
behavior could be an erroneous translation (e.g. 0x80-0xA0 in win-1252) or no translation at all.
Added unicode translation tables for all single-byte encodings. Entities are not translated for
multi-byte entities, except for ASCII characters whose code points are shared. We could add
the huge translation tables (several thousand elements) for those encodings in the future.
- Fixed numerical entities that after # had text accepted by strcol being accepted.
- Much more commented and well-structured code...
- Tests for get_html_translation_table()) are broken. I stared fixing the tests, but then I realized
it was completely helpless because get_html_translation_table() is broken by not handling
multi-byte characters correctly.

show more ...

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

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.

show more ...

New testcases for get_html_translation_table() function