From: Brian Candler Date: 2010-11-28T06:35:06+09:00 Subject: Re: Ruby 1.8 vs 1.9 Robert Klemme wrote in post #963807: >> But that basically is my point. In order to make your program >> comprehensible, you have to add extra incantations so that strings are >> tagged as UTF-8 everywhere (e.g. when opening files). >> >> However this in turn adds *nothing* to your program or its logic, apart >> from preventing Ruby from raising exceptions. > > Checking input and ensuring that data reaches the program in proper > ways is generally good practice for robust software. But that's not what Ruby does!. If you do s1 = File.open("foo","r:UTF-8").gets it does *not* check that the data is UTF-8. It just adds a tag saying that it is. Then later, when you get s2 from somewhere else, and have a line like s3 = s1 + s2, it *might* raise an exception if the encodings are different. Or it might not, depending on the actual content of the strings at that time. Say s2 is a string read from a template. It may work just fine, as long as s2 contains only ASCII characters. But later, when you decide to translate the program and add some non-ASCII characters into the template, it may blow up. If it blew up on the invalid data, I'd accept that. If it blew up whenever two strings of different encodings encounter, I'd accept that. But to have your program work through sheer chance, only to blow up some time later when it encounters a different input stream - no, that sucks. In that case, I would much rather the program didn't crash, but at least carried on working (even in the garbage-in-garbage-out sense). > Brian, it seems you want to avoid the complex matter of i18n - by > ignoring it. But if you work in a situation where multiple encodings > are mixed you will be forced to deal with it - sooner or later. But you're never going to want to combine two strings of different encodings without transcoding them to a common encoding, as that wouldn't make sense. So either: 1. Your program deals with the same encoding from input through to output, in which case there's nothing to do 2. You transcode at the edges into and out of your desired common encoding Neither approach requires each individual string to carry its encoding along with it. -- Posted via http://www.ruby-forum.com/.