I believe that ISO2022 allows for the full set of japanese names (and has some sort of process for introducing new kanji). That's probably a big part of the reason that Ruby's strings are bytes with an encoding attribute, rather than just being unicode.
Ruby was designed as utility goop for Japanese programmers. Inability to parse/output legacy encodings would have rendered it virtually useless for that, even if legacy encodings were strictly dominated by any available Unicode encoding, which many Japanese programmers would hotly contest.
The Ruby thing is probably due to the fact that EUC and Shift-JIS were then (and to some extent still are) the prevalent encodings. It's not so much about character sets, after all Unicode includes every kanji defined in ISO-2022. Please see my other comment in this thread.
Japanese computer systems are often not using Unicode but are based on other encodings like shift-jis.
Even if it wasn't for historical characters that aren't part of Unicode, this will probably stay that way because of the inefficiencies of encoding Asian text in e.g. UTF8.
That's part of the reason the ruby programming language didn't have proper Unicode support for a long time (and now supports arbitrary encodings for its strings, not just Unicode ones)
> Japanese computer systems are often not using Unicode but are based on other encodings like shift-jis.
That's true but doesn't really answer GP's question. Shift-jis is an encoding for one of the JIS X character sets. Unicode includes all the characters defined in JIS.
Though if we enter into details it gets a bit messy due to the complications due to different simplifications occured in (mainland) China and Japan, questions about different glyphs for the "same" character, etc.
