UTF-8 + FileExists() - бага?

[Azzx]

Народ, подскажите плиз, это я туплю, или я особо удачный такой... Чего-то сразу и не могу сообразить, в чём проблема и как решить. Если компилировать исходники в Lazarus (т.е. в кодировке UTF-8), то функция FileExists() отказывается опознавать файлы/каталоги с русскими именами. Соответственно, в "Мои документы" так просто уже не сохранишь.

[Vadim]

Azzx
Надо просто переводить UTF-8 в обратно в системную кодировку с помощью UTF8ToSys(Русское_название).

[Azzx]

Надо просто переводить UTF-8 в обратно в системную кодировку с помощью UTF8ToSys(Русское_название).

Дык фокус-то в том, что и компоненты открытия файлов не работают.
Окромя того - с какой стати я его должен конвертировать? Имхо - мне дела нет до внутреннего представления строк...

[Vadim]

Имхо - мне дела нет до внутреннего представления строк...

Тогда бросайте программирование и идите в менеджеры по продажам.
Это неправильно. До всего, что Вас касается, Вам должно быть дело, иначе будете иметь то, что сейчас имеете.
Давайте я Вам подробненько напишу:
Операционная система Windows работает с системными кодировками - либо ANSI, либо Unicode. Lazarus работает с кодировкой UTF-8. Сделано это для кроссплатформенности, поэтому кивать на то, что Вам конкретно это неудобно, не надо.
Какой из этого следует логический вывод? Если Вы собираетесь что-то передавать ОС - например имя файла для открытия или поиска, то передавать Вы должны именно в системной кодировке, а не как-нибудь ещё. Вы не согласны?

[Mr.Smart]

Надо просто переводить UTF-8 в обратно в системную кодировку с помощью UTF8ToSys(Русское_название).

Дык фокус-то в том, что и компоненты открытия файлов не работают.
Окромя того - с какой стати я его должен конвертировать? Имхо - мне дела нет до внутреннего представления строк...

Поиск по форуму проводили? Смотрю, что нет! Эта тема уже изжована.

Все функции RTL и WinAPI работают со строками Ansi, а LCL полностью построенна на UTF-8.
если всёже лень что либо конвертировать пользуйтесь функциями которые работают с UTF-8!
В модуле LCLProc есть функция FileExistsUTF8()!

UTF-8 + FileExists() - бага?

Эта не бага - это фича

Добавлено спустя 5 минут 37 секунд:
Полностью согласен с Vadim

[Azzx]

Давайте я Вам подробненько напишу:
Операционная система Windows работает с системными кодировками - либо ANSI, либо Unicode. Lazarus работает с кодировкой UTF-8. Сделано это для кроссплатформенности, поэтому кивать на то, что Вам конкретно это неудобно, не надо.
Какой из этого следует логический вывод? Если Вы собираетесь что-то передавать ОС - например имя файла для открытия или поиска, то передавать Вы должны именно в системной кодировке, а не как-нибудь ещё. Вы не согласны?

Таки нет - не согласен. Строка - это определённая абстракция. "Последовательность символов" или что-то типа того. Как они внутри хранятся - мне не важно для использования. Тем более, что, в конечном счёте, всё "передаётся ОС".

Эта не бага - это фича

Оригинальная фича, однако... А почитать где-нибудь про неё можно? В смысле - официальные источники/рекомендации и т.п.?

[Vadim]

Как они внутри хранятся - мне не важно для использования.

Для программиста важно. Всё что Вы программируете - это цифры. В компьютере нет ничего окромя цифр. За 40 лет удалось в некоторой степени абстрагироваться от цифр, но, увы, не совсем. Вы сейчас и пожинаете плоды этого самого "не совсем". Если Вам это не нравится - не занимайтесь программированием, ибо от учёта многочисленных нюансов избавится пока что нельзя никак.
И строка - это не абстракция. Для компьютера это самая что ни на есть конкретика. И для Вас, как для программиста, тоже. Неужели ещё не убедились?

[Azzx]

Вы сейчас и пожинаете плоды этого самого "не совсем". Если Вам это не нравится - не занимайтесь

Не можу... мне за это деньги платят...

И строка - это не абстракция. Для компьютера это самая что ни на есть конкретика. И для Вас, как для программиста, тоже. Неужели ещё не убедились?

Я не отрицаю факт её существования, если уж на то пошло... Просто это другой уровень манипулирования сущностями. Понятно объясняю? В данном случае отсутствие изоляции между уровнями - явная ошибка проектирования, имхо... Сам бы я выбрал компромиссное решение - все строки жёстко сделать UNICODE - как наиболее общий вариант из существующих.

[Mr.Smart]

Сам бы я выбрал компромиссное решение - все строки жёстко сделать UNICODE - как наиболее общий вариант из существующих.

А вы считаете это будет честно по отношению к системам с "локалью" UTF-8?
В данном случае UTF-8 был выбран в качестве общего варианта.

