-
Notifications
You must be signed in to change notification settings - Fork 144
[TASK] Deprecate Parser::setCharset()
and Parser::getCharset()
#688
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The jury's still out. I don't honestly know if these are useful methods, and thus whether they should be retained or not.
@sabberworm WDYT?
Not sure the deprecation comment should reference an issue number, but maybe it should.
d9edd5e
to
d07b100
Compare
@JakeQZ I don’t know the current state of affairs regarding charset support. IIRC, the original idea was to accept lots of different charsets and convert them all to UTF-8 for parsing and but still use it when stringifying. Since the world has pretty much settled on UTF-8, I don’t think this is at all relevant anymore. Only handling UTF-8 would also rid us of the need to use the mbstring functions. |
d07b100
to
b1ccd56
Compare
b1ccd56
to
1ccd661
Compare
Some notes on these two methods, and why I think we can deprecate (and then remove) them:
|
OK. It seems we're in agreement that these can be deprecated. Regarding parsing different charsets, I think we should continue to support |
I think we could still drop mbstring, if we use In essence: have some heuristic to determine the input encoding (BOM, |
@sabberworm Sounds good! I've added #706 for this. |
Fixes #681