string.upper(S) - русские буквы

Страницы: 1
RSS
string.upper(S) - русские буквы, Русские буквы в верхний регистр не получается сделать в string.upper(S) в Lua QUIK версии 8.13
 
Как просто и грамотно сделать string.upper(S) с русскими буквами в Lua QUIK версии 8.13?

Проблема в том, что string.upper('English') работает, а string.upper('русские буквы') не работатет.

Так как сделать string.upper('русские буквы') == 'РУССКИЕ БУКВЫ'
 
Стандартные текстовые функции Lua работают только с ASCII-строками, смена регистра работает через системную локаль.
Код
os.setlocale ( 'Russian_Russia.1251' ) -- 'ru_RU.CP1251', 'rus_RUS.CP1251', 'Russian_Russia.1251'
 
Можно вот так
Код
function upper(s)
  local str=""
  for i=1,string.len(s) do
    local byte=string.byte(s,i)
    local char=string.char(byte)
    if(byte>= 97)and(byte<=122)then char=string.char(byte-32) end -- Латинские буквы
    if(byte>=224)and(byte<=255)then char=string.char(byte-32) end -- Русские буквы
    if(byte==184)              then char=string.char(byte-16) end -- Русская ё
    str=str..char
  end
  return str
end
 
BlaZed, альтернативно:
Код
function string.upper ( str ) return str:gsub ( "([a-zа-я])", function ( c ) return string.char ( string.byte ( c ) - 32 ) end ) end
function string.lower ( str ) return str:gsub ( "([A-ZА-Я])", function ( c ) return string.char ( string.byte ( c ) + 32 ) end ) end
 
Цитата
Артем написал:
альтернативно:
Классный способ, еще бы в нем русскую "ё" учитывать, было бы идеально.
 
BlaZed, действительно, промах. Ну это в любом случае просто велосипединг. Правильный вариант - использовать системные функции и языковую локаль - первым ответом был предложен.
Код
function string.upper ( str ) return str:gsub ( "([a-zа-яё])", function ( c ) return string.char ( string.byte ( c ) - ( c == 'ё' and 16 or 32 ) ) end ) end
function string.lower ( str ) return str:gsub ( "([A-ZА-ЯЁ])", function ( c ) return string.char ( string.byte ( c ) + ( c == 'ё' and 16 or 32 ) ) end ) end
 
Считаю это ошибкой, которую разработчики QUIK должны исправить.
Интерфейс у терминала русский, по умолчанию для русских букв штатные upper / lower должны корректно работать.
 
Цитата
Артем написал:
Код
  os.setlocale (  'Russian_Russia.1251'  )  -- 'ru_RU.CP1251', 'rus_RUS.CP1251', 'Russian_Russia.1251'   
-- 'ru_RU.CP1251' для FreeBSD, 'rus_RUS.CP1251' для линукса, 'Russian_Russia.1251' для Windows -- я правильно понимаю?
 
Цитата
Артем написал:
Код
  os.setlocale (  'Russian_Russia.1251'  )  -- 'ru_RU.CP1251', 'rus_RUS.CP1251', 'Russian_Russia.1251'   
Попробовал:

было
Код
message(string.upper('привет'))
привет

стало
Код
os.setlocale('Russian_Russia.1251')
message(string.upper('привет'))
ПРИВЕТ

Работает! Спасибо!
 
Цитата
swerg написал:
Считаю это ошибкой, которую разработчики QUIK должны исправить.
Интерфейс у терминала русский, по умолчанию для русских букв штатные upper / lower должны корректно работать.
Да! Как тут тегнуть разработчиков Lua QUIK? Конечно они должны сделать нормально работающие РУССКИЕ БУКВЫ по умолчанию!
 
Цитата
swerg написал:
Считаю это ошибкой, которую разработчики QUIK должны исправить.
Интерфейс у терминала русский, по умолчанию для русских букв штатные upper / lower должны корректно работать.
интерфейс у терминала не только русский, увы...
www.bot4sale.ru        t.me/bot4sale
 
Цитата
s_mike@rambler.ru написал:
Цитата
swerg написал:
Считаю это ошибкой, которую разработчики QUIK должны исправить.
Интерфейс у терминала русский, по умолчанию для русских букв штатные upper / lower должны корректно работать.
интерфейс у терминала не только русский, увы...
И все же это ошибка

