> Perhaps mandating UTF-8 as the string encoding, leaving alternative encodings up to the programmer, would be reasonable these days, I suppose - if a little ru

> Perhaps mandating UTF-8 as the string encoding, leaving alternative encodings up to the programmer, would be reasonable these days, I suppose - if a little rude. It really works quite well, especially "these days" (maybe not so much in the '90s), and has the—huge—advantage that it's very simple and lightweight, and avoids the very tricky issue of re-encoding (Guaranteed To Make Your Life Hell). The python3/java/microsoft/whatever solution is to add an enormously heavyweight and complex layer that attempts to interpret and re-encode the contents of strings, with often dubious benefits. My experience suggest that the latter method is in many cases a classic case of over-engineering, where for a wide swathe of applications, the downsides—complexity and cost—exceed the upsides. But because these languages (or systems, in the case of MS) require this at a fundamental level, all applications pay the costs, even those that don't gain any benefit. [Given the encoding jungle of the '80s/'90s, it's to some degree understandable that MS/Java went the way they did (though UTF-8 was around back then, and would have at least made a much better canonical representation). That python3 dove into that swamp is a bit more mystifying given the rather clear signs that the future will essentially be Unicode encoded with UTF-8...]