How to write string in ASCII mode

[jonnysoe]

I've went through the quick tutorial (C++), and I noticed the string members in the output binary is having a lot of 0x00 characters. My initial guess was that the string members are writen in UTF-8 mode, then I found the schema guide mentioned:
"string, which may only hold UTF-8 or 7-bit ASCII."

It sounds like we could change it to ASCII mode, however I tried to explicitly use const char * name = "Sword"; and pass this explicit char variable to CreateString and its still written in UTF-8 mode.

I'm not sure if my deductions are accurate so I'll write my question in a more generic sense, I would like to know if its possible to write in single byte per character for string, if it is then how do we change string to write to binary in such manner?

[Advait251206]

I think there may be a misunderstanding here about how FlatBuffers stores strings.

FlatBuffers strings are already stored as a sequence of bytes containing UTF-8 text, and plain ASCII text is a valid subset of UTF-8. For a string like:

const char *name = "Sword";

the characters themselves are stored as:

53 77 6F 72 64

(one byte per character), plus the terminating null byte that FlatBuffers includes for convenience.

If you're seeing a lot of 0x00 bytes in the binary, they're likely not coming from UTF-8 encoding. More likely explanations are:

• The string length prefix.
• Alignment padding inserted by FlatBuffers.
• Offsets and other metadata in the buffer.
• The null terminator after the string.

For example, UTF-8 does not automatically store ASCII characters as:

53 00 77 00 6F 00 ...

That's UTF-16-style encoding, not UTF-8.

The schema documentation's statement that strings may contain "UTF-8 or 7-bit ASCII" means that the string contents must be valid UTF-8, and pure ASCII strings are naturally valid UTF-8 strings. There isn't a separate "ASCII mode" that changes how strings are serialized.

So if your strings only contain ASCII characters, they are already being stored using one byte per character. The extra 0x00 bytes you're observing are likely part of the FlatBuffer format itself rather than the string encoding.

If you can share a small hex dump of the buffer, it would be easier to identify exactly which bytes are string data versus alignment, offsets, or other FlatBuffers metadata.