Converting Letters into Numbers for Creating an Authenticator In Section 2.2 of DJB's Polynomial Evaluation and Message Authentication, he describes the construction of the first provably secure authenticator, which was the work of Gilbert, MacWilliams, and Sloane.

Fix a finite field $k$. The legitimate sender generates 9 independent
uniform random secrets $r1, r2, . . . , r8, s ∈ k$. The sender meets
the legitimate receiver in private and tells the receiver the same
secrets $r1, r2, . . . , r8, s$. Later the sender wants to send a
message $m$ to the receiver through a public network, where $m$ is a
sequence of 8 components $m1, m2, . . . , m8 ∈ k$. The sender
transmits $m$ together with the authenticator $a=m1r1+···+m8r8+s ∈ k$.

Fine.  Let's say the entire message looks like this:

sorry mrjoh nsony ourf light hasbe encan celed

This message is conveniently broken into a sequence of eight components.
What I cannot figure out is the simple question of how to represent the letters/blocks numerically for the computations shown above.
What is the best way?
Normalize the input and encode it using UTF-8. That gets you octet strings. Then the particular block size depends on the system you're using. For Poly1305, treat 16-byte long octet strings as little-endian integers. RFC8439 provides the way to convert a message composed of bytes into appropriately sized blocks (for Poly1305, other such systems need different sizes):

o ...divide the message into 16-byte blocks.  The last one might be shorter:


o  Read the block as a little-endian number.


o  Add one bit beyond the number of octets.  For a 16-byte block, this is equivalent to adding 2^128 to the number.  For the shorter block, it can be 2^120, 2^112, or any power of two that is evenly divisible by 8, all the way down to 2^8.


o  If the block is not 17 bytes long (the last block), pad it with zeros.  This is meaningless if you are treating the blocks as numbers.