Какая кодировка используются в Lua?

Я бы хотел узнать о поведении терминала, где например нет кирилицы?

Квик не будет работать на системе, где не установлена кирилица?

В какой кодировке будут строки, если вызвать lua_tolstring для преобразования в unicode?

Вот это поворот :) Проведите, ответьте :)

Странный ответ. При чем здесь lua? Терминал же сохраняет строки для дальнейшего использования в луа?
Вот я хочу узнать, что вы туда записываете.

Странный вопрос, Вы же спрашиваете про Lua, а не про терминал QUIK.
О tostring нам известно не больше чем то что написано в официальной документации на сайте lua.org
Если интересует в какой кодировке сервер QUIK отправляет данные на терминал, то в ANSI.

Кодировка то какая всегда windows-1251? Или зависит от настроек сервера?

Хорошо. Если кодировка Windows - 1251, то в терминале где нет кирилицы, будут проблемы.
А сервер квик не знает, какая кодировка у клиента на компьютере есть, а какой нету.

Вы имеете ввиду OS где нет кирилицы.
Да будут проблемы.
Но они как правило решаются настройкой "язык для программ, не поддерживающих юникод" = русский
Естественно не знает

В этом случае какая кодировка будет? Например в таблице инструментов есть поле name - наименование инструмента и оно может быть на русском языке.
Тут что будет?

Всегда и везде будет кодировка windows-1251 или она зависит от терминала (его языка), ос (наличие кирилицы или нет) или сервека квик?
Я так знаю, что все строки в ANSI. Вопрос изначально был: кодировка строк windows-1251 или зависит от ос (CP_ACP) или сервера квик?

Получается, что в терминале на английском языке на английской винде, в таблице текущих параметров в поле бумага - будет аракадабра?

и

Логично что если в настройках терминала выбран английский то и интерфейс и все значения будут на английском.
К сожалению у нас нет китайской винды чтобы проверить. Однако английская раскладка поддерживается во всех локализациях Windows.
Вопрос не понятен, что значит "не верно"?

В русском терминале название акции - "Газпром", а в английском - она будет называться по-другому?

Ответить прямо религия запрещает? Мне ваши ответы не понятны, поэтому задаю уточнящие вопросы.
Есть ли квик джуниор с интерфейсом на английском языке для теста?

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

трындец, уши вянут от ваших вендузяцких лозунгов
https://www.lua.org/manual/5.3/manual.html#2.1

Абсолютно неверное утверждение. В случае автоматического преобразования числа в строку да, получается ASCIIZ (а можно сказать, что получается utf-8 или win-1251 или что угодно, т.к. первая страница у всех codepage одинаковая, если не учитывать экзотику), но в случае строки возвращается строка как она есть, ровно в том виде, в каком ее туда засунули, в том числе со внутренними нулями (что автоматически отвергает ASCIIZ и, кстати, позволяет при некоторой осторожности впихнуть даже utf-16).

Да поддерживает

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

Вообще все в компьютере это массив байт. Остальное все неверно. Ноль в конце это чисто сишная фишка, в паскале их нет например. Строка это не байты, а codepoints, каждая из которых может быть больше байта (до четырех например в utf8). Если вы разрежете строку посреди codepoint, обе половины уже не будут строками или, в лучшем случае, будут битыми строками. Отображение это вообще отдельная тема, там не только codepoints действуют, композиция включается, а еще куча параметров конкретного шрифта. Знание кодировки нужно для любых действий со строкой, отличных от простого копирования. Это если говорить о строках, а не о кучке мусора с приделанным ноликом. Прежде чем пояснять, стоит все же хоть немного тему изучить.

да...да ... только до конца параграфа :)

https://www.lua.org/manual/5.3/manual.html#lua_tolstring

Николай Камынин, вы выдергиваете особенность реализации и позиционируете ее как отличительный признак строки вообще. Луа добавляет ноль чисто для удобства и даже можно сказать чисто технически, потому что есть lua_pushlstring, принимающая размер, и вы можете сделать так
Если бы луа не добалял ноль, то в следующем вызове
вы бы получили "hell" без нуля на конце и крэшнули бы приложение, пытаясь работать с ним сишными функциями. Именно поэтому луа ноль и добавляет, чтобы всегда возвращать терминированную строку. А теперь следите за руками. В сях я пишу
в луа пишу
и внезапно получаю (широкую!) строку "HELLODOLLY". То есть луа не только сохранил строки в utf-16 и потом правильно вернул, но и правильно их склеил даже. Почему? А потому что плевал он на нолики в конце. У него есть сохраненная длина строки и по ней он ориентируется. Для сравнения сишный strcat (который по ноликам ориентируется) на таких строках сфейлит, вернет "HD", потому что тут после каждого байта ноль идет. Все это к чему. К тому, что в луа строки это тупо мусор заданной длины (даже без нолика), никакой семантики луа им не придает. А где должен бы придавать, там фейлит. Например, если я эту строчку "DOLLY" сделаю ключом в таблице (из сей), луа это слопает на ура. Но вот из самого луа я этого ключа не увижу (через перебор всех ключей только), потому что кодировка не совпадает. О чем и говорил выше, любая именно строковая операция кроме копирования требует знания кодировки. Как только нужна семантика, тут луа умывает руки.