UTF-8 encoding woes about singer-python

[KAllan357]

Hi @martint17r - thanks for the issue.

I'm curious why this hasn't been a problem for any other consumers of this library. I am a little concerned about the downstream effects of such a change. I suspect there is no greater issue because our target-stitch library uses the corresponding parse_message function which is able to consume the ASCII output using json's loads.

I'm not sure if its relevant in this case, but in the past - when PYTHONIOENCODING was not enough - I've had to set the LANG environment variable described in this issue docker-library/python#13.

In any case, I'd be happy to merge a PR for this change if you make the default function work as it has worked but provide a flag to use your described behavior.

[martint17r]

I believe the reason why this has not popped up anywhere else is that this is not a problem within python, i.e. the escaped unicode notation is a Python specific encoding, see 7.2 Python specific encodings, which it tolerates.

I ran into that problem, because I am trying to implement a target in Go.

According to RFC 8259 Ch. 8.1 JSON must be encoded in UTF-8, even RFC 7493 Ch. 2.1 agrees on that.

Would you accept a second pull request to PROPOSALS.md to enhance the SPEC accordingly, i.e. define a MUST-HAVE UTF-8 encoding for all data? Something along the lines of:
"A Tap outputs structured messages to stdout in JSON format, one message per line, UTF-8 encoded".

I agree that this mandates a major version change in semver notation.

[KAllan357]

This makes sense and both parts sound like a good change. I've done some preliminary testing and Python seems happy to decode both the escaped and not-escaped versions of the string.

Making it an option seems unnecessary - if you could make a PR to add the flag and we can do a major bump to 6.0.0. Adding to the Singer Spec sounds good too. Thanks for this!

(note: this SO question helped me understand the issue and there seems to be less confusion in Python 3 than 2 - the dumps function no longer returns a string OR unicode object when this flag is present)

[ashutoshvarma]

Any update on this? For now I am using ensure_ascii=False locally.