Officedown: Bookmark \@ref ne fonctionne pas pour les chaînes multioctets

Créé le 27 août 2020 · 7Commentaires · Source: davidgohel/officedown

Supposons que j'ai un fichier .Rmd comme ci-dessous :

---
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).

Lorsque \@ref (ch1) est entouré de chaînes multi-octets (par exemple, des caractères chinois), il risque de rencontrer des erreurs.

Multioctet pur + réf
- Exemple : 上下\@ref(ch1)
- Résultat : correct
Mixte multioctet/singlebyte + ref
- Exemple : 上a下\@ref(ch1)
- Résultat : incorrect (上a下@ref (ch1))
réf + multioctet
- Exemple : \@ref(ch1)。
- Résultat : échec de la compilation
Erreur dans nchar(u, itype) : chaîne multioctet invalide, élément 1

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

Pouvez-vous s'il vous plaît examiner ce problème? Merci.

sessionInfo()

R version 4.0.2 (2020-06-22)
Plate-forme : x86_64-w64-mingw32/x64 (64 bits)
Fonctionnant sous : Windows 10 x64 (build 20180)

Produits matriciels : par défaut

lieu:
[1] LC_COLLATE=Chinois (simplifié)_Chine.936
[2] LC_CTYPE=Chinois (simplifié)_Chine.936
[3] LC_MONETARY=Chinois (simplifié)_Chine.936
[4] LC_NUMERIC=C
[5] LC_TIME=Chinois (simplifié)_Chine.936

forfaits de base attachés :
[1] stats graphiques grDevices utils datasets méthodes
[7] base

autres packages joints :
[1] agent_0.3.12 officedown_0.2.0 flextable_0.5.10
[4] ggplot2_3.3.2 tidyr_1.1.1 knitr_1.29
[7] dplyr_1.0.2 réticulé_1.16

chargé via un espace de noms (et non attaché) :
[1] Rcpp_1.0.5 lattice_0.20-41 jolies unités_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 rétroportages_1.1.9 évaluer_0.14
[13] pilier_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 étiquetage_0.3 devtools_2.3.1
[25] stringr_1.4.0 munsell_0.5.0 tinytex_0.25
[28] compilateur_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 tidyselect_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] grille_4.0.2 jsonlite_1.7.0 gtable_0.3.0
[46] cycle de vie_0.2.0 magritr_1.5 échelles_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 points de suspension_0.3.1
[58] génériques_0.0.2 vctrs_0.3.2 outils_4.0.2
[61] showtext_0.9 glue_1.4.1 ronronnement_0.3.4
[64] processx_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] usethis_1.6.1

bug

Source

madlogos

Tous les 7 commentaires

```````

titre : "Sans titre"
sortir:
officedown :: rdocx_document :

défaut

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

Chapitre1 {#ch1}

Chapitre2 {#ch2}

Reportez-vous à @ref (ch1).

Lorsque @ref (ch1) est entouré de chaînes multioctets (par exemple, des caractères chinois), il risque de rencontrer des erreurs.

Multioctet pur + ref:上下@ref (ch1)
Exemple :上a下@ref (ch1)
ref + multibyte : @ref (ch1)。
```````

Votre problème est lié au fait que vous ne travaillez pas avec un fichier encodé en UTF-8.

R, R Markdown et Windows ne fonctionnent pas bien lorsque l'encodage n'est pas UTF-8.

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

Sans titre.docx

davidgohel le 27 août 2020

👍1

Oui, @davidgohel , vous avez raison. Bien que le fichier .Rmd soit en UTF-8, le système d'exploitation fonctionne sur l'encodage GBK. Lorsque je passe à bookdown::word_document2 , le moteur knitr parvient à compiler le fichier. Mais je reçois toujours ?? où le signet est censé apparaître.

madlogos le 28 août 2020

Vous n'avez pas besoin d'essayer de nouvelles fonctions de format de sortie.

Le résultat présenté ci-dessous est réalisé avec un Windows avec les paramètres régionaux français. Mais je me suis assuré que le fichier était encodé en UTF-8 (j'utilise readr::guess_encoding() , s'il n'est pas encodé en UTF-8, je peux le changer en UTF8 avec fpeek::peek_iconv() ).

Pourriez-vous montrer le résultat de

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

davidgohel le 28 août 2020

Les résultats sont

non | encodage | confiance
---|-------------|----------- :
1 | UTF-8 | 1
2 | fenêtres-1252 | 0,28

madlogos le 29 août 2020

Salut @madlogos ,

Je suis également un utilisateur chinois. Le problème multi-octets m'a également dérangé pendant longtemps. Voici mon astuce pour cela :

Écrivez @ref comme d'habitude ;
Enregistrez le fichier Rmd et readr::read_lines ;
Faites correspondre les chaînes contenant le motif "\\\\@ref\$[^\$]+\\)" ;
Divisez-le et assurez-vous que le "\\\\@ref\$[^\$]+\\)" sur une seule ligne ;
Enregistrez le vecteur de caractères dans un nouveau fichier Rmd et affichez-le au format de votre choix. Fait!

Par exemple, 请参考表\@ref(tab: coco)中的数据 doit être divisé en
[ligne 1] 请参考表
[ligne 2] \@ref(tab: coco)
[ligne 3] 中的数据

Eh bien, je ne sais pas si c'est une solution efficace, mais cela fonctionne pour moi. 😄