A column of zero-padded account codes comes back as numbers with the zeros gone. What did the reader do, and what would have prevented it?

## Why this happens at all A file that stores every value as characters hands the reader a column of fields like `00471`, `00038`, `01900`. Nothing in the file says these are codes. The reader inspects some of them, sees digits and only digits, and concludes the column is numeric — which is the most useful conclusion it could draw if the column really were quantities. Having chosen, it parses. **Parsing is the point of loss.** Converting `00471` into a number produces the value four hundred and seventy-one; the two leading zeros are notation, not value, and a number does not carry its notation around. When you later look at the column you see `471`, and the characters that made it an identifier are gone from the table entirely. ## Why you cannot repair it afterwards The instinct is to format the column back: pad every value out to a fixed width with zeros. That works only when you know the width and the width is the same for every code. - If the scheme is fixed-width, re-padding recovers the original strings, and you got lucky. - If code lengths vary — some five characters, some seven — the number no longer tells you how many zeros to restore, and there is no way back from the table alone. - If a code could contain a separator, a plus sign or spacing that was significant, the same argument applies with no fixed-width escape hatch. Two neighbouring losses come from the same cause. An identifier long enough to exceed the exact range of the chosen numeric width comes back subtly altered rather than truncated at the front, which is worse because it looks fine. And an identifier that happens to contain a decimal point or an exponent marker can be read as a fractional quantity, which reprints in a form the producing system will not recognise. ## The general rule underneath **Digits are not a type.** A postal code, an account number, a product code, a national identifier, a phone number and a year-plus-sequence reference are all written with digits and none of them is a quantity. The test is not what the characters look like; it is whether you would ever add two of them together. If you would not, the column is text and should be read as text. This is the clearest case of a general property of an inferred type: **the guess is optimised for the common case and has no idea what your data means.** The reader is not wrong about the characters. It is wrong about the domain, and it has no access to the domain. ## The two fixes, and how they differ 1. **State the type at the read.** Tell the reader that column is text. It then carries the characters through untouched. This is one statement, costs nothing at read time, and is the answer in almost every case. 2. **Hand the reader a per-column conversion hook.** Some readers let you supply your own conversion for a named column. Say the hook's shape before you say its cost: if the reader hands it one field at a time, you pay a host-language call per field and the conversion, not the parse, becomes the expensive part of the read; if the same surface hands it the whole column at once, or accepts a stated type instead of a function, it runs at the reader's own speed. Use the hook when the column genuinely needs transforming, not merely to keep it as text. ## What good looks like in practice - Identify the identifier columns before the first read, not after the first wrong join. They are usually obvious from the column names. - State their types at the read, alongside whatever else you state. - Notice that this is cheap insurance in both directions: if a column you declared as text later needs to be numeric, you convert it deliberately and see the failures; if a column you let the reader guess about was destroyed, you may not find out for months. And be aware of the variation across designs, because the same file does not behave the same everywhere. Where the reader is built to guess, this bites by default. Where the reader leaves every column as text unless told otherwise, it never bites and the opposite complaint is heard — that you must state the numeric columns yourself. Where the file declares its own types, whatever the producer wrote is what you get, and the question moves to the producer. Knowing which of the three you are dealing with is the actual skill.