From your source code a pdf-file gets created.
Fonts get embedded for displaying the text of your document.
But there are things where these fonts are not relevant.
That is the case, e.g., with the hyperlinks within the bookmarks.
The bookmarks do not belong to the pages that form the document.
They are something extra, and they are there for making navigating through the document more easy.
The text related to a bookmark is displayed using a font that comes from the programs/platforms used for displaying the pdf-file.
Those characters that form text related to a bookmark must be encoded in an encoding which the programs/platforms used for displaying the pdf-file do understand and whose characters the programs/platforms used for displaying the pdf-file can display.
There currently are two such encodings known to me: PdfDocEncoding and Unicode (UTF-16 Big Endian).
These two encodings do represent single characters by byte-sequences.
Sequences of characters in turn that belong together are called strings.
Those strings which (La)TeX during creation of a pdf-file must include into the pdf-file either encoded in PdfDocEncoding or encoded in Unicode so that the programs/platforms used for displaying the pdf-file in question can process/display them properly, e.g., for displaying bookmarks with hyperlinks, are in TeX-jargon called pdf-strings.
Thus you need to ensure that (La)TeX delivers pdf-strings (, e.g., text that goes into the bookmarks and thus is to be processed by the programs/platforms used for displaying the pdf-file,) as plain-text in one of these two encodings.
When you use (La)TeX for creating pdf-files, the encoding of the .tex-input-files you type most likely is not PdfDocEncoding, and TeX-engines other than LuaTeX and XeTeX also don't have built-in support for .tex-input-files in some Unicode-encoding. Common input-encodings are latin 1 and ansinew and the like.
Therefore the hyperref-package does provide the macro
This macro takes two arguments. In situations of ordinary TeX-processing it delivers the tokens contained in the first argument untouched. In situations where a string needs to be delivered in PdfDocEncoding or UTF-16-Big-Endian-Encoding, so that programs/platforms used for displaying the pdf-file can properly process/handle/display it, the tokens contained in the second argument are delivered. But that is not all:
\texorpdfstring also makes sure that the things contained in the second argument get re-encoded properly. This re-encoding is necessary because the encoding of the .tex-input-file is not necessarily PdfDocEncoding or UTF-16-Big-Endian.
\texorpdfstring also provides alternative ways of handling things: E.g., at the time of compiling a .tex-input-file for creating a pdf-file, there is a LaTeX-compiler which obeys directives like
$$ for switching to math-mode and leaving math-mode. But at the time of displaying the pdf-file, there is no LaTeX-compiler. There is the program/platform used for displaying the pdf-file. This program does not care about directives which were intended for the LaTeX-compiler at the time of compiling the .tex-input-file and creating the pdf-file. Thus this program will not understand directives like
$\mu$. Thus within the second argument of
\texorpdfstring you can omit all those things which the LaTeX-compiler does understand but the program/platform used for displaying the pdf-file does not understand.
Within pdf-strings and thus within the second argument of
\texorpdfstring you can escape bytes by a backslash trailed by a three-digit-number (with leading zeros if necessary) denoting the value of the byte in question in octal notation.
In case the escape-octal-representation of a byte denotes the higher byte of a UTF-16-Big-Endian-character, within the second argument of
\texorpdfstring it is a convention to prefix that 3-octal-digit-sequence with the digit "9".
This can be done because "9" is not a digit of the octal system.
Another convention with the octal-representation of the higher byte of an UFT-16-Big-Endian-character within the second argument of
\texorpdfstring is: In case octal representation of the higher byte has two leading zeros, you can, instead of
\900⟨single octal digit⟩ do
\8⟨single octal digit⟩.
When loading the hyperref-package, pdf-strings usually need to be encoded in PdfDocEncoding.
In PdfDocEncoding (see http://www.verypdf.com/document/pdf-format-reference/pg_1001.htm), there is a Micro-Sign which is assigned to code-point number 181(dec) = 265(oct).
When you provide the option
unicode=true to the hyprref-package, pdf-strings need to be encoded in Unicode (UTF-16 Big Endian).
In Unicode (see https://dev.w3.org/html5/html-author/charref), there is μ, which is assigned to code-point number 956(dec).
For finding the bytes of that code-point-number's UTF-16-Big-Endian-representation, let's write that code-point-number in the base 256:
956(dec) = 3(dec) * (256(dec)1(dec)) + 188(dec)* (256(dec)0(dec))
Thus in UTF-16 (Big Endian), μ is encoded with two bytes whereof the higher byte has the value 3(dec) and the lower byte has the value 188(dec).
Let's express the values of each of these bytes in 3-digt-octal notation:
Higher byte's value = 3(dec) = 003 (oct)
Lower byte's value = 188(dec) = 274 (oct)
The facility of escaping the encoding of characters of pdf-strings via octal-sequences is nice because it offers a way of writing characters of pdf-strings in PDFDocEncodng or UTF-16 Big-Endian without the need of the .tex-input-file being written in the same encoding.
Even in ASCII the digits 0..9 and the backslash are available...
When loading the hyperref-package without option
unicode, you can within pdf-strings use PDFDocEncoding and hereby escape characters not contained in the encoding of your .tex input-file by their byte-wise representation in octal-notation:
When loading the hyperref-package with option
unicode, you can within pdf-strings use unicode-encoding and hereby escape characters not contained in the encoding of your .tex input-file by their byte-wise representation in octal-notation: