I don't know your exact scenario. However you have two options to encrypt data using elliptic curve cryptography (ECC). I'd recommend going with the first option I present.
- Use elliptic curve integrated encryption scheme (ECIES). ECIES basically performs ElGamal-like encryption on a key. The key is generated at random and encrypted like in ElGamal (replace the multiply operations with add operations). One then can use this symmetric key to symmetricly encrypt and authenticate the data. ECIES defines how to exactly do that. You then go ahead and simply process the data as you normally would using a symmetric encryption scheme.
- Use generalized ElGamal on elliptic curves (no abbreviation, likely never deployed or proposed outside of ECIES). You can as well simply use the generalized ElGamal construction and somehow represent the data you want to encrypt as a point on your curve (which is harder than it sounds).
I do not recommend this method. The reason is that you're limited to a message space of 256 to 512 bit (32-64 bytes) and that representing your message may actually be quite difficult, as the reconstruction of the message data from the "decrypted" point won't be easy.
If you're question was only aiming at "How can I represent my bytes in the textfile for the encryption?", then by using approach no. 1 the solution is rather straightforward and with approach no. 2 you have to invent some scheme yourself to aid re-construction. This could go as follows:
- Represent your message as octet string $B$.
- Convert the octet string to an integer $b$.
- Initialize $c=0$
- Check if $b$ is a valid x-coordinate on your curve, if yes go to step 6
- Set $b=b+1$ and $c=c+1$ and go to step 4
- Encrypt the data and append $c$ (maybe with some sort of separator)
Reconstruction should be more easy. You retrieve $b$ by decrypting the message and setting $b$ to be the x-coordinate of the resulting point. Now you simply subract $c$ from $b$ yielding the original $b$ value and making you able to reconvert the integer to a byte array (the text in your file).
Note: If an attacker tampers with $c$, he can let you decrypt the ciphertext to arbitrary messages. Because of this property you should always prefer ECIES.