[Alexx2000]

А почитать где-нибудь про неё можно? В смысле - официальные источники/рекомендации и т.п.?

LCL Unicode Support

На самом деле вся проблема в том, что Lazarus сейчас полностью перешел на Unicode (а конкретно на UTF-8). А FPC RTL, остался не юникодным, из-за этого и приходится использовать такие вот костыли.

[Vadim]

Не можу... мне за это деньги платят...

Тогда вникайте в тонкости - денег будет больше.

Сам бы я выбрал компромиссное решение - все строки жёстко сделать UNICODE - как наиболее общий вариант из существующих.

Сейчас как раз идёт переход на UNICODE. Другое дело, что этих самых UNICOD'ов - вагон и маленькая тележка. И один из них - UTF-8. Когда с кодировками всё устаканится - проблем со строками не будет.
К сожалению русскому языку не повезло. В досе была своя кодировка, в Windows своя, в Unix ажно две, для MacOS - своя. В то время как английский текст в какую ОС не засунь - он везде будет читаем. В чехарде кодировок мы сами виноваты. Во-первых, когда в США кинулись развивать кибернетику, у нас за неё расстреливали, во-вторых, когда времена массовых "сиделищ" прошли, мы не нашли ничего лучшего, как воровать и железо и софт у США, а американцам кроме американцев на всех было наплевать. В третьих, Микрософт в своё время присылало нам запрос о кодировке русского языка при разработке Windows - мы гордо промолчали. Теперь пожинаем плоды своей гордости.

[Azzx]

А вы считаете это будет честно по отношению к системам с "локалью" UTF-8?
В данном случае UTF-8 был выбран в качестве общего варианта.

Гм... А имена в студию? А то мне даже чего-то ничего в голову не приходит, кроме того, что гонять строки из UNICODE - оно проще бы было...

На самом деле вся проблема в том, что Lazarus сейчас полностью перешел на Unicode (а конкретно на UTF-8). А FPC RTL, остался не юникодным, из-за этого и приходится использовать такие вот костыли.

Ну, надеюсь, они хоть собираются его туда перевести?

Тогда вникайте в тонкости - денег будет больше.

Дык как бы и так прекрасно в этом разбираюсь...

Сейчас как раз идёт переход на UNICODE. Другое дело, что этих самых UNICOD'ов - вагон и маленькая тележка. И один из них - UTF-8. Когда с кодировками всё устаканится - проблем со строками не будет.

UTF-8 - это способ кодирования, далеко не всегда удобный, кстати.

[Павел Ишенин]

Для FPC 2.4 скорее всего реализуют поддержку строк вроде тех что появились в D2009, т.е. UTF8String будет сам на лету конвертироваться в системную кодировку. Сам RTL будет поддерживать UnicodeString - кажется есть соответсвующий branch для fpc.

На текущий момент используйте специальные UTF8 функции из FileUtil.

[Vadim]

UTF-8 - это способ кодирования, далеко не всегда удобный, кстати.

А вот позвольте с Вами не согласиться. Чем удобен двухбайтовый Unicode с жёстко фиксированным кол-вом байтов на один символ? Даже ежу понятно, что такая кодировка имеет ту же болезнь, что и более ранние кодировки - семибитная, восьмибитная(однобайтная) - невозможность использования нескольких языков одновременно. На первый взгляд можно подумать, что 64 000 символов, которые нам резервирует двухбайтный Unicode, хватит для всего и вся. Увы, дружище, это не так. К примеру традиционный китайский язык имеет примерно 63 000 иероглифов. А теперь представим, что переписываются китаец с японцем. В японском языке тоже немало. Да, конечно, можно пользоваться и упрощённой системой, но суть проблемы, я думаю, понятна. К примеру, прилетят к нам жители Сириуса, так их язык тоже надо вводить в компьютер, иначе мы не сможем обмениваться поздравлениями с национальными праздниками.
UTF-8 имеет кардинальное отличие - изменяемое значение количества байт на символ. К примеру, если я пишу английский текст, то у меня действует 1 байт на символ, а если русский - то два байта на символ. В то время как двухбайтовый Unicode всегда занимает два байта на символ - и часто один байт совершенно лишний. С другой стороны, в UTF-8 мы можем спокойно добавлять и третий и четвёртый байт на символ, по мере необходимости, в то время как в двухбайтном Unicode мы жёстко ограничены и уже отсюда видна стена, препятствующая многоязыковому общению.

[Sergei I. Gorelkin]

Да нету сейчас "двухбайтового Unicode". Раньше, в первых версиях стандарта Unicode, когда считали, что "65536 символов хватит на всех", он был. Сейчас есть кодировка UTF-16, в которой символы с кодом > 65535 кодируются так называемыми "парами суррогатов", и есть куча софта, которая эти пары не поддерживает, по-прежнему считая что все укладывается по 2 байта.