> Ну "при каждой перерисовке окошка" - это очевидный наброс, не буду комментировать. Нет, не наброс. Тебе придётся перекодировать все эти теги. Либо в момент, когда ты их читаешь с диска, либо в момент когда ты их рендеришь на экране, чтобы символы тягать из юникодного шрифта, либо где-нибудь в промежутке.
В момент рендеринга на экран перекодировать глупо, я вижу что ты это понимаешь. Но при этом, складывается впечатление, что момент чтения с диска и конвертации прочитанных байтовых массивов в String не кажется тебе удачным моментом для перекодирования. Если так, то в какой момент ты бы стал перекодировать?
> Случай "куча треков россыпью с разными кодировкам в одном каталоге" я не рассматриваю, это случай отдельный. Тут как раз разовое перекодирование предпочтительнее (кстати, для такого перекодирования, ВНЕЗАПНО, тоже нужен инструментарий).
Я не вижу разницы между этими случаями. Мне кажется, что ты говоришь о логике принятия решения о том, в какой кодировке какой файл, но это совершенно отдельная логика ведь -- может быть ты используешь эвристики, может быть хранишь базу уже встреченных файлов и в ней кодировку к каждому, может быть объединяешь и то и другое, чтобы сделать пользователю удобно эвристикой, но не прибивать его гвоздями к её несовершенствам и дать возможность вручную настроить. Может ты придумаешь что-то ещё. Это не важно. Важно то, что если ты хочешь рендерить теги, то как бы ты не принимал это решение, тебе придётся перекодировать в юникод.
На самом деле, я вот подумал, рендерить ведь мало, неплохо наверное ещё поиск по тегам иметь? А это значит, что неплохо было бы вообще собирать все теги со всех файлов в sqlite и хранить там. И хранить их там в юникоде. Не будешь же ты каждый раз при каждом поиске перебирать все файлы и вынимать из них теги? И хранить мешанину кодировок в sqlite не будешь: как ты там после этого искать будешь?
