Req #47875 [Ver->Csd]: No option to set HTML input encoding

From: Date: Mon, 13 Nov 2023 21:16:19 +0000
Subject: Req #47875 [Ver->Csd]: No option to set HTML input encoding
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-245797@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=47875&edit=1

 ID:                 47875
 Updated by:         nielsdos@php.net
 Reported by:        thomas dot koch at ymc dot ch
 Summary:            No option to set HTML input encoding
-Status:             Verified
+Status:             Closed
 Type:               Feature/Change Request
 Package:            DOM XML related
 Operating System:   Debian Lenny
 PHP Version:        5.2.9
-Assigned To:        
+Assigned To:        nielsdos
 Block user comment: N
 Private report:     N

 New Comment:

The fix for this bug has been committed.
If you are still experiencing this bug, try to check out latest source from https://github.com/php/php-src and re-test.
Thank you for the report, and for helping us make PHP better.

This is available now via the newly introduced DOM classes DOM\HTMLDocument and DOM\XMLDocument in
PHP-8.4-dev. They have an argument to override the encoding.


Previous Comments:
------------------------------------------------------------------------
[2023-10-04 20:02:05] nielsdos@php.net

This will be fixed when this RFC is accepted & implemented: https://wiki.php.net/rfc/domdocument_html5_parser

------------------------------------------------------------------------
[2023-09-20 17:54:11] markokarjalainen at kolumbus dot fi

Any plan to fix this real old bug?

1. loadHTML should be always UTF-8 as default, like DOMDocument self is.

2. If user give charset in DOMDocument::__construct(), then loadHTML should to be use it.

3. If imported HTML contains charset, then use it.

Maybe this kind of change not broke the world?

------------------------------------------------------------------------
[2020-10-23 15:22:50] cmb@php.net

Not a solution, but likely a viable workaround would be prepending
the HTML string with a BOM ("\xef\xbb\xbf" for UTF-8), see
<https://3v4l.org/ArhNb>.

------------------------------------------------------------------------
[2018-07-22 18:36:11] anrdaemon at freemail dot ru

Prefixing does not work.

The default input encoding of DOMDocument is IS-8859-1 contrary to the documentation that says the
input should be UTF-8 encoded.

If you prefix your document with "<?xml …", it will change mode to UTF-8
regardless of encoding specified in the XML declaration, and mangle the declaration itself.

https://3v4l.org/HL5It

In short, DOMDocument is largely unusable for HTML, only well-formed XML with explicit declaration
gives you a small hope of success.

------------------------------------------------------------------------
[2015-12-22 21:19:12] nathan dot renniewaldock at gmail dot com

This really does need to be supported. Though libxml2 is partly to blame for ignoring <meta
charset="utf-8">

For now, workaround is to prefix the HTML with either
<?xml version="1.0" encoding="UTF-8"?>
or
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">

------------------------------------------------------------------------


The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at

    https://bugs.php.net/bug.php?id=47875


--
Edit this bug report at https://bugs.php.net/bug.php?id=47875&edit=1


Thread (9 messages)

« previous php.bugs (#245797) next »