Открытый христианский форум JesusChrist.ru

Библия | Книги | Словари | Софт | Аудио, BQT, Евангелизм, JCQ, Молитва

Добро пожаловать на Открытый христианский форум JesusChrist.ru. Для того чтобы писать в форуме, Вам необходимо зарегистрироваться и войти на форум через ссылку для входа.

Общие разделы
   >> "Цитата из Библии"
Просмотров: 1284003 Просмотреть ВСЕ ветвиСледующая ветвь*Отображение Ветвями

Страниц в этой нити: << 45 | 46 | 47 | 48 | 49 | 50 | 51 | 52 | 53 | 54 | 55 | 56 | 57 | 58 | 59 | 60 | 61 | 62 | 63 | 64 | 65 | (показать все)
Victorian
03/07/10 19:07

# 772310

Re: Бета-версия 6.0 программы "Цитата из Библии" нов [re: AlekId, #771513] Help admins  

резюмируя, у Ц. есть все необходимые функции поддержки кодировок.
Это не так - нет поддержки BOM-кода для кодировки UTF-8.
Я не смог сделать перевод в кодировку 65001, сделал в кодировке 1201.

AlekId
04/07/10 02:49

# 772370

Re: Бета-версия 6.0 программы "Цитата из Библии" нов [re: Victorian, #772310] Help admins  

Это не так - нет поддержки BOM-кода для кодировки UTF-8.
А поддержка самого utf-8 есть... не так ли?
Ц. использует BOM для двухбайтового представления юникода, чтобы определить порядок байт. Для однобайтовых кодировок в этом нет нужды.
Я не смог сделать перевод в кодировку 65001, сделал в кодировке 1201
А в самих этих файлах модуля, в html, вы проверили, что есть строчка
<meta http-equiv="content-type" content="text/html; charset=utf-8">
или там в чарсете значится что-то не то?
Поддержка кодировок, насколько я знаю, сделана Дорошем, и сделана неплохо.

Victorian
04/07/10 08:48

# 772382

Re: Бета-версия 6.0 программы "Цитата из Библии" нов [re: AlekId, #772370] Help admins  

Это не так - нет поддержки BOM-кода для кодировки UTF-8.
А поддержка самого utf-8 есть... не так ли?
Вопрос поднят именно потому, что её нет. Программа воспринимает кодировку 1251 и на экране отображает соотвествующими искаженными символами, которые должны были быть прочитаны как кодировка 65001 и преобразованы в двубайтную UNICODE системными средствами (сама система не поддерживает однобайтного UNICODE, преобразуя её в памяти в двубайтную). В начале файла есть BOM (EF BB BF), неоднозначностей быть не должно и не нужно никаких дополнительных указаний на UTF-8.
Ц. использует BOM для двухбайтового представления юникода, чтобы определить порядок байт. Для однобайтовых кодировок в этом нет нужды.
UTF-8 не является однобайтной кодировкой, у неё многобайтные символы, предаставленные в упакованном виде. Однобайтная кодировка позволяет представить 256 символов только, а эта может представить 24-битный символ (16777216 различных символов одновременно в окне программы).
Ссылку на описание назначения BOM-кода я давал, и UTF-8 предполагает наличие BOM-кода.
Равно как и двубайтная кодировка может быть представлено без него, и программа должна все равно принять эту кодировку, чего нет (вот тут и можно уточнять используемую кодировку с помощью тэгов).
А в самих этих файлах модуля, в html, вы проверили, что есть строчка
<meta http-equiv="content-type" content="text/html; charset=utf-8">
Ставил, как и указание на кодировку UTF-8. Бесполезно. Программа не понимает. Не понимает также, если изымать BOM-код, когда указания на кодировку должны быть действенны.
Поддержка кодировок, насколько я знаю, сделана Дорошем, и сделана неплохо.
Спасибо ему, работает поддержка UNICODE-32 в виде чарсетов 1200 и 1201.

AlekId
04/07/10 15:40

# 772415

Re: Бета-версия 6.0 программы "Цитата из Библии" нов [re: Victorian, #772382] Help admins  

Ставил, как и указание на кодировку UTF-8. Бесполезно. Программа не понимает.

Ну хорошо, я посмотрел, как там Дорош это реализовал. Такой код прокатит, думаю:
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
</head>
UTF-8 не является однобайтной кодировкой, у неё многобайтные символы

Мы с разных позиций смотрим. С позиции Delphi программирования, utf-8 текст может быть сохранена в однобайтовой строке, так как там нет где попало нулевых символов. В Delphi UTF8String - синоним или специализация строки однобайтовых символов. Так мы с ней и работаем, как с однобайтовой, ведь в этом вся соль utf-8.
UTF-8 предполагает наличие BOM-кода

Разве есть такой международный стандарт? Я вам скажу какой стандарт есть: стандарт html, так вот по нему тег meta должен находится внутри секции head, а в теге meta и должна указываться кодировка, если что... И ведь если бы ваши файлы модуля соответствовали этому стандарту, то - дайте угадаю - вопрос не возник бы...

Равно как и двубайтная кодировка может быть представлено без него, и программа должна все равно принять эту кодировку
Ну нет, вряд ли. Уж если взялся чел делать модуль, так хоть пусть минимальные условия соблюдает.
Честно, я уже устал при помощи замысловатого и сложного кода маскировать многоразличные недостатки модулей. Сравните, например, с модулями аналогичных проектов типа eSword... Так таких вольностей с кодировками и прочим вообще быть не может.
работает поддержка UNICODE-32 в виде чарсетов 1200 и 1201
Utf-16 имели в виду? Может, тогда и не стоит усложнять. Все равно Ц. все тексты перекодирует в стандартный utf-16 прежде, чем начать какую-либо обработку.

Исправлено пользователем AlekId 04/07/10 16:46.


Victorian
04/07/10 16:34

# 772422

Re: Бета-версия 6.0 программы "Цитата из Библии" нов [re: AlekId, #772415] Help admins  

<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
</head>
Поставил, сработало.

Только это выход на тот случай, если сам файл содержит текст в кодировке UTF-8 и не содержит начальные байты BOM-метки, характеризующие формат данных.
Ведь чтобы прочитать вышеприведенный текст, кодировка должна быть совместима с ASCII, т.е. не содержать BOM-кода. Я его специально удалил для этого.
Предполагается, что если читаю файл с кодировкой UTF-8, то при наличии BOM-кода он правильно отображается и обрабатывается всеми возможными программами без необходимости задавать уточняющие вопросы о кодировке, в которой содержатся в нём данные. Одного наличия BOM-кода должно быть достаточно, чтобы сделать вышеописанную конструкцию излишней.

Мы с разных позиций смотрим
Это понятно, я смотрю с точки зрения низкого уровня - формата хранения данных в самом файле.

UTF-8 предполагает наличие BOM-кода
Разве есть такой международный стандарт? Я вам скажу какой стандарт есть: стандарт html, так вот по нему тег meta должен находится внутри секции head, а в теге meta и должна указываться кодировка, если что...
Опять мы говорим на разных языках: когда речь заходит о тегах, то файл уже должен быть в формате, в котором возможно прочитать эти теги. Например, в кодировке 1200 или 1201 ни один тег не поможет, ибо там однобайтные "правильные" символы ANSI чередуются с дополняющими до 16 бит байтами, в частности нулевыми. То есть текст, прочитанный без BOM-кода и потому не загруженный в виде двухбайтовых символов, не может быть воспринят как содержащий теги. Для этого потребуется пробное преобразование, чтобы компенсировать этот глюк, попытаться подобрать кодировку.

Наличие же BOM-кода позволяет на низком уровне принять данные в том формате, который позволит хотя бы разобрать теги.
Теги имеют смысл только для однобайтных кодировок, когда матрица из 256 символов может содержать символы различных языков, в различных кодировках.
В частности, у файлов в UTF-8 и UTF-16 может отсутствовать BOM-код, в этом случае потребуется ухищрение для распознавания кодировки для UTF-16, и проще будет прочитать тег в кодировке UTF-8. Если конечно, в последнем случае проигнорировать те многобайтные символы, что способны сбить программу "с толку".

И ведь если бы ваши файлы модуля соответствовали этому стандарту, то - дайте угадаю - вопрос не возник бы...
Простите великодушно!
Я вообще-то ориентировался на реализацию существующих модулей, в которых данный тег нигде не присутствует, даже в JSS-модуле.
И он не является международным стандартом, а скорее рекомендацией для данной программы.

Логично соблюсти единообразие, и если для распознавания кодировки UTF-16 тербуется BOM-код, то также достаточно бы соответствующего BOM-кода для распознавания кодировки UTF-8.

Для примера, я уже приводил случай в JSS-модулем, когда пытался текст перенести в файл с той же кодировкой 1201, но не содержащего в начале байтов BOM-кода. Результат - программа вообще отказывалась прочитать этот модуль. Не помогают ни явное наличие первой строки "DefaultEncoding=utf-16", ни вышеописанный тэг.

Уж если взялся чел делать модуль, так хоть пусть минимальные условия соблюдает.
Честно, я уже устал при помощи замысловатого и сложного кода маскировать многоразличные недостатки модулей.
Тут речь не о недостатках модуля.
Скорее об иерархии объектов или структур данных.
Ведь для того чтобы прочесть модуль и распознать его содержимое, должна быть ему сопоставлена правильная кодировка.

Скажите на милость:
вот я добавил тэги в файлы модуля, с которым экспериментирую.
А как быть с файлом bibleqt.ini, в котором этот тэг не решает проблемы?
Я вижу искаженные символы в названиях глав и в оглавлении (окно навигации и окно закладок).
Даже название самого модуля искажено, и тэг тут не помощник (вообще удивительно что программа на него не руганулась, где ему не место).

Utf-16 имели в виду? Может, тогда и не стоит усложнять. Все равно Ц. все тексты перекодирует в стандартный utf-16 прежде, чем начать какую-либо обработку.
Стоит не усложнять даже, а прсото приводить ситуацию к здравому смыслу.
Ведь нет смысла преобразовывать из однобайтной кодировки в двухбайтную, если при этом есть издержки в виде удвоения объемов файлов модуля.
В этом смысле кодировки 1200 и 1201 не совсем удобны, но без всяких потерь устроила бы кодировка 65001 (UTF-8), которая сохранила бы Status Quo.

Усложнения практически нет: раз программа умеет понимать два BOM-кода для UTF-16, то несложно было бы заодно научить понимать BOM-код для UTF-8. Наличие BOM-кода исключает возможность наличия внутри файла текста в других кодировках, кроме как UTF-8.

Зато при этом появляется возможность переносить данные в другие программы, работающие в UNICODE.
Появляется смысл делать двухбайтные шрифты взамен однобайтных UCS, исходя из поддержания совместимости со старыми модулями.
Можно по мере необходимости вводить некоторые символы, которым не нашлось места в однобайтных кодировках прежних модулей.

P.S. Пока надо бы хотя бы заставить программу воспринимать файл bibleqt.ini в кодировке UTF-8, научив её разумно воспринимать его BOM-код.
P.P.S. Ещё один "побочный эффект": если файл кодировке UTF-16 и есть BOM-код, то вышеописанный тэг просто игнорируется. Что и должно быть и в случае с UTF-8.

AlekId
04/07/10 20:15

# 772452

Re: Бета-версия 6.0 программы "Цитата из Библии" нов [re: Victorian, #772422] Help admins  

Например, в кодировке 1200 или 1201 ни один тег не поможет, ибо там однобайтные "правильные" символы ANSI чередуются с дополняющими до 16 бит байтами, в частности нулевыми.

В Ц. BOM как раз и используется именно как маркер utf-16. Его отсутствие собственно говорит о том, что с файлом можно обращаться как с ASCII кодировкой, то есть все символы 1..127 есть инвариант для любой кодировки не BOM-кодировки. Это верно и для ANSI и для utf-8. Теги читаемы.
Вот только эти два вида кодировок Ц. поддерживает и будет поддерживать впредь: (1) ASCII-инвариантные однобайтовые и (2) Utf-16 с BOM. Третьего не дано.

В частности, у файлов в UTF-8 и UTF-16 может отсутствовать BOM-код

Для примера, я уже приводил случай в JSS-модулем, когда пытался текст перенести в файл с той же кодировкой 1201, но не содержащего в начале байтов BOM-кода. Результат - программа вообще отказывалась прочитать этот модуль. Не помогают ни явное наличие первой строки "DefaultEncoding=utf-16", ни вышеописанный тэг.

Utf-16 без BOM не будет поддерживаться, впрочем, вы и так ярый сторонник BOM.

Логично соблюсти единообразие, и если для распознавания кодировки UTF-16 тербуется BOM-код, то также достаточно бы соответствующего BOM-кода для распознавания кодировки UTF-8.
Я вам указал иное единообразие, которое избрал Дорош и которое работает. Зачем трогать то, что уже работает?

Скажите на милость: вот я добавил тэги в файлы модуля, с которым экспериментирую. А как быть с файлом bibleqt.ini, в котором этот тэг не решает проблемы?


DefaultEncoding=utf-8

Ведь нет смысла преобразовывать из однобайтной кодировки в двухбайтную, если при этом есть издержки в виде удвоения объемов файлов модуля.

utf-8 вам тут не поможет, ведь русские символы там не одним байтом кодируются.

В этом смысле кодировки 1200 и 1201 не совсем удобны, но без всяких потерь устроила бы кодировка 65001 (UTF-8), которая сохранила бы Status Quo.


В этом случае(копеечной экономии) лучше всего использовать windows-1251 ANSI, чтобы еще и Ц.5 сохранить совместимость. А хотите лучшей экономии, так для этого есть поддержка сжатых модулей, там ни много ни мало 7z сжатие, в том числе PPMD алгоритм, которые ужмет раза в 4+ текстовый файл.

Наличие BOM-кода исключает возможность наличия внутри файла текста в других кодировках, кроме как UTF-8.
Первая заповедь программиста: не трогай, что уже и так работает. Зачем я буду искать приключения, изменяя чужой код, если в итоге получу то же? Минимальное преимущество. Сколько пользователей это заметит?
Распознавание библейских ссылок, поиск в библиотеке по названиям модулей/книг/меток - от этого удобней будет всем, это качественный рост.
А зачем я буду тратить время на опцию? У меня нет этого времени.
Зато при этом появляется возможность переносить данные в другие программы, работающие в UNICODE.
Другие библейские программы? Вы шутите, наверное? Ц. есть стандарт библейского ПО на xUssr пространстве, и я не стану помогать иным проектам конкурировать с ней. А Word и OpenOffice достаточно умны, чтобы понять эти файлы.

Появляется смысл делать двухбайтные шрифты взамен однобайтных UCS, исходя из поддержания совместимости со старыми модулями.
Можно по мере необходимости вводить некоторые символы, которым не нашлось места в однобайтных кодировках прежних модулей.
Не понял. Думаю, Ц.5 юникод ни под каким соусом не поймет, в том числе и utf-8.
Пока надо бы хотя бы заставить программу воспринимать файл bibleqt.ini в кодировке UTF-8, научив её разумно воспринимать его BOM-код.

Я указал вам иной работающий способ.

AlekId
05/07/10 19:15

# 772607

Re: Бета-версия 6.0 программы "Цитата из Библии" нов [re: AlekId, #772452] Help admins  

a9a Распознавание ссылок во втором приближении. Тестируем, отписываемся.

Victorian
05/07/10 20:03

# 772615

Re: Бета-версия 6.0 программы "Цитата из Библии" нов [re: AlekId, #772452] Help admins  

как быть с файлом bibleqt.ini, в котором этот тэг не решает проблемы?
DefaultEncoding=utf-8
Я бы не стал задавать столь сложный для вас вопрос, если бы это работало.

Вышеприведенная строка есть, с ней получаю неудобочитаемый текст, в результате того, что программа не понимает, что UTF-8 не является однобайтной кодировкой, а скорее родственница UTF-16 и UTF-32 под эгидой UNICODE.

Пока надо бы хотя бы заставить программу воспринимать файл bibleqt.ini в кодировке UTF-8, научив её разумно воспринимать его BOM-код.
Я указал вам иной работающий способ.
Я его не вижу.
Программа упорно считает, что текст содержится в кодировке 1251.

Премудрости Соломоновы 1

Victorian
05/07/10 20:19

# 772620

Re: Бета-версия 6.0 программы "Цитата из Библии" нов [re: AlekId, #772452] Help admins  

Зато при этом появляется возможность переносить данные в другие программы, работающие в UNICODE.
Другие библейские программы? Вы шутите, наверное? Ц. есть стандарт библейского ПО на xUssr пространстве, и я не стану помогать иным проектам конкурировать с ней. А Word и OpenOffice достаточно умны, чтобы понять эти файлы.
Вы прекрасно знаете, что меня интересует совместимость со Skype, где не поддерживаются однобайтные кодировки вовсе (UTF-8 не является однобайтной кодировкой, это байтовый способ организации файла лишь только). Нужна возможность переноса отдельных цитат через буфер обмена.

Насчет конкурирующих программ. Меня это заинтересовало, - какие есть конкретные достойные примеры?
И поясните пожалуйста, чем для некоммерческого опенсорсного проекта может помешать конкуренция?

Я не вижу других причин для этого, кроме как мотивированным самолюбием. Например, OpenOffice скорее помогает утвердиться MS_Office, т.к. гарантирует совместимость с ним, и эта парочка может существовать неограниченно долго. Вроде бы если стандарт Ц. поддерживается другими конкурирующими программами, то тем самым этот стандарт организации модулей получает всеобщее признание и распространение. Было бы интересно услышать ваше мнение.

Victorian
05/07/10 20:26

# 772623

Re: Бета-версия 6.0 программы "Цитата из Библии" нов [re: AlekId, #772452] Help admins  

В этом случае(копеечной экономии) лучше всего использовать windows-1251 ANSI, чтобы еще и Ц.5 сохранить совместимость. А хотите лучшей экономии, так для этого есть поддержка сжатых модулей, там ни много ни мало 7z сжатие, в том числе PPMD алгоритм, которые ужмет раза в 4+ текстовый файл.
Это конечно, замечательно.
Хотелось бы прочитать о требованиях к организации модуля для реализации данной возможности.

Всё-таки, дело даже не столь в экономии. Мне претит мысль неоправданно раздувать файл, используя UTF-16 там, где UTF-8 сделает файл компактнее и без сжатия. Но это не главное. Главное, что с моей точки зрения, UTF-8 находится в промежутке между UTF-16 и UTF-32, а потому более перспективен.
Как насчёт поддержки UTF-32 в Цитатнике?


Страниц в этой нити: << 45 | 46 | 47 | 48 | 49 | 50 | 51 | 52 | 53 | 54 | 55 | 56 | 57 | 58 | 59 | 60 | 61 | 62 | 63 | 64 | 65 | (показать все)

ОТВЕТИТЬ ВСЕМ   Просмотреть ВСЕ ветвиСледующая ветвь*Отображение Ветвями
Перейти на