Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Strings with the literal values "true" and "false" are mistaken with bytes when written and parsed from SNBT. #63

Open
Igrium opened this issue Jun 30, 2021 · 4 comments

Comments

@Igrium
Copy link

Igrium commented Jun 30, 2021

If you have a string tag with the value "true" or "false" and you write it to SNBT, it's read as a byte when parsed again. This is problematic when trying to manipulate gamerules using SNBT.
Potential fix is to check if a string matches "true" or "false" when writing to SNBT and surround it with quotes if it does.

@DalekCraft2
Copy link

Bumping this, because I also experience this. At the moment, I have to use a custom static method to convert bytes into strings, but it would be safer if the issue was fixed at the source.

@LiamFry
Copy link

LiamFry commented Feb 2, 2025

I'm guessing this project has been abandoned. It's 3-1/2 years since this issue was originally posted and there's been no fix. I, too, have been bitten by the "true" => 1b issue.

querz-nbt is an ever-so-slightly more recent fork of this project but it, too, suffers from the exact same bug.

The NBT => SNBT => NBT workflow is critical for what I'm doing and it remains broken.

@HoldYourWaffle
Copy link
Contributor

I haven't used this library in ages, but that sounds like a wild corruption bug to go unnoticed for so long.

querz-nbt is an ever-so-slightly more recent fork of this project but it, too, suffers from the exact same bug.

As far as I'm aware my fork isn't necessarily "more recent", though there are branches with #91 and #97. You're welcome to submit a fix to my fork, but you might be interested in @ens-gijs's fork that grew out of #68 instead. I haven't used it myself (yet), but as far as I can tell it's been steadily improving upon (and diverging from) this library

@LiamFry
Copy link

LiamFry commented Feb 3, 2025

... that sounds like a wild corruption bug to go unnoticed for so long.

It seems to happen at these location ...

querz/SNBTParser.java, lines 117 and 119

querz-nbt/SNBTParser.java, lines 243 and 246

The incoming NBT has a StringTag with the text "true" or "false" but the library writes it to SNBT as a "bare" true or false. When reversing the process, the SNBT parser sees something like waterlogged:true (with the "bare" true) and assumes that's a boolean so it writes a ByteTag of 1b. As @Igrium suggested - and this is how I'm working around it - I post-process the SNBT text with a global search/replace of :false with :"false" etc. This forces the SNBT parser to treat this as text and it correctly (re)writes the NBT as a StringTag.

I'll definitely look into those other forks; thanks!

As an aside - and I'm conflating issues here - for whatever reason, the compressed file produced by NBTUtil.write() is not GZip compatible! I don't think this is a library issue; the library simply uses the Java-provided GZip facilities (java.util.zip.GZIPOutputStream). I'm assuming this might be a mismatch between my Java version (21) and the gzip tools installed on my system. (The MC server shows no signs of having an issue when decompressing a file produced by NBTUtil.write() so ... I'll fret over this one later.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants