[php-src] Issue #8308: The return value of mb_list_encodings() doesn't contain 'SJIS-win'

Issue: https://github.com/php/php-src/issues/8308 Comment Author: alexdowad @sj-i I am sorry I have delayed a bit in responding. Thanks for your exhaustive research. I think we are almost ready to update *both* documentation for core developers (i.e. code comments) and the PHP manual here. To summarize @sj-i's findings, I think we can characterize mbstring's CP932 implementation as follows: • It follows the "best fit" CP932 mappings from the Microsoft Windows API... • ...together with an extra mapping which improves the quality of conversions from SJIS to CP932. • It is also compatible with the [WHATWG standard for "Shift_JIS"](https://encoding.spec.whatwg.org/#shift_jis). Before we put that information in the PHP manual, we need to confirm that those statements are true. For example, @sj-i kindly checked the Win32 mappings for U+203E and U+00A5, but we haven't checked *all* Win32 "best fit" mappings from Unicode → CP932 and CP932 → Unicode. I would also like to check *all* Shift_JIS mappings in the JavaScript Encoding API (i.e. WHATWG), to confirm whether we are truly compatible with them or not. I can do this when I have some time (probably in the next few days). For core developers, we can add the following information: • The 'extra mapping' is for U+203E. • mbstring's implementation of CP932 is also compatible with iconv's. • We can also include a *small* amount of historical background information. Again, we need to check if the statement about iconv is true or not. If it is true, it is good information for core developers. But for users of PHP, I don't think most of them really care about compatibility with iconv. Hence, I don't think that statement needs to go into the PHP manual. (If you disagree, please mention.) **NOW!** We have come a long way here, but are still have not 100% reached where we need to go. The remaining piece of critical information which needs to be documented, both for core developers and for users of PHP, is why we have the so-called SJIS-win encoding. We already know that this encoding matches the original implementation of CP932 which was included in libmbfl when it was integrated into PHP. Further, when CP932 was adjusted, @moriyoshi retained the previous implementation as SJIS-win, presumably for backwards compatibility. That is all well and good, but do we really want to tell our users that we are currently keeping SJIS-win purely for BC? If so, that implies that nobody should be using it for new, 'greenfield' development. But I think it is useful for more than just BC. SJIS-win maps U+203E and U+00A5 to fullwidth, JIS X 0208 characters. For people who are converting arbitrary Unicode text to SJIS/CP932, that could help to avoid situations where a source text contains ¥, but after conversion, the user sees \ instead. I think we can summarize the recommended uses of these mapping tables as follows: • If you are converting SJIS text to CP932, use CP932. *(Should we mention this? Is it something that people are actually likely to do?)* • If you are exchanging CP932 data with Microsoft Windows software (such as Microsoft Office), especially if you receive data which was exported from MS Office and then emit data which will be imported back into MS Office, use CP932 for maximum compatibility. • If you will be processing SJIS/CP932 data in a web browser using JavaScript, use CP932 for maximum compatibility between conversions performed in the browser and those performed in PHP. • If you need to convert other, generic Unicode text to CP932, use SJIS-win. Does that sound right?