Part of the problem is that inputs don't necessarily reflect the specific intent behind the use of certain symbols. For 99% of people using US keyboards when they input a dash in a credit card number they are using the exact same key as one would use for the minus when inputting a negative number. If you asked them to verbalize their inputs they would probably use different words for the same symbol, signifying that the meaning or intent isn't the same but even that isn't entirely reliable.

You can attempt to infer intent or meaning based on the context of the input field but often the least-problematic method is to provide instruction/hints with the field, examples of correctness, and real-time validation with specific syntax errors when invalid or unexpected data is provided. I'd argue that it would also be worthwhile to request clarity from the user when an input hits a filtering rule so that they can make clear their intent... e.g. if you assume that they're using "-" as a symbol for separation rather than simply follow that assumption, ask if that's the case and list other optional valid contexts for that symbol so they can be explicit. If they choose None of the Above or a context that is inappropriate for the field, inform them of that.

The 4-box credit card form, while pretty terrible in many ways, at least made explicit the expectations. Often we now hide the expectations and either auto-reformat what was put in the field (which can be surprising to the user or worse can modify their input to mean something other than what they intended) or do hidden filtering, which can have the same problems but doesn't even bother to inform the user of the changes.