Notes |
|
(0015777)
|
zed
|
26-04-2015 13:59
|
|
А этот формат юникод понимает? Потому как исправить этот косяк можно двумя способами. |
|
|
|
Написал Паразиту. Он у нас главный специалист по этому формату. По его просьбе вообще делался экспорт. |
|
|
|
Приаттачь реально генерируемый сейчас файл - я попробую всунуть в GES и посмотреть, что тот скажет. |
|
|
|
Та тебе проще самому сделать. Сделай файл на пару тайлов, а потом переименую папку с кэшом с добавлением символов не из активной локали и в сгенерированном файле исправь путь. Попробуй разные форматы: utf-8 (c BOM и без), utf-16 (c BOM и без) |
|
|
|
Насколько я понимаю всю проблему - вопрос только с нац.символами в путях, и вопрос не в том возьмет ли GES "неправильный" список. Вопрос в том, сможет ли ОС найти файл по тому пути, который указан в файле (ибо GES работает с диском не напрямую, а тупо просит у оси отдать ему контент файла по пути ХХХХХ). То есть, вопрос собссно к оси - найдет ли оная файл с указанным абс.путем, или нет. То есть, путь до файла можно тупо копи-пастить из .AUX в Проводника (БЕЗ учета возможного декодирования Блокнотом при открытии), и пытаться открыть. Если ось его найдет - то его найдет и GES ничуть не хуже. Умная ось по идее должна понимать Unicode-стринги в путях автоматом, и перекодировать оные в соответствии с текущей региональной схемой. Имхо.
Как доберусь до GESа - буду попробовать, но сдается мне что вопрос явно не к нему. Быстро не обещаю - свободного времени почти ноль. |
|
|
|
>Вопрос в том, сможет ли ОС найти файл по тому пути, который указан в файле
Да.
>Умная ось по идее должна понимать Unicode-стринги в путях автоматом, и перекодировать оные в соответствии с текущей региональной схемой.
А вот тут ты ошибаешься. Таких осей нет. Линух ожидает имя файла в utf-8, винда пользуется utf-16le, но для обратной совместимости имеет функции принимающие Анси строки и кодирующие их в utf-16le в соответствии с текущей локалью. Так что все дел именно в программе и в том как она будет интерпретировать файл и какие функции вызывать. Программа может детектить тип файла по BOM и потом работать уже с перекодированным файлом. Может всегда считать что там utf-8 и перекодировать его в utf-16le для винды. Может считать что там всегда Ansi и тогда использовать пути с символами не из текущей локали будет невозможно. Вот и нужно выяснить как конкретная программа работает с этим файлом. Но я пока просто добавлю кодирование в utf-8. Для путей с английскими символами ничего не поменяется, а остальным, в худшем случае, не повезло - откроешь новый баг. |
|
|
(0015934)
|
Parasite
|
17-05-2015 12:59
(edited on: 17-05-2015 13:02) |
|
Проверил:
- ANSI - тайлов не находит (см.аттач)
- UNICIDE/noBOM - работает
- UNICIDE/BOM - работает
WinXP SP3
|
|
|
(0015935)
|
zed
|
17-05-2015 13:05
|
|
Текущая ночнушка сохраняет в UTF8. Где ты взял ANSI и зачем переоткрыл тикет? |
|
|
|
>Текущая ночнушка сохраняет в UTF8. Где ты взял ANSI и зачем переоткрыл тикет?
Хм. А ты вообще тикет читал, не?
Выше было запрошено (от меня) потестировать AUX а разных кодировках оного (4й пост сверху). Вот, потестировал.
Сохраняет в UTF? Отлично. Так-то у меня русских путей все равно нет, так что лично мне - без разницы. Если ничего больше тут от меня не требуется - закрывай тикет. |
|