Firstly, there are two common formats to store such values:
PEM and DER. PEM is what you posted. It is, actually, the same data as DER, but base-64 encoded.
There is a thing which is called 'ASN.1' structure. Basically, an ASN.1 structure is a set of fields of some basic types, such as INTEGER, BOOLEAN, SEQUENCE and others.
In the previous post, you can see one concrete example of this ASN.1 structure.
On different platforms there exist tools which are able to read these ASN.1 structures, as well as write them. There is even a tool, you feed it the specification of your ASN.1 structure in some format, and it generates a C code which can read files of this structure and write them.
For things such as, let's say, RSA private key, this ASN.1 structure is defined in the standard:
PKCS#1 (RFC 3447) defines the ASN.1 structure for RSA Private key. It must be used by everyone. Of course, you can create your own:) but I think you realise why standardisation is important.
You can play with it that way: generate your own RSA key pair (create some short one).
Then take this .PEM file and copy this base-64 encoded string to ASN.1 decoder (there are a couple of online decoders, such as https://lapo.it/asn1js/). And take a look! :) You will see a long line of numbers, and you can make sense of them in some text editor.
As far as I remember, first several numbers are a header, and then it goes that way:
02 - means 'int'
01 - means 'of length 1'
08 - is your int
and the ASN.1 parser will read all values that way - read type, read length, then read (length) number of bytes, read type, read length, read (length) number of bytes .......
After that, since the parser knows that it was a ASN.1 structure for RSA private key, he will say 'ok, that field was the first prime and that field was the second prime'