Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove zero-width chars from key, before matches #243

Merged
merged 1 commit into from
Feb 23, 2023

Conversation

egregors
Copy link
Contributor

As a last way to compare keys, remove all zero-width characters from the key.

Solved #242

@pikanezi
Copy link
Member

Isn't it normal that "\u200Bdate" does not match "date"? I'm not sure if it is up to gocsv to normalize your data.

Can't you fix your data before using gocsv?

@egregors
Copy link
Contributor Author

Isn't it normal that "\u200Bdate" does not match "date"? I'm not sure if it is up to gocsv to normalize your data.

But for some reason, you're already doing it. I didn't see a big difference between strings.TrimSpace(key) == k which already in matchesKey method and cleaning zw-chars. Why “\u200Bdate” does not match “date” is normal, but “ date“ does not match “date” isn't?

A user-story here is pretty clear.
Let's say I'm a consumer of the lib. And I'd like to parse some csv.
So, I open a csv file and see titles row: data;a;b;c;;d which contains some \u200B. Obviously, I don't see any zero-width chars in titles, and write csv annotation as I see it in the raw doc.

But, after Unmarshal call, I am getting invalid result. Some cols are not parsed.

For me, it looks, like libs responsibility to maintain expected behavior. As far as you're already doing some normalization in fieldInfo.matchesKey method.

@pikanezi
Copy link
Member

Good point, thanks

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants