Open Bug 1826657 Opened 2 years ago Updated 2 years ago

Extra 0xa4 byte throws off EUC-JP detection in Firefox and Safari, but not Chrome

Categories

(Core :: Internationalization, defect, P3)

Product:
Core
Component:
Internationalization
Type:
defect

Tracking

()

Project Flags:
Webcompat Priority P3

People

(Reporter: twisniewski, Unassigned)

References

(
URL
)

Details

See this comment on webcompat.com for more details.

Essentially, this Oracle document has its inteded EUC-JP encoding guessed by Chrome, but not rejected despite an invalid character in <code>DBL_MIN</code> 3.0, which is a 0xA4 byte. Firefox (and presumably Safari) reject the guess because of the character.

Since this is a webcompat issue, it seems like something the spec should rectify, so I've filed this bug for now until proper next steps can be determined.

Webcompat Priority: --- → ?
Severity: -- → S3
Priority: -- → P3

(In reply to Thomas Wisniewski [:twisniewski] from comment #0)

and presumably Safari

Was this tested with Safari's UI language set to Japanese? With other UI languages, Safari doesn't run a detector at all, which explains the result.

Summary: Extra 0xa4 byte throws off EUC-JP decoding in Firefox and Safari, but not Chrome → Extra 0xa4 byte throws off EUC-JP detection in Firefox and Safari, but not Chrome

Was this tested with Safari's UI language set to Japanese?

Ah, no it wasn't.

status-firefox111: --- → fixed
status-firefox112: --- → fixed
status-firefox113: --- → fixed
status-firefox-esr102: --- → fixed
status-thunderbird_esr102: --- → fixed
status-thunderbird_esr91: --- → fixed
Webcompat Priority: ? → P3
You need to log in before you can comment on or make changes to this bug.