Чтение из языкового файла .lng (расширение GetMsg)

Здесь обсуждается всё, что касается макросов.
User avatar
buniak_a_h
Posts: 4234
Joined: Sat 20 Apr, 2013 00:17
Location: Санкт-Петробад
Has thanked: 222 times
Been thanked: 642 times
Contact:

Чтение из языкового файла .lng (расширение GetMsg)

Post by buniak_a_h »

Здравствуйте!
Реализовал "расширенную" версию функции GetMsg.







Выпустил версию 5.

В связи с включением в скрипт информационных данных (истории, примеров, инструкции) он разросся, и я не стану больше помещать сам скрипт в текст поста. Только во вложении.
GetMsg.v5.lua.7z
Версия 1.5.1
(4.97 KiB) Downloaded 144 times
Last edited by buniak_a_h on Sat 28 Dec, 2019 07:25, edited 8 times in total.
User avatar
buniak_a_h
Posts: 4234
Joined: Sat 20 Apr, 2013 00:17
Location: Санкт-Петробад
Has thanked: 222 times
Been thanked: 642 times
Contact:

Чтение из языкового файла .lng

Post by buniak_a_h »

Latest post of the previous page:

2useven10 wrote: Tue 06 Nov, 2018 15:01
buniak_a_h wrote: Tue 06 Nov, 2018 14:49 Просто проверка BOM в каждой строке пользовательского (а, значит, не очень большого) файла - маленькая плата за гарантию от трудно находимой ошибки.
Если на этом обработка файла заканчивается, или вы отдаёте исправленный файл - да, всё хорошо.
Но если файл с BOM в середине вы передаёте дальше, то предпочтительнее показывать ошибку, а не прятать её.
Чо-т я затормозил...
1. обработка какого файла?
2. Исправленный файл скрипта - в первом посте темы. Если Вы про исправленный файл с несколькими BOM-ами в разных строках, то (а) это был тест и (б) кому я должен его отдать?
3. Прячу ошибку опять же не я. Я встроенного ФАРовского редактора не касался. Я тоже считаю, что BOM должен быть виден (или всегда, или внутри файла - на вкус и цвет...). Но редактор делал не я.
3. Что Вы предлагаете мне сделать? Убрать анализ в каждой строке - я уже объяснил, что может привести к ошибке, которую невозможно найти без спец. средств типа Hex Editor или вообще сторонних редакторов. Юзеру надо облегчать жизнь, а не усложнять... Или Вы хотите получить пример?
2useven10
Posts: 5192
Joined: Mon 07 Sep, 2009 10:40
Has thanked: 18 times
Been thanked: 309 times

Чтение из языкового файла .lng

Post by 2useven10 »

buniak_a_h, Насколько я понял...
Вы читаете .lng файл,
если BOM у него в середине - файл 'плохой',
если для себя вы BOM убрали - ваш скрипт отработает,
но файл останется плохим и это может вылезти где-то ещё (если файл читается другими средствами).
Если ваш скритп покажет ошибку - файл может быть исправлен раньше, т.е. ваш скрипт будет 'спец. средством' обнаружившим ошибку.
User avatar
buniak_a_h
Posts: 4234
Joined: Sat 20 Apr, 2013 00:17
Location: Санкт-Петробад
Has thanked: 222 times
Been thanked: 642 times
Contact:

Чтение из языкового файла .lng

Post by buniak_a_h »

2useven10 wrote: Tue 06 Nov, 2018 18:38 Если ваш скритп покажет ошибку - файл может быть исправлен раньше, т.е. ваш скрипт будет 'спец. средством' обнаружившим ошибку.
Понятно, спасибо. Легко, сделаю диагностику. Но Ignore всё же оставлю...
User avatar
buniak_a_h
Posts: 4234
Joined: Sat 20 Apr, 2013 00:17
Location: Санкт-Петробад
Has thanked: 222 times
Been thanked: 642 times
Contact:

Чтение из языкового файла .lng

Post by buniak_a_h »

Кстати!
Wikipedia
Если же символ U+FEFF встречается в середине потока данных, он должен интерпретироваться как «нулевой ширины неразрывный пробел» (по существу, неотображаемый и ничего не меняющий символ)
Т.е. по стандарту BOM-сигнатуру надо просто игнорировать...
Т.е. вроде как файл-то вполне валидный. А если другой софт будет "валиться" BOM-ом внутри, то это - проблема другого софта...
User avatar
HaRT
Moderator
Posts: 10806
Joined: Tue 30 Aug, 2005 17:21
Has thanked: 220 times
Been thanked: 357 times

Чтение из языкового файла .lng

Post by HaRT »

