Yeah, there's no way I'd try to do that through text editing, an editor would make the project about a thousand times more fun to use.
I would strongly suggest using a 16x16 block of your images, so each image would have 256 32x32 images, so the actual size would be 512x512. Instead of using strings, you could use bytes to store the map layout - maybe make image 0 a blank, but having your images laid out on a grid is a great way to expand. Saving and loading a map based simply on bytes is easy, just have your 2D array save and load with the built in commands if the map size stays a standard. Even if you don't need 256 tiles per level, you could use a compressed file format like PNG and the extra space would cost practically nothing while allowing easy expansion.
For example, if you went for this method, your engine could cut out each image and paste it to generate the level - but then it would also lend itself well to using a simple matrix, memblock matrix, or even individual sprites. If you used sprites, a matrix, or meshes you wouldn't need to cut out each image - that 1 image with the 256 tiles could encompass a whole level and would make adjustments really easy. You could have 1 copy of the tileset for daylight, 1 for night, 1 for snow - it depends on how your engine works.
The reason I mention these 3D techniques in a 2D game is that by going 2.5D, in other words sticking to 2D principles but using 3D technology - you can avoid a lot of issues, like Z depth sorting, but the main benefit is speed. The speed difference in displaying a mesh instead of pasting the images is huge. You also avoid resolution problems this way - instead of having to force the program into a set resolution you can just display it all as 3D and there's no need to worry about unsupported resolutions.
Personally I'd only go for pure 2D if I was making an exact remake of an old 2D game, 3D engines hold far too many benefits to ignore.
