如何将大的 lua 字符串分成小字符串

发布于 2024-11-25 10:58:28 字数 213 浏览 2 评论 0原文

我有一个大字符串(base64 编码的图像),它有 1050 个字符长。如何附加由小字符串组成的大字符串,就像在 C 中一样

 function GetIcon()
    return "Bigggg string 1"\
"continuation of string"\
"continuation of string"\
"End of string"

I have a big string (a base64 encoded image) and it is 1050 characters long. How can I append a big string formed of small ones, like this in C

 function GetIcon()
    return "Bigggg string 1"\
"continuation of string"\
"continuation of string"\
"End of string"

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(5

爱你是孤单的心事 2024-12-02 10:58:28

根据 Lua 2.4 字符串编程

我们还可以通过匹配双方括号 [[...]] 来分隔文字字符串。这种括号形式的文字可以运行多行,可以嵌套,并且不解释转义序列。此外,当字符串的第一个字符是换行符时,此形式会忽略该字符。这种形式对于编写包含程序片段的字符串特别方便;例如,

page = [[
<HTML>
<HEAD>
<TITLE>An HTML Page</TITLE>
</HEAD>
<BODY>
 <A HREF="http://www.lua.org">Lua</A>
 [[a text between double brackets]]
</BODY>
</HTML>
]]

这是与您所要求的最接近的事情,但是使用上述方法会将换行符嵌入到字符串中,因此这不会直接起作用。

您还可以通过字符串连接来完成此操作(使用 ..):

value = "long text that" ..
      " I want to carry over" ..
      "onto multiple lines"

According to Programming in Lua 2.4 Strings:

We can delimit literal strings also by matching double square brackets [[...]]. Literals in this bracketed form may run for several lines, may nest, and do not interpret escape sequences. Moreover, this form ignores the first character of the string when this character is a newline. This form is especially convenient for writing strings that contain program pieces; for instance,

page = [[
<HTML>
<HEAD>
<TITLE>An HTML Page</TITLE>
</HEAD>
<BODY>
 <A HREF="http://www.lua.org">Lua</A>
 [[a text between double brackets]]
</BODY>
</HTML>
]]

This is the closest thing to what you are asking for, but using the above method keeps the newlines embedded in the string, so this will not work directly.

You can also do this with string concatenation (using ..):

value = "long text that" ..
      " I want to carry over" ..
      "onto multiple lines"
鹿童谣 2024-12-02 10:58:28

这里的大多数答案在运行时解决这个问题,而不是在编译时解决。

Lua 5.2引入了转义序列\z来优雅地解决这个问题,并且不会产生任何运行时开销。

> print "This is a long \z
>>                                string with \z
>>      breaks in between, \z
>> and is spanning multiple lines \z
>> but still is a single string only!"
This is a long string with breaks in between, and is spanning multiple lines but still is a single string only!

\z 跳过字符串文字1 中的所有后续字符,直到第一个非空格字符。这也适用于非多行文字文本。

> print "This is a simple \z                string"
This is a simple string

摘自Lua 5.2参考手册

转义序列“\z”会跳过接下来的空白字符,包括换行符;将长文字字符串拆分并缩进为多行特别有用,而无需在字符串内容中添加换行符和空格。

1:所有转义序列,包括 \z,仅适用于短文字字符串"..."'... '),并且可以理解的是,不在长文字字符串上([[...]]等)

Most answers here solves this issue at run-time and not at compile-time.

Lua 5.2 introduces the escape sequence \z to solve this problem elegantly without incurring any run-time expense.

> print "This is a long \z
>>                                string with \z
>>      breaks in between, \z
>> and is spanning multiple lines \z
>> but still is a single string only!"
This is a long string with breaks in between, and is spanning multiple lines but still is a single string only!

\z skips all subsequent characters in a string literal1 until the first non-space character. This works for non-multiline literal text too.

> print "This is a simple \z                string"
This is a simple string

From Lua 5.2 Reference Manual

The escape sequence '\z' skips the following span of white-space characters, including line breaks; it is particularly useful to break and indent a long literal string into multiple lines without adding the newlines and spaces into the string contents.

1: All escape sequences, including \z, work only on short literal strings ("…", '…') and, understandably, not on long literal strings ([[...]], etc.)

卖梦商人 2024-12-02 10:58:28

我将所有块放入表中并对其使用 table.concat 。这避免了在每次连接时创建新字符串。例如(不计算 Lua 中字符串的开销):

             -- bytes used
foo="1234".. --          4  = 4
    "4567".. -- 4  + 4 + 8  = 16
    "89ab"   -- 16 + 4 + 12 = 32
             -- |    |    |    \_ grand total after concatenation on last line
             -- |    |    \_ second operand of concatenation
             -- |    \_ first operand of concatenation
             -- \_ total size used until last concatenation

如您所见,它的爆炸速度非常快。最好:

foo=table.concat{
"1234",
"4567",
"89ab"}

大约需要 3*4+12=24 字节。

I'd put all chunks in a table and use table.concat on it. This avoids the creation of new strings at every concatenation. for example (without counting overhead for strings in Lua):

             -- bytes used
foo="1234".. --          4  = 4
    "4567".. -- 4  + 4 + 8  = 16
    "89ab"   -- 16 + 4 + 12 = 32
             -- |    |    |    \_ grand total after concatenation on last line
             -- |    |    \_ second operand of concatenation
             -- |    \_ first operand of concatenation
             -- \_ total size used until last concatenation

As you can see, this explodes pretty rapidly. It's better to:

foo=table.concat{
"1234",
"4567",
"89ab"}

Which will take about 3*4+12=24 bytes.

素年丶 2024-12-02 10:58:28

你有没有尝试过
string.sub(s, i [, j]) 函数。
您可能想看这里:

http://lua-users.org/wiki/StringLibraryTutorial

Have you tried the
string.sub(s, i [, j]) function.
You may like to look here:

http://lua-users.org/wiki/StringLibraryTutorial

还给你自由 2024-12-02 10:58:28

这种:

    return "Bigggg string 1"\
"continuation of string"\
"continuation of string"\
"End of string"

C/C++ 语法使编译器将其全部视为一个大字符串。它通常用于可读性。

Lua 等效项是:

    return "Bigggg string 1" ..
"continuation of string" ..
"continuation of string" ..
"End of string"

请注意,C/C++ 语法是编译时的,而 Lua 等效项可能在运行时进行串联(尽管编译器理论上可以优化它)。不过这应该没什么大不了的。

This:

    return "Bigggg string 1"\
"continuation of string"\
"continuation of string"\
"End of string"

C/C++ syntax causes the compiler to see it all as one large string. It is generally used for readability.

The Lua equivalent would be:

    return "Bigggg string 1" ..
"continuation of string" ..
"continuation of string" ..
"End of string"

Do note that the C/C++ syntax is compile-time, while the Lua equivalent likely does the concatenation at runtime (though the compiler could theoretically optimize it). It shouldn't be a big deal though.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文