#Firefox change text encoding how to#
It could be argued that database content should have been converted when the default encoding was converted, but now content under the old encoding is many years old and it would be unreasonable to go and manually change the encoding for each post (I'm assuming web comic artists run their sites with a WYSIWYG solution of some sort, and it would be unreasonable to expect them to understand how to write code to automate this process). I have also experienced related bugs (such as Chrome's lack of such a menu to begin with) on websites hosting content like web comics, where commentary for the comic was written with one character encoding in the past, but the site's coding changed and now encodes commentary under a different character encoding. This was outside of the control of the owners of the website, and it would be unreasonable to expect them to manually correct every post by a user which was uploaded with the wrong character encoding.
In this case, a user's post on a forum was encoded with the wrong character set, resulting in the word 'executable' displaying as 'exécutable'. Telemetry suggests that useless use or incorrect use of the encoding menu was a big part of its overall use. While the edge case seen here is unfortunate, bug 980904 helps users not waste time with a remedy that's virtually always wrong for the symptoms they are seeing (if the page was labeled as UTF-8 and had no UTF-8 errors, chances are that whatever looks wrong with the page is not a problem that would be remedied by decoding as another encoding). I think we shouldn't roll back that change. > the UI changes from bug 980904 in some circumstances? Henri, do you have any thoughts about reconsidering (In reply to :Gijs (he/him) from comment #4) Then you can put as a hidden field of the form and the browser will fill it in with the actual encoding used. If the script needs to be able to handle non-UTF-8 submission for legacy reasons, it could be changed to copy the value of the form field named "_charset_" into the charset= parameter of the email Content-Type header. If you control the HTML of the form, you can add the attribute accept-charset="windows-1252" on the element. I suggest complaining to the hosting company that they should make the encoding of the HTML page containing the form and the expectations of the form submission handler script match (preferably by changing the script to expect UTF-8). That's a fundamentally bogus configuration. > in latin-1 but they also provide an utf-8 charset on this page. > company in Europe have a incorrectly configured form wich need data encoded Is there a way to bypass this behavior ? here my need, a major hosting
0 kommentar(er)
