Opened 13 months ago
Closed 13 months ago
#68356 closed defect (fixed)
libiconv @1.17_0: conversion to UTF8 unsupported
Reported by: | eric-j-ason | Owned by: | ryandesign (Ryan Carsten Schmidt) |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | 2.8.1 |
Keywords: | Cc: | ||
Port: | libiconv |
Description
Converting to or from "UTF8" yields an error, but "UTF-8" works. This is in contrast to other versions of iconv.
iconv from MacPorts gives an error:
$ echo hello | /opt/local/bin/iconv --to-code UTF8 iconv: conversion to UTF8 unsupported iconv: try '/opt/local/bin/iconv -l' to get the list of supported encodings
$ /opt/local/bin/iconv --list | grep --extended-regexp --ignore-case 'UTF-?8' UTF-8 UTF-8-MAC UTF8-MAC
$ /opt/local/bin/iconv --version iconv (GNU libiconv 1.17) Copyright (C) 2000-2022 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Written by Bruno Haible.
iconv from MacOS gives no error:
$ echo hello | /usr/bin/iconv --to-code UTF8 hello
$ /usr/bin/iconv --list | grep --extended-regexp --ignore-case 'UTF-?8' UTF-8 UTF8 UTF-8-MAC UTF8-MAC
$ /usr/bin/iconv --version iconv (GNU libiconv 1.11) Copyright (C) 2000-2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Written by Bruno Haible.
iconv on Debian gives no error:
$ echo hello | /usr/bin/iconv --to-code UTF8 hello
$ /usr/bin/iconv --list | grep --extended-regexp --ignore-case 'UTF-?8' ISO-10646/UTF-8/ ISO-10646/UTF8/ UTF-8// UTF8//
$ /usr/bin/iconv --version iconv (Debian GLIBC 2.31-13+deb11u7) 2.31 Copyright (C) 2020 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Written by Ulrich Drepper.
This bug was noticed because pdfjam uses iconv and stopped working:
https://github.com/rrthomas/pdfjam/blob/v3.08/bin/pdfjam#L954 https://github.com/rrthomas/pdfjam/blob/v3.08/bin/pdfjam#L975
Change History (5)
comment:1 Changed 13 months ago by ryandesign (Ryan Carsten Schmidt)
Cc: | ryandesign removed |
---|---|
Owner: | set to ryandesign |
Status: | new → assigned |
comment:2 follow-up: 3 Changed 13 months ago by eric-j-ason
That was an interesting e-mail conversation. Very well researched by the submitter, with links to specific source code lines in many implementations and a survey of standards. It's amazing that there are so many different implementations of the thing!
Anyway, should pdfjam (which uses "utf8") then be considered to be where the bug resides?
Also, do you have any idea of how this problem has arisen now? The bug report #57886 is five years old, yet for me it must have stopped working only in the last few months or so.
comment:3 follow-up: 4 Changed 13 months ago by ryandesign (Ryan Carsten Schmidt)
Replying to eric-j-ason:
Anyway, should pdfjam (which uses "utf8") then be considered to be where the bug resides?
I see you already submitted a fix to the developer and they accepted it and released a new version and you filed #68365 to update MacPorts pdfjam to this version.
Also, do you have any idea of how this problem has arisen now? The bug report #57886 is five years old, yet for me it must have stopped working only in the last few months or so.
Looks like the code that started using iconv
(with utf8
) was added to pdfjam in November 2021 but it was not included in a release until version 3.0.4 in May 2023. MacPorts updated to this version in August 2023 so you would not have seen the problem with pdfjam before then.
comment:4 Changed 13 months ago by eric-j-ason
Replying to ryandesign:
I see you already submitted a fix to the developer and they accepted it and released a new version and you filed #68365 to update MacPorts pdfjam to this version.
Yes, that seemed to be where to fix it. Counting on that the port for pdfjam will be updated, I'm thinking that this issue for libiconv can be closed. (I don't think I can do that myself, though, right?)
Looks like the code that started using
iconv
(withutf8
) was added to pdfjam in November 2021 but it was not included in a release until version 3.0.4 in May 2023. MacPorts updated to this version in August 2023 so you would not have seen the problem with pdfjam before then.
That explains it. Thank you!
comment:5 Changed 13 months ago by breun (Nils Breunese)
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
This has come up before, and it was decided not to support this. See #57886 and the linked mailing list thread for more info.