如何转义 javadoc 内联标记中的大括号,例如 {@code} 标记
/**
* Gets the meatball icon for a nincompoop.
*
* <p>
* Example: {@code <custom:meatball color="<%= Meatball.RED %> nincompoop="${person}" />}
*
* @author King Cong
*
*/
“${person}”部分破坏了文档注释,因为它使用花括号。
/**
* Gets the meatball icon for a nincompoop.
*
* <p>
* Example: {@code <custom:meatball color="<%= Meatball.RED %> nincompoop="${person}" />}
*
* @author King Cong
*
*/
The "${person}" part breaks the doc comment because it uses curly braces.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(7)
使用
{@literal}
,所以这样做{@literal } }
。 在我的测试中有效。所以对于你的情况,它看起来像这样:
Use the
{@literal}
, so do this{@literal } }
. Works in my tests.So for your case, it would look like this:
与其说是答案,不如说是解决方法,但如果您将
{@code ...}
替换为旧版本
它会按照您的预期呈现大括号。...
不幸的是,这会破坏尖括号,因此对于最初的问题,您需要转义这些:
您甚至可以通过让 Notepad++ 为您执行此操作,使用方便的 TextFX -> 来作弊。 转换-> 编码 HTML (&<>")。
这至少有一个好处,即所有内容在生成的 Javadoc 和 Eclipse 的 Javadoc 视图中都可以很好地呈现,而 Javadoc 视图似乎无法理解
} ;
和朋友们。Not so much an answer as a workaround, but if you replace
{@code ...}
with the old version<code>...</code>
it will render curly braces how you expect.Unfortunately, this breaks angle brackets, so to the original question you need to escape these:
You can even cheat here by getting Notepad++ to do that for you, with the handy TextFX -> convert -> Encode HTML (&<>").
This does at least have the benefit that everything renders nicely both in the generated Javadoc and in Eclipse in the Javadoc view, which doesn't appear to understand
}
and friends.尝试使用 HTML 转义:
Try using HTML escapes:
bodunbodun 解决方案的工作方式通常是在 javadoc 中也有换行符。 不起作用
如果您想要同时使用 { 和换行符,HTML 转义将
bodunbodun solution works as it usually happens that you have newline as well in the javadocs. HTML escapes won't work if you want both { and newline
will give you
实际上我也遇到了同样的问题 - 没有一个建议对我有用(HTML 转义无论出于何种原因都不起作用)。
如果这有帮助 - 尝试在有问题的符号之前关闭 {@code} 并在之后重新打开它,如下所示:
{@code nincompoop="}${person}{@code" />
}似乎不是解决方案,但它有效,并且如果仔细使用也不会破坏格式:)
I had the same problem actually - none of propositions have worked for me (HTML escapes do not work for whatever reason).
If that helps - try closing the {@code} before problematic symbol and reopen it after, like this:
{@code nincompoop="}${person}{@code" />}
This doesn't seem the solution, but it works, and does not break formatting if used carefully :)
至少从 Java 1.8.0_31 开始,我无法再重现该问题。 您的输入按预期呈现:
我的测试表明
javadoc
考虑了@code
内的平衡大括号,并且仅在找到相应的大括号时结束它。因此,如果代码像您的示例一样具有平衡的大括号
{}
,那么它现在可以按预期工作。但我仍然不知道如何处理不平衡的大括号,例如:
此外,行为取决于您使用的内联标记。
man javadoc
明确表示对于@link
:因此在这种情况下不可能做得更好。
不幸的是,我找不到支持我的实验的类似的
@code
引用。At least as of Java 1.8.0_31, I can't reproduce the issue anymore. Your input renders as expected:
My tests indicate that
javadoc
takes into consideration balanced curly braces inside@code
, and only ends it when the corresponding curly brace is found.So if the code has balanced curly braces
{}
like your example, it now works as expected.But I still don't know what to do with unbalanced curly braces like:
Also, the behavior depends on which inline tag you are using.
man javadoc
explicitly says that for@link
:So in that case it is impossible to do any better.
Unfortunately, I couldn't find a similar quote for
@code
which backs my experiments.为此找到了另一个不太理想的解决方法。 它比其他的更好还是更差? 我会让你决定。 将
{@code }
部分替换为; 。 (由于尖括号,这使得它全部消失。)将第一个
<
包裹在{@literal }
中,使其看起来像这样{@literal<}
。 现在一切都会显示得很好,而且代码中并没有被残酷地屠杀。 最终结果如下所示或者,如果您不喜欢
{@literal<}
,那么您可以使用<
代替。 结果如下:这两个解决方案都不是很好的解决方案,但它们确实有效。
Found another less than stellar workaround for this. Is it better or worse than the other ones? I'll let you decide. Take the
{@code }
part and replace it with<code> </code>
. (This makes it all disappear because of the angle braces.) The take the very first<
and wrap it in{@literal }
, making it look like this{@literal<}
. Now everything will show up fine, and it's not too horribly slaughtered in the code. The final result looks like thisAlternatively, if you don't like the
{@literal<}
, then you could use<
instead. The result would look like this:Neither are great solutions, but they do work.