Универсальность vs. логика

12 апрель, 2012 - 11:47Игорь Дериев

Вроде бы CSV – достаточно очевидный и стандартный способ обмена данными между программами, оперирующими табличными данными. Но «сюрпризов» он по-прежнему преподносит более чем.

Не спрашивайте почему и зачем (это долгая и печальная история, начавшаяся еще вот с этого), но понадобилось передать в смартфон адресную книгу именно через CSV. Ну, есть программы, которые это умеют, главная задача – получить исходный файл.

Казалось бы, чего проще? Имеется резервная копия телефонной книги в Outlook, которая умеет экспортировать контакты в CSV: раз – и готово. Но если бы все было так просто, не было бы этого текста :) В результирующем файле все символы кириллицы (имена, фамилии) оказались заменены знаком вопроса. Предположив, что что-то сломалось в Outlook, попробовал проделать то же самое в Hotmail. Аналогично!

Хорошо, что я человек бывалый и немного с проблемами CSV знакомый. В частности, еще давно сталкивался с их переносом (и соответствующих макросов) между системами с разными языками, а главное – с разными региональными настройками. Та самая comma оказывается запятой только для американцев и британцев, а для прочих европейцев – точкой с запятой. Ну, тут как бы все честно, нам запятая нужна для других целей. В любом случае хорошо, что есть стандартный способ управления такими нюансами – особенно, если пользователь о них осведомлен.

У меня ОС англоязычная, Microsoft Office русскоязычный, системная локаль выставлена правильно, но вот служебные форматы по какой-то причине я оставил английские. Здесь-то собака и зарыта. Поменял форматы на русские и все получилось. С Hotmail, кстати, ситуация аналогична: достаточно сделать интерфейс сервиса русским и кириллица преобразуется корректно.

В общем, happy end, но осадок остался. Ведь и Outlook, и Hotmail оперируют Unicode. В этом легко убедиться: в Hotmail достаточно глянуть на текущую кодировку веб-страницы, а в Microsoft Office, к примеру, испортить заголовок doc-файла и, открыв его в Word, выбрать Unicode. На первый взгляд может показаться, что перекодировка Unicode в ANSI – процесс неоднозначный, ведь часть информации действительно теряется. Но ведь язык-то известен! На то и Unicode. Логично предположить, что и в дальнейшем (в CSV) я хочу получить данные на том же языке. На деле же происходит  следующее: почему-то применяется таблица перекодировки для некоего «главного» языка, в данном случае, видимо, английского, естественно, кириллица не попадает на нужные места в таблице ANSI и программа в ужасе заменяет ее знаком вопроса. Хотя, чем знак вопроса лучше, чем другие (предположительно) нечитаемые, но все же несущие информацию символы?

Странно сталкиваться с подобными проблемами в XXI веке. Программисты, видимо, пошли по пути наименьшего сопротивления, выбрав универсальный алгоритм "на все случаи жизни", хотя стоило бы чуть-чуть дополнительно поразмыслить. К примеру, обнаружив большое количество «левых» символов, вероятно, стоит заменить таблицу перекодировки. Хотя нельзя исключить что это унаследованная проблема. Ведь получается, что текстовые данные, записанные более чем в двух алфавитах, через CSV перенести полностью нельзя в принципе. Так почему бы не использовать для этого формата Unicode, предоставив выбор пользователю?