Home/ Questions/Q 7725687
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-01T05:00:07+00:00

I am writing an erlang module that has to deal a bit with strings,

  • 0

I am writing an erlang module that has to deal a bit with strings, not too much, however, I do some tcp recv and then some parsing over the data.

While matching data and manipulating strings, I am using binary module all the time like binary:split(Data,<<":">>) and basically using <<"StringLiteral">> all the time.

Till now I have not encounter difficulties or missing methods from the alternative( using lists) and everything is coming out quite naturally except maybe for adding the <<>>, but I was wondering if this way of dealing with strings might have drawbacks I am not aware of.

Any hint?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    You do need to be very aware of how your string is encoded in your binaries. When you do <<“StringLiteral”>> in your code, you have to be aware that this is simply a binary serialization of the list of code-points. Your Erlang compiler reads your code as ISO-8859-1 characters, so as long as you only use Latin-1 characters and do this consistently, you should be fine, But this isn’t very friendly to internationalization.

    Most application software these day should prefer a unicode encoding. UTF-8 is compatible with your <<“StringLiteral”>> for the first 128 codepoints, but not for the second 128, so be careful. You might be surprised what you see on your UTF-8 encoded web applications if you use <<“StrïngLïteral”>> in your code.

    There was an EEP proposal for binary support in the form of <<“StrïngLïteral”/utf8>>, but I don’t think this is finalized.

    Also be aware that your binary:split/2 function may have unexpected results in UTF-8 if there is a multi-byte character that contains the IS0-8859-1 byte that to are splitting on.

    Some would argue that UTF-16 is a better encoding to use because it can be parsed more efficiently and can be more easily split by index, if you are assuming or verify that there are no 32-bit characters.

    The unicode module should be use, but tread carefully when you use literals.

    • 0