# \[X\] Trailing nulls in ID3v2 comments
**URL:** https://community.mp3tag.de/t/x-trailing-nulls-in-id3v2-comments/19227
**Category:** No Bugs
**Created:** [August 13, 2017, 6:30pm UTC](https://community.mp3tag.de/t/x-trailing-nulls-in-id3v2-comments/19227 "2017-08-13T18:30:39Z")
**Posts on this page:** 1
**Showing post:** 4
### Author:  [@Florian](https://community.mp3tag.de/u/Florian)
#### Post date: [August 15, 2017, 4:40am UTC](https://community.mp3tag.de/t/x-trailing-nulls-in-id3v2-comments/19227/4 "2017-08-15T04:40:56Z")
OK, let me jump in there.
In the past there were different reports from users that had issues with programs that were expecting all strings terminated with 00 (or 00 00 in case of UTF-16), which led to me changing the way Mp3tag writes strings in ID3v2.
After reading the specification again (not sure how many times I did this), it's clear to me that it makes a implicit differentiation between "text strings" and "terminated text strings". However, at one crucial point in the ID3v2.4 spec §4 it describes the structure of text strings (highlights in bold are added by me):
> [@](#):
>
> If nothing else is said, strings, including numeric strings and URLs
> [URL], are represented as ISO-8859-1 [ISO-8859-1] characters in the
> range $20 - $FF. Such strings are represented in frame descriptions
> as , or if newlines are allowed. If
> nothing else is said newline character is forbidden. In ISO-8859-1 a
> newline is represented, when allowed, with $0A only.
>
> Frames that allow different types of text encoding contains a text
> encoding description byte. Possible encodings:
>
> ```
> $00 ISO-8859-1 [ISO-8859-1]. Terminated with $00.
> $01 UTF-16 [UTF-16] encoded Unicode [UNICODE] with BOM. All
> strings in the same frame SHALL have the same byteorder.
> Terminated with $00 00.
> $02 UTF-16BE [UTF-16] encoded Unicode [UNICODE] without BOM.
> Terminated with $00 00.
> $03 UTF-8 [UTF-8] encoded Unicode [UNICODE]. Terminated with $00.
>
> ```
>
> Strings dependent on encoding are represented in frame descriptions
> as , or if newlines are allowed. Any empty strings of
> type $01 which are NULL-terminated may have the Unicode BOM followed
> by a Unicode NULL ($FF FE 00 00 or $FE FF 00 00).
This can give the impression that all strings are terminated. In fact, some developers implemented in exactly this way (e.g., Apple iTunes or foobar2000), whereas others are not terminating the strings (e.g., Windows Media Player).
I'd prefer to keep this more compatible implementation. Maybe James could relax his implementation a little?
Kind regards
– Florian
---
_[View the full topic](https://community.mp3tag.de/t/x-trailing-nulls-in-id3v2-comments/19227)._