[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 These are good points and are appreciated. In general, I will certainly try to follow your advice. Regarding the specific issue under discussion here (SJIS-win vs. CP932), I must honestly say that this discussion has left a lot of question marks in my mind. How we got to the present state of affairs is now fairly clear. The general principles which @sji-i has set forth regarding future development of mbstring, at least as regards to legacy Japanese encodings, are clear (and I do agree with all of them). A lot of things have become clear, largely due to @sj-i's research. The remaining "question marks" are all related to the way forward from here. If I had known in 2020 that there was a difference in behavior between SJIS-win and CP932, I would not have merged these encodings at that time. But I didn't know, and I did merge them, and so here we are in 2022, trying to decide what to do next. Normally, when a change like this is made unintentionally or due to a misunderstanding, the default response is to roll it back. And we might still go that way. But, there are some unusual things about this situation, which are making it hard for me to feel sure about what to do: - PHP 8.1 was released 6 months ago, but at present, we do not have any evidence that any PHP application in production has been broken by the merge of SJIS-win and CP932. Certainly, it is possible that some application, somewhere, might have been broken, and perhaps the developers have already patched it, without reporting the breakage. I wouldn't want to ignore that possibility; but still, for now, we do not have any evidence of actual problems being caused. - @zonuexe and @sj-i are obviously both very experienced, knowledgeable, and accomplished Japanese PHP developers, but it seems that neither of these esteemed developers has any reason for preferring SJIS-win or CP932. Certainly, reasons could be invented ex post facto to justify the request to restore SJIS-win; but when this GH issue was opened, neither had a reason. It is revealing that both gentlemen could experience many years of PHP development without ever finding it necessary to pay attention to the difference between SJIS-win and CP932. Of course, there may be other Japanese PHP developers out there who have practical reasons to care about the difference; but at the moment, we do not have any evidence of such. - From a (very limited, incomplete) survey of Japanese-language blog posts on the subject, it did not appear that any of the authors had clear reasons for preferring SJIS-win or CP932. It seems likely that most existing users have just chosen randomly, or by "superstition" (copying what others do, without understanding the reasons). - It doesn't seem that other software development platforms have found it necessary or desirable to support two different variants of CP932. Another point: To me, the maintenance burden of keeping two different CP932 variants in mbstring is not a great concern. My concern is more for the users. I think it is a disservice to PHP users if we keep two different features, which work almost the same, but just slightly different, and nobody can provide any reasonable explanation of why things should be that way or how the users can choose which one to use. (The PHP platform may have had such inconsistencies in the past, but they are being gradually smoothed out with each successive release.) Thought experiment: If we were not working on PHP here, but on Python, Ruby, JavaScript, or some other platform which only supports one variant of CP932 in its standard library, would you recommend that a second variant of CP932 should be *added*? If not, that suggests there might not be a logical or practical reason to have two variants. If indeed, there is no practical reason to have two different CP932 variants, it is possible that we could still roll the change back for PHP 8.1 (to avoid BC break), and perform the simplification in a future release. Please note, I am just mentioning this as an idea and am still open to all possible outcomes here. At this point, it would be very helpful if other core developers can share their views. Finally, I would like to say that the issue raised in #8281 may be more straightforward than this one, and it is possible we might be able to sort it out more quickly.