Strings in Elixir are a sequence of Unicode characters,
typically written between double quoted strings, such
as "hello" and "héllò".
In case a string must have a double-quote in itself,
the double quotes must be escaped with a backslash,
for example: "this is a string with \"double quotes\"".
You can concatenate two strings with the <>/2 operator:
Strings in Elixir also support interpolation. This allows
you to place some value in the middle of a string by using
the #{} syntax:
iex> name="joe"iex> "hello #{name}""hello joe"
Any Elixir expression is valid inside the interpolation.
If a string is given, the string is interpolated as is.
If any other value is given, Elixir will attempt to convert
it to a string using the String.Chars protocol. This
allows, for example, to output an integer from the interpolation:
iex> "2 + 2 = #{2+2}""2 + 2 = 4"
In case the value you want to interpolate cannot be
converted to a string, because it doesn't have a human
textual representation, a protocol error will be raised.
Escape characters
Besides allowing double-quotes to be escaped with a backslash,
strings also support the following escape characters:
\0 - Null byte
\a - Bell
\b - Backspace
\t - Horizontal tab
\n - Line feed (New lines)
\v - Vertical tab
\f - Form feed
\r - Carriage return
\e - Command Escape
\s - Space
\# - Returns the # character itself, skipping interpolation
\\ - Single backslash
\xNN - A byte represented by the hexadecimal NN
\uNNNN - A Unicode code point represented by NNNN
\u{NNNNNN} - A Unicode code point represented by NNNNNN
Note it is generally not advised to use \xNN in Elixir
strings, as introducing an invalid byte sequence would
make the string invalid. If you have to introduce a
character by its hexadecimal representation, it is best
to work with Unicode code points, such as \uNNNN. In fact,
understanding Unicode code points can be essential when doing
low-level manipulations of string, so let's explore them in
detail next.
Unicode and code points
In order to facilitate meaningful communication between computers
across multiple languages, a standard is required so that the ones
and zeros on one machine mean the same thing when they are transmitted
to another. The Unicode Standard acts as an official registry of
virtually all the characters we know: this includes characters from
classical and historical texts, emoji, and formatting and control
characters as well.
Unicode organizes all of the characters in its repertoire into code
charts, and each character is given a unique numerical index. This
numerical index is known as a Code Point.
In Elixir you can use a ? in front of a character literal to reveal
its code point:
iex> ?a97iex> ?ł322
Note that most Unicode code charts will refer to a code point by its
hexadecimal (hex) representation, e.g. 97 translates to 0061 in hex,
and we can represent any Unicode character in an Elixir string by
using the \u escape character followed by its code point number:
iex> "\u0061"==="a"trueiex> 0x0061=97=?a97
The hex representation will also help you look up information about a
code point, e.g. https://codepoints.net/U+0061
has a data sheet all about the lower case a, a.k.a. code point 97.
Remember you can get the hex presentation of a number by calling
Integer.to_string/2:
iex> Integer.to_string(?a,16)"61"
UTF-8 encoded and encodings
Now that we understand what the Unicode standard is and what code points
are, we can finally talk about encodings. Whereas the code point is what
we store, an encoding deals with how we store it: encoding is an
implementation. In other words, we need a mechanism to convert the code
point numbers into bytes so they can be stored in memory, written to disk, and such.
Elixir uses UTF-8 to encode its strings, which means that code points are
encoded as a series of 8-bit bytes. UTF-8 is a variable width character
encoding that uses one to four bytes to store each code point. It is capable
of encoding all valid Unicode code points. Let's see an example:
Although the string above has 5 characters, it uses 6 bytes, as two bytes
are used to represent the character é.
Grapheme clusters
This module also works with the concept of grapheme cluster
(from now on referenced as graphemes). Graphemes can consist
of multiple code points that may be perceived as a single character
by readers. For example, "é" can be represented either as a single
"e with acute" code point, as seen above in the string "héllo",
or as the letter "e" followed by a "combining acute accent"
(two code points):
Although it looks visually the same as before, the example above
is made of two characters, it is perceived by users as one.
Graphemes can also be two characters that are interpreted as one
by some languages. For example, some languages may consider "ch"
as a single character. However, since this information depends on
the locale, it is not taken into account by this module.
In general, the functions in this module rely on the Unicode
Standard, but do not contain any of the locale specific behavior.
More information about graphemes can be found in the Unicode
Standard Annex #29.
For converting a binary to a different encoding and for Unicode
normalization mechanisms, see Erlang's :unicode module.
String and binary operations
To act according to the Unicode Standard, many functions
in this module run in linear time, as they need to traverse
the whole string considering the proper Unicode code points.
For example, String.length/1 will take longer as
the input grows. On the other hand, Kernel.byte_size/1 always runs
in constant time (i.e. regardless of the input size).
This means often there are performance costs in using the
functions in this module, compared to the more low-level
operations that work directly with binaries:
The UTF-8 encoding is self-synchronizing. This means that
if malformed data (i.e., data that is not possible according
to the definition of the encoding) is encountered, only one
code point needs to be rejected.
This module relies on this behavior to ignore such invalid
characters. For example, length/1 will return
a correct result even if an invalid code point is fed into it.
In other words, this module expects invalid data to be detected
elsewhere, usually when retrieving data from the external source.
For example, a driver that reads strings from a database will be
responsible to check the validity of the encoding. String.chunk/2
can be used for breaking a string into valid and invalid parts.
Compile binary patterns
Many functions in this module work with patterns. For example,
String.split/3 can split a string into multiple strings given
a pattern. This pattern can be a string, a list of strings or
a compiled pattern:
The compiled pattern is useful when the same match will
be done over and over again. Note though that the compiled
pattern cannot be stored in a module attribute as the pattern
is generated at runtime and does not survive compile time.
The types String.t() and binary() are equivalent to analysis tools.
Although, for those reading the documentation, String.t() implies
it is a UTF-8 encoded binary.
Returns the grapheme at the position of the given UTF-8 string.
If position is greater than string length, then it returns nil.
Linear Access
This function has to linearly traverse the string.
If you want to access a string or a binary in constant time based on the
number of bytes, use Kernel.binary_slice/3 or :binary.at/2 instead.
Returns a float value between 0 and 1 representing the bag
distance between string1 and string2.
The bag distance is meant to be an efficient approximation
of the distance between two strings to quickly rule out strings
that are largely different.
The algorithm is outlined in the "String Matching with Metric
Trees Using an Approximate Distance" paper by Ilaria Bartolini,
Paolo Ciaccia, and Marco Patella.
Returns a substring starting at (or after) start_bytes and of at most
the given size_bytes.
This function works on bytes and then adjusts the string to eliminate
truncated codepoints. This is useful when you have a string and you need
to guarantee it does not exceed a certain amount of bytes.
If the offset is greater than the number of bytes in the string, then it
returns "". Similar to String.slice/2, a negative start_bytes
will be adjusted to the end of the string (but in bytes).
This function does not guarantee the string won't have invalid codepoints,
it only guarantees to remove truncated codepoints immediately at the beginning
or the end of the slice.
Examples
Consider the string "héllo". Let's see its representation:
Although the string has 5 characters, it is made of 6 bytes. Now imagine
we want to get only the first two bytes. To do so, let's use binary_slice/3,
which is unaware of codepoints:
iex> binary_slice("héllo",0,2)<<104,195>>
As you can see, this operation is unsafe and returns an invalid string.
That's because we cut the string in the middle of the bytes representing
"é". On the other hand, we could use String.slice/3:
iex> String.slice("héllo",0,2)"hé"
While the above is correct, it has 3 bytes. If you have a requirement where
you need at most 2 bytes, the result would also be invalid. In such scenarios,
you can use this function, which will slice the given bytes, but clean up
the truncated codepoints:
iex> String.byte_slice("héllo",0,2)"h"
Truncated codepoints at the beginning are also cleaned up:
iex> String.byte_slice("héllo",2,3)"llo"
Note that, if you want to work on raw bytes, then you must use binary_slice/3
instead.
Converts the first character in the given string to
uppercase and the remainder to lowercase according to mode.
mode may be :default, :ascii, :greek or :turkic. The :default mode
considers all non-conditional transformations outlined in the Unicode standard.
:ascii capitalizes only the letters A to Z. :greek includes the context
sensitive mappings found in Greek. :turkic properly handles the letter i
with the dotless variant.
Also see upcase/2 and capitalize/2 for other conversions. If you want
a variation of this function that does not lowercase the rest of string,
see Erlang's :string.titlecase/1.
To retrieve code points in their natural integer
representation, see to_charlist/1. For details about
code points and graphemes, see the String module
documentation.
Searches if string contains any of the given contents.
contents can be either a string, a list of strings,
or a compiled pattern. If contents is a list, this
function will search if any of the strings in contents
are part of string.
Searching for a string in a list
If you want to check if string is listed in contents,
where contents is a list, use Enum.member?(contents, string)
instead.
Examples
iex> String.contains?("elixir of life","of")trueiex> String.contains?("elixir of life",["life","death"])trueiex> String.contains?("elixir of life",["death","mercury"])false
The argument can also be a compiled pattern:
iex> pattern=:binary.compile_pattern(["life","death"])iex> String.contains?("elixir of life",pattern)true
An empty string will always match:
iex> String.contains?("elixir of life","")trueiex> String.contains?("elixir of life",["","other"])true
An empty list will never match:
iex> String.contains?("elixir of life",[])falseiex> String.contains?("",[])false
Be aware that this function can match within or across grapheme boundaries.
For example, take the grapheme "é" which is made of the characters
"e" and the acute accent. The following returns true:
Converts all characters in the given string to lowercase according to mode.
mode may be :default, :ascii, :greek or :turkic. The :default mode considers
all non-conditional transformations outlined in the Unicode standard. :ascii
lowercases only the letters A to Z. :greek includes the context sensitive
mappings found in Greek. :turkic properly handles the letter i with the dotless variant.
If you plan to compare multiple strings, multiple times in a row, you
may normalize them upfront and compare them directly to avoid multiple
normalization passes.
Computes the Jaro distance (similarity) between two strings.
Returns a float value between 0.0 (equates to no similarity) and 1.0
(is an exact match) representing Jaro
distance between string1 and string2.
The Jaro distance metric is designed and best suited for short
strings such as person names. Elixir itself uses this function
to provide the "did you mean?" functionality. For instance, when you
are calling a function in a module and you have a typo in the
function name, we attempt to suggest the most similar function
name available, if any, based on the jaro_distance/2 score.
iex> string1="fox hops over the dog"iex> string2="fox jumps over the lazy cat"iex> String.myers_difference(string1,string2)[eq:"fox ",del:"ho",ins:"jum",eq:"ps over the ",del:"dog",ins:"lazy cat"]
The result is a tuple with the code point and the
remainder of the string or nil in case
the string reached its end.
As with other functions in the String module, next_codepoint/1
works with binaries that are invalid UTF-8. If the string starts
with a sequence of bytes that is not valid in UTF-8 encoding, the
first element of the returned tuple is a binary with the first byte.
Examples
iex> String.next_codepoint("olá"){"o","lá"}iex> invalid="\x80\x80OK"# first two bytes are invalid in UTF-8iex> {_,rest}=String.next_codepoint(invalid){<<128>>,<<128,79,75>>}iex> String.next_codepoint(rest){<<128>>,"OK"}
Comparison with binary pattern matching
Binary pattern matching provides a similar way to decompose
a string:
Normalization forms :nfkc and :nfkd should not be blindly applied
to arbitrary text. Because they erase many formatting distinctions,
they will prevent round-trip conversion to and from many legacy
character sets.
Forms
The supported forms are:
:nfd - Normalization Form Canonical Decomposition.
Characters are decomposed by canonical equivalence, and
multiple combining characters are arranged in a specific
order.
:nfc - Normalization Form Canonical Composition.
Characters are decomposed and then recomposed by canonical equivalence.
:nfkd - Normalization Form Compatibility Decomposition.
Characters are decomposed by compatibility equivalence, and
multiple combining characters are arranged in a specific
order.
:nfkc - Normalization Form Compatibility Composition.
Characters are decomposed and then recomposed by compatibility equivalence.
Returns a new string padded with a leading filler
which is made of elements from the padding.
Passing a list of strings as padding will take one element of the list
for every missing entry. If the list is shorter than the number of inserts,
the filling will start again from the beginning of the list.
Passing a string padding is equivalent to passing the list of graphemes in it.
If no padding is given, it defaults to whitespace.
When count is less than or equal to the length of string,
given string is returned.
Raises ArgumentError if the given padding contains a non-string element.
Returns a new string padded with a trailing filler
which is made of elements from the padding.
Passing a list of strings as padding will take one element of the list
for every missing entry. If the list is shorter than the number of inserts,
the filling will start again from the beginning of the list.
Passing a string padding is equivalent to passing the list of graphemes in it.
If no padding is given, it defaults to whitespace.
When count is less than or equal to the length of string,
given string is returned.
Raises ArgumentError if the given padding contains a non-string element.
Returns a new string created by replacing occurrences of pattern in
subject with replacement.
The subject is always a string.
The pattern may be a string, a list of strings, a regular expression, or a
compiled pattern.
The replacement may be a string or a function that receives the matched
pattern and must return the replacement as a string or iodata.
By default it replaces all occurrences but this behavior can be controlled
through the :global option; see the "Options" section below.
Options
:global - (boolean) if true, all occurrences of pattern are replaced
with replacement, otherwise only the first occurrence is
replaced. Defaults to true
Note that we had to escape the backslash escape character (i.e., we used \\N
instead of just \N to escape the backslash; same thing for \\g{N}). By
giving \0, one can inject the whole match in the replacement string.
When an empty string is provided as a pattern, the function will treat it as
an implicit empty string between each grapheme and the string will be
interspersed. If an empty string is provided as replacement the subject
will be returned:
Be aware that this function can replace within or across grapheme boundaries.
For example, take the grapheme "é" which is made of the characters
"e" and the acute accent. The following will replace only the letter "e",
moving the accent to the letter "o":
Replaces all leading occurrences of match by replacement of match in string.
Returns the string untouched if there are no occurrences.
If match is "", this function raises an ArgumentError exception: this
happens because this function replaces all the occurrences of match at
the beginning of string, and it's impossible to replace "multiple"
occurrences of "".
Replaces all trailing occurrences of match by replacement in string.
Returns the string untouched if there are no occurrences.
If match is "", this function raises an ArgumentError exception: this
happens because this function replaces all the occurrences of match at
the end of string, and it's impossible to replace "multiple" occurrences of
"".
Examples
iex> String.replace_trailing("hello world"," world","")"hello"iex> String.replace_trailing("hello world world"," world","")"hello"iex> String.replace_trailing("hello world"," world"," mundo")"hello mundo"iex> String.replace_trailing("hello world world"," world"," mundo")"hello mundo mundo"
This function can replace across grapheme boundaries. See replace/3
for more information and examples.
In the first example the accent is before the vowel, so
it is considered two graphemes. However, when you reverse
it once, you have the vowel followed by the accent, which
becomes one grapheme. Reversing it again will keep it as
one single grapheme.
Returns a substring from the offset given by the start of the
range to the offset given by the end of the range.
This function works on Unicode graphemes. For example, slicing the first
three characters of the string "héllo" will return "hél", which internally
is represented by more than three bytes. Use String.byte_slice/3 if you
want to slice by a given number of bytes, while respecting the codepoint
boundaries. If you want to work on raw bytes, check Kernel.binary_part/3
or Kernel.binary_slice/3 instead.
If the start of the range is not a valid offset for the given
string or if the range is in reverse order, returns "".
If the start or end of the range is negative, the whole string
is traversed first in order to convert the negative indices into
positive ones.
Returns a substring starting at the offset start, and of the given length.
This function works on Unicode graphemes. For example, slicing the first
three characters of the string "héllo" will return "hél", which internally
is represented by more than three bytes. Use String.byte_slice/3 if you
want to slice by a given number of bytes, while respecting the codepoint
boundaries. If you want to work on raw bytes, check Kernel.binary_part/3
or Kernel.binary_slice/3 instead.
If the offset is greater than string length, then it returns "".
The pattern may be a string, a list of strings, a regular expression, or a
compiled pattern.
The string is split into as many parts as possible by
default, but can be controlled via the :parts option.
Empty strings are only removed from the result if the
:trim option is set to true.
When the pattern used is a regular expression, the string is
split using Regex.split/3.
If the pattern cannot be found, a list containing the original
string will be returned.
Options
:parts (positive integer or :infinity) - the string
is split into at most as many parts as this option specifies.
If :infinity, the string will be split into all possible
parts. Defaults to :infinity.
:trim (boolean) - if true, empty strings are removed from
the resulting list.
This function also accepts all options accepted by Regex.split/3
if pattern is a regular expression.
Examples
Splitting with a string pattern:
iex> String.split("a,b,c",",")["a","b","c"]iex> String.split("a,b,c",",",parts:2)["a","b,c"]iex> String.split(" a b c "," ",trim:true)["a","b","c"]
iex> String.split("a,b,c",~r{,})["a","b","c"]iex> String.split("a,b,c",~r{,},parts:2)["a","b,c"]iex> String.split(" a b c ",~r{\s},trim:true)["a","b","c"]iex> String.split("abc",~r{b},include_captures:true)["a","b","c"]
Splitting on a non-existing pattern returns the original string:
iex> String.split("abc",",")["abc"]
Be aware that this function can split within or across grapheme boundaries.
For example, take the grapheme "é" which is made of the characters
"e" and the acute accent. The following will split the string into two parts:
When using both the :trim and the :parts option, the empty values
are removed as the parts are computed (if any). No trimming happens
after all parts are computed:
iex> String.split(" a b c "," ",trim:true,parts:2)["a"," b c "]iex> String.split(" a b c "," ",trim:true,parts:3)["a","b"," c "]
Splits a string into two at the specified offset. When the offset given is
negative, location is counted from the end of the string.
The offset is capped to the length of the string. Returns a tuple with
two elements.
Linear Access
This function splits on graphemes and for such it has to linearly traverse
the string.
If you want to split a string or a binary based on the number of bytes,
use Kernel.binary_part/3 instead.
Returns an enumerable that splits a string on demand.
This is in contrast to split/3 which splits the
entire string upfront.
This function does not support regular expressions
by design. When using regular expressions, it is often
more efficient to have the regular expressions traverse
the string at once than in parts, like this function does.
Converts a string to an existing atom or creates a new one.
Warning: this function creates atoms dynamically and atoms are
not garbage-collected. Therefore, string should not be an
untrusted value, such as input received from a socket or during
a web request. Consider using to_existing_atom/1 instead.
By default, the maximum number of atoms is 1_048_576. This limit
can be raised or lowered using the VM option +t.
The maximum atom size is of 255 Unicode code points.
Specifically, this function takes a UTF-8 encoded binary and returns a list of its integer
code points. It is similar to codepoints/1 except that the latter returns a list of code points as
strings.
In case you need to work with bytes, take a look at the
:binary module.
Converts a string to an existing atom or raises if
the atom does not exist.
The maximum atom size is of 255 Unicode code points.
Raises an ArgumentError if the atom does not exist.
Inlined by the compiler.
Atoms and modules
Since Elixir is a compiled language, the atoms defined in a module
will only exist after said module is loaded, which typically happens
whenever a function in the module is executed. Therefore, it is
generally recommended to call String.to_existing_atom/1 only to
convert atoms defined within the module making the function call
to to_existing_atom/1.
To create a module name itself from a string safely,
it is recommended to use Module.safe_concat/1.
Returns a float whose text representation is string.
string must be the string representation of a float including leading digits and a decimal
point. To parse a string without decimal point as a float, refer to Float.parse/1. Otherwise,
an ArgumentError will be raised.
Returns an integer whose text representation is string.
string must be the string representation of an integer.
Otherwise, an ArgumentError will be raised. If you want
to parse a string that may contain an ill-formatted integer,
use Integer.parse/1.
Inlined by the compiler.
Examples
iex> String.to_integer("123")123
Passing a string that does not represent an integer leads to an error:
Converts all characters in the given string to uppercase according to mode.
mode may be :default, :ascii, :greek or :turkic. The :default mode considers
all non-conditional transformations outlined in the Unicode standard. :ascii
uppercases only the letters a to z. :greek includes the context sensitive
mappings found in Greek. :turkic properly handles the letter i with the dotless variant.
Checks whether string contains only valid characters.
algorithm may be :default or :fast_ascii. Both algorithms are equivalent
from a validation perspective (they will always produce the same output), but
:fast_ascii can yield significant performance benefits in specific scenarios.
If anything else but a string is given as argument, it raises.
Fast ASCII
If all of the following conditions are true, you may want to experiment with
the :fast_ascii algorithm to see if it yields performance benefits in your
specific scenario:
You expect most of your strings to be longer than ~64 bytes
You expect most of your strings to contain mostly ASCII codepoints
Note that the :fast_ascii algorithm does not affect correctness, you can
expect the output of String.valid?/2 to be the same regardless of algorithm.
The only difference to be expected is one of performance, which can be
expected to improve roughly linearly in string length compared to the
:default algorithm.
You are visitor 01402503 — GeezerVison does not store the pages you look up. Best viewed with Netscape Navigator 4.7 or Internet Explorer 6 at 800×600. No cookies required.