不要摇摆，直达关键点：
什么？
何时？
在哪里？
表支持
2020-11-23
元堆栈Exchange＆DBA Meta
更多表支持
2020-11-30一周
DBA Stack Exchange
甚至更多的表支持
2020-12-07星期
全网启动（如果未发现重大问题）
是的。终于到了在我们的Markdown方言中支持表语法的时候了。这是一个长期以来一直要求的功能，我们很高兴能够最终对此做一些事情。从今天开始，您可以使用GitHub风格的Markdown表语法在您的帖子中包含表。
过去，我们一直不愿将表语法引入Markdown方言中。原因之一是缺乏良好的标准。网络上有各种各样的格式，但是很长一段时间以来没有一个明确的标准。 CommonMark仍未在0.29版中指定表格。
另一个主要原因是表格难以提取。如果做得不好，流氓表可能会破坏我们用户的整个页面布局。当我们仍然维护自己的markdown渲染器时，将一堆markdown转换为适当的表一直是一个令人恐惧的任务。
已经过去了很多时间，现在该重新评估我们的担忧了。 CommonMark付出了很多努力：新引入的开源Markdown渲染器支持表格语法，我们可以依靠它们很好地处理这项棘手的任务。
良好指定的表语法的不确定性尚未完全消除。理想情况下，如果只有一种，我们将使用官方的CommonMark语法。但是，我们认为GitHub风格的markdown提供了一种稳定且可用的表格语法，足以满足我们的目的。我们的网站。在为团队创建文章时，我们的团队用户应告知我们表支持对于他们的文档编制至关重要。该请求是今天整个CommonMark迁移和支持表语法背后的主要诱因之一。
注意：我们通常的假期构建冻结开始于11月24日（星期二）结束。我们希望尽早开始收集反馈，但是直到感恩节之后的11月30日星期一，我们才能解决任何问题。如果发生严重错误，我们将再次禁用该功能（但希望最好！）。
语法
好吧，那您如何使用表格呢？我们更新了格式帮助，为您提供一些指导。但这是为您提供的概述。
一个简单的表如下所示：
| A header | Another header |
| -------- | -------------- |
| First | row |
| Second | row |
结果：
头文件
/>另一个标头
第一行
行
第二行
行
/>
规则
您始终需要标题行
单元格由管道（
|）符号您可以包含前导和尾随管道，但不必
必须跟随标题行通过具有相同单元格数量的分隔符行
（即
|---|---|行）单元格中的空格和
-字符的数量不必对齐（但是如果可以的话肯定看起来不错）您可以通过在分隔线的相应单元格中包含
:来设置表格列的对齐方式。左侧的:将使列左对齐（这是默认设置）。右侧的:将使其右对齐。左右:都会产生一个中心对齐的列。| left | center | right |
|:---- |:------:| -----:|
| One | Two | Three |
left
right
一个
两个
三个
限制
降价表有一些限制。它们不支持您可以使用HTML表做的所有事情，这是有目的的。每个单元格只能包含内联内容（文本，图像，链接，内联代码）。
您不能合并单元格或行。
阻止内容，如多个段落，列表，代码块，子表和其他复杂的东西不起作用。如果您要将Markdown表与内联HTML混合使用，则可能会遇到麻烦。
您无法手动确定列的宽度。您的浏览器将根据表中的内容确定任何给定列的合适宽度。
如果您需要更多详细信息，建议您浏览一下GitHub风格的Markdown表规范。
滚动计划
团队用户已经可以使用其帖子中的表格了几周了，所以那边什么都没有改变。
从2020-11-23开始，我们将启用对Meta的表格支持Stack Exchange和我们喜欢表的朋友可以在DBA Meta Stack Exchange上交流，这样您就可以开始使用该功能，熟悉语法并帮助我们清除一些我们遗漏的问题。
计划是启用表如果没有反馈或担忧表明这是个坏主意，请在2020-11-30的一周内访问DBA Stack Exchange。
之后，我们让功能沉入一点，并在滚动之前收集更多反馈在整个网络范围内扩展到Stack Exchange网络中的所有站点。我们希望在2020年12月7日这一周推出。
常见问题解答
我发现了一个错误。我该怎么办？
太好了！我们知道表支持仍然会有些粗糙。请在此公告中添加答案，以复制您发现的问题（如果可能），我们将进行调查。
您花费了这么长时间吗？
构建和维护我们自己的渲染器的工作量很大当我们仍然构建自己的Markdown渲染器时，这项更改的成本过高。要求此功能的团队客户允许我们花时间从根本上改进Markdown渲染功能，并为最终支持表奠定一切基础。
如果CommonMark将来采用正式的表语法会发生什么？ />我们正在尝试尽可能与CommonMark兼容，因此如果发生这种情况，我们很可能会支持CommonMark语法。我们的Markdown渲染器（markdown-it和Markdig）均符合CommonMark规范。在他们采用正式的CommonMark表语法之前，这很可能是时间问题。如果这样做，我们可以更新两个库以在Stack Exchange网络上引入相同的语法。如果我们能做到这一点，我们将了解更多细节，并可以仔细考虑所有细节。
为什么您选择GitHub风格的语法而不是
GitHub风格的Markdown的原因（“ GFM”）表语法具有合理的规范。它适用于网络上的其他重要站点。我们的Markdown渲染器开箱即用地支持GFM样式的表格。从我们的角度来看，这是最务实的选择。
表格是否可以在实时预览中正确显示？
是的。在编辑器下方的实时预览将在您键入时呈现表。
我们将在接下来几周内发布的表的插入和编辑列表中进行一些改进。
#1 楼
功能请求状态已完成在表头中允许使用小写字母
即使Markdown将它们作为小写字母，表头似乎也总是以大写字母显示。这似乎是表标题样式的一部分：这里有一个
text-transform: uppercase。我了解从样式上看，大写标题看起来更好，并且可以更好地表示它是标题而不是普通单元格。但是，请提供一个选项来禁用表标题中的大写字母，这有以下三个主要原因：
大写字母对于定义和区分标题很重要
在某些情况下，表内容的大小写实际上对帖子的内容。下面的示例：
用户组
样式“ HoTMaiL”的首选项
样式“ Hotmail”的首选项
老用户
72％
23％
新用户
19％
63％
如果单击以编辑帖子，您将看到第二个标题实际上具有文本“ HoTMaiL”，而第三个标题则为“ Hotmail”。但是，它们在表头中看起来完全一样。 （在上下文中，网站的最初创建者使用第一种样式表示该网站提供了第一个基于HTML的电子邮件客户端-大写的字母“ HTML”。）
在某些手册中违反了样式规则，即使在使用所有大写字母的情况下，在某些特定情况下也需要小写字母
，这也可能违反某些样式手册中的样式规则，该规则指出，即使以其他方式使用所有大写字母，某些字母也应小写。例如，在至少一本样式书中，所有大写字母中的名称“ McDonald”和“ LaSalle”应写为
McDONALD或LaSALLE。但是这种样式不允许这样做。示例：更喜欢麦当劳
更喜欢汉堡王
72％
23 ％
19％
63％
某些字符的大写形式可能与小写形式大不相同。
最后，全大写样式可能会引入怪异的字符，这些字符的大写形式与小写形式不同。例如，长S字符
ſ的大写形式为“ S”，因此具有该字符的表将令人迷惑地显示字母“ S”，而不是长S字符ſ。下面的示例：年份
书中ſ的发生率
1700-1800
64％
也无法在标题中键入德国eszett符号ß，因为它会拆分为“ SS”：
打破表头的字符
ß
iBug在评论中指出：头中的实际字符：
ß
虽然可以使用代码格式解决这些实例，但在完成此答案后，表标题中的代码不再大写，网站上的常规礼节仅使用代码
是否可以通过某种方式在表头中写小写字母，即使首选的样式是将它们全部大写？ br />
评论
“从风格上看，我知道大写的标题看起来更好，它可以更好地表示它是标题，而不只是普通的单元格。”我什至不同意。大写字母更难读。粗体和阴影背景足以表明该单元格是表格标题。只需使所有标头使用普通大小写即可。如果作者想要大写，则可以键入。
–科迪·格雷
20 Nov 24'4:16
@CodyGray该文本的目的不是“我同意”，而是“我知道你来自哪里，但是请...”。
–好奇号刺猬索尼克
20 Nov 24'4:18
@CodyGray所有大写字母的实际问题是，如果列标题需要区分大小写的标题（例如，编程语言中的标题），则其样式会违反语言规则。我从外观上喜欢从设计POV中进行选择，但是从编码的角度来看，它没有灵活性。
– Bad_coder
20-11-24在17:25
是的即使将其实现为将当前的全大写格式设置为默认设置，但使用某些参数或方法在特定表中将其禁用（除了不适当地对非代码使用代码格式设置之外），这还是对它的一种改进。毫无例外地将其格式化为全大写。
– V2Blast
20-11-27在8:36
更糟糕的是，fl是一个字符，但是大写时会分成两个字符。同样，ffi分为三，再加上更多。 stflßstfl→SSSSTFL（什么？）
– iBug说恢复莫妮卡
20-11-28在19:14
@iBug：无论如何，Unicode都不鼓励使用那些连字字符：unicode.org/faq/ligature_digraph.html。但是，德语eszett是另一回事，因为它是“真实的字母”，而不是纯粹的表象作品。幸运的是，它确实具有大写形式（ẞ），可以代替小写形式使用。
–凯文
20-11-29在22:36
@Kevin我知道这一点，这就是为什么这是我为回应他们的评论而编辑到我的帖子中的唯一角色。不过，尽管如此，小写的eszett变成“ SS”而不是fact的事实是意外的。从外观上看，这是CSS属性的直接结果，因此，如果不大幅度更改代码，将很难解决。
–好奇号刺猬索尼克
20-11-29在22:41
@Sonic：我同意eszett是个问题。可能是因为在将小写eszett添加到Unicode时，大写eszett正式不是德语中的东西。据我所知，新的大写形式被认为是“可选的”，这意味着SS仍被视为有效的替代形式，而Unicode必须选择一个或另一个。由于它先前选择了SS，并且必须应对各种稳定策略，因此这可能是阻力最小的路径。
–凯文
20-11-29在22:51
也不可能在标题中键入德国eszett符号ß，因为它会拆分为“ SS”。实际上，德语具有大写的ß，即ẞ。将ß大写为SS是错误的。
– Polygnome
20/12/04在14:48
@Polygnome参见以上两个评论。
–好奇号刺猬索尼克
20/12/04在20:04
@Polygnome大写ß为SS并没有错。见§25 E3
– jazzpi
20/12/7在13:03
使用MathJax有一种解决方法：meta.stackexchange.com/a/357525/391772。不过这并不理想。
–user1271772
20 Dec 7'at 17:49
Aaron说这将在下一版Stacks中使用，但是他必须解决一些对齐问题。
–Catija♦
20/12/7在20:46
@poke在Stacks设计中，但在7天前被删除。不幸的是，正如Catija所说，他们遇到了一些布局问题，因此尚未将最新版本部署到站点。他们仍然在拥有它的旧版本上。
–好奇号刺猬索尼克
20 Dec 8'在9:16
在发布到Stacks以及将Stacks投入生产时可能会有滞后。您可以想象，在我们可以随时随地更新Stacks软件包之前，还需要在生产方面进行大量测试。现在到处都在生产，整个应用程序看起来都很好。
–亚伦·谢基♦
20/12/14在18:54
#2 楼
功能请求编辑器状态已完成请同时提供表格支持的帮助。
有关实现建议的信息，请参见屏幕截图。
评论
我刚刚得到了一个修复程序供审查，该修复程序将为表添加内联帮助。该修复程序将在下周初发布。请不要失望，因为我找不到适合您设计的合适字体，因此我不得不偏离您的设计建议。
–汉姆·沃克♦
20-11-26在10:35
感谢您的工作@HamVocke。我知道，我难以置信的字体很难复制。我肯定希望您找到了支持巨型S的合适替代品;）
–Luuklag
20-11-26在11:25
太糟糕了，您的字体不支持巨型S @HamVocke，让我想投票否决这个答案;）
–Luuklag
20年12月3日，9：45
@Tinkeringbell是否应该将“代码”复数为“代码”或“ Codez”？ :)
– Zev Spitz
20/12/05在20:06
@Zev Oof，困难的问题...问母语人士吗？ ;）
–小叮当♦
20 Dec 6'在10:49
@ZevSpitz中的“代码”是“用编程语言编写的文本”的含义，因此无法计数，因此不需要巨型S（无论如何，模因已被弃用）。因此，“ Codez”显然更好，这使您有机会展示您的1337状况。
–离散蜥蜴
20 Dec 6'在12:55
@ZevSpitz您尚未在HTMLz中签出我的Skillz。
–雷
20年12月7日，16：06
#3 楼
feature-requeststatus-deferred具有按字典顺序对列中的数据进行排序的功能。即，使表可排序（单击标题=对相应的列进行排序）。
例如，在结果表中有用：
ASR API
日期
CV
F
LS-c
人类
12.7
2018-03-30
23.2
24.2
16.6
12.1
28.8
Google Cloud
2018-03-30
23.3
26.3
18.3
12.3
27.3
IBM
2018-03-30
21.8
47.6
24.0
9.8
25.3
Microsoft
2018-06-30
29.1
28.1
23.1
18.8
35.9
语音统计技术
2018-09-12
19.1
38.4
21.4
19.4
Wit.ai
2018-01-03
35.6
54.2
37.4
19.2
41.7
在大多数电子表格程序或维基百科中，我们都可以做到：
另一个排序有用的表格示例：https：// spa ce.stackexchange.com/a/49247/1111
评论
您将需要Javascript才能使其正常运行，并且通常仅对具有多行的表才有意义。可能会有默认的排序顺序，用户也可以按其他列进行排序。通常在网页中使用向上和向下的三角形。例如，维基百科具有此功能。团队用户可能会非常喜欢。
– Trilarion
20 Nov 24 '20：20
这背后的想法是什么？这应该是帖子作者在撰写帖子时对表格进行排序的工具吗？还是应该为读者提供某种东西，以便他们可以根据需要对数据进行排序？
–汉姆·沃克♦
20-11-25在16:24
@HamVocke供读者使用。与Wikipedia相同。
–弗朗克·德农库尔
20 Nov 25 '18：36
我们的设计系统Stacks中已有现有技术。也许我们可以在这里做类似的事情。这是一个有趣的建议，我们必须仔细考虑。
–汉姆·沃克♦
20-11-25在18:40
@HamVocke我可以想象可能两者都有。即使内容创建者原则上可以手动创建任何所需的排序，但是一旦该功能可用，使用该功能也可能会很方便，以便允许帖子作者指定默认排序。并且一旦到达那里，也可以让读者重新排序。到达那里后，您可能还需要过滤。我想到了数据表。
– Trilarion
20 Nov 26'10:31
今天，我们已经与很多人讨论了这个想法。我们认为这比最初看起来更难解决。对表数据进行排序将不可避免地引起后续问题：对多列进行排序又如何呢？那么不同的排序方法（日期，整数等）呢？我同意这是一个不错的功能，但是需要花费更多的精力才能正确实现。
–汉姆·沃克♦
20-11-30在17:10
@HamVocke感谢您的反馈。我同意，很难实现完美的解决方案。只要穿上鞋子，我就可以简单地模仿Wikipedia的可排序表格。
–弗朗克·德农库尔
20 Nov 30'17:13
我喜欢在Wikipedia中对表格进行排序的功能；并且我更新了几篇文章，以允许对具有“奇怪”数据的表进行正确排序，但是不幸的是，有很多变通办法可以很好地进行排序。 en.wikipedia.org/wiki/Help：排序我认为SO中很少有可以对表进行排序的情况。
–马克·斯图尔特
20 Dec 4'在17:03
我们为什么不完全做维基百科所拥有的呢？该代码并不难访问，并且易于模仿。
–user1271772
20 Dec 6'在17:33
如果曾经引入过排序，请使用一种稳定的排序算法（一种在有联系的情况下保留先前顺序的算法）-这是进行多列排序的一种直观方法。
– Jan Dorniak
20/12/08在18:44
我想不出哪个用例会有用吗？如果有人添加了太多数据以至于排序很有用，那么该数据可能会对所提出的问题有害。似乎是出于创意的想法。考虑到任务的难度，我会说有更好的事情要解决
–利亚姆
20 Dec 9'在10:02
@Liam容易做客户端。表格也可以用于答案。不需要一个大的表就可以进行排序。我的表是一个排序有用的示例。
–弗朗克·德农库尔
20 Dec 9'在10:07
@Liam我会在表格中使用有关语音识别API准确性的问题。语言学SE或DS。
–弗朗克·德农库尔
20 Dec 9'在10:12
好的，我想我的重点是Excel中的名称列表。我现在明白了，我仍然认为这是利基TBH。我猜这取决于该功能的使用方式，我认为我们现在还不知道这一点。
–利亚姆
20 Dec 9'在10:13
@HamVocke“如何对多列进行排序？”支持此功能的最简单方法是使用稳定排序（而IMO是进行列排序的正确方法；非稳定变量是错误的）。然后，如果要按（名字，姓氏）排序，则可以对名字列进行排序，然后对姓氏列进行排序。
–贾斯汀
20 Dec 12'在18:43
#4 楼
该表在块引用中工作正常：头文件
另一个头文件
行，划你的船
轻轻地顺流而下
，因为生命不过是疲惫。
这是扰流板中发生的事情：
|标头|另一个标头|
| -------- | -------------- |
|第一|行|
|第二|行|
评论
剧透不支持Markdown语法，包括代码块和块引用。
–user289905
20-11-23在18:21
不支持全部或大部分Markdown语法：meta.stackexchange.com/questions/116613/…
–zcoop98
20/11/23在18:50
表格格式的剧透如何？
–罗伯特尼克
20-11-27在2:54
停止破坏乐趣^ H ^ H ^ Htable！
–克里斯·伦戈（Cris Luengo）
20/12/3在17:01
您实际上并不需要扰流板中的表。真的很罕见
–技术专家向导
20/12/11在15:50
#5 楼
标头中包含MathJaX时发生的错误
标头中包含MathJax时，存在很多浪费的空间：
这是到目前为止我尝试过的代码：
| Can MathJax be used as a workaround for lower case letters? | $\textrm{Yes}$ |
| -------------- | --------------------- |
| | $\int e^x = f(u)n$ |
| Is the right-side ruined just because there's Mathjax in the header? | $\int e^x=f(u)n$ |
| -------------- | --------------------- |
| | $\int e^x = f(u)n$ |
| What about if we mix MathJax with non-mathjax? | $\int e^x=f(u)n$ It fixes it |
| -------------- | --------------------- |
| | $\int e^x = f(u)n$ |
| So can there be a workaround? by using ` ` | $\int e^x=f(u)n$ |
| -------------- | --------------------- |
|It required 15 ` ` commands though, and the spacing<br> required at the end is sub-ideal. In fact without the `<br>` <br> commands I'm using, the right-side gets messed up again.<br> So there's even more wasted space on the left-side than <br> one would hope would be necessary. | $\int e^x = f(u)n$ |
| So can there be a workaround? by using ` ` | $\int e^x=f(u)n$ |
| -------------- | --------------------- |
|It required 15 ` ` commands though, and the spacing required <br>at the end is sub-ideal. This is what the above table looks like if the <br>`<br>` comes just one word later. Lots of wasted space on the<br> left-side of the table, and still the right-side is slightly mesed up. | $\int e^x = f(u)n$ |
| So can there be a workaround? by using ` ` | $\int e^x=f(u)n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~$ |
| -------------- | --------------------- |
|It required 15 ` ` commands though, and the spacing required <br>at the end is sub-ideal. This is what the above table looks like if the <br>`<br>` comes just one word later. Lots of wasted space on the<br> left-side of the table, and still the right-side is slightly mesed up. | $\int e^x = f(u)n$ |
评论
阅读此公告，我认为应该支持表中的Mathjax。 “内联内容”似乎包括Mathjax。我不认为它是“其他复杂内容”的一部分，因为Mathjax不能包含其他markdown元素。但是我可能是错的，这还不是很清楚。此外，当前似乎没有一个站点同时支持降价表和Mathjax，因此目前很难测试它是否可以工作。
–离散蜥蜴
20/12/6在18:06
是。在“限制”部分下，原始帖子未提及MathJax。
–user1271772
20 Dec 6 '21：34
据我所知，这应该工作。不过，它现在已在全网络范围内直播，请随时尝试。
–Catija♦
20 Dec 7'在17:03
@Catija也许您可以指定它最近才发布？对原始帖子的更新是在您发表评论前3分钟进行的，实时更新在此之前不久。您的评论让我觉得好像它已经存在于整个网络上很长时间了，而当我数次对其进行测试时，我的大脑出现了问题。
–user1271772
20 Dec 7'at 17:21
列宽的问题最肯定与以下事实有关：MathJax内容的宽度在实际呈现之前是未知的，因此表布局无法适应它。如果该列中的一项是常规文本，则将强制该列容纳该文本，从而减轻了问题。
–埃米尔·杰拉贝克（EmilJeřábek）
20/12/08在12:08
@EmilJeřábek很好。我不明白为什么在最后两个示例中，左列中必须有这么多浪费的空间。同样，在渲染MathJax之前$ \ int e ^ x = f（u）n $将被“估计”占用的空间大于渲染后的空间，所以我有点困惑-在上述某些示例中，列是如此之窄。
–user1271772
20 Dec 9'在22:21
如果您有一个15行的表格，只需要1个符号的mathjax，则@Edward确实是一个糟糕的解决方案。
–user1271772
11小时前
@Edward我想知道您是否可以考虑删除自己的命令，我也会这样做。我认为这是“噪音”，使人们无法注意到信号。我写了这个问题math.meta.stackexchange.com/q/32841/202425（不同的用户名，但相同的网络配置文件），其中包含大量此类表的示例。如果您想补充一下这是具有主要缺陷（例如，降低页面加载速度）的临时修复程序，请这样做，但我不希望有人建议不要修复此错误。其实看这个问题的v1
–user1271772
11小时前
也许指向该math.meta问题的指针可能会对其他人有所帮助？
–爱德华
11小时前
#6 楼
功能请求状态已完成标头中的代码不应该大写吗？
code sample大写同一个
code sample是小写字母评论
是的，我不好，我已经删除了评论。我一直忘了有两种方式来编写代码示例（内联与块）：)不过，对我来说似乎也不是一个错误，因为其他所有内容也都是大写的……而且我想知道会有多少人将代码示例放入一个。在表格中，并b。）在表格标题中。我仍然喜欢现在的样子，至少看起来是一致的。
–小叮当♦
20-11-23在17:22
固定在堆栈中。它需要片刻才能投入生产。
–亚伦·谢基♦
20 Nov 23 '17：43
你为什么要这个？如果要使标头中的代码大写，为什么不使用CODE SAMPLE而不是code sample？看到这个：meta.stackexchange.com/a/357019/391772和这个：meta.stackexchange.com/a/357525/391772
–user1271772
20 Dec 9'在22:21
@ user1271772我要小写而不是大写。在状态完成之前，它是大写的：i.stack.imgur.com/yFPuJ.png。
–收集帽子的蜘蛛
20 Dec 9'在23:03
@ amask-wearingarachnid好的，这有点令人困惑，因为现在您的帖子以小写形式显示了代码示例。因此，这只是较大功能请求的子集，以允许标头中使用小写字母。您帮助它使代码块成为可能，现在我们需要它们来使它适用于其他所有功能。
–user1271772
20 Dec 9'在23:35
#7 楼
错误状态延迟在表中放置降价引号时在预览中呈现而不会中断...
...在实际帖子中失败：
this|is|a|table
-|-|-|-
> markdown quote | > another quote | > quote 3 | > 4
此
是
a
表
降价报价| >其他报价| >报价3 | > 4
虽然这是一个极端的情况，但如果预览与真实的渲染相匹配会很好。
Update
@ HamVocke♦在在下面的注释中，只要将管道
|添加到包含前导>字符的表行的外边缘，它就应呈现而不中断。示例：
|this|is|a|table|
|-|-|-|-|
|> markdown quote | > another quote | > quote 3 | > 4|
此
是
a
表
< br / >> markdown报价
>另一个报价
>报价3
> 4
评论
谢谢！我们的预览和服务器端渲染之间的渲染差异总是细微而令人讨厌。我发现，如果在每行中都包含前导和尾随的竖线字符，则可以使两者都能正确呈现表。
–汉姆·沃克♦
20-11-24在9:16
@HamVocke客户端渲染器和服务器渲染器之间差异的一般原因是什么？我已经看到很多错误因彼此之间的差异而出现，尤其是自CommonMark迁移开始以来。为什么两个渲染器不同？为什么不使用完全相同的代码在两侧进行渲染？
–好奇号刺猬索尼克
20 Nov 24'9:50
@ SonictheK-DayHedgehog客户端渲染器和服务器端渲染器是两个不同的代码段，都遵循CommonMark规范。事实证明，该规范留有歧义的余地，并且两者在解释规范时有时会略有不同，从而导致我们所看到的差异。我们不能在两个地方都运行相同的代码，而后端必须在C＃上运行，因此必须使用JavaScript客户端。我们正在努力尽可能地消除这些差异（在时间和影响上是合理的）。
–汉姆·沃克♦
20 Nov 24 '10：00
感谢您提供信息@HamVocke！添加外部管道是有道理的将限制该行，并帮助渲染器将其识别为表行而不是blockquote。
–zcoop98
20-11-24在16:12
鉴于我们已经找到了消除任何歧义的解决方法，因此我将其定为延期状态。理想情况下，我们在此处对齐两个库，但这将直接在相应的库中进行一些修复，这比我们直接修复它要麻烦。
–汉姆·沃克♦
20 Nov 25'7:52
等一下，为什么我们不能在表格单元格内降价？
– einpoklum
20/12/3在21:42
@HamVocke是否值得考虑在服务器上运行node.js微服务？或不那么琐碎但更酷的替代方法是使用wasm或blazor将markdig编译为webassembly。
– David Mulder
20年12月7日在7:34
#8 楼
bugstatus-deferred链接渲染器（将原始链接自动转换为显示问题标题的链接）可以在预览中工作，但在实际渲染的帖子中则不能工作，除非您添加前导和尾随空格。
源
链接
空格
| https://meta.stackexchange.com/q/277369 | 服务条款更新限制在未经您许可的情况下抓取您的个人资料信息的公司
lead + trailing
|https://meta.stackexchange.com/q/333965 | https://meta.stackexchange.com/q/333965
跟踪
| https://meta.stackexchange.com/q/336526| https：//meta.stackexchange.com/q/336526 | leading |
|https://meta.stackexchange.com/q/7931| https://meta.stackexchange.com/q/7931
没有
第三行特别有趣由于客户端预览渲染器正确地猜出了我的意图，而服务器端渲染器却不能。
您可以开始编辑此帖子以自己查看，或者查看此屏幕截图。
评论
我怀疑我们的服务器端渲染器跳闸了，因为您在| |之后没有使用前导/尾随空格。表格的字符。当然，您不必使用空格，但是我的假设是，如果添加了空格，它将可以正常工作-因此，这可能暂时可以解决。我将进行一些挖掘，看看是否可以复制。
–汉姆·沃克♦
20 Dec 1'在8:08
因此，现在您发现了一个错误：在当前版本（第3版）中，预览在“空格”列中显示倒数第二行，其中“领先”，而保存的版本在链接一中显示，其完整内容为https：// meta .stackexchange.com / q / 336526 | lead |。
– fedorqui'停止伤害'
20 Dec 1'在8:21
@ fedorqui'SOstopharming'感谢您对此进行细分，这很有帮助。看来这是Markdig的链接解析器的问题（它似乎将|解释为URL的一部分，根据官方RFC不允许）。这将对Markdig本身进行修复，这将使我们花费更长的时间，因为我们必须协调这些更改。目前：请使用空格。
–汉姆·沃克♦
20 Dec 1'在8:41
@HamVocke如此延期还是计划中？
–Luuklag
20年12月1日在9:27
@Luuklag推迟了。这不是我们一个人掌握的，所以我不能对修复的及时性做出任何承诺。
–汉姆·沃克♦
20年12月1日，9：44
#9 楼
错误状态已完成表格未显示在配置文件编辑器预览中：
尽管它们确实显示在我的实际配置文件中：
评论
这是由于标签Wiki，个人资料说明和选举提名帖子中使用了旧的编辑器。希望它将很快被替换。
–user289905
20 Nov 23在18:59
@ user289905很好的想法，但事实并非如此。它与我们在其他地方使用的编辑器相同，但是好像我错过了传递用户个人资料，标签Wiki和选举提名的表选项。完全是我的错，希望能尽快解决。 （旁白：这是一个快速解决方案）
–汉姆·沃克♦
20-11-25在16:42
#10 楼
错误状态已完成这些表也不会在标记Wiki预览中呈现：
但是，这些表确实可以在实际的标记Wiki（此处）中正确呈现。
评论
根据user2389905对另一个答案的评论：“这是由于在标签Wiki，个人资料描述和选举提名职位中使用了旧的编辑器，希望它将很快被替换。”
– V2Blast
20 Nov 24'1:12
与其他帖子相同的更新：不是老编辑，只是我很傻。得到修复以供审查。再进行一些测试，再加上一些批评，我相信它可以在下周初发布（在我们的构建冻结结束之后）。
–汉姆·沃克♦
20 Nov 25 '17：00
#11 楼
关于HTML元素限制的注释之后，我想尝试一下：left align
center align
right align
none /默认align
markdown链接
HTML图像：
pre tag
三反引号仅产生
code spans backtick inline code, with no added breaks html code tag pre tag withlinebreak tags
pre tag withlinebreak tags
> markdown quote这会在实际帖子中中断，但没有预览>！破坏器
html
<blockquote> html带引号的带引号
html code tagwith inlinebreak tags * markdown ul
1。 markdown ol
html
<strike> 描述列表（
<dl>）：项目（
<dt>）1 项目1描述（
<dd>）描述列表项2
项目2 desc
订购列表（
<ol>）：列表项1
列表项2
列表项3
无序列表（
<ul>）：列表项1
列表项2
列表项3
默认对齐的
<ol>列表：列表项1
列表项2
列表项3
markdown斜体
markdown粗体
markdown粗体斜体
＃markdown标头
html斜体
html粗体
html粗体斜体
html
<h1>标头下标
<sub> 水平降价---规则
html horizontalrule
<hr> （允许SE进行HTML标记刷新）
表面上看来，现在看来玩起来还不错！
有什么原因吗？这种支持将来会发生变化吗？
还是可以将其视为一项功能？
评论
当前，系统不允许您在单元格内编写CommonMark列表。如果我们开始看到HTML标签散布在帖子中，那就倒退了一步，因为在编辑其他人的帖子时很少会看到任何HTML。同样，不保持分隔器对齐会造成严重的意大利面条。
– Bad_coder
20 Nov 23'20:31
响亮地同意意大利面条的评论。这篇文章的潜在消息来源是一团糟
–zcoop98
20-11-23在20:56
感谢您的努力，即将推出的编辑器可能会有所帮助。但无法解析和呈现此答案的内容。
–Rob
20-11-24在1:46
我不愿提出任何鼓励混合使用HTML和Markdown的建议。有太多令人讨厌的情况，这怎么会出错并破坏假设。官方规格是真理的源头。您可以实现的任何事情都是巧合。实际上，这并不像我们经常更换Markdown渲染器一样-因此，如果现在可以正常工作，它很可能会继续工作一段时间。
–汉姆·沃克♦
20-11-24在7:51
#12 楼
feature-requeststatus-declined请添加使表不包含标题的功能。
评论
我们暂时不打算这样做。官方的表扩展规范需要一个表头，我们绝对希望坚持一个（事实上的）标准，并避免使用我们自己的标准。每当GitHub风格的Markdown规范或CommonMark指定无需标题即可工作的表时，我们都会很乐意支持此表。在此之前，所有表都必须包含标题。
–汉姆·沃克♦
20-11-30在17:02
@HamVocke允许在标题中使用小写字母怎么办？
–user1271772
20 Dec 7'at 17:23
@ user1271772我们正在努力。
–汉姆·沃克♦
20/12/7在18:26
#13 楼
bugstatus-review表在帖子的时间轴上的呈现方式与实际情况不同。例如，这是此帖子时间轴中的表格的屏幕截图：
这是实际文章中的表格：
您可以看到“用户组”和“样式首选项”未与
|管道应包含的行分开。标头字体在时间轴中也不是黑色/粗体。评论
接得好。看起来像帖子冲突中的表的样式定义与用于显示时间轴的表结构冲突。
–汉姆·沃克♦
20-11-27在8:06
@HamVocke与此类似吗？
–奥利
20-11-27在21:42
#14 楼
错误意见建议编辑diff当建议进行编辑并从“ Rendered Output”切换到“ Markdown”再回到“ Rendered Output”时，表格在diff中消失。 >
切换后：
另外，差异中的表头填充也很有趣。
评论
好发现。可以确认您在链接的示例建议编辑中看到了同样的怪异现象。
– V2Blast
20 Dec 6'在22:36
#15 楼
feature-request我们可以在markdown编辑器工具栏中获得“表格”选项吗，与Stack Overflow文档中已经介绍的选项相同。
SO文档中的截图： >
评论
这是新编辑器的一部分，该编辑器已经存在于SO Teams中。我认为它最终将在整个网络范围内推出：meta.stackexchange.com/a/356354/361484
–Luuklag
20 Dec 3在11:27
@Luuklag：从堆栈主持人团队来看，目前没有快捷方式-Ctrl + E似乎不起作用...当前编辑界面中的“表格”按钮似乎只是在插入表格“模板”， 2-3行和2-3列（它不会提示用户选择许多行和列或其他内容）。
– V2Blast
20 Dec 6'22:56
#16 楼
bug如果在表格的上方或下方有文字，则预览会将表格的减价呈现为表格。但是，在您保存帖子后，表格不会呈现，只会显示降价代码。
您可以使用以下代码作为示例。如果您尝试编辑我的答案，它将在预览中显示一个表格，但在后端渲染的帖子视图中则不显示。
发布后的结果
表格上方的文本
| test | test |
| ---- | ---- |
| test | test |
因此后端渲染器损坏或预览渲染器损坏。
评论
通常，这是相当标准的。我所知道的唯一无需整个段落中断就可以使用的降价方法是紧跟标题之后的段落。我什至不确定标题之前没有双倍返回是否可以正常工作。它仍然只是以前的代码块的一部分。
–Catija♦
20 Dec 8'在2:24
在这种情况下，@ Catija由于未遵循此规则，因此预览呈现已损坏。
–科多斯·约翰逊（Kodos Johnson）
20 Dec 8'在2:27
这还算公平。我很想知道我们是否可以工作。 🙂
–Catija♦
20 Dec 8'在2:28
#17 楼
feature-request增加了交换表中两列的能力（手动完成很麻烦）。
例如：
评论
这应该是永久的，即自动生成的修改吗？
– Trilarion
20-11-24在15:03
@Trilarion很好，我想为作者提供自动生成的编辑，但是使列可从读者端切换也是很好的（以防读者喜欢的列顺序不同于作者决定的列顺序）。
–弗朗克·德农库尔
20-11-24在19:42
是时候使用Microsoft Excel插件了；）
–Luuklag
20-11-25在7:54
新的编辑器（已在Teams上试用）具有WYSIWYG表编辑器，它可能/可能不支持此功能。
–好奇号刺猬索尼克
20-11-25在8:08
这对我来说不是必须的，但是拥有它真是太棒了-我什至没有考虑过这种可能性！ :)
– V2Blast
20-11-27在8:42
#18 楼
feature-request请添加键盘快捷键，以将表格插入帖子中。我真的很喜欢这些新表，希望不必单击
Show formatting tips → Insert table → copy/paste table来插入它们。评论
在撰写SE帖子时，您使用哪些键盘快捷键？我很好奇！
–user1271772
20/12/6在21:15
@ user1271772：Ctrl + L添加链接，Ctrl + B和Ctrl + I添加粗体/斜体格式，Ctrl + U表示项目符号（无序）列表，Ctrl + O表示编号（有序）列表，Ctrl + Q表示块引用格式。
– V2Blast
20 Dec 6'在22:33
此外，Ham回复了Nick对问题的评论，确认在编辑界面中将有一个按钮来简化插入/编辑表的操作，但我很好奇它的外观-大概可以通过键盘快捷键来完成与单击该按钮相同。
– V2Blast
20 Dec 6'在22:33
@ user1271772所有人！
–奥利
20 Dec 6'在22:40
从Arulkumar的回答来看，新的帖子编辑器似乎包括（或将包括）表格的“ Ctrl + E”快捷方式。尽管从Stack Moderators团队判断，目前还没有捷径-Ctrl + E似乎不起作用...当前编辑界面中的“表格”按钮似乎只是插入了带有2的表格“模板” 3行和2-3列（它不会提示用户选择许多行和列或其他内容）。
– V2Blast
20/12/6在22:55
@ V2Blast这是一个很好的观点。事实是，我们不知道何时将新的编辑器公开，直到那时我仍然会喜欢键盘快捷键。另外，Ctrl + E是搜索Google的快捷方式，因此可能需要轻按。
–奥利
20 Dec 6 '23：00
@Ollie：我很确定SE帖子编辑器的快捷方式可以“替代”浏览器已经用于其他用途的任何快捷方式。例如，Ctrl + B会在Firefox中弹出“书签”侧栏，但是在帖子编辑器中使用时，它会加粗该内容。同样，Ctrl + L跳转到Firefox中的地址栏，但是在SE的帖子编辑器中，它会插入一个链接。至于您的另一点，Yakov在另一个MSE回答中说，他们将不再对当前编辑器进行任何更改（新的Stacks Editor最终将在网络范围内推出）。
– V2Blast
20 Dec 6'23:25
@ V2Blast我将等到实际拥有快捷方式后再进行测试。
–奥利
20 Dec 6'23:27
#19 楼
feature-request增加了转置表格的能力（手动完成很繁琐）。可能会意识到桌子的宽度已经变得太大了，对桌子进行转置将使其适合而不需要水平滚动。
评论
我认为这是一个好主意，可以节省很多时间！
–user1271772
20 Dec 6'在21:11
甚至Excel也没有此功能...祝您好运，那太好了。
– TylerH
20 Dec 7'在14:52
@TylerH复制，粘贴特殊的/选中“转置”框;-)
–马修·金登（Mathieu Guindon）
20 Dec 9'在20:26
@MathieuGuindon再次让杯子马克... :-)
– TylerH
20 Dec 9'在20:51
#20 楼
我
想要
想要
说...
<
非常
很多
！
已经说过...
feature-requeststatus-declined
我想对我在网络上的所有帖子进行一些漫游/查询/处理，并建议那些带有表格的帖子，以便我查看并编辑成实际的表格。例子。
评论
@Ollie：也许将其发布为错误报告回复？我还没有收到有关表的任何收件箱通知。
– einpoklum
20/12/3在21:46
@Ollie：您可以链接到该屏幕快照的部分截图吗？
– einpoklum
20/12/3在21:49
@Ollie：还不错。
– einpoklum
20/12/3在21:51
您可以链接到出现在桌子上的示例吗？
–ReinstateMonica3167040
20年12月4日，0：55
@Userthatisnotauser：好的。但是，为什么您“不是用户”？
– einpoklum
20 Dec 4'在9:34
我对SEDE基本上一无所知...但是可能有什么方法可以使用SEDE查询来查找此类帖子吗？
– V2Blast
20 Dec 6'在22:28
@ V2Blast：1.这将是一个非常昂贵的查询，可能会失败。 2.查询是针对特定站点的，不是吗？ 3.我的意思是要为所有人做到这一点，而不是让个人能够自己做到。
– einpoklum
20 Dec 6'23:09
@einpoklum：关于第3点，我并不是要用它替代您的请求，而只是选择（例如，如果SE未实现此目的）。我认为第二点是正确的。 （我对你的第一点一无所知。）
– V2Blast
20 Dec 6'23:21
我知道这可能是有用的，但是现在我们不打算花时间了。成本/收益比对我来说并不吸引人。人们一直在创造性地解决我们过去没有合适的桌子这一事实，因此，充满信心地摆放所有这些职位将是获得边际收益的巨大障碍。这些帖子在没有适当的表格的情况下似乎表现良好，因此现在没有太多紧迫性来触发转化。
–汉姆·沃克♦
20 Dec 7'在8:40
@HamVocke：我猜这很公平。但是，明显的情况是带有许多-----和|的代码段。随便可能不会花费很多精力。
– einpoklum
20 Dec 7'在9:11
在这里，您可以使用：data.stackexchange.com/stackoverflow/query/…是每个站点的，因为我无法在2分钟内运行全网络版本。
–rene
20/12/7在9:19
@rene：我认为您应该将其设为独立帖子...
– einpoklum
20 Dec 7'在9:22
如果你这么说。做完了meta.stackexchange.com/questions/357555 / ...
–rene
20年12月7日13:00
#21 楼
bugstatus-bydesign突出显示时，表主体为橙色，而标题保持为灰色
评论
需要明确的是，这特别是：target（或#fragment）Flash高亮动画，例如在新标签页中打开答案。
–user289905
20 Nov 23'17:38
这不是故意设计的吗？
–user1271772
20 Dec 6'在18:07
另外，我无法在Ubuntu 16.04的Chrome中重现此内容。
–user1271772
20/12/6在21:10
这个掉了我的雷达。是的，是设计使然。表格标题具有专用的背景色，而不是突出显示时使用的默认淡黄色背景色。表格主体未定义明确的背景色，因此问题主体的黄色也会在此处应用。
–汉姆·沃克♦
20/12/08在9:10
#22 楼
添加从电子表格软件（Microsoft Excel，LibreOffice Calc，Google表格等）复制表格的功能，并将其粘贴到SE上的编辑框中。自从GitLab引入此选项以来，它已成为我的首选工作流程。评论
这是一个棘手的问题。我当然看到了价值，在构建新的编辑器时我们一直在努力。处理粘贴（尤其是从Office应用程序粘贴）非常困难。您必须根据从中复制的来源（包括浏览器差异）来处理很多不一致和极端情况。最重要的是：Markdown表仅支持Excel表可以执行的功能的有限子集-没有合并的单元格，没有调整大小，没有自定义格式。我还没有找到一种不会让用户感到困惑的好方法来处理这些案件，但是我很高兴！
–汉姆·沃克♦
20/12/08在19:40
GitLab MR看起来非常简单-即使是非常基本的支持总比没有强。即使删除所有格式的IMO，只要我可以粘贴表格，这都是胜利。它可能不适合SE的工作方式，但是具有随时间推移而改进的选项的简单实现比使其完美无缺-您是对的，这很难。我相信我不是典型的用户，但是只要可以预见甚至不完美的行为就可以了。不过，我在此描述的内容可能最适合技术性更高的网站...
– Jan Dorniak
20/12/08在19:48
对于普通用户而言，虽然不是一个可行的集会，但非技术用户只会抱怨它不起作用。
– Jan Dorniak
20/12/08在19:48
（而且我几乎开始大声疾呼为什么不喜欢Markdown了……没有多行表行是这些原因之一，尽管您无法解决）
– Jan Dorniak
20/12/08在19:51
GitLab的实现确实看起来很诱人，它们依赖于复制的Excel表的纯文本表示形式（与我之前尝试使用的HTML表示形式相反）。让我再旋转一遍，也许我们可以准备就绪。感谢您的指导，我真的很感激！
–汉姆·沃克♦
20/12/08在20:32
乐意效劳！我确实希望这件事早日实现；）
– Jan Dorniak
20/12/08在20:45
相关功能请求：meta.stackexchange.com/q/358890/394472
– Boghyon Hoffmann
2天前
#23 楼
我不知道这将如何影响复制编辑。由于编辑格式错误的表格可能会成为复制编辑者最繁琐的工作。希望您可以建立某种检测机制，以在表格格式不正确时向OP警告。
评论
IMO会经历使用表进行格式化的麻烦，可能会再次检查其格式是否正确。
–科多斯·约翰逊（Kodos Johnson）
20-11-23在18:21
拥有Markdown衍生品的@KodosJohnson海报并不是我担心的那些。那些经验不足的成员可能会发布破表（留给其他人修复）。我喜欢这个主意，这是改变游戏规则的人。
– Bad_coder
20 Nov 23在18:29
是的，如果它们包含一个用于生成表代码的按钮，那可能会更糟，我认为这将在即将推出的新编辑器中进行。
–科多斯·约翰逊（Kodos Johnson）
20/11/23在18:45
编辑格式错误的表已经是较繁琐的任务之一（当有人使用引号而不是代码来突出显示它们时，解开错误堆栈就变得很麻烦）。至少现在这些表看起来会很漂亮。
– Ben倒退
20-11-23在20:41
老实说，我对此最大的恐惧。我喜欢在有意义的情况下使用表，而只是生成它们。为我省了很多麻烦。当编辑器屏幕太小而无法容纳整个内容时，请确保手动正确设置表格的声音听起来像是一种缓慢的折磨，而您正试图再增加一列。我确实希望出现某种便利工具。
– VLAZ
20 Nov 24在7:36
@VLAZ编辑器窗口是否可调整大小？
–泰勒
20-11-30在14:31
@TylerH可以上下调整大小，但不能左右调整大小。屏幕截图。
– VLAZ
20-11-30在14:41
@VLAZ啊，真可惜。虽然SO应该解决此问题，但可以使用以下CSS选择器/属性通过用户样式进行用户固定：textarea {resize：revert！important;职位：相对z索引：1； }
– TylerH
20-11-30在14:45
@TylerH也不确定这是一个很好的解决方案。使用垂直显示器时，侧面没有太多的空间。当使用水平监视器时，我使用三列编辑器用户脚本，该脚本将页面分成三部分，并显示问题（左侧面板），答案框（中间面板）和答案预览（右侧框）。看起来像这样。因此，我不确定将包装盒加宽是否是个好主意。如果内容较广，我已经使用了文本编辑器。
– VLAZ
20-11-30在14:49
@VLAZ好吧，试图将输入框滚动到比监视器宽的地方与在查看框宽超过显示器的意义上一样，因此似乎没有太大的问题：-P
– TylerH
20-11-30在15:01
因此，@ TylerH希望能提供一些方便的工具。在答案中添加代码时，我们可以使用堆栈代码段。如果代码实际上不是可运行的，则有点麻烦，但是如果代码太宽，它的确可以让您更轻松地对其进行编辑，因为您可以在编辑器窗口中向左/向右滚动。然后，您可以删除开始的代码段标签，只剩下一个代码块。像这样的更复杂的表格很难编辑。 3栏检视|用CSS查看
– VLAZ
20-11-30在15:16
#24 楼
bug在Opera（不支持，但我知道，但仅供参考）上，在Android 10上具有Opera的暗模式：表边框有时是灰色的，有时是白色的：
评论
Opera应该使用眨眼...因此理论上Chrome应该有同样的问题。有例子检查吗？
–游侠怪胎♦
20-11-25在9:38
@JourneymanGeek是的，我截图来自meta.stackexchange.com/a/357021/178179
–弗朗克·德农库尔
20-11-25在9:40
您如何在meta中使用黑色主题？
–游侠怪胎♦
20 Nov 25'9:41
@JourneymanGeek使用Opera的黑暗模式
–弗朗克·德农库尔
20-11-25在9:42
不支持Opera吗？从何时起？
– TylerH
20/12/7在14:51
#25 楼
Stack Overflow或Database Administrators的最低可重现示例应具有供读者剪切和粘贴并运行的代码，包括以表格形式格式化的表或类似数据结构的初始值，以提高可读性。由于初始值将以我们无法剪切，粘贴和运行的格式给出，因此更难获得MRE。特别是对于SQL以及具有讽刺意味的是，在数据库管理员处。至少，请更新表，代码后撰写和编辑的文档，以强调使用降价表不应干扰给出以下代码：不仅在链接中，而且可读性强，可以剪切和粘贴并运行。但是，不应该期望读者都复制这种努力。
我们走了。
连接两个表以显示彼此相关的数据
评论
表用于输出数据，而不是输入数据/代码。您不会以表格格式编写SQL。因此，我不确定这会对这些网站产生负面影响。
– TylerH
20 Dec 2'在2:27
@TylerH因为，正如我所说，MRE的初始值是表格，不知情的询问者使用非代码来表示它们。 （回答者也可以接受。）此外，无法剪切和粘贴输出表以按照当前的降价表格式化它们。本质上，降价在与MRE相关的帖子中是没有用的。
– philipxy
20 Dec 2'在19:23
我没有看到通过在markdown中进行操作来破坏包含在表中的数据作为所需输出或当前输入/当前数据的OP（相对于“复制和粘贴”）如何受到损害，因为它已经无法使用通过复制和粘贴。
– TylerH
20/12/2在19:29
@TylerH正如我所说，人们将使用markdown来格式化表格，而不是代码块文本或实际输出。剪切和粘贴时的markdown源或输出是有效的输入代码或文本输出，因此使用markdown可以使问题远离MRE。我同意，剪切和粘贴markdown输入或输出或多或少与不使用输入代码或实际输出一样糟糕，但是，正如我说的那样，它对MRE没有用，并且强调表markdown用户不要在MRE中使用它。
– philipxy
20/12/2在19:53
您是否有一个使用Stack Overflow或DBA.SE上的MRE使用基于表的布局的人的示例？听起来您希望人们出于某种原因会开始将代码格式化为markdown表。
– TylerH
20/12/2在20:13
是的...这似乎不是问题。如果有的话，这似乎是一种改进，因为那里的OP已将其数据显示为图像，这……您已经无法复制并粘贴到任何可运行的场景/环境中。至少如果他们将表格数据输入为降价表，则至少可以复制文本。
– TylerH
20/12/2在20:22
@TylerH它总是发生。使用图像而不是文本说明了如何类似地滥用表格。
– philipxy
20/12/2在20:29
在过去的几天里，我一直在思考这个问题，并得出一个相同的结论：我们没有什么可以做的事情来防止人们使用不正确的格式。代码样本和示例数据应格式化为代码块，以逐字呈现所有内容。如果那没有发生，不仅是表弄乱了表示形式。 *字符可能导致文本加粗，＃注释将被解释为标题。我们依靠评论者指出这一点，或者依靠编辑者直接解决此问题。在过去，这种方式运行良好。
–汉姆·沃克♦
20 Dec 9'在8:02
@HamVocke单击编辑功能时，您可能会弹出警告，说明示例代码（包括调试问题）中要使用的数据表不应使用所选功能。等等，但我还要指出，尽管有人要求进行表格格式化，但在（至少是指向）代码格式化程序之前提供非代码格式化程序会导致优先级错误，而不是考虑到人性和网站的不良用户教育。 （您甚至没有看过SO和DBA应当以哪种方式格式化表的百分比？）
– philipxy
20 Dec 9'在8:18
@philipxy对不起，但我真的不明白您的建议。您是在说我们应该将所有用户输入都视为纯文本，并且默认情况下放弃Markdown以避免错误格式化可能是代码示例的内容吗？
–汉姆·沃克♦
20 Dec 9'在9:44
#26 楼
功能请求聊天Onebox的状态已延迟我们还可以在聊天中的Onebox上启用表支持吗？
当前这篇文章的呈现方式为：
哪个不如帖子在网站本身上。
评论
我认为当聊天中的一个问题被“单框”显示时，大多数帖子格式都无法正确显示...
– V2Blast
20-11-24在1:14
这个问题比表面上看起来更难解决。由于我们要截断单一框内容，因此很有可能在表格的中间切掉所有内容，并且无法再适当地理解它了。我同意这会超级聪明，但我不得不说“现在不行”。
–汉姆·沃克♦
20-11-25在7:55
#27 楼
feature-requeststatus-declined添加了指定
thead（<th>）标签（即行标题）的功能。例如：
评论
目前尚无法将列语义上标记为标题，这将需要更改GFM规范，这是我们最终未触发的内容。标题行中的所有内容都将创建为
–汉姆·沃克♦
20 Dec 7'在8:52
#28 楼
bugstatus-bydesign表中的扰流器既不会在预览中也不会在实际帖子中呈现：
一个标题
另一个标题
>！首先
>！行
>！第二
>！行
在预览中：
评论
我认为这更多是功能请求，而不是错误。表格似乎仅支持注释和赏金评论中使用的微型Markdown功能。
–好奇号刺猬索尼克
20 Nov 26 '21：33
是的，这绝对是设计使然。块级元素，如块引用，代码块或扰流器在Markdown表中不起作用。
–汉姆·沃克♦
20-11-27在8:08
@HamVocke我理解您的意思，但是很难称其为“设计使然”。这更像是markdown不支持它，不是说他们故意选择了他们不起作用。这是极少数需要Markdown分叉的情况之一。
– TylerH
20-11-30在14:36
@TylerH我不同意。分叉Markdown将是维护的噩梦，我们只是在CommonMark迁移的相反方向上迈出了一步。不允许表内的块级元素并不是疏忽。如果您想使用简洁的表格语法，则完全不允许使用允许代码块或块引用，而不会发生冲突。表依靠换行符来标记行的结尾，块引号和代码块允许将换行符作为其内容的一部分。在其单元格中带有换行符的表将几乎不可用。
–汉姆·沃克♦
20/12/04在7:45
@HamVocke“块级元素（如块引用）在Markdown表中不起作用...”请稍等，我认为我通过使用blockquote HTML标记找到了解决方法。似乎不是故意的，我应该把它发布为这个问题的答案吗？
– Mindstormsboi
20 Dec 4'15:39
@mindstormsboi将HTML和Markdown混合使用可以使您突破一些限制，但迟早会给您带来其他麻烦。这里还有另一个答案，概述了可以使用Markdown表和HTML进行的一些操作。我个人不鼓励混合使用HTML和Markdown，因为我们知道结果很难预测。
–汉姆·沃克♦
20/12/04在20:06
我同意@ SonictheK-DayHedgehog。我认为没有人真的需要在桌子上放一个扰流板。这真的没有多大意义。太有趣了（笑）。
–技术专家向导
20/12/11在15:57
@HamVocke允许内嵌的spolier使用说>！spoiler text！<= spolier text 帮助吗？我遇到了这个问题，并在此处发布了功能请求
–TheMaster
2天前
#29 楼
bugstatus-bydesign使用网站的移动版本，某些列可能太细，因此无法读取其内容。看到这个帖子：
原始表是这样的：
App
版本
免费吗？
描述
RAE和ASALE的Diccionario de la la lenguaespañola
-Android-iOS iOS
是
Duolingo
-Android- iOS-Windows Phone
是
应用程序，可帮助您通过游戏类课程学习西班牙语
Anki（类似Memrise）
是的
可以在palalabra /expresión/oración中继续学习惯性出售在加拿大的临时工，在西班牙的临时工。在西班牙库萨斯坦州的体育锻炼。 Para sabermás，请咨询esta respuesta。
Speed西班牙语
-Android
是
应用程序，具有多种工具和游戏，可帮助用户学习西班牙语，包括：字典，翻译器，共轭器，课程和多人游戏。由Kes Walker开发
从我的手机中，我看到了以下内容。您可以通过切换到网站的移动版本并将屏幕最小化来重现它：
您可以看到，第一列非常薄。我不知道为什么它不占用更多空间，而是全部分配给第四列。
评论
是的，不幸的是，浏览器的默认布局算法可能很烦人，尤其是在小视口上。我们的Stacks员工可以轻松获得响应式表格的基本版本，但上次我检查他们仍在为一些边缘情况而苦苦挣扎。一旦了解了这些情况，如果表格超过最小宽度，则应该在狭窄的视口上开始水平滚动。
–汉姆·沃克♦
20 Dec 10 '13：16
@HamVocke这是个好消息。感谢您的大力支持
– fedorqui'停止伤害'
20 Dec 10'在13:48
我与我们的Stacks人员签到，事实证明我错了。如果表格已经需要在小视口上显示，则表格确实会开始滚动。但是，此功能在页面的移动视图中不可用，而仅在响应视图中可用。确保在页脚中选择“完整站点”和“启用响应性”以进行切换。
–汉姆·沃克♦
20/12/11在8:02
#30 楼
在整个网络范围内启用？好吧，不完全是...一小群不屈不挠的聊天者仍在抵抗入侵者。这在聊天中不起作用。我们也可以获取聊天更新吗？
评论
您为什么要在聊天中插入一个巨型表？
–科迪·格雷
20 Dec 18'在6:26
我只说了一张桌子，没有说“巨人”。
–松鼠杀手
20 Dec 18'在7:20
让我再试一次：表用于显示长格式信息。您为什么要在聊天中这样做？这有什么用？
–科迪·格雷
20/12/18在7:33
@CodyGray多行代码段在聊天中起作用的原因相同吗？ Markdown支持应该尽可能保持一致，这样我就不必记住聊天/评论/问题/答案/中哪些功能不起作用了。
–贝尔吉
20/12/18在11:00
评论
是否有计划为那些...在md方面不太熟练的人向编辑器中添加表格按钮（向导，csv转换器等）？及时向读者提供建议，最简单的方法是在电子表格中编写表格并以降价支持的格式之一导出。
@Ollie显然，我们对它们感到非常兴奋，我们不想让您隐藏它们！ ：P（我想，他们俩都不是CommonMark，所以他们在一起玩的不好）随意发帖作为答案
现在，“格式设置沙箱”中有一些表格信息，例如这强调了预览和完成后的帖子之间的一些区别-当然还有通常的沙箱怪异。
“假日建筑冻结于11月24日”。我还能得到5个圣诞节假期吗？
@Luuklag直到11月30日星期一。
@Nick是的，我们将在即将推出的新编辑器中包含用于插入和编辑表格的按钮。表很复杂，因此我们可能需要几次迭代才能使此正确，但是我认为这将是朝正确方向迈出的一步。
@Catija，太糟糕了。我猜世界还有另一个以美国为中心的假期;）
感谢您实施此操作。在某些情况下可能非常方便。 “团队客户要求这样做……”使我意识到这里的社区应该与Teams用户社区建立更紧密的联系。这样，无论何时我们想要什么，我们都应该告诉Teams用户，这对于Teams而言首先是多么美妙。 :)
这是什么假期？我在Google搜索“ 11月24日假期”时只找到了国家沙丁鱼节。这是真的吗？
@EmilJeřábek美国-感恩节。今天是26日（星期四）。它也不是特定的日期，而是11月的第四个星期四。
@EmilJeřábek我必须承认，沙丁鱼节有点...是一个令人讨厌的度假理由。
@AndrewGrimm我们在谈论哪种残疾？我们正在生成的HTML表使用了正确的语义，并且对于使用屏幕阅读器的用户来说应该可以正常工作。我们的Stacks设计系统会格外小心，以确保我们为视障用户使用的颜色和字体有效。可访问性很难，我们并不总是能做到正确，但是我们正在努力。如果您发现无法访问的特定内容，请通知我们。
@DavidConrad我明白为什么这令人困惑。让我尝试澄清一下：CommonMark是一种流行的降价规范。切换到CommonMark可以使我们用现成的东西替换旧的手动Markdown渲染器。 CommonMark没有定义表（还可以吗？）。但是，我们介绍的开源渲染器不仅仅支持CommonMark（例如，GFM表）。这就是因果关系。切换到CommonMark给我们带来了开源渲染器，并且带来了表格支持。
@TheTechExpertGuy社区Wiki的工作方式并非如此。 CW表示该帖子已接受所有希望参与的人进行编辑和发表。这不是避开销售代表收益的方法。此外，这是Ham领导的重要发行版，因此赢得了一定声誉，并花时间宣布和支持该发行版是完全公平的。我们不使用CW进行公告。这将大大偏离我们的标准。这也是一个很大的变化，这就是为什么它被推荐了一段时间的原因，但是“相当长的时间”只是一个星期，而不是那么长。