Suggest GBK instead of gb18030 for Simplified Chinese fallback

[hsivonen]

In the table under step 8 of https://html.spec.whatwg.org/#determining-the-character-encoding , change gb18030 to GBK. Both decode the same way per the Encoding Standard, but GBK doesn't generate 4-byte sequences in form submission. Sites that are legacy enough to have unlabeled content might not be able to deal with the 4-byte sequences.

(Firefox uses GBK instead of gb18030.)

[TimothyGu]

What happens if the form submission contains a character that cannot be represented in GBK though, and requires GB 18030?

[hsivonen]

What happens if the form submission contains a character that cannot be represented in GBK though, and requires GB 18030?

The characters not representable in GBK will be converted to decimal numeric character references.

Considering that failing to label the encoding is a legacy authoring error, it seems implausible that more such erroneous sites would be broken by failing to submit non-GBK characters as gb18030 than be broken by submitting non-GBK gb18030 characters to a form handler that expects only GBK.

We don't have actual data for this. The Firefox experience from problems that arose from submitting 3-byte EUC-JP sequences was extrapolated to make Big5 encode asymmetric with decode and to keep GBK as a distinct encoding from gb18030 with asymmetric encode and decode.

[hsivonen]

Anyway, if we believe that the Encoding Standard made the right call on GBK, what the HTML Standard says makes no sense.