腾讯云

开发者社区

文档建议反馈控制台

首页

文章/答案/技术大牛

发布

社区首页 >问答首页 >如何让getLine接受unicode字符？

问如何让getLine接受unicode字符？
EN

Stack Overflow用户

提问于 2018-08-02 11:52:16

回答 1查看 341关注 0票数 4

运行以下代码时

do line <- getLine
   putStrLn line

或,

getLine >>= putStrLn

然后，之后

 getLine >>= putStrLn

入场

µ

我们会遇到这样的输出：

⠀

现在，我已经预先尝试过chcp 65001了，它不起作用，而stdin的编码是utf8。

没有putStrLn的考试显示：

 getLine
µ
'\NIL'

我的环境：

Windows 10版本10.0.17134构建17134

联想ideapad 510-15 510

BIOS版联想3JCN30WW

GHCi诉8.2.2

如何解决这一问题？

编辑:具体来说，以下操作顺序导致了这种情况：

开放cmd
chcp 65001型
ghci型
getLine >>= putStrLn型
µ型

然而，以下并不是：

搜索ghci
开放ghci.exe at %PROGRAMS%\Haskell Platform\8.2.2\bin
重复4-5次。

注意：%PROGRAMS%不是真实的环境变量。

编辑:根据请求，GHC.IO.Encoding.getLocaleEncoding的输出

UTF-8

此外，System.IO.hGetEncoding stdin的输出

Just UTF-8

(使用chcp 65001时)

编辑:字符是U+00B5。我使用德国键盘，系统本地化德国，语言设置英语，键盘语言ENG与德语布局。

encoding

console

windows

haskell

unicode

云点播特惠1元起

提供制作上传、存储、转码、媒体处理、媒体 AI、加速分发播放、版权保护等一体化的高品质媒体服务

回答 1

Stack Overflow用户

回答已采纳

发布于 2018-08-05 02:14:10

控制台输入/输出在Windows上完全崩溃，而且已经有一段时间了。下面是跟踪Windows上与IO相关的所有问题的顶级票证：https://ghc.haskell.org/trac/ghc/ticket/11394

我相信，这两张票最能描述你正在经历的行为：

现在唯一的工作就是手动使用Windows来处理控制台输出/输入，这本身就是一个痛苦。

编辑

所以，我决定忍受一些痛苦。:)

下面是代码的输出：

====
Input: µ
Output: µ
====

这绝不是一个完全正确或安全的解决方案，但它确实有效：

module Main where

import Control.Monad
import System.IO
import Foreign.Ptr
import Foreign.ForeignPtr
import Foreign.C.String
import Foreign.C.Types
import Foreign.Storable

import System.Win32
import System.Win32.Types
import Graphics.Win32.Misc

foreign import ccall unsafe "windows.h WriteConsoleW"
  c_WriteConsoleW :: HANDLE -> LPWSTR -> DWORD -> LPDWORD -> LPVOID -> IO BOOL

foreign import ccall unsafe "windows.h ReadConsoleW"
  c_ReadConsoleW :: HANDLE -> LPWSTR -> DWORD -> LPDWORD -> LPVOID -> IO BOOL

-- | Read n characters from a handle, which should be a console stdin
hwGetStrN :: Int -> Handle -> IO String
hwGetStrN maxLen hdl = do
  withCWStringLen (Prelude.replicate maxLen '\NUL') $ \(cstr, len) -> do
    lpNumberOfCharsWrittenForeignPtr <- mallocForeignPtr
    withHandleToHANDLE hdl $ \winHANDLE ->
      withForeignPtr lpNumberOfCharsWrittenForeignPtr $ \lpNumberOfCharsRead -> do
        c_ReadConsoleW winHANDLE cstr (fromIntegral len) lpNumberOfCharsRead nullPtr
        numWritten <- peek lpNumberOfCharsRead
        peekCWStringLen (cstr, fromIntegral numWritten)

-- | Write a string to a handle, which should be a console stdout or stderr.
hwPutStr :: Handle -> String -> IO ()
hwPutStr hdl str = do
  void $ withCWStringLen str $ \(cstr, len) -> do
    lpNumberOfCharsWrittenForeignPtr <- mallocForeignPtr
    withHandleToHANDLE hdl $ \winHANDLE ->
      withForeignPtr lpNumberOfCharsWrittenForeignPtr $ \ lpNumberOfCharsWritten ->
      c_WriteConsoleW winHANDLE cstr (fromIntegral len) lpNumberOfCharsWritten nullPtr

main :: IO ()
main = do
  hwPutStr stdout "====\nInput: "
  str <- hwGetStrN 10 stdin
  hwPutStr stdout "Output: "
  hwPutStr stdout str
  hwPutStr stdout "====\n"

编辑2

@dfeuer要求我列出不安全、不正确或不完整的问题，并给出答案。我只在Linux上编写代码，所以我不是Windows程序员，但在真正的程序中使用这些代码之前，我会突然想到一些需要改变的东西：

最重要的部分是代码只能与控制台句柄一起工作，控制台句柄可以通过GetConsoleMode API调用来确定。
对于其他类型的句柄，上面的代码将什么也不做，例如。如果与管道或文件句柄一起使用，则在编码方面有自己的问题，但这是一个完全不同的问题。
未考虑API调用失败的原因。因此，我们必须通过查看返回的BOOL来检查调用是否成功，并在不使用GetLastError向用户报告错误时进行检查。
上面实现的函数是非常有限的，没有检查它们实际读/写了多少缓冲区。因此，hwGetStrN只能处理n字符，因此需要递归调用才能获得类似于hGetLine的行为。
做所有的健全检查(如)。DWORD是Word32，因此fromIntegral len调用容易受到整数溢出的影响，这既不正确又不安全。
在32位操作系统上，FFI调用必须是stdcall，而ccall则是x86_64，所以有些CPP是必需的。