Запускать на только что запущенном квике, пока никакой скрипт локаль не установил еще
Код
message(string.upper('привет'))
message(os.setlocale(''))
message(string.upper('привет'))
Вывод:
Цитата
привет
Russian_Russia.1251
ПРИВЕТ
Как видно из примера, квик знает про нужную локаль, но почему то не устанавливает ее сам, хотя надо бы.

QUIK 8.13.1.16, интерфейс русский, Windows 10
 
BlaZed, эта функция берет системную локаль. У вас системная локаль совпадает с требуемой, у меня - English_United States.1252 и на ней преобразование регистра кириллицы не работает (в ней кириллицы-то нет).

По-хорошему, решение тут это перекомпилировать квик с поддержкой юникода (давно пора!) и все эти проблемы отпадут сами собой. Заодно не нужно будет пердолиться с настройками чтобы квик показывал человеческие буквы а не неандертальские крякозябры.


В отсуствии юникода нужно ставить локаль. Такие вещи устанавливать автоматически на стороне программы это плохая практика, но с учётом того что поддерживается только одна-единснтвенная кодировка 1251 то имел бы смысл устанавливать соответствующую локаль автоматически.
 
Цитата
Артем написал:
имел бы смысл устанавливать соответствующую локаль автоматически
Ага, не забыв при этом дать доступ на чтение символа разделителя дробной части числа (для строковых операций с числами).
Сравните:
Код
message(tostring(1.2))    --> 1.2
message(os.setlocale('')) --> Russian_Russia.1251
message(tostring(1.2))    --> 1,2

Возможно, ещё где-то что-то вылезет.
Я не могу быть заинтересован в устранении ошибок в чужом ПО больше, чем его разработчик.
 
Артем, Вот токо поддержки юникода Квику не хватало! Квик - это программа ДЛЯ ТОРГОВЛИ! И до тех пор, пока эта часть не заработает как часы, всю остальную херню вроде upper-lower надо вычищать отседова поганой метлой! Как я писал в своей книге (про JS):

Язык JavaScript. Количество никому не нужного мусора просто невероятное! Полное ощущение, что создатели языка ставили своей задачей поиздеваться над программистом и здравым смыслом. Методов-то, методов! В глазах рябит! Ну, очевидным образом anchor, big, blink, bold, fixed, fontcolor, fontsize, italics, lastIndexOf, link, small, strike, sub, sup отправляем на помойку. А charAt, indexOf, substring, toLowerCase, toUpperCase, возможно, ещё на что-то сгодятся. Кстати, у indexOf есть ещё пара нюансов, которые могут оказаться полезными: во-первых, искать может не только символ, но и подстроку и, во-вторых, может искать с определённой позиции (если задан второй аргумент).

Кошмарики с Date: getYear, getMonth, getDay, getHours, getMinutes, getSeconds, getTimezoneOffset, toGMTString, setSeconds и т.д. сведут с ума любого. И, главное – зачем?! Зачем это пользователю? Что, программисту заняться больше нечем?!

Первое же из того, что нам действительно необходимо, повергает программиста в шок. Итак, прошу любить и жаловать – метод charAt: возвращает символ из строки. Синтаксис: StringName.charAt(index); Нет, позвольте – какой ещё «метод»?! Это же всего лишь строка! У всех нормальных людей принято: Symbol=StringName[index]. Так я и думал вначале. Поверил же я в происходящее, когда увидел радостный вопль в учебнике: отныне можно var s=new String("a") – ура, товарищи! Это было реальное потрясение: что же ещё насовали в несчастную строку?

Украденный синтаксис языка С используется приблизительно в том же смысле, и лишь незначительно изуродован. Впрочем, в противном случае JS не просуществовал бы и недели. Самое ужасное, что JS при этом при всём – это всё-таки лучшее из того, что есть на клиенте!

Как оказалось, JS не способен интерпретировать функций, тела которых расположены в переменных – они должны быть явно прописаны в теле страницы. Убей, не понимаю, какая разница – но делать нечего: базовый набор функций придется подгружать на морду путём генерации тела функций из переменных во фреймы виртуальных страниц.

Опера не умеет перерисовывать группу фреймов, а Сафари – наоборот: только группу и может.

Лиса прекрасно всё рисует, но… только в том случае, если страничка будет иметь расширение SVG. Если переименовать её в HTM – девственно чистый лист!

После редактирования браузер quot втихаря заменяет на кавычки. Вот кто тебя просил?! Кавычка (как метаданные) предназначена для конкретного интерпретатора, и тут их сразу пять штук! Кавычка, которую должен увидеть юзер на экране – это вовсе не та кавычка, которую должен увидеть браузер как ограничитель параметра тега. И вовсе не та кавычка, которую должен увидеть интерпретатор JS, для которого она часть тела функции. И вовсе не та кавычка, которую должен увидеть монитор, для которого она разделитель параметров очереди. И вовсе не та кавычка, которую должен увидеть SPS, запихивающий все остальные кавычки на морду, кроме тех, которые он опознает как свои, и интерпретирует соответствующим образом. Проблема вовсе не загнать кавычку в строку, проблема не перепутать их разными итерпретаторами! А тут ещё «интеллектуальный» браузер гадит…

Вам хочется и здесь огрести подобного говна, господа? Мало того, что есть, ещё хочется?
 
Цитата
Старатель написал:
не забыв при этом дать доступ на чтение символа разделителя дробной части числа (для строковых операций с числами).
Да, я тож переживал на тему смены "американской десятичной точки 0.5" на "русскую десятичную запятую 0,5", но вроде норм -- старый код работает в математических выражениях типа
Код
os.setlocale('Russian_Russia.1251') --'ru_RU.CP1251' для FreeBSD, 'rus_RUS.CP1251' для линукса, 'Russian_Russia.1251' для Windows
b = 1
a = b + 0.5
message(tostring(a))
1,5 таки получается -- я переживал, что сглючит, распознав десятичную точку как разделитель тысяч или ещё как и будет математическая ошибка -- но вроде всё норм. Продолжаем в коде писать десятичную точку, хотя во внешнем выводе видим десятичную запятую :-)
Потому что если написать
Код
os.setlocale('Russian_Russia.1251') --'ru_RU.CP1251' для FreeBSD, 'rus_RUS.CP1251' для линукса, 'Russian_Russia.1251' для Windows
b = 1
a = b + 0,5
message(tostring(a))
1 будет :-)
 
Юрий Волошин, локаль влияет только на работу строковых функций, на сам язык никак не влияет. Можно задать регион применения локали: "collate", "ctype", "monetary", "numeric", "time".

Владимир,  юникод это стандарт, который надо соблюдать; кодовым страницам место на помойке, равно как и их преверженцам.
 
Цитата
Юрий Волошин написал:
во внешнем выводе видим десятичную запятую
При сохранении результатов в файл, особенно сериализации таблиц, это надо учитывать.
Я не могу быть заинтересован в устранении ошибок в чужом ПО больше, чем его разработчик.
 
Артем, НА КОЙ ХРЕН "этот стандарт надо соблюдать"? Кодировка 1251 (как и DOS, ISO, KOI и прочая хрень) - это ТОЖЕ стандарты! И у них, по крайней мере, ОДИН байт на символ! Что могут сотворить нынешние криворукие со стандартом с переменным числом байт на символ, можно только догадываться. К тому же, шрифты к этим стандартам всё равно необходимы! Ну, и как Вы будете воспроизводить японские иероглифы или арабскую вязь? Не занимайтесь ХЕРНЁЙ, господа! ДАВИТЬ надо подобные инициативы! В зародыше! Лично я рассматриваю их как источник дополнительных потенциальных глюков, и ТОЛЬКО так! То со сраной запятой вместо точки не могут разобраться, то со сраной датой, представленной в виде строки... Вот и засирают язык всяким говном. Керниган с Ричи даже printf из языка выбросили! Керниган рассказывал, что хотели включить, мучились, но всё-таки выбросили. Молодцы! Потому-то С и есть ВЕЧНЫЙ язык, что написан гениями, а не тупорылыми пидарасами, которые каждую вдарившую в их головожопу пое... как это в нормативной лексике... каждую лабуду стараются впендюрить в язык. "Творческий вклад", панимаш!
 
Владимир, ну чего тогда мелочиться, собсна - давайте поддержку русского языка вырежем, только английский оставим. Кому надо тот выучит, чо.
 
