multiple detection failures with 2.2.1

[chardet]

multiple detection failures with 2.2.1

[sigmavirus24]

@mwoehlke-kitware part of the problem is that those strings are so small that chardet cannot properly work. Because part of chardet's algorithm relies on statistical significance of characters, having very small samples like this make it easy for chardet to not guess the correct encoding.

The failing unit tests are also well known.

[mwoehlke-kitware]

Sure, I get that it's hard. Still, from a statistics point of view, I'd think you could guess that a string consisting mostly of ASCII is more likely to contain latin characters than kanji, etc. (Also utf-8 is just more common.)

Hoping for the emoji example to work might be a bit much 😺.

[shakkhar]

I have chardet running in production and these regressions are holding me back to 2.1.1. I have quite a few UTF-8 files being misdetected as ISO-8859-2. All these files are English. All of them start with unicode BOM (which I suspect is the culprit). When can I expect a fix for this issue?

[dan-blanchard]

The UTF-8 BOM issue should be fixed now that we merged #32. I've been putting of another release until we fix the remaining unit test failures (#13) we're experiencing, but I hope to tackle that in the next couple months.

[sigmavirus24]

@Shahriman if you can try out the master branch and give us feedback, that would be great. If it works for you, I think we could release 2.2.2 and cut 2.3.0 when the unit tests are fixed

[shakkhar]

I just tested git master with my samples. Encoding guess is correct now. But let me point out that chardet.detect() returns encoding: UTF-8 in 2.1.1 whereas in git master it returns encoding: UTF-8-SIG which breaks API compatibility. So I think if you make a new release from master, it should get a major version bump.

[dan-blanchard]

@Shahriman Could you try the same thing with the develop branch? It was my intention to move to using git-flow as the workflow for our project now, so there are changes in develop not present in master. Ideally, master should match whatever the current released version is, but this didn't quite happen because #32 was merged before I saw that it was targeting master instead of develop.

As for your more general comment about major version changes, maybe @sigmavirus24 will disagree with me here, but I don't see this as an API change. It is changing from returning the incorrect encoding to the correct one. The API itself isn't changing, just the value being returned by the chardet.detect(). If you try to decode something that's really utf-8-sig (i.e., starts with the BOM) as utf-8, you'll end up with junk at the beginning of the resulting string.

[shakkhar]

If you try to decode something that's really utf-8-sig (i.e., starts with the BOM) as utf-8, you'll end up with junk at the beginning of the resulting string.

I know. I have a special case in my code to handle that.

As for your more general comment about major version changes, maybe @sigmavirus24 will disagree with me here, but I don't see this as an API change.

My test is simple - if your change breaks downstream code then it is API breaking. The assumption is that downstream is using your API correctly. Now I couldn't find any API documentation for chardet. So it boils down to what you consider to be part of the public API.

[sigmavirus24]

@Shahriman sorry to tell you this but your test for breaking changes is completely incorrect. The API here is not the text in the response, it is the fact that you call chardet.detect and expect a string returned which is a valid codec value. The text in the response can change at any time. We could, for example, call .upper on every string we return and that would not be a backwards incompatible change for the simple fact that the primary usage of chardet is with the codecs module in Python and that will accept both without complaining.

We're correcting the value we use here because it was formerly incorrect in several ways. By your logic, the fact that we fixed the character encoding we return is a backwards incompatible change because some people may have been relying on the fact that strings that were in fact a variant of utf-8 were returning iso-8859-2, in which case any fix we make is a backwards incompatible change which is nonsense.

[shakkhar]

The API here is not the text in the response, it is the fact that you call chardet.detect and expect a string returned which is a valid codec value. The text in the response can change at any time. We could, for example, call .upper on every string we return and that would not be a backwards incompatible change for the simple fact that the primary usage of chardet is with the codecs module in Python and that will accept both without complaining.

So that's your API documentation right there :)

[shakkhar]

Could you try the same thing with the develop branch?

Tested and works.