I had concerns too, but I haven’t yet seen one complaint about failing/invalid event ids.
Here is the extract from the NIP-01, which strictly defines how the hash digest must be formed prior to hashing the event id.
Discussion
It's not that strict. It only says that the encoding is UTF-8 and that there shouldn't be white spaces or line breaks. I have seen different implementations serializing the same object differently for example when you use stranger characters like emojis. So here when you calculate the event ID/signature you have to pay attention on how the rest of the clients will serialize your object so that their calculations will match yours.
You can look at some Nostr library code and open source apps to see how’s it done today.
Certainly could be more strict. But it leverages existing JSON programming language libraries, which likely have already mostly standardise.
The signature is only signing the event id, not the serialised event. But again, I’m yet to see any issues in the wild.
The signature signs the whole object (minus the signature of course). Let me quote NIP-01:
> "sig": <64-bytes hex of the signature of the sha256 hash of the serialized event data, which is the same as the "id" field>
https://github.com/0xtlt/nostr_rust/blob/main/src/events.rs#L127
https://github.com/scsibug/nostr-rs-relay/blob/master/src/event.rs#L359
What's your point? They are all signing the hash of the serialized event data (the whole object basically)