Officedown: O marcador \@ref não funciona para strings multibyte

Criado em 27 ago. 2020 · 7Comentários · Fonte: davidgohel/officedown

Suponha que eu tenha um arquivo .Rmd como abaixo:

---
title: "Untitled"
output:
  officedown::rdocx_document:
    default
---

```{r setup, include=FALSE}
knitr::opts_chunk$set(echo = TRUE)



md5-4caffc4710057148fdad652000287a10



# Chapter1 {#ch1}

# Chapter2 {#ch2}

Refer to \@ref(ch1).

Quando \@ref (ch1) é cercado por strings multibyte (por exemplo, caracteres chineses), possivelmente encontraria erros.

Multibyte puro + ref
- Exemplo: 上下\@ref(ch1)
- Resultado: correto
Misto multibyte/singlebyte + ref
- Exemplo: 上a下\@ref(ch1)
- Resultado: incorreto (上a下@ref (ch1))
ref + multibyte
- Exemplo: \@ref(ch1)。
- Resultado: compilação falhou
Erro em nchar(u, tipo): string multibyte inválida, elemento 1

Chamadas:... regmatches<- -> regmatches -> Map -> mapply ->

Você pode, por favor, olhar para esta questão? Obrigado.

SessãoInfo()

R versão 4.0.2 (22/06/2020)
Plataforma: x86_64-w64-mingw32/x64 (64 bits)
Executando em: Windows 10 x64 (compilação 20180)

Produtos da matriz: padrão

localidade:
[1] LC_COLLATE=Chinês (simplificado)_China.936
[2] LC_CTYPE=Chinês (simplificado)_China.936
[3] LC_MONETARY=Chinês (simplificado)_China.936
[4] LC_NUMERIC=C
[5] LC_TIME=Chinês (simplificado)_China.936

pacotes de base anexados:
[1] gráficos de estatísticas grDevices utils métodos de conjuntos de dados
[7] base

outros pacotes anexados:
[1] oficial_0.3.12 officedown_0.2.0 flextable_0.5.10
[4] ggplot2_3.3.2 arrumador_1.1.1 tricô_1.29
[7] dplyr_1.0.2 reticulate_1.16

carregado por meio de um namespace (e não anexado):
[1] Rcpp_1.0.5 lattice_0.20-41 unidades bonitas_1.1.1
[4] sysfonts_0.8.1 ps_1.3.4 utf8_1.1.4
[7] rprojroot_1.3-2 assertthat_0.2.1 digest_0.6.25
[10] R6_2.4.1 backports_1.1.9 avaliar_0.14
[13] pilar_1.4.6 gdtools_0.2.2 rlang_0.4.7
[16] curl_4.3 uuid_0.1-4 data.table_1.13.0
[19] callr_3.4.3 Matrix_1.2-18 rmarkdown_2.3
[22] desc_1.2.0 labeling_0.3 devtools_2.3.1
[25] stringr_1.4.0 munsell_0.5.0 tinytex_0.25
[28] compilador_4.0.2 xfun_0.16 pkgconfig_2.0.3
[31] systemfonts_0.2.3 base64enc_0.1-3 pkgbuild_1.1.0
[34] rvg_0.2.5 htmltools_0.5.0 arrumadoselect_1.1.0
[37] tibble_3.0.3 bookdown_0.20 fansi_0.4.1
[40] crayon_1.3.4 showtextdb_3.0 withr_2.2.0
[43] grid_4.0.2 jsonlite_1.7.0 gtable_0.3.0
[46] ciclo de vida_0.2.0 magrittr_1.5 escalas_1.1.1
[49] zip_2.1.0 cli_2.0.2 stringi_1.4.6
[52] farver_2.0.3 fs_1.5.0 remotes_2.2.0
[55] testthat_2.3.2 xml2_1.3.2 reticências_0.3.1
[58] generics_0.0.2 vctrs_0.3.2 tools_4.0.2
[61] showtext_0.9 cola_1.4.1 purrr_0.3.4
[64] processox_3.4.3 pkgload_1.1.0 yaml_2.2.1
[67] colorspace_1.4-1 sessioninfo_1.1.1 memoise_1.1.0
[70] use this_1.6.1

bug

Fonte

madlogos

Todos 7 comentários

```````

título: "Sem título"
saída:
officedown::rdocx_document:

padrão

{r setup, include=FALSE} knitr::opts_chunk$set(echo = TRUE)

Capítulo1 {#ch1}

Capítulo2 {#ch2}

Consulte @ref (ch1).

Quando @ref (ch1) é cercado por strings multibyte (por exemplo, caracteres chineses), possivelmente encontraria erros.

Multibyte puro + ref:上下@ref (ch1)
Exemplo:上a下@ref (ch1)
ref + multibyte: @ref (ch1)。
```````

Seu problema está relacionado ao fato de você não estar trabalhando com um arquivo codificado em UTF-8.

R, R Markdown e Windows não funcionam bem quando a codificação não é UTF-8.

Capture d’écran 2020-08-27 à 10 53 27

Sem título.docx

davidgohel em 27 ago. 2020

👍1

Sim, @davidgohel , você está certo. Embora o arquivo .Rmd esteja em UTF-8, o SO está sendo executado na codificação GBK. Quando mudo para bookdown::word_document2 , o mecanismo knitr consegue compilar o arquivo. Mas ainda consigo?? onde o marcador deve aparecer.

madlogos em 28 ago. 2020

Você não precisa experimentar novas funções de formato de saída.

O resultado mostrado abaixo é feito com um Windows com localidade francesa. Mas me certifiquei de que o arquivo fosse codificado como UTF-8 (estou usando readr::guess_encoding() , se não for codificado em UTF-8, posso alterá-lo para UTF8 com fpeek::peek_iconv() ).

Você poderia mostrar o resultado de

readr::guess_encoding("your/rmd/file")

davidgohel em 28 ago. 2020

Os resultados são

não | codificação | confiança
---|-------------|-----------:
1 | UTF-8 | 1
2 | windows-1252 | 0,28

madlogos em 29 ago. 2020

Olá @madlogos ,

Eu também sou um usuário chinês. O problema multibyte também me incomodou por um longo tempo. Aqui está o meu truque para isso:

Escreva @ref como de costume;
Salve o arquivo Rmd e readr::read_lines ;
Combine as strings contendo o padrão "\\\\@ref\$[^\$]+\\)" ;
Divida-o e certifique-se de que o "\\\\@ref\$[^\$]+\\)" esteja em uma única linha;
Salve o vetor de caractere em um novo arquivo Rmd e renderize-o com o formato que desejar. Feito!

Por exemplo, 请参考表\@ref(tab: coco)中的数据 deve ser dividido como
[linha 1] 请参考表
[linha 2] \@ref(tab: coco)
[linha 3] 中的数据

Bem, não tenho certeza se esta é uma solução eficaz, mas funciona para mim. 😄