Артем, Если она после этого будет нормально торговать - давайте вырежем! Руками и ногами ЗА! Это торговая система, и она не обязана обслуживать выкрутасы страдальцев по букве ё или по регистру символов. А то загадят софт всяким говном, а потом ещё удивляются, что глючит.
 
Владимир, ну по итогу мы имеем что смена регистра в Lua решается средствами самого Lua и программисты арки тут ни при чём.


А поддержка языков просто решается: создаются такого рода файлы и из них читаются строчки. Если в файле строчки нет - ворнинг в консоль и подставить стандартный текст. Тут программисты-то не нужны, любую макаку со словарем можно посадить это делать.

Код
ru_RU.lang
open_connection="Установить соединение"
settings_menu="Настройки"
...
 
Артем, А я и не обвиняю программистов арки, я даже говорю, что если бы они и были "при чём", всё равно делать ничего не надо.

Я когда-то делал мультиязычные интерфейсы и конвертер из разных кодировок друг в друга, но все они были однобайтовыми (DOS, WIN, KOI, ISO, MAC), а UTF тогда ещё в природе не существовало (или, по крайней мере, никто про него не слышал). И там немало подводных камней! Например, горячие клавиши в меню на другом языке могут быть совершенно другими. Как и размеры строк и самих меню. И я совсем не уверен, что после "макаки" мы не напоремся на какие-нибудь крупные неприятности.
 
Владимир, кодовые страницы вымерли вместе с динозаврами, все адекватные люди уже работают только с юникодом и там таких проблем нет.
 
Артем, Кодовые страницы В ПРИНЦИПЕ не могут вымереть - это КЛАССИЧЕСКОЕ программирование  данными, и ничего более простого и эффективного придумать просто НЕЛЬЗЯ. Что до "адекватных людей" - так я тыщу раз видел, как эта шобла кидалась всем кагалом на очередное нововведение типа "плоского мира" (тогда ещё 32-разрядного) или того же юникода или нейросетей, после чего переписывала всю свою "современную" математику на очередную "блестящую идею". КАКИХ там "таких проблем нет"? Огласите весь список, пжалста! На любом программистском форуме, включая этот, идёт сплошной скулёж о проблемах, почти все из которых просто смехотворные. И нет этому конца - программисты вымерли "вместе с динозаврами". :smile:  
 
Владимир, как раз таки программистам с мозгами юникод проблем не создает никаких, а какая польза с универсального формата должно быть очевидно даже слепому.
 
Артем, Лапуль, программисты прошлого В МИЛЛИОН РАЗ лучше нынешнего стада баранов умели пользоваться мозгами по назначению. Это именно НЫНЕШНЕМУ стаду "польза с универсального формата должно быть очевидно даже слепому", а тогда никто подобными "проблемами" вообще не заморачивался - были задачи поважнее.

А вот такой вопрос к стаду "зрячих" КАКОЙ ИМЕННО  "универсальный формат" использовать предлагаете? Что, срочно хлебала захлопнули, умники хреновы? UTF-8? UTF-16? Ещё какой-то? А как насчёт ГРАФИЧЕСКИХ форматов? Их же ВАЩЕ НЕМЕРЯНО! А ну, где ваш "универсальный"? Правильно, В ЖОПЕ!

Между прочим, я встречался с Кеном Томпсоном примерно в то время (где-то в районе 1995 года). И он ни слова не говорил об "универсальном формате"! Ибо для него (как и для любого нормального программиста) это была рядовая задача, довольно занудная и не требующая мозгов вообще. А у вас-то откуда взялись мозги, господа? Я что-то не припомню случая, когда вы их использовали. :wink:  
 
Владимир, Прими таблетки и успокойся. Весь форум уже заспамил. Когда тебя уже забанят?
 
Александр, А за что меня банить, лапуль? Я ведь не спамлю, я как раз наоборот, спамящих вытравливаю. :wink:  И тыщу раз уж говорил: я спокоен как фараон в пирамиде!
 
Добрый день!

Действительно, по умолчанию строковые функции работают только с asci таблицей. Мы добавим умолчательную поддержку cp1251 в будущих версиях ПО.
 
Цитата
Roman Azarov написал: Мы добавим умолчательную поддержку cp1251 в будущих версиях ПО.
Ура! Здравый смысл победил!
Страницы: 1
Читают тему (гостей: 53)
Наверх