smarter_csv 1.16.1 → 1.16.2

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 043745aedb1c63fd4a044b9ae46bb8e5d98324c14e609214ee3d895acfd5f501
-  data.tar.gz: c39a10521b767daf51887278c9020c9ff6d8d93c32c5ec3f95a17ec575ebdab5
+  metadata.gz: 6d4cf6c7123e6048cb2c8de80ad92625a9985954e4308084f0a5b86cae4df03c
+  data.tar.gz: 5bd6237f017a8d4c54e4ee9ce6f9c3863d65d744c49ed1d6409c78c07f84ec88
 SHA512:
-  metadata.gz: 5f1d125138443f02e0276e964dac9e584b996de6acafe8b3856316852a38220094e69a2c14302f922bcc93b6d23cc594bbf926940ccd70a2bd65ab08c5a18b49
-  data.tar.gz: '0929051996781c8643c0239556d123c840e7041d9c12f7d867e3800dfb2c2eb92e6f6fb77b5fc08660a36f34f470cb826f255943fa445d3e29d231e648da51b4'
+  metadata.gz: 25259d4b0b4edfe05c8e5d83e5ba691f6c82effaacc3a2cb9b78490f89b1e7a132ae70c8d1ea32731d1c3cce1f62e1dd98d05ae23576cc9872bd1ff4ac635ea3
+  data.tar.gz: 045fae96155913ff53c7661c7b4fe59946a792b72ff833eb723b49138406f30b3d6763e196c2cb6d5286ce014dc3d07f7bda94434a58857701b97d24a407fb4f

data/CHANGELOG.md

@@ -1,6 +1,22 @@
 
 # SmarterCSV 1.x Change Log
 
