Добро пожаловать на Открытый христианский форум JesusChrist.ru. Для того чтобы писать в форуме, Вам необходимо зарегистрироваться и войти на форум через ссылку для входа.
Только это выход на тот случай, если сам файл содержит текст в кодировке 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.
Re: Бета-версия 6.0 программы "Цитата из Библии"
[re: AlekId]
Re: Бета-версия 6.0 программы "Цитата из Библии"