buniak_a_h wrote: Tue 06 Nov, 2018 19:19
Wikipedia wrote: Если же символ U+FEFF встречается в середине потока данных, он должен интерпретироваться как «нулевой ширины неразрывный пробел» (по существу, неотображаемый и ничего не меняющий символ)
Однако не стоит забывать, что это относится только к маркеру для UTF-16, но не для UTF-8.
Фар есть инструмент, а не нянька. © 2009 DrKnS
User avatar
DrKnS
Posts: 6114
Joined: Thu 04 Aug, 2005 06:44
Location: Kyiv
Has thanked: 12 times
Been thanked: 426 times

Чтение из языкового файла .lng

Post by DrKnS »

Я так понимаю, что служебная информация в начале lng никого не напрягает, все упирается в противный бом?
2useven10
Posts: 5192
Joined: Mon 07 Sep, 2009 10:40
Has thanked: 18 times
Been thanked: 309 times

Чтение из языкового файла .lng

Post by 2useven10 »

Как я понимаю, служебная информация скриптом благополучно игнорируется с BOM или без него.
Проблемы могут быть при склеивании 'самодельных' .lng файлов в которых никакой служебной информации нет.
User avatar
buniak_a_h
Posts: 4234
Joined: Sat 20 Apr, 2013 00:17
Location: Санкт-Петробад
Has thanked: 222 times
Been thanked: 642 times
Contact:

Чтение из языкового файла .lng

Post by buniak_a_h »

HaRT wrote: Tue 06 Nov, 2018 19:55 Однако не стоит забывать, что это относится только к маркеру для UTF-16, но не для UTF-8.
На сайтеW3Cнаписано:
Potential issues with the UTF-8 BOM
<...>
This is because the BOM is not stripped before inclusion into the page, and acts like a character occupying a line of text.
По стандарту BOM в любом месте, кроме начала, надо заменять на \n. Но тогда переделывать проверку, искать тег ДО и ПОСЛЕ BOM ... В этом как раз есть сермяга: при склеивании первый файл может не оканчиваться пусто строкой. Но вот это - точно может сильно замедлить получение локализованной строки (поиск)... Проще, действительно, удалять в начале всех строк. Компромисс...
DrKnS wrote: Tue 06 Nov, 2018 20:21 Я так понимаю, что служебная информация в начале lng никого не напрягает, все упирается в противный бом?
Я не знаю, на что может повлиять эта служебная информация в плане получения строки по тегу. Её я в скрипте просто игнорирую.
2useven10 wrote: Tue 06 Nov, 2018 20:59 Проблемы могут быть при склеивании 'самодельных' .lng файлов в которых никакой служебной информации нет.
Совершенно верно. Просто представил, что группа товарищей "локализовала" нечто, разделив работу, а потом администратор просто слил файлы *.lng.custom, полученные от сотрудников. Ситуация гипотетическая, но "оправдывающая" мою лень (нежелание проверять, начало ли файла).
User avatar
HaRT
Moderator
Posts: 10806
Joined: Tue 30 Aug, 2005 17:21
Has thanked: 220 times
Been thanked: 357 times

Чтение из языкового файла .lng

Post by HaRT »

buniak_a_h wrote: Tue 06 Nov, 2018 22:00 По стандарту BOM в любом месте, кроме начала, надо заменять на \n.
Это по какому такому стандарту?! На странице по ссылке написано, что нежелательное поведение наблюдается (из-за неправильного софта), а не то, что наблюдаемое нежелательное поведение является стандартным.
Фар есть инструмент, а не нянька. © 2009 DrKnS
User avatar
buniak_a_h
Posts: 4234
Joined: Sat 20 Apr, 2013 00:17
Location: Санкт-Петробад
Has thanked: 222 times
Been thanked: 642 times
Contact:

Чтение из языкового файла .lng

Post by buniak_a_h »

HaRT wrote: Tue 06 Nov, 2018 22:05
buniak_a_h wrote: Tue 06 Nov, 2018 22:00 По стандарту BOM в любом месте, кроме начала, надо заменять на \n.
Это по какому такому стандарту?! На странице по ссылке написано, что нежелательное поведение наблюдается (из-за неправильного софта), а не то, что наблюдаемое нежелательное поведение является стандартным.
Извините, неточно выразился.
Имеется софт, который интерпретирует BOM как \n . И этот софт упомянут в официальных документах. Значит, такое поведение не считается криминалом, а некоей "особенностью", которую надо учитывать.
По стандарту же BOM надо просто игнорировать.
Короче, тема не стоит времени, потраченного на обсуждение. Ну, игнорирую - и игнорирую. Хуже от этого никому не станет (если кто-нить станет использовать скрипт), а вот помочь может.
User avatar
John Doe
Бюрократ
Posts: 13801
Joined: Wed 27 Apr, 2005 20:42
Has thanked: 72 times
Been thanked: 425 times
Contact:

Чтение из языкового файла .lng

Post by John Doe »

buniak_a_h wrote: Tue 06 Nov, 2018 22:28 Ну, игнорирую - и игнорирую
Непоследовательно игнорируете. Если уж у вас бом может встретится в любом месте, то недостаточно его игнорировать в начале строк.
User avatar
buniak_a_h
Posts: 4234
Joined: Sat 20 Apr, 2013 00:17
Location: Санкт-Петробад
Has thanked: 222 times
Been thanked: 642 times
Contact:

Чтение из языкового файла .lng

Post by buniak_a_h »

John Doe wrote: Wed 07 Nov, 2018 08:28
buniak_a_h wrote: Tue 06 Nov, 2018 22:28 Ну, игнорирую - и игнорирую
Непоследовательно игнорируете. Если уж у вас бом может встретится в любом месте, то недостаточно его ингнорировать в начале строк.
Я в курсе. Я же писал - разумный компромисс. С одной стороны, намного эффективнее, чем поиск в любом месте каждой строки (и разбивание строки на две); другой - BOM в начале строки объясним, а в середине - ну, это экзотика какая-то...
И давайте уже закончим обсуждение BOM. Не стоит тема того. Меня вполне устраивает то, что написано. Я бы и этим не заморачивался бы, если б не напоролся на трудно распознаваемую ошибку. Исходники скрипта - открытые. Живите кто хотите ©Успенский .
User avatar
John Doe
Бюрократ
Posts: 13801
Joined: Wed 27 Apr, 2005 20:42
Has thanked: 72 times
Been thanked: 425 times
Contact:

Чтение из языкового файла .lng

Post by John Doe »

buniak_a_h wrote: Wed 07 Nov, 2018 08:41 BOM в начале строки объясним, а в середине - ну, это экзотика какая-то...
Вы предположили что бом может появиться в результате слияния 2х файлов.
Если последняя строка первого файла не завершалась переводом строки, то ваш бом и будет как раз в середине строки.

P.S.
Мне всё равно что там вы делаете в скрипте, уточняю исключительно для ясности.
User avatar
buniak_a_h
Posts: 4234
Joined: Sat 20 Apr, 2013 00:17
Location: Санкт-Петробад
Has thanked: 222 times
Been thanked: 642 times
Contact:

Чтение из языкового файла .lng

Post by buniak_a_h »

John Doe wrote: Wed 07 Nov, 2018 08:54 Вы предположили что бом может появиться в результате слияния 2х файлов.
Если последняя строка первого файла не завершалась переводом строки, то ваш бом и будет как раз в середине строки.
Снова.
buniak_a_h wrote: Tue 06 Nov, 2018 22:00 <...> при склеивании первый файл может не оканчиваться пустой строкой. Но вот это - точно может сильно замедлить получение локализованной строки (поиск)... Проще, действительно, удалять в начале всех строк. Компромисс...
Ну и ещё; в этом случае две строки из разных файлов "склеятся" в одну, м это БУДЕТ ВИДНО в редакторе; в гипотетической ситуации сливания админ, который это будет делать, сможет увидеть и разбить такую строку. После разбивания BOM оказывается в конце строки (проверил - так делает встроенный редактор ФАРа). Поиску это не помешает.
А вот BOM в начале строки не виден совсем никак, а поиск делает невозможным. Именно поэтому имеет смысл его оставить, а остальное - от лукавого.
User avatar
buniak_a_h
Posts: 4234
Joined: Sat 20 Apr, 2013 00:17
Location: Санкт-Петробад
Has thanked: 222 times
Been thanked: 642 times
Contact:

Чтение из языкового файла .lng

Post by buniak_a_h »

Выложена 4-я версия скрипта.
1. Добавлена возможность "многострочных строк"
2. Добавлена возможность указания не строки, а, например, функции (передача аргументов обеспечивается). Возвращаемое значение может быть не только строкового типа.
Last edited by buniak_a_h on Tue 20 Aug, 2019 08:05, edited 1 time in total.
User avatar
buniak_a_h
Posts: 4234
Joined: Sat 20 Apr, 2013 00:17
Location: Санкт-Петробад
Has thanked: 222 times
Been thanked: 642 times
Contact:

Чтение из языкового файла .lng

Post by buniak_a_h »

Выложена 5-я версия. Основные изменения:
1. Поиск файла по маске и по регэкспу (учитывается служебная строка .Language=…
2. Раньше информация из файла File.lng.custom читалась ТОЛЬКО в формате <Name>="<Value>". Однако:
changelog wrote:Такой формат также допустим в .lng.custom файлах.

Code: Select all

//[MListFileSize]
" %1 bytes in %2 files, %3 folders "
3. Расширение переменных среды.
Post Reply

Return to “Обсуждение макросов”