Should I use special characters in MQTT topics?

Question

I have used MQTT to connect all my ESP8266 units but I have a general question regarding topics. According to www.hivemq.com:

• "Leading forward slash" / should be avoided.
• Spaces should be avoided.
• Use only ASCII characters.
• Embed a unique identifier or the ClientId into the topic.
• Etc.

I have pretty much applied to this but I use some special characters (% and ° for example). For example I use:

Garage_Sensor_001/Temperature/°C value

Livingroom_HID_002/Switch_001/Action value

Bedroom_Sensor_001/Motion_001/Detection value

I.e.

PLACEMENT_OF_NODE/TYPE_OF_SENSOR_UNIT_OR_ACTION/FUNDAMENTAL_UNIT_OF_VALUE_IF_ANY

So my question is: Should I use special characters when naming MQTT topics?

Answer 1

Goufalite is entirely correct about this problem: it's not a technical issue at all, just a naming problem, so a lot of the advice is very opinionated based on the author's idea of what names are best.

The MQTT 3.1 specification says:

• Topic Names and Topic Filters are case sensitive
• Topic Names and Topic Filters can include the space character
• Topic Names and Topic Filters are UTF-8 encoded strings, they MUST NOT encode to more than 65535 bytes

So, purely speaking on technical grounds, the ASCII-only and 'no spaces' rules are not necessary; all compliant MQTT brokers should be able to handle them just fine.

I don't really agree with some of the points HiveMQ make anyway:

A space is the natural enemy of each programmer, they often make it much harder to read and debug topics, when things are not going the way, they should be. So similar to the first one, only because something is allowed doesn’t mean it should be used. UTF-8 knows many different white space types, it’s pretty obvious that such uncommon characters should be avoided.

It's highly unlikely you're going to be using spaces any other way than just pressing the SPACE key on your keyboard, so I don't think accidental usage of homoglyphs is really going to be a problem.

Using non-ASCII UTF-8 character makes it really hard to find typos or issues related to the character set, because often they can not be displayed correctly. Unless it is really necessary we recommend avoid using non ASCII character in a topic.

Fair point - typing non-ASCII characters can be a big problem. Personally, I would avoid Garage_Sensor_001/Temperature/°C simply because a lot of keyboards don't have a degrees symbol built-in (British keyboards certainly don't!). This decision is really based on practicality rather than due to the protocol; if you are able to use special characters without much fuss, and you're certain that no-one else will need to type the characters in, go for it!

Also, I'd be a little sceptical about some of HiveMQ's advice; further on in the page you linked, it says "Don't subscribe to #", which has already been disputed on the site!

Answer 2

I think topic naming is the same problem as variable naming: common application design.

Let's turn it another way: how does your implementation programming language manage special chars? Spaces? Accents? ... Especially when you split them, hence the "no forward slash" rule.

If you have a perfect control on UTF-8/ASCII codepages (trust me, you don't) then go ahead! Put accents, specials chars!

Then think of the following, and this applies to all projects:

• Evolutivity: who will take care of your project? You? An open-source community? Keep it simple for anybody (even you) to not have to type complex/long topic names.
• I18N: let's face it, popular projects are in English and hey, English doesn't have accents!

Answer 3

Use only ASCII characters.

ASCII format for Network Interchange specifies that the ASCII range extends from hexadecimal 0 to 7F, i.e., 128 characters. I think % should be supported but not °.