+## 1.16.2 (2026-03-30) — Bug Fixes
+
+RSpec tests: **1,410 → 1,425** (+15 tests)
+
+### Bug Fixes
+
+* Fixed `value_converters` to accept lambdas and Procs in addition to class-based converters.
+  Thanks to [Jonas Staškevičius](https://github.com/pirminis) for issue [#329](https://github.com/tilo/smarter_csv/issues/329).
+
+* Fixed blank header auto-naming to use **absolute column position**, consistent with extra data column naming.
+  `name,,` now produces `column_2`/`column_3` instead of `column_1`/`column_2`.
+  ⚠️ If your code references auto-generated keys for blank headers, update those to use the absolute column position.
+
+* Fixed `Writer`: when both `map_headers:` and `header_converter:` were used together, `map_headers` was silently ignored.
+  `map_headers` is now applied first, then `header_converter` on top.
+
 ## 1.16.1 (2026-03-16) — Bug Fixes & New Features
 
 RSpec tests: **1,247 → 1,410** (+163 tests)
@@ -101,7 +117,6 @@ Measured on 19 benchmark files, Apple M1, Ruby 3.4.7. See [benchmarks](docs/rele
  * `remove_values_matching:` → use `nil_values_matching:`
  * `strict:` → use `missing_headers: :raise/:auto`
  * `verbose: true/false` → use `verbose: :debug/:normal`
- * `only_headers:` / `except_headers:` → use `headers: { only: }` / `headers: { except: }`
 
 ### Bug Fixes
 

data/CONTRIBUTORS.md

@@ -1,4 +1,4 @@
-# A Big Thank You to all 61 Contributors!!
+# A Big Thank You to all 63 Contributors!!
 
 
 A Big Thank you to everyone who filed issues, sent comments, and who contributed with pull requests:
@@ -65,3 +65,4 @@ A Big Thank you to everyone who filed issues, sent comments, and who contributed
  * [Tophe](https://github.com/tophe)
  * [Dom Lebron](https://github.com/biglebronski)
  * [Paho Lurie-Gregg](https://github.com/paholg)
+ * [Jonas Staškevičius](https://github.com/pirminis)

data/README.md

@@ -249,7 +249,7 @@ For reporting issues, please:
   * open a pull-request adding a test that demonstrates the issue
   * mention your version of SmarterCSV, Ruby, Rails
 
-# [A Special Thanks to all 62 Contributors!](CONTRIBUTORS.md) 🎉🎉🎉
+# [A Special Thanks to all 63 Contributors!](CONTRIBUTORS.md) 🎉🎉🎉
 
 
 ## Contributing

data/docs/options.md

@@ -119,7 +119,7 @@ See [Parsing Strategy](./parsing_strategy.md) for full details on quote handling
 |--------|---------|-------------|
 | `:strip_whitespace` | `true` | Remove whitespace before/after values and headers. |
 | `:convert_values_to_numeric` | `true` | Convert strings containing integers or floats to the appropriate numeric type. Accepts `{except: [:key1, :key2]}` or `{only: :key3}` to limit which columns. |
-| `:value_converters` | `nil` | Hash of `:header => ClassName`; each class must implement `self.convert(value)`. See [Value Converters](./value_converters.md). |
+| `:value_converters` | `nil` | Hash of `:header => converter`; converter can be a lambda/Proc or a class implementing `self.convert(value)`. See [Value Converters](./value_converters.md). |
 | `:remove_empty_values` | `true` | Remove key/value pairs where the value is `nil` or an empty string. |
 | `:remove_zero_values` | `false` | Remove key/value pairs where the numeric value equals zero. |
 | `:nil_values_matching` | `nil` | Set matching values to `nil`. Accepts a regular expression matched against the string representation of each value (e.g. `/\ANAN\z/` for NaN, `/\A#VALUE!\z/` for Excel errors). With `remove_empty_values: true` (default), nil-ified values are then removed. With `remove_empty_values: false`, the key is retained with a `nil` value. |

data/docs/releases/1.16.0/changes.md

@@ -195,8 +195,6 @@ See [performance_notes.md](performance_notes.md) and [benchmarks.md](benchmarks.
 
 **Deprecations:**
 
-- `only_headers:` → use `headers: { only: }`
-- `except_headers:` → use `headers: { except: }`
 - `remove_values_matching:` → use `nil_values_matching:`
 - `strict: true` → use `missing_headers: :raise`
 - `strict: false` → use `missing_headers: :auto`

data/docs/ruby_csv_pitfalls.md

@@ -26,50 +26,84 @@
 
 # Ruby CSV Pitfalls: Silent Data Corruption and Loss
 
-Ruby's built-in `CSV` library is for many the go-to — it ships with Ruby and requires no dependencies. But it has failure modes that produce **no exception, no warning, and no indication that anything went wrong**. Your import runs, your tests pass, and your data is quietly wrong.
+When having to parse CSV files, many developers go straight to the Ruby `CSV` library — it ships with Ruby and requires no dependencies.
 
-This page documents ten reproducible ways `CSV.read` (and `CSV.table`) can silently corrupt or lose data, with examples you can run yourself, and how SmarterCSV handles each case.
+But it comes at the cost of boilerplate post-processing you have to write, test, and maintain yourself. Worse, there are some failure modes that produce **no exception, no warning, and no indication that anything went wrong**. Your import runs, your tests pass, and your data is quietly wrong.
 
-> **Note on `CSV.table`:** It's a convenience wrapper for `CSV.read` with `headers: true`, `header_converters: :symbol`, and `converters: :numeric`.
+`CSV.read` is fine for small, trusted, well-formed files — particularly when you control the source. This page is about what can happen with **messy real-world files your partners produce, or users upload** — ten reproducible ways `CSV.read` and `CSV.table` can silently corrupt or lose data, with examples you can run yourself, and how SmarterCSV handles each case.
+
+> Not all ten may be equally surprising — some are odd behavior that bites you anyway, others are genuine traps. All ten are silent.
+
+---
+
+> 💡 **Want to follow along?** Download the [example CSV files](https://raw.githubusercontent.com/tilo/articles/main/ruby/smarter_csv/10-ways-ruby_csv-can-silently-corrupt-or-lose-your-data/images/10-ways-ruby_csv-can-silently-corrupt-or-lose-your-data-examples.tgz) and run the examples locally.
 
 ---
 
 ## At a Glance
 
-| # | Ruby CSV Issue | Failure Mode | SmarterCSV fix | SmarterCSV Details |
-|---|-------|-------------|:--------------:|---------|
-| 1 | Extra columns silently dropped | Values beyond header count compete for the `nil` key — all but the last are discarded | by default ✅ | Default `missing_headers: :auto` auto-generates `:column_N` keys |
-| 2 | Duplicate headers — last wins | `.to_h` keeps only the last value for a repeated header; earlier values silently lost | by default ✅ | Default `duplicate_header_suffix:` → `:score`, `:score2`, `:score3` |
-| 3 | Empty headers — `""` key collision | Blank header cells become `""` keys; multiple blanks collide and overwrite each other | by default ✅ | Default `missing_header_prefix:` → `:column_1`, `:column_2` |
-| 4 | BOM corrupts first header | `"\xEF\xBB\xBFname"` ≠ `"name"` — first column becomes unreachable by its key | by default ✅ | Automatic BOM stripping — always on, no option needed |
-| 5 | Whitespace in headers ¹ | `" Age"` ≠ `"Age"` — lookup silently returns `nil` | by default ✅ | Default `strip_whitespace: true` strips headers and values |
-| 6 | `liberal_parsing` garbles fields | Unmatched quotes produce wrong field boundaries — corrupted data returned as valid | by default ✅ | `on_bad_row: :raise` (default); opt-in `:skip` / `:collect` for quarantine |
-| 7 | `nil` vs `""` for empty fields | Unquoted empty → `nil`, quoted empty → `""` — inconsistent empty checks | by default ✅ | Default `remove_empty_values: true` removes both; `false` normalizes both to `nil` |
-| 8 | Backslash-escaped quotes (MySQL/Unix) | `\"` treated as field-closing quote — crash or garbled data | by default ✅ | Default `quote_escaping: :auto` handles both RFC 4180 and backslash escaping |
-| 9 | Missing closing quote eats the rest of the file | One unclosed `"` swallows all subsequent rows into one field value | via option | `field_size_limit: N` raises immediately; `quote_boundary: :standard` (default) reduces exposure |
-| 10 | No encoding auto-detection | Non-UTF-8 files either crash or silently produce mojibake | via option | `file_encoding:`, `force_utf8: true`, `invalid_byte_sequence:` |
-
-¹ The one case where `CSV.table` does better than `CSV.read`: its `header_converters: :symbol` option includes `.strip`, so whitespace is removed from headers. All other nine issues are identical between `CSV.read` and `CSV.table`.
+| # | Severity | Ruby CSV Issue | Failure Mode | SmarterCSV fix | SmarterCSV Details |
+|---|:--------:|-------|-------------|:--------------:|---------|
+| 1 | 🔴 | Extra columns silently dropped | Values beyond header count compete for the `nil` key — only the first survives, the rest are discarded | by default ✅ | Default `missing_headers: :auto` auto-generates `:column_N` keys |
+| 2 | 🔴 | Duplicate headers — first wins | `.to_h` keeps only the first value for a repeated header; later values silently lost | by default ✅ | Default `duplicate_header_suffix:` → `:score`, `:score2`, `:score3` |
+| 3 | 🔴 | Empty headers — `nil` key collision | Blank header cells become `nil` keys; multiple blanks collide and only the first value survives | by default ✅ | Default `missing_header_prefix:` → `:column_1`, `:column_2` |
+| 4 | 🔴 | `converters: :numeric` silently corrupts leading-zero values as octal ¹ | `Integer()` interprets leading zeros as octal — `"00123"` → `83` ❌ | by default ✅ | Default `convert_values_to_numeric: true` uses decimal — no octal trap; `convert_values_to_numeric: false` preserves strings exactly |
+| 5 | 🟡 | Whitespace in headers ² | `" Age"` ≠ `"Age"` — lookup silently returns `nil` | by default ✅ | Default `strip_whitespace: true` strips headers and values |
+| 6 | 🟡 | Whitespace around values | `"active  " == "active"` → `false` — leading/trailing spaces or tabs cause status/type checks to silently return wrong results | by default ✅ | Default `strip_whitespace: true` strips all values; set `false` to preserve spaces |
+| 7 | 🟠 | `nil` vs `""` for empty fields | Unquoted empty → `nil`, quoted empty → `""` — inconsistent empty checks | by default ✅ | Default `remove_empty_values: true` removes both; `false` normalizes both to `""` |
+| 8 | 🟠 | Backslash-escaped quotes (MySQL/Unix) | `\"` treated as field-closing quote — crash or garbled data | by default ✅ | Default `quote_escaping: :auto` handles both RFC 4180 and backslash escaping |
+| 9 | 🔴 | TSV file read as CSV — completely breaks ❌ | Default `col_sep: ","` on a tab-delimited file returns each row as a single string; all column structure lost | by default ✅ | Default `col_sep: :auto` detects the actual delimiter — no option needed |
+| 10 | 🔴 | No encoding auto-detection | Non-UTF-8 files either crash or silently produce mojibake | via option | `file_encoding:`, `force_utf8: true`, `invalid_byte_sequence: ''` |
+
+¹ Issue #4 can be triggered two ways: `CSV.table` enables `converters: :numeric` by default (no opt-in required), and `CSV.read` triggers the same corruption when passed `converters: :numeric` explicitly. Either way, any leading-zero string field — ZIP codes, customer IDs, product codes — is silently converted to a wrong integer.
+
+² The one case where `CSV.table` does better than `CSV.read`: its `header_converters: :symbol` option includes `.strip`, so whitespace is removed from headers (#5). Values (#6) are not stripped — `CSV.table` has the same whitespace-around-values problem. For all other issues `CSV.table` is identical to or worse than `CSV.read`.
+
+> `CSV.table` is a convenience wrapper for `CSV.read` with `headers: true`, `header_converters: :symbol`, and `converters: :numeric`.
+
+---
+
+## The Real Cost of Handling This Yourself
+
+Experienced users of `CSV.read` know some of these gotchas and handle them in post-processing — but not all of them can be: some are serious bugs that will silently corrupt your data regardless. And even for the ones you can handle, manual post-processing has five hidden costs:
+
+* **You hand-craft boilerplate for every use case.** The right fix for whitespace differs when headers have spaces vs. values have spaces vs. both. Encoding handling depends on the source system. There is no generic post-processing snippet — you write a slightly different version every time.
+
+* **You have to remember all of it, every time.** Every new import, service, or data source needs the same gotchas handled — consistently. But boilerplate doesn't enforce itself. A fix you wrote for one importer doesn't automatically apply to the next. The gotchas don't announce themselves — you only catch them if you remember to look.
+
+* **Your boilerplate is probably undertested.** Post-processing code that wraps `CSV.read` rarely gets the same test coverage as business logic. Developers don't think of it as the risky part. Data edge cases — files with blank headers, leading-zero IDs, quoted empty fields, mixed encoding — don't make it into the test suite until they cause a production incident. You don't know what your boilerplate misses until a file breaks it.
+
+> ❓ Do your tests for your CSV wrapper just test the mechanics, or include data corner cases?
+
+* **Your benchmarks probably don't include the boilerplate code.** When you chose `CSV.read`, you probably looked at raw parsing performance — but did you measure the end-to-end cost of your post-processing? Whitespace stripping, header cleanup, empty normalization: none of that is free. Your end-to-end data pipeline is much slower than what you initially measured.
+
+* **One library that handles it predictably and performant is worth more than the sum of its parts.** The value isn't "these ten cases are covered." It is that you stop maintaining a bespoke cleaning pipeline, stop writing one-off fixes after production surprises, and don't have to worry about test coverage or performance - you can trust that the default behavior handles edge cases sensibly — without silently damaging your data.
+
+Predictable behavior in a well-tested library beats hand-crafted boilerplate that anticipates fewer edge cases.
 
 ---
 
 ## Why These Failures Are Dangerous
 
-Every failure in this list is **silent**. No exception, no warning, no log line — the import completes successfully and the data is quietly wrong. That makes them hard to catch in tests and easy to miss in code review.
+**Every single failure in this list is silent.** No exception, no warning, no log line — your import completes successfully and your data is quietly wrong. That's what makes these issues so dangerous: they don't surface in tests, they don't cause immediate errors, and they're easy to miss during code review.
+
+The root cause is that `CSV.read` is a **tokenizer**, not a data pipeline. It splits bytes into fields and hands them back with no normalization, no validation, and no defensive handling of real-world messiness. Every assumption about what "clean" input looks like is left to the caller.
 
-The root cause is that `CSV.read` is a tokenizer, not a data pipeline. It splits bytes into fields and returns them with no normalization, no validation, and no defensive handling of real-world messiness. Every assumption about what "clean" input looks like is left to the caller.
+Issue #4 deserves special mention: `CSV.table`'s default `converters: :numeric` silently turns `"00123"` into `83`³ and `"01234"` into `668`³ — values that look like perfectly valid integers. ZIP codes, customer IDs, and product codes are quietly replaced with wrong numbers that pass every validation, get stored in your database, and are indistinguishable from real data until someone notices the numbers don't match.
 
-`CSV.table` fixes exactly one issue out of ten — whitespace in headers — because its `:symbol` converter happens to call `.strip`. Everything else is identical.
+These aren't obscure edge cases. Extra columns, trailing commas, Windows-1252 encoding, duplicate headers, blank header cells, TSV-vs-CSV confusion, leading-zero identifiers, and whitespace-padded values are all common in CSV files exported from Excel, reporting tools, ERP systems, and legacy data pipelines. If your application accepts user-uploaded CSV files, you will encounter these.
 
-These are not obscure edge cases. Extra columns, trailing commas, BOMs, Windows-1252 encoding, duplicate headers, and blank header cells are all common in CSV files exported from Excel, reporting tools, ERP systems, and legacy data pipelines.
+The defensive post-processing code required to handle all ten cases correctly — octal-safe numeric conversion, whitespace normalization, duplicate header disambiguation, extra column naming, consistent empty value handling, backslash quote escaping, delimiter auto-detection, encoding detection — is non-trivial to write, test, and maintain. Most applications never bother, because the failures are silent.
 
-> **Ready to switch?**  ➡️ [Migrating from Ruby CSV](./migrating_from_csv.md)
+³ These aren't rounding errors or truncations — they are completely different numbers. [Octal](https://en.wikipedia.org/wiki/Octal) is a base-8 number system from the early days of computing, still used in low-level Unix file permissions and C integer literals. It has no place in CSV data. No spreadsheet, ERP system, or database exports ZIP codes or customer IDs in octal — but Ruby CSV silently assumes that's exactly what a leading zero means.
+
+Read on for a detailed explanation and reproducible example for each issue.
 
 ---
 
 ## 1. Extra Columns Without Headers — Values Silently Discarded
 
-When a row has more fields than there are headers, `CSV.read` maps every extra field to the `nil` key. If there are multiple extra fields, they all compete for the same `nil` key — **only the last one survives**, the rest are silently discarded.
+When a row has more fields than there are headers, `CSV.read` maps every extra field to the `nil` key. If there are multiple extra fields, they all compete for the same `nil` key — **only the first one survives**, the rest are silently discarded.
 
 ```
 $ cat example1.csv
@@ -78,36 +112,46 @@ Alice , Smith,  30, VIP, Gold ,
 Bob, Jones,  25
 ```
 
-**With Ruby CSV:**
-
 ```ruby
 rows = CSV.read('example1.csv', headers: true).map(&:to_h)
 rows.first
-# => {"   First Name  " => "Alice ", " Last Name " => " Smith", " Age" => "  30", nil => ""}
-#                             the values "VIP" and "Gold" are silently lost here  ^^^^^^^^^
+# => {
+#       "   First Name  " => "Alice ",
+#           " Last Name " => " Smith",
+#                 " Age" => "  30",
+#                    nil => " VIP"
+#                    ^^^^^^^^^^^^^
+#  data from unnamed column with "Gold" is silently lost
+# }
 ```
 
-Alice's row has 6 fields but only 3 headers. The extra fields `"VIP"`, `"Gold"`, and `""` (trailing comma) all land on `nil` — each overwriting the last. No error, no warning.
+Alice's row has 6 fields but only 3 headers. The extra fields `" VIP"`, `" Gold"`, and `""` (trailing comma) all land on `nil` — only the first one wins. No error, no warning.
 
 This is common in real-world exports: tools frequently append audit columns, status flags, or trailing commas that don't correspond to headers.
 
 **`CSV.table` has the same problem.**
 
-**With SmarterCSV:**
+**SmarterCSV:** The default `missing_headers: :auto` auto-generates distinct names for extra columns using `missing_header_prefix` (default: `"column_"`). The trailing empty field is dropped by the default `remove_empty_values: true` setting. No data loss.
 
 ```ruby
 rows = SmarterCSV.process('example1.csv')
 rows.first
-# => {first_name: "Alice", last_name: "Smith", age: 30, column_1: "VIP", column_2: "Gold"}
+# => {
+#     first_name: "Alice",
+#      last_name: "Smith",
+#            age: 30,
+#       column_4: "VIP",
+#       column_5: "Gold"
+#       ^^^^^^^^^^^^^^^^
+#  extra data columns are handled, no data is lost
+# }
 ```
 
-The default `missing_headers: :auto` auto-generates distinct names for extra columns using `missing_header_prefix` (default: `"column_"`). The trailing empty field is dropped by the default `remove_empty_values: true` setting. No data loss.
-
 ---
 
-## 2. Duplicate Header Names — First Value Silently Dropped
+## 2. Duplicate Header Names — Second Value Silently Dropped
 
-When two columns share the same header name, `CSV::Row#to_h` keeps only the **last** value. The first is silently dropped.
+When two columns share the same header name, `CSV::Row#to_h` keeps only the **first** value. Later values are silently dropped.
 
 ```
 $ cat example2.csv
@@ -115,18 +159,18 @@ score,name,score
 95,Alice,87
 ```
 
-**With Ruby CSV:**
-
 ```ruby
 rows = CSV.read('example2.csv', headers: true).map(&:to_h)
 rows.first
-# => {"score" => "87", "name" => "Alice"}
-#    ^^^ first score (95) silently lost
+# => {"score" => "95", "name" => "Alice"}
+#    ^^^ second score (87) silently lost
 ```
 
 Common with reporting tool exports that repeat a column (e.g., two date columns both labeled `"Date"`).
 
-**With SmarterCSV:**
+**`CSV.table` has the same problem.**
+
+**SmarterCSV:** disambiguates duplicate headers by appending a number directly: `:score`, `:score2`, `:score3`.
 
 ```ruby
 rows = SmarterCSV.process('example2.csv')
@@ -136,15 +180,15 @@ rows.first
 
 * The default `duplicate_header_suffix: ""` disambiguates by appending a counter: `:score`, `:score2`, `:score3`.
 * Use `duplicate_header_suffix: '_'` to get `:score_2`, `:score_3`.
-* Set `duplicate_header_suffic: nil` to raise `DuplicateHeaders` instead.
+* Set `duplicate_header_suffix: nil` to raise `DuplicateHeaders` instead.
 
 ---
 
-## 3. Empty Header Fields — `""` Key Collision
+## 3. Empty Header Fields — `nil` Key Collision
 
-A CSV file with blank header cells (e.g., `name,,age`) gives those columns an empty string key. Multiple blank headers all collide on `""` — same overwrite problem as issue #1.
+A CSV file with blank header fields (e.g., `name,,age`) gives those columns a `nil` key. Multiple blank headers all collide on `nil` — same overwrite problem as issue #1, and only the first value survives.
 
-> This is distinct from issue #1. Issue #1 is about extra *data* fields beyond the header count, which get keyed under `nil`. Issue #3 is about blank cells *in the header row itself*, which get keyed under `""`.
+> Note: this is distinct from issue #1. Issue #1 is about extra *data* fields beyond the header count, which get keyed under `nil`. Issue #3 is about blank cells *in the header row itself*, which also get keyed under `nil`.
 
 ```
 $ cat example3.csv
@@ -152,25 +196,23 @@ name,,,age
 Alice,foo,bar,30
 ```
 
-**With Ruby CSV:**
-
 ```ruby
 rows = CSV.read('example3.csv', headers: true).map(&:to_h)
 rows.first
-# => {"name" => "Alice", "" => "bar", "age" => "30"}
-#    ^^^ "foo" silently lost — both blank headers wrote to the "" key
+# => {"name" => "Alice", nil => "foo", "age" => "30"}
+#    ^^^ "bar" silently lost — both blank headers map to nil, first value wins
 ```
 
-`CSV.table` converts headers to symbols — blank headers become `:"" ` — same collision, different key:
+`CSV.table` has the same `nil` key collision:
 
 ```ruby
 rows = CSV.table('example3.csv').map(&:to_h)
 rows.first
-# => {name: "Alice", :"" => "bar", age: 30}
-#    ^^^ "foo" still silently lost
+# => {name: "Alice", nil => "foo", age: 30}
+#    ^^^ "bar" still silently lost
 ```
 
-**With SmarterCSV:**
+**SmarterCSV:** `missing_header_prefix:` (default `"column_"`) auto-generates names for blank headers: `:column_1`, `:column_2`, etc. No collision, no data loss.
 
 ```ruby
 rows = SmarterCSV.process('example3.csv')
@@ -178,47 +220,62 @@ rows.first
 # => {name: "Alice", column_1: "foo", column_2: "bar", age: 30}
 ```
 
-`missing_header_prefix:` (default `"column_"`) auto-generates names for blank headers: `:column_1`, `:column_2`, etc. No collision, no data loss.
-
 ---
 
-## 4. BOM Corrupts the First Header
+## 4. `converters: :numeric` Silently Corrupts Leading-Zero Values as Octal
 
-Files saved by Excel on Windows often include a UTF-8 BOM (`\xEF\xBB\xBF`) at the start. `CSV.read` does not strip it, so the BOM is silently prepended to the first header name.
+`converters: :numeric` When numbers have leading zeroes, the result does not just strip them - the entire number is silently converted to a completely different value³ that looks plausible but is incorrect ❌ .
+
+`CSV.table` enables `converters: :numeric` by default without any opt-in, **triggering the bug by default**. `CSV.read` is safe by default, but triggers the same corruption when `converters: :numeric` (or `converters: :integer`) is passed explicitly.
 
 ```
 $ cat example4.csv
-name,age
-Alice,30
+customer_id,zip_code,amount
+00123,01234,99.50
+00456,90210,9.99
 ```
 
-```
-$ hexdump -C example4.csv
-00000000  ef bb bf 6e 61 6d 65 2c  61 67 65 0a 41 6c 69 63  |...name,age.Alic|
-00000010  65 2c 33 30 0a                                     |e,30.|
+**With Ruby CSV:**
+
+```ruby
+# CSV.table — converters: :numeric on by default, no opt-in needed
+rows = CSV.table('example4.csv').map(&:to_h)
+rows.first
+# => {customer_id: 83, zip_code: 668, amount: 99.5}
+#    ^^^ "00123" → 83  (octal 0123 = decimal 83)
+#    ^^^ "01234" → 668 (octal 1234 = decimal 668)
+
+# CSV.read with explicit converters: :numeric — same result
+rows = CSV.read('example4.csv', headers: true, converters: :numeric).map(&:to_h)
+rows.first
+# => {"customer_id" => 83, "zip_code" => 668, "amount" => 99.5}
 ```
 
-The `ef bb bf` at offset 0 is the UTF-8 BOM — invisible in `cat` output but silently prepended to the first header by `CSV.read`.
+`"00123"` becomes `83`. `"01234"` becomes `668`. ZIP codes, customer IDs, order numbers, product codes — any field with a leading zero becomes a completely wrong integer. No exception, no warning. The resulting values look plausible and pass all type validations.
 
-**With Ruby CSV:**
+`CSV.read` without converters is safe — strings are returned as-is:
 
 ```ruby
 rows = CSV.read('example4.csv', headers: true).map(&:to_h)
-rows.first.keys.first   # => "\xEF\xBB\xBFname"  ← not "name"
-
-rows.first['name']      # => nil   ← first column unreachable
+rows.first
+# => {"customer_id" => "00123", "zip_code" => "01234", "amount" => "99.50"}
 ```
 
-The data is present but every lookup on the first column silently returns `nil`. The BOM is invisible in most terminals and editors — the output appears correct.
-
-**With SmarterCSV:**
+**SmarterCSV:**
 
 ```ruby
+# Default (convert_values_to_numeric: true) — decimal conversion, no octal trap
 rows = SmarterCSV.process('example4.csv')
-rows.first[:name]       # => "Alice"  ← BOM stripped automatically
+rows.first
+# => {customer_id: 123, zip_code: 1234, amount: 99.5}
+
+# convert_values_to_numeric: false — preserves strings exactly, including leading zeros
+rows = SmarterCSV.process('example4.csv', convert_values_to_numeric: false)
+rows.first
+# => {customer_id: "00123", zip_code: "01234", amount: "99.50"}
 ```
 
-By default SmarterCSV automatically detects and strips BOMs. Always on, no option needed.
+SmarterCSV's default `convert_values_to_numeric: true` uses `to_i` / `to_f`, which always treats strings as decimal — no octal interpretation. Use `convert_values_to_numeric: false` when leading zeros must be preserved (ZIP codes, IDs, product codes).
 
 ---
 
@@ -232,94 +289,71 @@ $ cat example5.csv
 Alice,30
 ```
 
-**With Ruby CSV:**
-
 ```ruby
 rows = CSV.read('example5.csv', headers: true).map(&:to_h)
 rows.first
-# => {" name " => "Alice", " age " => "30"}
+# => {" name " => "Alice", " age" => "30"}
 
-rows.first['name']   # => nil  ← key is " name ", not "name"
+rows.first['name']   # => nil  ← silent miss; key is " name ", not "name"
 rows.first['age']    # => nil
 ```
 
-> `CSV.table` mitigates this: the `:symbol` header converter includes `.strip`. This is the one issue where `CSV.table` behaves better than `CSV.read`.
+**`CSV.table` mitigates this:** ² the `:symbol` header converter includes `.strip`, so whitespace is removed from headers. This is the one issue where `CSV.table` behaves better than `CSV.read`.
 
-**With SmarterCSV:**
+**SmarterCSV:**
 
 ```ruby
 rows = SmarterCSV.process('example5.csv')
 rows.first
 # => {name: "Alice", age: 30}
 ```
-
 The default setting `strip_whitespace: true` strips leading/trailing whitespace from both headers and values.
 
+
 ---
 
-## 6. `liberal_parsing: true` Garbles Field Values
+## 6. Whitespace Around Values — Silent Comparison Failure
 
-`CSV.read` raises `MalformedCSVError` when it encounters an unmatched quote. `liberal_parsing: true` suppresses the error and returns a row anyway — but with wrong field boundaries.
+`CSV.read` returns field values exactly as they appear in the file — leading spaces, trailing spaces, and tab characters all preserved. Exporters from fixed-width database systems (Oracle `CHAR` columns, COBOL-era systems) routinely pad string fields to a fixed width; other tools leave accidental leading spaces. The values look correct when printed, but equality checks silently return `false`.
 
-**The key danger:** without `liberal_parsing` you at least know something is wrong. With it, corrupted data is silently returned as valid.
+This pairs with Example 5 (whitespace in headers): Ruby CSV strips neither headers nor values by default.
 
 ```
 $ cat example6.csv
-name,note,score
-Alice,"unclosed quote,99
-Bob,normal,87
+name,status,city
+Alice,active  ,New York    ← trailing spaces after 'active'
+Bob,inactive,Chicago
+Carol, active,Boston       ← leading space before 'active'
 ```
 
-**With Ruby CSV:**
-
 ```ruby
-# Without liberal_parsing: you know something is wrong
-CSV.read('example6.csv', headers: true)
-# => CSV::MalformedCSVError: Unclosed quoted field on line 2
+rows = CSV.read('example6.csv', headers: true).map(&:to_h)
 
-# With liberal_parsing: silent corruption
-rows = CSV.read('example6.csv', headers: true, liberal_parsing: true).map(&:to_h)
-rows.length   # => 1  (not 2 — Bob's row is gone)
-rows[0]
-# => {"name" => "Alice", "note" => "unclosed quote,99\nBob,normal,87", "score" => nil}
-#    ^^^ Alice's note field swallowed the rest of the file; Bob vanished
+rows[0]['status']  # => "active  "
+rows[2]['status']  # => " active"
+
+rows.select { |r| r['status'] == 'active' }
+# => []  ← Alice and Carol are not found. No error raised.
 ```
 
-The garbled row passes validations, gets inserted into the database, and surfaces as a data quality issue later.
+The values look fine in logs and `puts` output. The bug only surfaces when the comparison silently returns the wrong result.
 
-**With SmarterCSV:**
+**Workaround:** pass `strip: true` to `CSV.read`. This correctly strips spaces and tab characters. Note it also strips intentional leading/trailing spaces from any field — including quoted fields where spaces may be meaningful.
 
-```ruby
-reader = SmarterCSV::Reader.new('example6.csv', on_bad_row: :collect)
-good_rows = reader.process
-reader.errors
-# => {
-#     :bad_row_count => 1,
-#          :bad_rows => [
-#         {
-#                 :csv_line_number => 2,
-#                :file_line_number => 2,
-#             :file_lines_consumed => 2,
-#                     :error_class => SmarterCSV::MalformedCSV,
-#                   :error_message => "Unclosed quoted field detected in multiline data",
-#                :raw_logical_line => "Alice,\"unclosed quote,99\nBob,normal,87\n"
-#         }
-#     ]
-# }
-```
+**`CSV.table` has the same problem** — its `:symbol` converter strips header names but does not touch field values.
 
-Or pass a lambda to `on_bad_row` — works with `SmarterCSV.process` (no `Reader` instance needed):
+**SmarterCSV:**
 
 ```ruby
-bad_rows = []
-good_rows = SmarterCSV.process('example6.csv',
-  on_bad_row: ->(rec) { bad_rows << rec })
+rows = SmarterCSV.process('example6.csv')
+
+rows[0][:status]  # => "active"
+rows[2][:status]  # => "active"
+
+rows.select { |r| r[:status] == 'active' }.length  # => 2
 ```
 
-* `on_bad_row: :raise` (default) fails fast.
-* `on_bad_row: :collect` quarantines them — use `reader.errors` to access.
-* `on_bad_row: ->(rec) { ... }` calls your lambda per bad row; works with `SmarterCSV.process`.
-* `on_bad_row: :skip` discards bad rows silently.
+`strip_whitespace: true` (default) strips all leading and trailing whitespace (spaces and tabs) from values. Set `strip_whitespace: false` to preserve spaces when needed.
 
 ---
 
@@ -337,8 +371,6 @@ Alice,
 Bob,""
 ```
 
-**With Ruby CSV:**
-
 ```ruby
 rows = CSV.read('example7.csv', headers: true).map(&:to_h)
 
@@ -349,9 +381,11 @@ rows[0]['city'].nil?   # => true
 rows[1]['city'].nil?   # => false  ← same semantic meaning, different Ruby type
 ```
 
-Both rows have no city, but your code sees two different things. Any check using `.nil?`, `.blank?`, `.present?`, or `if row['city']` will behave differently depending on how the upstream exporter quoted the empty field.
+Both rows have no city. But your code sees two different things. Any check using `.nil?`, `.blank?`, `.present?`, or a simple `if row['city']` will behave differently depending on how the upstream exporter happened to quote the empty field. No two exporters agree on this.
 
-**With SmarterCSV:**
+**`CSV.table` has the same problem.**
+
+**SmarterCSV:** `remove_empty_values: true` (default) removes both from the hash. With `remove_empty_values: false`, both are normalized to `""`. Consistent either way.
 
 ```ruby
 # remove_empty_values: true (default) — both empty cities are dropped from the hash
@@ -359,17 +393,17 @@ rows = SmarterCSV.process('example7.csv')
 rows[0]   # => {name: "Alice"}
 rows[1]   # => {name: "Bob"}
 
-# remove_empty_values: false — both normalized to nil
+# remove_empty_values: false — both normalized to ""
 rows = SmarterCSV.process('example7.csv', remove_empty_values: false)
-rows[0]   # => {name: "Alice", city: nil}
-rows[1]   # => {name: "Bob",   city: nil}
+rows[0]   # => {name: "Alice", city: ""}
+rows[1]   # => {name: "Bob",   city: ""}
 ```
 
 ---
 
 ## 8. Backslash-Escaped Quotes — MySQL / Unix Dump Format
 
-MySQL's `SELECT INTO OUTFILE`, PostgreSQL `COPY TO`, and many Unix data-pipeline tools escape embedded double quotes as `\"` — not as `""` (the RFC 4180 standard). Ruby's `CSV` only understands RFC 4180, so a backslash before a quote is treated as two separate characters: a literal `\` followed by a `"` that immediately **closes the field**.
+MySQL's `SELECT INTO OUTFILE`, PostgreSQL `COPY TO`, and many Unix data-pipeline tools escape embedded double quotes as `\"` — not as `""` (the RFC 4180 standard). Ruby's `CSV` only understands the RFC 4180 convention, so a backslash before a quote is treated as two separate characters: a literal `\` followed by a `"` that immediately **closes the field**.
 
 ```
 $ cat example8.csv
@@ -378,92 +412,69 @@ Alice,"She said \"hello\" to everyone"
 Bob,"Normal note"
 ```
 
-**With Ruby CSV — Scenario 1: crash** (at least you know something went wrong):
+**Scenario 1 — crash** (at least you know something went wrong):
 
 ```ruby
 rows = CSV.read('example8.csv', headers: true)
-# => CSV::MalformedCSVError: Illegal quoting in line 2.
+# => CSV::MalformedCSVError: Any value after quoted field isn't allowed in line 2.
 ```
 
-**With Ruby CSV — Scenario 2: silent garbling** with `liberal_parsing: true`:
+**Scenario 2 — silent garbling** with `liberal_parsing: true`:
 
 ```ruby
 rows = CSV.read('example8.csv', headers: true, liberal_parsing: true)
-rows[0]['name']   # => "Alice"
-rows[0]['note']   # => "She said \\"   ← field closed at the backslash-quote; rest lost
-rows[1]['name']   # => "hello"          ← Alice's leftovers eaten as Bob's name
-rows[1]['note']   # => nil
+rows[0]['note']   # => 'She said \"hello\" to everyone'
 ```
 
-No exception. No warning. `rows.length` is still 2. The data just quietly moved to the wrong fields.
+No exception. No warning. The note field has extra wrapping quotes and mangled escaping — it won't compare, display, or serialize correctly.
+
+**`CSV.table` has the same problem** — and adding `liberal_parsing: true` makes it silently worse.
 
-**With SmarterCSV:**
+**SmarterCSV:** `quote_escaping: :auto` (default since 1.0) detects and handles both `""` and `\"` escaping row-by-row. No option required.
 
 ```ruby
 rows = SmarterCSV.process('example8.csv')
-rows[0]   # => {name: "Alice", note: "She said \"hello\" to everyone"}
+rows[0]   # => {name: "Alice", note: 'She said \"hello\" to everyone'}
 rows[1]   # => {name: "Bob",   note: "Normal note"}
 ```
 
-`quote_escaping: :auto` (default) detects and handles both `""` and `\"` escaping row-by-row. No option required. This covers MySQL `SELECT INTO OUTFILE`, PostgreSQL `COPY TO`, and Unix `csvkit`/`awk`-generated files.
-
 ---
 
-## 9. Missing Closing Quote Consumes the Rest of the File
+## 9. TSV File Read as CSV — Completely Breaks ❌
 
-A single unclosed `"` causes the parser to enter quoted-field mode and treat everything that follows — newlines included — as part of one field. **All remaining rows are swallowed into a single field value.**
+`CSV.read` defaults to `col_sep: ","`. When given a tab-delimited file (TSV), it finds no commas and treats each entire row as a single field. The header row becomes one giant key; each data row becomes one giant value. All column structure is silently lost — no error, no warning, and `rows.length` looks correct.
 
 ```
-$ cat example8.csv
-name,age
-"Alice,30
-Bob,25
-Carol,40
+$ cat example9.csv
+name	city	score
+Alice	New York	95
+Bob	Chicago	87
 ```
 
-**With Ruby CSV:**
-
 ```ruby
-rows = CSV.read('example8.csv', headers: true)
-rows.length         # => 1  (not 3)
-rows.first['name']  # => "Alice,30\nBob,25\nCarol,40"
-#                         ^^^ entire remainder of file in one field
-```
+rows = CSV.read('example9.csv', headers: true).map(&:to_h)
 
-On a large file this is an OOM risk: the parser accumulates an ever-growing string until EOF or memory exhaustion. There is no field size limit, no timeout, and no error until the file ends.
+rows.length           # => 2  (looks right — but...)
+rows.first.keys       # => ["name\tcity\tscore"]  ← entire header is one key
+rows.first['name']    # => nil  ← column unreachable
+rows.first.values     # => ["Alice\tNew York\t95"]  ← entire row is one value
+```
 
-**With SmarterCSV:**
+This can happen when users upload TSV instead of CSV - the file name could still be `.csv`, so indistinguishable from actual CSV data.
 
-```ruby
-reader = SmarterCSV::Reader.new('example8.csv',
-  on_bad_row: :collect,
-)
-good_rows = reader.process
-reader.errors
-# => {
-#     :bad_row_count => 1,
-#          :bad_rows => [
-#         {
-#                 :csv_line_number => 2,
-#                :file_line_number => 2,
-#             :file_lines_consumed => 3,
-#                     :error_class => SmarterCSV::MalformedCSV,
-#                   :error_message => "Unclosed quoted field detected in multiline data",
-#                :raw_logical_line => "\"Alice,30\nBob,25\nCarol,40\n"
-#         }
-#     ]
-# }
-```
+**`CSV.table` has the same problem.**
 
-Or pass a lambda to `on_bad_row` — works with `SmarterCSV.process` (no `Reader` instance needed):
+**SmarterCSV:**
 
 ```ruby
-bad_rows = []
-good_rows = SmarterCSV.process('example8.csv',
-  on_bad_row: ->(rec) { bad_rows << rec })
+rows = SmarterCSV.process('example9.csv')
+# col_sep: :auto detects the tab separator automatically
+
+rows.first
+# => {name: "Alice", city: "New York", score: 95}
 ```
 
-`field_size_limit: N` raises `SmarterCSV::FieldSizeLimitExceeded` as soon as any field or accumulating multiline buffer exceeds N bytes — the runaway parse stops immediately. Additionally, `quote_boundary: :standard` (default since 1.16.0) means mid-field quotes don't toggle quoted mode, reducing the attack surface further.
+`col_sep: :auto` (default) samples the file and detects the actual delimiter. No option required.
 
 ---
 
@@ -472,42 +483,62 @@ good_rows = SmarterCSV.process('example8.csv',
 `CSV.read` assumes UTF-8. CSV files exported from Excel on Windows are typically Windows-1252 (CP1252), which encodes accented characters (é, ü, ñ) differently from UTF-8.
 
 ```
-$ cat example9.csv
+$ cat example10.csv
 last_name,first_name
 Müller,Hans
 ```
 
 The file is saved in Windows-1252 encoding — `ü` is stored as `\xFC`, not as UTF-8.
 
-**With Ruby CSV — Scenario 1: crash** (the better outcome — at least you know):
+**Scenario 1 — crash** (the better outcome — at least you know):
 
 ```ruby
-rows = CSV.read('example9.csv', headers: true)
-# => Encoding::InvalidByteSequenceError: "\xFC" from ASCII-8BIT to UTF-8
+rows = CSV.read('example10.csv', headers: true)
+# => CSV::InvalidEncodingError: Invalid byte sequence in UTF-8 in line 2.
 ```
 
-**With Ruby CSV — Scenario 2: silent mojibake** (the worse outcome):
+**Scenario 2 — silent mojibake** (the worse outcome):
 
 ```ruby
 # Specifying the wrong encoding suppresses the error
-rows = CSV.read('example9.csv', headers: true, encoding: 'binary')
+rows = CSV.read('example10.csv', headers: true, encoding: 'binary')
 rows.first['last_name']                # => "M\xFCller"  ← garbled string
-rows.first['last_name'].valid_encoding? # => true  ← Ruby thinks it's fine
+rows.first['last_name'].valid_encoding? # => true  ← Ruby thinks it's fine!
 ```
 
-The mojibake string passes `.valid_encoding?`, passes database validations, gets stored, and surfaces as a display bug in production.
+The mojibake string passes `.valid_encoding?`, passes database validations, gets stored, and surfaces as a display bug weeks later in production.
+
+**`CSV.table` has the same problem.**
 
-**With SmarterCSV:**
+**SmarterCSV:** `file_encoding:` accepts Ruby's `'external:internal'` transcoding notation; `force_utf8: true` transcodes to UTF-8 automatically; `invalid_byte_sequence: ''` controls the replacement character for bytes that can't be transcoded, e.g. `''`.
 
 ```ruby
-rows = SmarterCSV.process('example9.csv',
+rows = SmarterCSV.process('example10.csv',
   file_encoding: 'windows-1252:utf-8')
 rows.first[:last_name]   # => "Müller"
 ```
 
-* `file_encoding:` accepts Ruby's `'external:internal'` transcoding notation.
-* `force_utf8: true` transcodes to UTF-8 automatically.
-* `invalid_byte_sequence:` controls the replacement character for bytes that can't be transcoded.
+---
+
+## The Alternative
+
+```ruby
+gem 'smarter_csv'
+```
+
+```ruby
+# Before
+rows = CSV.read('data.csv', headers: true).map(&:to_h)
+
+# After
+rows = SmarterCSV.process('data.csv')
+```
+
+SmarterCSV handles nine of the ten cases out of the box — octal-safe numeric conversion, whitespace normalization, duplicate header disambiguation, extra column naming, consistent empty value handling, backslash quote escaping, and delimiter auto-detection.
+
+The remaining one (encoding control) requires explicit opt-in options, but the building blocks are there. No boilerplate, no post-processing pipeline, no silent data loss.
+
+> **Ready to switch?** → [Migrating from Ruby CSV](./migrating_from_csv.md)
 
 ---
 

data/lib/smarter_csv/hash_transformations.rb

@@ -62,7 +62,7 @@ module SmarterCSV
         # Apply value converters
         if value_converters
           converter = value_converters[k]
-          hash[k] = converter.convert(hash[k]) if converter
+          hash[k] = converter.respond_to?(:convert) ? converter.convert(hash[k]) : converter.call(hash[k]) if converter
         end
       end
 

data/lib/smarter_csv/header_transformations.rb

@@ -27,19 +27,21 @@ module SmarterCSV
 
     def disambiguate_headers(headers, options)
       counts = Hash.new(0)
-      empty_count = 0
       prefix = options[:missing_header_prefix] || 'column_'
       # Pre-collect non-blank header names so auto-generated names can avoid collisions.
       used = headers.reject { |h| blank?(h) }
-      headers.map do |header|
+      headers.each_with_index.map do |header, idx|
         if blank?(header)
-          # Empty headers use missing_header_prefix (e.g. "column_1", "column_2") so they
-          # produce a usable key instead of :"" which gets silently deleted downstream.
-          # Skip ahead if the generated name collides with an existing header.
-          begin
-            empty_count += 1
-            candidate = "#{prefix}#{empty_count}"
-          end while used.include?(candidate)
+          # Use absolute 1-based column position, consistent with how extra data columns
+          # beyond the header count are named. If the positional name collides with an
+          # existing header, append underscores until a free name is found — this avoids
+          # stealing the positional name from any subsequent blank header.
+          candidate = "#{prefix}#{idx + 1}"
+          suffix = ''
+          while used.include?(candidate)
+            suffix += '_'
+            candidate = "#{prefix}#{idx + 1}#{suffix}"
+          end
           used << candidate
           candidate
         else

data/lib/smarter_csv/reader.rb

@@ -357,7 +357,7 @@ module SmarterCSV
 
               if options[:value_converters]
                 options[:value_converters].each do |key, converter|
-                  hash[key] = converter.convert(hash[key]) if hash.key?(key)
+                  hash[key] = converter.respond_to?(:convert) ? converter.convert(hash[key]) : converter.call(hash[key]) if hash.key?(key)
                 end
               end
             else
@@ -755,7 +755,7 @@ module SmarterCSV
 
         if options[:value_converters]
           options[:value_converters].each do |key, converter|
-            hash[key] = converter.convert(hash[key]) if hash.key?(key)
+            hash[key] = converter.respond_to?(:convert) ? converter.convert(hash[key]) : converter.call(hash[key]) if hash.key?(key)
           end
         end
       else

data/lib/smarter_csv/version.rb

@@ -1,5 +1,5 @@
 # frozen_string_literal: true
 
 module SmarterCSV
-  VERSION = "1.16.1"
+  VERSION = "1.16.2"
 end

data/lib/smarter_csv/writer.rb

@@ -149,7 +149,7 @@ module SmarterCSV
 
     def write_header_line
       mapped_headers = @headers.map { |header| @map_headers[header] || header }
-      mapped_headers = @headers.map { |header| @header_converter.call(header) } if @header_converter
+      mapped_headers = mapped_headers.map { |header| @header_converter.call(header) } if @header_converter
       force_quotes = @quote_headers || @force_quotes
       mapped_headers = mapped_headers.map { |x| escape_csv_field(x, force_quotes) }
       @output_file.write(mapped_headers.join(@col_sep) + @row_sep) unless mapped_headers.empty?

metadata

@@ -1,13 +1,13 @@
 --- !ruby/object:Gem::Specification
 name: smarter_csv
 version: !ruby/object:Gem::Version
-  version: 1.16.1
+  version: 1.16.2
 platform: ruby
 authors:
 - Tilo Sloboda
 bindir: bin
 cert_chain: []
-date: 2026-03-16 00:00:00.000000000 Z
+date: 2026-03-30 00:00:00.000000000 Z
 dependencies: []
 description: |
   SmarterCSV is a high-performance CSV reader and writer for Ruby focused on