The ciphertext of RSA is actually just a number in the range 0..N that has been encoded to an octet string (another name for byte array) of the same size as the minimum modulus N. To be precise, the ciphertext is an unsigned, statically sized, big endian integer.
The PKCS#1 standard defines it this way, both for PKCS#1 as well as OAEP padding:
Convert the ciphertext representative c to a ciphertext C of
length k octets (see Section 4.1):
C = I2OSP (c, k).
Where I2OSP - integer to octet string primitive - is defined here. I2OSP is just a mathematical way of defining how the number is encoded as described in the first section of the answer. Stupid implementations actually perform these kinds of calculations, most implementations require some resizing / reversing (in case little endian is used internally) and smart implementations already keep the numbers in the correct format in memory.
Now for textbook RSA, you can, of course, argue that pointing to the PKCS#1 specification is unfair because textbook RSA is not defined in that standard, and textbook RSA isn't required to follow the conventions specified in it. However, the fact that the ciphertext is just an encoded number remains. Sometimes the minimum length and / or little endian encoding is returned and of course, some implementations will simply return the number without performing encoding at all. However, in all cases, it should be easy to get the numeric value of the ciphertext - which is just the result of modular exponentiation with the public exponent after all.
Note that many languages - notably the C language - unfortunately handle bytes and characters as being the same type; they are not. The bytes generated by encoding a number can have any value and may not be printable. If you need a printable text that contains these bytes you will have to encode the bytes to a string, e.g. base 64 or hexadecimal encoding. Some libraries allow you to specify this as output size, and some bad ones even default to performing an encoding over the ciphertext bytes. To convert those back you need to first decode back into bytes and then perform the bytes-to-number conversion.
Despite the possible output values, you should never ever have to perform calculations on the individual bytes unless you cannot load any kind of library that does this for you and you will have to define your BigNum yourself (and yes, I have been there). Usually the cryptographic libraries themselves contain this kind of library; they need the functionality after all. They are quite often in the "hazmat" part of the library or not directly present in the API however.