Sorry, I misunderstood.
Took me a while to understand this, because I thought you were talking about real numbers as opposed to integers, rational numbers, etc. :~) But yes, it's the numbers that are the real things, and numerals are their names, sort of.
A representation isn't quite the same thing as an abstraction. Behind the keyboard that produced the post to which I'm responding is, presumably, a person -- a bunch of bones and muscles and plumbing inside a skin -- and the word "bluebaritone21" is a representation of that person. An abstraction would be something like Person, the kind of thing that you are. Or, for that matter, Name, the kind of thing that "bluebaritone21" is. But yes, representations and abstractions are related; they're both a kind of stepping back from that sack of bones, etc.
If you're going to talk about numbers, you need a way to represent them, such as numerals. If you're going to talk about people, you need a way to represent them, such as names.
It happens that there are lots of representations for numbers, that are connected algorithmically with the numbers themselves -- given a number, you can compute its representation (in a particular system), and vice versa. People can have more than one name (you, presumably, have a True Name that may not be spoken on the Internet, for example), but they aren't connected by algorithms (unless you count table lookup) the way numbers' names are.
Well, if that breaks, we have plumbers for that, don't we? 
Brian's excellent post is focused on integers but I have seen students who understand Brian's point get confused by fractions. I just visited Numeral (linguistics) - Wikipedia and I'm not so happy with how they label the columns in the fractional numerals table.
"Value" and "Fraction" are numerals just like the "Common names"
But yes there are infinitely numbers for the number represented by 0.12
You meant "infinitely many representations," but because you typed "numbers" I thought you were talking about how any floating point value represents infinitely many real numbers! :~)
Whoops - you are right.
Would Unicode or ASCII or whatever character encoding system technically be a way of representing numbers? a=97, !=33, etc.
Those are ways of using numbers to represent characters. (Using numbers, not numerals, because, for example, lower case "a" is represented by ninety-seven, whether you write it as "97" or "0o141" or "0x61" or whatever.)
i mean in reverse, so instead 97->a it is a->97
Even so. That 97 is a number (which, as always, Snap! represents as a decimal numeral when showing it to a human user). You can do arithmetic on it. More to the point, certain subsets of the character set are guaranteed contiguous, e.g., lower case letters are represented by 26 consecutive numbers, a concept that doesn't apply to numerals.
How could that represent negatives and non-integers?
For negatives, you can use U+0000 at the front:
(tofu lol 
)
For non-integers, you can use U+0000 at the non-first digit.
This would be use a base-255 system, like U+0001 being 0, U+0002 being 1, etc.
For example, to represent 11/255, just use this: ��� (why it's �'s??? By the way, it's U+0002 then U+0000 then U+0002)
Why not just interpret Unicode text as base-65536?
Because the base-65536 can sometimes break things, like surrogate characters becoming emojis, U+FFFE outside of BMP, etc. That's probably what I don't do.
Good point about U+FFFE - I didn't realize there were invalid codes. Though it doesn't seem to matter to Snap!
Why are emojis a problem?
Because they require 4 bytes and sometimes don't work in some websites, like the Scratch forums. Like 𒍅 ← this one. (U+12345)
I see the cuneiform emoji, not sure what that problem is.
OK 4 bytes, then base-(2^32). I'm interested in this to understand if there is a flaw in my project for encrypting text by applying reversable arithmetic to the number which corresponds to interpreting the text as a numeral in base-(2^32).
Your calculation must be a "hard problem" as described below.
Also, the full-blown crypto protocol must deal with the typical weak points - short input, repeated data in input, known plaintext injection, and vulnerability to differential cryptanalysis.
Didn't know about the Unicode limitations.
Yes, it isn't strong encryption but I think it can be a great exercise for middle or high school students to explore this.