pandoc continua reclamar sobre o caractere não-utf8, embora pareça que não há nenhum caractere não-utf8

Question

Estou tentando converter um arquivo de marcação em pdf usando pandoc . Como meu markdown contém caracteres chineses, uso o seguinte comando para produzir o pdf:

pandoc --pdf-engine=xelatex -V CJKmainfont=KaiTi test.md -o test.pdf

Mas pandoc reclama que o arquivo contém caracteres não-utf8 que ele não pode manipular, a mensagem de erro exata é:

Error producing PDF.
! Undefined control sequence.
pandoc.exe: Cannot decode byte '\xbd': >Data.Text.Internal.Encoding.streamDecodeUtf8With: Invalid UTF-8 stream

De acordo com o que eu encontrei na internet. Isso se deve em grande parte à codificação do arquivo de remarcação e pode não ter nada a ver com o pandoc. Meu arquivo contém muitos caracteres chineses e caracteres ingleses. Eu o converti para a codificação utf-8.

Coisas que tentei mas sem sucesso

Eu tentei transferir meu arquivo para o meu servidor CentOS e descobrir onde estão os caracteres inválidos ou apenas remover os caracteres inválidos. Mas sem sucesso.

Grep para o caractere não utf8

Seguindo as instruções aqui e aqui (Na verdade, tentei várias respostas principais nas duas postagens, mas elas não funciona). Verifiquei que a localidade do sistema está configurada como UTF-8, saída de localectl status is:

   System Locale: LANG=en_US.UTF-8
       VC Keymap: us
      X11 Layout: us

Eu tentei grep para caracteres não-utf8. O comando usado é grep -axv '.*' test.md . Mas o comando não produz nada. (Eu pensei que isso significa que não há caracteres inválidos que não podem ser decodificados pelo utf-8.)

Tente descartar caracteres inválidos

Eu segui as instruções aqui tentando remover caracteres não-utf8 do meu arquivo. O comando que eu uso é:

iconv -f utf-8 -t utf-8 -c test.md > output.md

Depois disso, quando tentei converter output.md em pdf usando pandoc . Eu ainda encontrei a mesma mensagem de erro, o que sugere que o arquivo ainda contém caracteres não-utf8.

Minha pergunta

Surpreende-me que os métodos acima não funcionem. Como posso identificar qual parte do arquivo está causando o problema ou como realmente remover o caractere não-utf8 do arquivo para que eu possa compilá-lo sem erro?

Outras informações

• Você pode encontrar o arquivo de remarcação aqui .

• Se você estiver usando o sistema Linux, talvez seja necessário definir CJKmainfont como outro nome de fonte chinês válido em seu sistema.

• no sistema Linux, parece que o comando para produzir pdf a partir do markdown com texto em chinês deve ser (mudar a fonte para a fonte válida):

  pandoc --latex-engine = xelatex -V CJKmainfont = teste de KaiTi.md -o teste.pdf

Answer 1

Ok, depois de longas horas de luta com os problemas e cavando. Eu finalmente encontrei a causa raiz do problema.

A causa

O problema é que no test.md , os textos que começam com barra invertida existem em vários lugares e devem ser considerados literais. Por exemplo,

* 一般现在时\过去时\将来时，simple present\past\future
* 现在(过去\将来)进行时，present(past\ future) continuous
* 现在（过去\将来）完成时，present(past\future) perfect
* 现在（过去\将来）完成进行时，present(past\future) perfect continuous

As barras invertidas no parágrafo acima servem apenas como separador para diferentes situações. É markdown válido. Mas infelizmente eles são processados como comandos por pandoc.

Solução

Use o seguinte comando:

pandoc -f markdown-raw_tex --pdf-engine=xelatex -V CJKmainfont=KaiTi test.md -o test.pdf

Ou distorça o texto começando com barra invertida usando backticks (mas isso nem sempre é desejado) ou apenas use duas barras invertidas.

Alguns pensaram

A mensagem de erro da Pandoc é enganosa, pois o problema não está relacionado à decodificação UTF-8. Eu não tenho idéia porque a mensagem de erro é assim.

Além disso, parece que as mensagens de erro para esse problema não são consistentes. Por exemplo, para o texto acima contendo barras invertidas. Se você compilar usando

pandoc -f markdown --pdf-engine=xelatex -V CJKmainfont=KaiTi test.md -o test.pdf

A mensagem de erro será algo como:

Error producing PDF.
! Undefined control sequence.
l.75 一般现在时\过去时

Em seguida, será muito mais fácil descobrir onde está o problema em vez de desenterrar problemas relacionados ao utf-8.

Follow-ups

Este é realmente um bug no xelatex. Pode produzir bytes utf-8 inválidos quando encontrar seqüências de controle inválidas. Mas pandoc apenas assume que o que recebe é uma sequência utf-8 válida. Daí o erro. Para explicações mais detalhadas, consulte este post .

update 2017.12.29
 Com o lançamento do Pandoc 2.0.6 , esse comportamento é tratado de maneira mais adequada:

Allow lenient decoding of latex error logs, which are not always properly UTF8-encoded

Agora, é mais fácil depurar esse tipo de problema.

    

Answer 2

pandoc está respondendo sobre byte \xbd (hexadecimal "bd"), então grep para isso. por exemplo,

grep -n $'\xbd' file 

por exemplo. se eu criar um arquivo pequeno com 4 linhas, uma delas contendo o caractere \xbd :

a
b
c½
d

então grep -n me dirá que está na linha 3:

$ grep -n $'\xbd' file 
3:c½

NOTA: o $'\xbd' requer um shell unix como o bash. Veja man bash e procure por " QUOTING " para detalhes.

BTW, o caractere \xbd é um caractere ascii estendido. Pode ser uma sequência de unicode quebrada (muitos caracteres unicode têm 0xbd como um dos seus valores de byte). Na minha tela, ele é exibido como uma fração de '1/2'. Veja o que o ascii tem a dizer sobre isso:

$ ascii bd
ASCII 11/13 is decimal 189, hex bd, octal 275, bits 10111101: meta-=