Closed lrasmus closed 2 years ago
@lrasmus, thanks for digging into the problem.
redcap_read_oneshot()
(and redcap_read()
, which calls redcap_read_oneshot()
) could accept an encoding
argument and pass it to the part of kernel_api()
that you highlighted. If this enhancement would help you, then I'd love to accept a PR.redcap_read_oneshot()
to pass through an encoding value (i.e., the PR you described above)encoding
argument is explicitly set to NULL
, then uchardet decides. Where does this happen --inside the kernel_api()
function?redcap_read_oneshot()
)? It should be the encoding of the column redcap_data.value
. I saw some chatter on the forums about recent changes to MySQL & Maria & REDCap.@lrasmus, I implemented your idea and added the http_response_encoding
parameter to redcap_read()
and redcap_read_oneshot()
.
Judging from the lack of responses, I'm guessing you and others don't feel too strongly for the need to add an automatic detection mechanism for encoding, so I went with the simpler route that doesn't require another package dependency.
If you or anyone else would like to open a new issue (and reference this one), I'm happy to revisit the issue. If you do, please send me a few simple-ish dictionaries & PHI-free datasets that can be included in the test suite.
We have loaded data that contains non-ASCII characters. When calling
read
, the data frame is coming back empty:I have traced this back that the
httr::POST
is correctly returning data from the API, but the call tohttr::content
is using the default UTF-8 encoding. The conversion fails, and the data is then returned as empty.In the current
read
calls, it doesn't appear to allow overriding the encoding. I am happy to propose a fix and submit a PR, but was wondering if we want the user to always explicitly set the encoding, or if the package should try to detect the encoding using something like theuchardet
package: