|laziness, impatience, and hubris|
Re^6: Text::CSV encoding parse()by afoken (Canon)
|on Aug 15, 2019 at 13:38 UTC||Need Help??|
A simple hex dump of bytes is not always sufficient.
Perl scalars can store strings in two ways: legacy, using characters that match bytes, and Unicode, using characters that can have values larger than 255. In the first case, the unicode flag (unfortunately called "the UTF8 flag") is cleared, in the second case, it is set. You can query it using the core function utf8::is_utf8($scalar). More details: utf8, perlunifaq
Things get interesting when encoding and decoding happens, as the outside world usually talks bytes, not characters. If you handle all data as binary, "Unicode in, Unicode out" seems to work magically, as long as you don't touch the bytes. Perl does not see Unicode, but a string of bytes. The difference is subtile, but can cause huge problems. length('Bär') is suddenly not 3, but 4 (UTF-8), 6 (UTF-16) or 12 (UTF-32). You can't match the 'ä' in 'Bär'. And so on. See Match full utf-8 characters for a real-world example.
The correct way is, of course, to handle encodings correctly. That way, perl decodes input to strings of characters, and encodes those strings of characters back on the way to output. length('Bär') will always be 3, you can match the 'ä' in 'Bär', and so on.
To see if all encoding and decoding happened as expected, you have to look at the unicode flags of the scalars. Comparing actual length and expected length is also useful. Especially when working not only with STDIN and STDOUT, but e.g. also with a database interface, you really want to know if you have successfully read and written a string as Unicode or just happened to get the same bytes back as you wrote, and the other side saw just Mojibake. That's the main reasons why t/40UnicodeRoundTrip.t, t/41Unicode.t, and t/UChelp.pm in DBD::ODBC exist. Let me tell from experience gained while developing the initial Unicode patch for DBD::ODBC: It is really easy to mess up the encoding and decoding.
Oh, and just a little extra: CGI does NOT change STDOUT to use UTF-8 encoding when using the -utf8 pragma. It also does NOT change STDOUT when you send a document encoded as UTF-8. You have to do so manually (binmode STDOUT,':encoding(utf-8)'). If you find "wide character in print" warnings in the web server's error log, you have your string encodings right, but STDOUT was not set to UTF-8. If you don't see those warnings, with warnings enabled and no binmode STDOUT, your strings most likely aren't encoded properly.
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)