Я чувствую, что в сообществе Haskell идет спор о String против Data.Text, но, на мой взгляд, они оба страдают от одного и того же недостатка, а именно: они не представляют все текстовые данные, просто Текст в Юникоде.
Единственный найденный мной проект, касающийся кодировки символов, - это пакет с точно названным encoding , но, похоже, он поддерживает только преобразование в / из Unicode, не предоставляя никаких механизмов для обработки текста в этих кодировках. ,
Есть ли проект, который пытается получить новый класс типов (Textual?), Экземплярами которого могут быть разные кодировки символов, чтобы я мог выполнять обработку текста непосредственно с UTF-8 так же легко, как и с, скажем GB-2312?
Что касается комментария @ bergey, я не пытаюсь работать с персонажами, которые не являются частью Unicode. Все файлы не в Юникоде, с которыми я сталкиваюсь, обычно используют установленные устаревшие наборы символов, которые были включены в Юникод.
Моя проблема больше связана с текстовыми функциями, которые были разработаны для работы с не-Unicode текстом. Например:
RFC 3986 разрешает процентное кодирование и передачу не-юникодовых кодировок символов, и в реальном мире все еще есть люди, использующие GB2312 / EUC-CN. Когда библиотека Haskell предлагает только кодировку Unicode в процентах (например, Network.HTTP.urlEncode :: String -> String), она не будет работать для этих API.
Точно так же цитируемый-печатаемый текст должен иметь возможность представлять кодировки не-Unicode, и я все еще сталкиваюсь с этими типами электронных писем. Единственная библиотека, с которой я столкнулся для печати в кавычках, Codec.MIME.Decode, также работает со строками, что означает, что она не может работать с этими не-Unicode-кодировками.
Я, конечно, не пытаюсь быть критическим здесь; В основном меня интересует, как лучше всего добавить поддержку для других типов текстовых данных (и узнать, работают ли над этим люди или нет). На мой взгляд, было бы здорово, если бы такие функции, как urlEncode, можно было написать один раз и сохранить тип String -> String, а также иметь возможность обрабатывать текстовые строки любого типа, а не только Unicode, без необходимости отдельных реализаций для каждого возможного типа. текста.
Что касается комментария @ DanielWagner:
String абсолютно специфично для определенных кодировок.
[martin@localhost ~]$ echo -n '中文' > utf8text
[martin@localhost ~]$ iconv -f utf8 -t gb2312 utf8text > gb2312text
[martin@localhost ~]$ xxd gb2312text
00000000: d6d0 cec4 ....
[martin@localhost ~]$ ghc -e 'readFile "gb2312text"'
<interactive>: gb2312text: hGetContents: invalid argument (invalid byte sequence)
Выдается исключение invalid byte sequence, поскольку функция String не может преобразовать эти байты в кодовые точки.