Page 2 of 4

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

Posted: Sun 04 Nov, 2018 00:18
by buniak_a_h
Здравствуйте!
Реализовал "расширенную" версию функции GetMsg.







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

В связи с включением в скрипт информационных данных (истории, примеров, инструкции) он разросся, и я не стану больше помещать сам скрипт в текст поста. Только во вложении.
GetMsg.v5.lua.7z
Версия 1.5.1
(4.97 KiB) Downloaded 154 times

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

Posted: Tue 06 Nov, 2018 18:38
by 2useven10

Latest post of the previous page:

buniak_a_h, Насколько я понял...
Вы читаете .lng файл,
если BOM у него в середине - файл 'плохой',
если для себя вы BOM убрали - ваш скрипт отработает,
но файл останется плохим и это может вылезти где-то ещё (если файл читается другими средствами).
Если ваш скритп покажет ошибку - файл может быть исправлен раньше, т.е. ваш скрипт будет 'спец. средством' обнаружившим ошибку.

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

Posted: Tue 06 Nov, 2018 19:11
by buniak_a_h
2useven10 wrote: Tue 06 Nov, 2018 18:38 Если ваш скритп покажет ошибку - файл может быть исправлен раньше, т.е. ваш скрипт будет 'спец. средством' обнаружившим ошибку.
Понятно, спасибо. Легко, сделаю диагностику. Но Ignore всё же оставлю...

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

Posted: Tue 06 Nov, 2018 19:19
by buniak_a_h
Кстати!
Wikipedia
Если же символ U+FEFF встречается в середине потока данных, он должен интерпретироваться как «нулевой ширины неразрывный пробел» (по существу, неотображаемый и ничего не меняющий символ)
Т.е. по стандарту BOM-сигнатуру надо просто игнорировать...
Т.е. вроде как файл-то вполне валидный. А если другой софт будет "валиться" BOM-ом внутри, то это - проблема другого софта...

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

Posted: Tue 06 Nov, 2018 19:55
by HaRT
buniak_a_h wrote: Tue 06 Nov, 2018 19:19
Wikipedia wrote: Если же символ U+FEFF встречается в середине потока данных, он должен интерпретироваться как «нулевой ширины неразрывный пробел» (по существу, неотображаемый и ничего не меняющий символ)
Однако не стоит забывать, что это относится только к маркеру для UTF-16, но не для UTF-8.

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

Posted: Tue 06 Nov, 2018 20:21
by DrKnS
Я так понимаю, что служебная информация в начале lng никого не напрягает, все упирается в противный бом?

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

Posted: Tue 06 Nov, 2018 20:59
by 2useven10
Как я понимаю, служебная информация скриптом благополучно игнорируется с BOM или без него.
Проблемы могут быть при склеивании 'самодельных' .lng файлов в которых никакой служебной информации нет.

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

Posted: Tue 06 Nov, 2018 22:00
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, полученные от сотрудников. Ситуация гипотетическая, но "оправдывающая" мою лень (нежелание проверять, начало ли файла).

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

Posted: Tue 06 Nov, 2018 22:05
by HaRT
buniak_a_h wrote: Tue 06 Nov, 2018 22:00 По стандарту BOM в любом месте, кроме начала, надо заменять на \n.
Это по какому такому стандарту?! На странице по ссылке написано, что нежелательное поведение наблюдается (из-за неправильного софта), а не то, что наблюдаемое нежелательное поведение является стандартным.

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

Posted: Tue 06 Nov, 2018 22:28
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 надо просто игнорировать.
Короче, тема не стоит времени, потраченного на обсуждение. Ну, игнорирую - и игнорирую. Хуже от этого никому не станет (если кто-нить станет использовать скрипт), а вот помочь может.

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

Posted: Wed 07 Nov, 2018 08:28
by John Doe
buniak_a_h wrote: Tue 06 Nov, 2018 22:28 Ну, игнорирую - и игнорирую
Непоследовательно игнорируете. Если уж у вас бом может встретится в любом месте, то недостаточно его игнорировать в начале строк.

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

Posted: Wed 07 Nov, 2018 08:41
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. Не стоит тема того. Меня вполне устраивает то, что написано. Я бы и этим не заморачивался бы, если б не напоролся на трудно распознаваемую ошибку. Исходники скрипта - открытые. Живите кто хотите ©Успенский .

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

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

P.S.
Мне всё равно что там вы делаете в скрипте, уточняю исключительно для ясности.

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

Posted: Wed 07 Nov, 2018 09:17
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 в начале строки не виден совсем никак, а поиск делает невозможным. Именно поэтому имеет смысл его оставить, а остальное - от лукавого.

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

Posted: Tue 20 Aug, 2019 07:39
by buniak_a_h
Выложена 4-я версия скрипта.
1. Добавлена возможность "многострочных строк"
2. Добавлена возможность указания не строки, а, например, функции (передача аргументов обеспечивается). Возвращаемое значение может быть не только строкового типа.

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

Posted: Fri 06 Dec, 2019 07:44
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. Расширение переменных среды.

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

Posted: Fri 06 Dec, 2019 12:42
by John Doe
Из шапки не вполне ясно, как этим пользоваться.
А всё что до "Похоже, нет." стоит убрать под спойлер.