PyCharm README.md 不使用 \ 轉義 *

Question

賞金將在 2 天后到期。 此問題的答案有資格獲得+50聲望賞金。 FluidMechanics Potential Flows希望引起更多人對這個問題的關注。

在README.md文件中執行此操作

In A\*68sff

預覽是（證明）：

In A\*68sff

它應該是：

In A*68sff

GitHub上，預覽無誤，預覽為（校對）：

In A*68sff

我在用着：

PyCharm 2022.3.1 (Professional Edition)
Build #PY-223.8214.51, built on December 20, 2022
Licensed to **********************
Subscription is active until May 13, 2023.
For educational use only.
Runtime version: 17.0.5+1-b653.23 amd64
VM: OpenJDK 64-Bit Server VM by JetBrains s.r.o.
Windows 11 10.0
GC: G1 Young Generation, G1 Old Generation
Memory: 2030M
Cores: 16
Non-Bundled Plugins:
    com.chesterccw.excelreader (2022.12.1-203.223)
    com.github.copilot (1.1.38.2229)
    me.lensvol.blackconnect (0.5.0)

Answer 1

當你說：

它應該是：

 In A*68sff

事實上它不應該，或者至少不一定。 這就是 Markdown 規范中所謂的“歧義” 。 讓我們仔細看看原始的 Markdown 規范：

強調

Markdown 將星號 ( * ) 和下划線 ( _ ) 視為強調的指示符。 用一個*或_包裹的文本將用 (...)

這就是您的示例中的“歧義” ，因為A*68sff沒有用星號包裹，它只包含一個星號，而原始的 Markdown 規范遺漏了在這種情況下如果轉義應該如何處理未包裹的星號。

發生的事情是 GitHub 和 PyCharm 使用 Markdown 規范的不同實現（解析器）以不同方式解決歧義，隨后的 CommonMark 規范首先對此進行總結：

為什么需要 CommonMark？

John Gruber 對 Markdown 語法的規范描述並未明確指定語法。

(...)

由於沒有明確的規范，在過去 10 年中，實現方式存在很大差異。 結果，用戶經常驚訝地發現在一個系統上以一種方式呈現的文檔（例如，GitHub wiki）在另一個系統上以不同方式呈現（例如，使用 Pandoc 轉換為 docbook） 。 更糟糕的是，由於 Markdown 中沒有任何內容被視為“語法錯誤”，因此通常不會立即發現分歧。