# Génération incorrecte du balisage des pièces jointes avec des underscores dans le nom du fichier
**URL:** https://meta.discourse.org/t/incorrect-attachment-markup-generation-with-underscores-in-the-file-name/400079
**Category:** Bug
**Created:** [Avril 7, 2026, 4:26 UTC](https://meta.discourse.org/t/incorrect-attachment-markup-generation-with-underscores-in-the-file-name/400079 "2026-04-07T04:26:19Z")
**Posts on this page:** 2
**Page:** 1
### Author:  [@ValdikSS](https://meta.discourse.org/u/ValdikSS)
#### Post date: [Avril 7, 2026, 4:26 UTC](https://meta.discourse.org/t/incorrect-attachment-markup-generation-with-underscores-in-the-file-name/400079/1 "2026-04-07T04:26:19Z")
J’ai trouvé un petit bug lors du téléchargement d’un fichier :
Si le fichier commence et se termine par un tiret bas (`_test_file_.txt` dans ce cas), le code de génération du balisage n’échappe pas le tiret bas, ce qui donne le « nom de fichier » suivant :
[_test\_file_.txt|attachment](https://meta.discourse.org/uploads/short-url/eSJGButIpkpu4IEifmmispiFRJu.txt) (23 octets)
`[_test_file_.txt|attachment](upload://eSJGButIpkpu4IEifmmispiFRJu.txt) (23 octets)`
Si j’échappe le premier tiret bas avec une barre oblique inverse, il est correctement analysé :
[\_test\_file\_.txt](https://meta.discourse.org/uploads/short-url/eSJGButIpkpu4IEifmmispiFRJu.txt) (23 octets)
`[\_test_file_.txt|attachment](upload://eSJGButIpkpu4IEifmmispiFRJu.txt) (23 octets)`
---
### Author:  [@zogstrip](https://meta.discourse.org/u/zogstrip)
#### Post date: [Avril 7, 2026, 2:33 UTC](https://meta.discourse.org/t/incorrect-attachment-markup-generation-with-underscores-in-the-file-name/400079/3 "2026-04-07T14:33:35Z")
Merci pour le rapport @ValdikSS 👍 Voici une tentative pour régler ce problème une fois pour toutes
>
>
> Filenames containing markdown formatting characters (\`\_\`, \`\*\`, \`~\`, \`\` \` \`\`, \`\[\`…, \`\]\`, \`|\`) would break upload markup when cooked. For example, uploading \`\_test\_file\_.txt\` generated:
>
> \[\_test\_file\_.txt|attachment\](upload://...)
>
> The underscores triggered emphasis parsing inside the link text, which both rendered the filename incorrectly (with italics) and prevented the \`|attachment\` marker from being recognized — losing the \`class="attachment"\` on the resulting \`\\` tag.
>
> \*\*Markdown generation (defense in depth)\*\*
>
> Add \`escapeMarkdownCharacters\` (JS) and \`UploadMarkdown.escape\_markdown\` (Ruby) to backslash-escape all inline formatting characters in filenames before embedding them in markdown link text. Applied in:
>
> \- \`UploadMarkdown\` — image, attachment, and playable media methods
> \- \`uploads.js\` — \`attachmentMarkdown\` and \`markdownNameFromFileName\`
> \- \`inline\_uploads.rb\` — HTML anchor conversion and hotlinked image URLs
> \- \`to-markdown.js\` — HTML-to-markdown attachment link reconstruction
> \- \`sanitizeAlt\` in \`markdown-image-builder.js\` — image alt text
>
> \*\*Parser resilience (belt and suspenders)\*\*
>
> The markdown-it \`renderAttachment\` renderer and ProseMirror's link parser both assumed \`tokens\[idx+1\]\` was a single text token containing the full link text. When emphasis/bold/strikethrough/code was parsed inside the link text, the token sequence included formatting tokens and the \`|attachment\` marker was lost. Both now scan forward through all tokens between \`link\_open\` and \`link\_close\` to find the marker.
>
> The image renderer (\`renderImageOrPlayableMedia\`) split alt text on \`|\` assuming the first segment was always the alt and everything after was structured suffixes (dimensions, video/audio, data attributes). A pipe in the filename would produce extra segments that confused the dimension parser. It now scans from the right, consuming known suffixes, and treats everything remaining as alt text.
>
> https://meta.discourse.org/t/400079