# domdocument loadhtml and encoding

- Thread: https://externals.io/message/60716
- Original archive: https://news-web.php.net/php.internals/60716
- Started by Tjerk Meesters on 2012-06-01T15:57:56+00:00
- Messages: 2
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #60716 — Tjerk Meesters — 2012-06-01T15:57:56+00:00

URL: https://externals.io/message/60716#60716

Gentlemen,

Regarding this bug report: https://bugs.php.net/bug.php?id=49705

As more developers move away from using regular expressions to parse
HTML and start using DOMDocument, I've noticed that quite a few
stumble over encoding "issues". They're not bugs, because it's
documented (I think) that if a document is loaded using
::loadHTMLFile() or if it contains a "content-type" meta tag which
specifies the character encoding it will work as expected.

So far I've suggested a hack that involves adding the meta-tag in
front of the string that contains the HTML. As horrible as it seems,
that does the job!

That said, I'm hoping to get enough internals support to add a
parameter to ::loadHTML() that set / overrides the default character
set when processing the document; when given, any <meta> tags
pertaining to character set encoding should be ignored (AFAIK that's
also the browser's behavior).

Btw, there's another patch that also introduces a new parameter to
::parseHTML() which has gone into 5.4 branch
(https://bugs.php.net/bug.php?id=54037), so it looks like this would
be the second (optional) parameter then.

Thoughts?

-- 
--
Tjerk

---

## #62081 — Ferenc Kovacs — 2012-08-07T21:35:19+00:00

URL: https://externals.io/message/60716#62081 · In reply to: #60716

> Gentlemen,
>
> Regarding this bug report: https://bugs.php.net/bug.php?id=49705
>
> As more developers move away from using regular expressions to parse
> HTML and start using DOMDocument, I've noticed that quite a few
> stumble over encoding "issues". They're not bugs, because it's
> documented (I think) that if a document is loaded using
> ::loadHTMLFile() or if it contains a "content-type" meta tag which
> specifies the character encoding it will work as expected.
>
> So far I've suggested a hack that involves adding the meta-tag in
> front of the string that contains the HTML. As horrible as it seems,
> that does the job!
>
> That said, I'm hoping to get enough internals support to add a
> parameter to ::loadHTML() that set / overrides the default character
> set when processing the document; when given, any <meta> tags
> pertaining to character set encoding should be ignored (AFAIK that's
> also the browser's behavior).
>
> Btw, there's another patch that also introduces a new parameter to
> ::parseHTML() which has gone into 5.4 branch
> (https://bugs.php.net/bug.php?id=54037), so it looks like this would
> be the second (optional) parameter then.
>
> Thoughts?
>
>
would be nice.
bump.


-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu