Summary: | Не учитывает кодировку в SPEC | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | Infrastructure | Reporter: | Rinat Bikov <bikr> | ||||||
Component: | packages.altlinux.org | Assignee: | Nobody's working on this, feel free to take it <nobody> | ||||||
Status: | CLOSED WONTFIX | QA Contact: | |||||||
Severity: | normal | ||||||||
Priority: | P3 | CC: | becase, rider | ||||||
Version: | unspecified | ||||||||
Hardware: | all | ||||||||
OS: | Linux | ||||||||
URL: | http://prometheus.altlinux.org/en/Sisyphus/srpms/alt-docs-main/spec | ||||||||
Bug Depends on: | |||||||||
Bug Blocks: | 22555 | ||||||||
Attachments: |
|
Description
Rinat Bikov
2010-12-10 14:07:59 MSK
(В ответ на комментарий №0)
> Если на sisyphus.ru предполагалось, что spec написан в кодировке koi8-r, то
> теперь предполагается, что он написан в кодировке UTF-8, а указанные кодировки
> в Summary(ru_RU.KOI8-R), %description -l ru_RU.KOI8-R игнорируются.
Дело в том что ни sisyphus.ru ни prometheus.a.o ничего в плане спеков и их кодировок не делает. Просто на sisyphus.ru использовалась кодировка KOI8-R для страниц, а на prometheus я сконвертил всё в UTF-8.
Какие предложения по поводу не игнорирования кодировки? И на каких страницах?
(В ответ на комментарий №1)
> Какие предложения по поводу не игнорирования кодировки? И на каких страницах?
Есть предложение по обработке последовательности Summary(ln_LN.encoding).
Либо проходить 2 раза, в первый раз в поисках этой последовательности, либо изменять кодировку входных данных на лету после встречи такой последовательности.
(В ответ на комментарий №2) > (В ответ на комментарий №1) > > Какие предложения по поводу не игнорирования кодировки? И на каких страницах? > > Есть предложение по обработке последовательности Summary(ln_LN.encoding). > Либо проходить 2 раза, в первый раз в поисках этой последовательности, либо > изменять кодировку входных данных на лету после встречи такой > последовательности. Повторюсь: > Какие предложения по поводу не игнорирования кодировки? И на каких страницах? Я пока не понимаю что, где и зачем. Предложение не игнорировать кодировку на странице вывода spec-файла (см. URL для примера). То есть отсеки с внутренней кодировкой spec-файлов преобразовать в кодировку UTF-8, чтобы далее при отображении этих спек-файлов не было нечитаемых символов. Сложность в том, что в одном файле могут быть пункты с разной кодировкой: CP1251, UTF8, KOI8-u. (В ответ на комментарий №4) > Предложение не игнорировать кодировку на странице вывода spec-файла (см. URL > для примера). > > То есть отсеки с внутренней кодировкой spec-файлов преобразовать в кодировку > UTF-8, чтобы далее при отображении этих спек-файлов не было нечитаемых > символов. > > Сложность в том, что в одном файле могут быть пункты с разной кодировкой: > CP1251, UTF8, KOI8-u. Предлагаю не решать политические вопросы техническим путём. Пишите спеки в UTF-8 и проблем не будет. NOTABUG -> WONTFIX Жаль, а интересная задача по идее :) Да и в policy нигде не видел, чтобы было требование писать в какой-либо одной кодировке... (В ответ на комментарий №7) > Жаль, а интересная задача по идее :) Приходите лучше сразу с патчем. :) Created attachment 4851 [details]
Вот конвертер кодировок на Java (jar-файл)
Я написал конвертер кодировок в utf-8.
Created attachment 4852 [details]
Исходный код конвертера (Java).
И исходник.
Прошу учесть код конвертора :). Вот сложный случай: http://prometheus.altlinux.org/en/Platform5/srpms/wget/spec Для него некорректно работает. Нужно найти способ получения кодировки для указанной локали... Уточню один момент. После миграции на ruby 1.9.2 на прометее теперь не показываются спек-файлы которые содержат символы из не UTF-8 кодировки. Мы показываем specfile расчитывая что всё в нём написано в UTF-8, а то, что не в UTF-8 отображается нечитаемым образом и это исправляться не будет: https://beta.packages.altlinux.org/ru/sisyphus/srpms/wallpapers-mike/specfiles/ |