回帖风格：修订间差异
小 机器人：移除8个跨语言链接，现在由维基数据的d:q2296103提供。 |
无编辑摘要 |
||
| 第1行： | 第1行： | ||
在[[电子邮件]]、[[网络论坛]]或者[[Usenet]]回 |
在[[电子邮件]]、[[网络论坛]]或者[[Usenet]]回覆文章时，经常会引用原始文字。在实践中存在着多种'''回帖风格'''。 |
||
主要的风格包括：'''上回 |
主要的风格包括：'''上回覆(Top-posting)'''，即在原文上方攥写回覆；'''下回覆(Bottom-posting)'''，即在原文下方回覆；以及'''交织回覆(Interleaved-posting)'''。不同的[[虚拟社区]]对何种风格是适当的有不同的看法。在一个社区中使用“错误”的风格，可能被视作严重违反[[网络礼仪]]，从而遭致社区成员的激烈反应。 |
||
由于比较先进的邮件客户端和邮件服务（如[[Gmail]]）会按照主题将邮件组织在一起，各种回帖风格的差异就显得不那么重要了。 |
由于比较先进的邮件客户端和邮件服务（如[[Gmail]]）会按照主题将邮件组织在一起，各种回帖风格的差异就显得不那么重要了。 |
||
| 第7行： | 第7行： | ||
== 风格 == |
== 风格 == |
||
=== 上回 |
=== 上回覆 === |
||
这种方法在回帖里包含被回 |
这种方法在回帖里包含被回覆的信息的完整内容，在其前方加上回覆内容。有时这种风格被称作'''TOFU'''，即“Text Over, Fullquote Under（文本结束，后附完整引文）”的缩写。这是[[微软Outlook]]、[[Outlook Express]]、[[Gmail]]和其他一些邮件客户端的默认风格，类似在转发消息时将新内容加在顶部： |
||
<div style="border:none; display:table; margin:auto;"> |
<div style="border:none; display:table; margin:auto;"> |
||
| 第39行： | 第39行： | ||
</div> |
</div> |
||
回帖本身是完整的内容，有些类似于传统的[[书信]]，不同之处是附带上了原帖。虽然有时不推荐使用上回 |
回帖本身是完整的内容，有些类似于传统的[[书信]]，不同之处是附带上了原帖。虽然有时不推荐使用上回覆，但是在商业信函中这是一个常见的风格。[[顾客服务]]信件往往要求所有的回覆内容要以清晰的方式表达，没有引文。同时可能附上原始邮件，但仅仅作为证据。 |
||
这种风格的一个好处是，当新人收到一个之前是私有的讨论时（由于[[电子邮件转发|转发]]或者增加收信人），这个讨论的所有背景信息（即“[[线索化讨论|线索]]”）对其都是可见的。特别是在商业信函中，可能需要将整个消息线索转发给第三方进行处理。在这种情况下，将处理指示“上回 |
这种风格的一个好处是，当新人收到一个之前是私有的讨论时（由于[[电子邮件转发|转发]]或者增加收信人），这个讨论的所有背景信息（即“[[线索化讨论|线索]]”）对其都是可见的。特别是在商业信函中，可能需要将整个消息线索转发给第三方进行处理。在这种情况下，将处理指示“上回覆”在引文之上更加合适──因为目的仅仅是提供指示，而非进行针对性的回答。（在整个讨论都是公开的的环境下，比如[[新闻组]]或者[[网络论坛]]，没必要包含过往讨论，[[#交织回覆|裁剪]]就足已。） |
||
许多流行的e-mail应用程序（如[[微软Outlook]]和[[Gmail]]）默认的[[光标]]放置方式有利于上回 |
许多流行的e-mail应用程序（如[[微软Outlook]]和[[Gmail]]）默认的[[光标]]放置方式有利于上回覆。由于其软件的广泛使用，[[微软]]对上回覆起了很大的影响；它的e-mail和新闻组软件默认把光标放在顶端，在某些情况下甚至难以做到不使用上回覆（这是由于微软Outlook的许多版本都存在一个bug，即在用文本模式回覆一封以HTML/RTF格式发送的邮件时，没有引用符号，再加上微软Outlook的默认设置根本就不生成引用符号──这使得很难区分新加文字和引用文字）；许多用户把这个当作[[De facto|事实]]标准接受了。另外，[[手持设备]]（如[[黑莓手机]]）用户倾向于使用上回覆，由于这些设备只下载邮件的开始部分用作显示。邮件的其余部分仅仅在需要的时候才下载，这需要花费额外的下载时间。对黑莓用户来说，把关心的内容放在邮件的开始部分可以节省带宽和时间，也可减少滚屏。 |
||
部分由于微软的影响，在[[邮件列表]]和私人信件中，上回 |
部分由于微软的影响，在[[邮件列表]]和私人信件中，上回覆更常见。一般认为上回覆严重破坏了[[邮件列表]]的摘要功能，因为很难跳过多层的上回覆。在最坏的情况下，一个上回覆会包含整个摘要作为原始邮件。 |
||
一些人认为，上回 |
一些人认为，上回覆适合人际间的email，而对于像新闻组这样的线索讨论，则应该使用交织回覆。新闻组中对上回覆的形成规则的抵制，看起来主要来自在[[Usenet]]早期就上线的人，以及Usenet早期就存在的社区。抵制最激烈的包括Usenet的comp.lang树下的新闻组，特别是comp.lang.c和comp.lang.c++。而在alt树下的社区更能容忍上回覆。新的线上用户，特别是那些没有太多Usenet经验的人，往往对关于回帖风格的争论不敏感。 |
||
在邮件列表里，下面的例子偶尔被用来嘲弄和劝阻上回 |
在邮件列表里，下面的例子偶尔被用来嘲弄和劝阻上回覆的行为：<ref>[http://www.arm.linux.org.uk/mailinglists/etiquette.php ARM Linux — Mailing Lists — Etiquette]</ref><ref>[http://www.idallen.com/topposting.html Top Posting and Bottom Posting]</ref><ref>[http://what-is-what.com/what_is/top_posting.html What is Top Posting?]</ref> |
||
<div style="border:none; display:table; margin:auto;"> |
<div style="border:none; display:table; margin:auto;"> |
||
答：因为它把人们正常的阅读顺序打乱了。 |
答：因为它把人们正常的阅读顺序打乱了。 |
||
问：为什么上回 |
问：为什么上回覆不好呢？ |
||
答：上回 |
答：上回覆。 |
||
问：E-mail中最让人讨厌的是什么？ |
问：E-mail中最让人讨厌的是什么？ |
||
</div> |
</div> |
||
=== 下回 |
=== 下回覆 === |
||
另一种回 |
另一种回覆信息的风格是“下回覆”。回覆内容放在引用内容的下面，以保持回覆的逻辑顺序，符合从上向下的阅读习惯。 |
||
通常只有需要回 |
通常只有需要回覆的内容才被引用，其余无关信息均被删除。 |
||
<div style="border:none; display:table; margin:auto;"><span style="color:red"> |
<div style="border:none; display:table; margin:auto;"><span style="color:red"> |
||
| 第76行： | 第76行： | ||
</div> |
</div> |
||
向下滚动翻过整篇文章才能看到回 |
向下滚动翻过整篇文章才能看到回覆，特别是在原始文章很长而回覆很短的情况下，这是非常不方便的。很多没有经验的计算机使用者甚至可能不知道需要滚动以看到他们想要找的回覆。当发送一封未经剪裁的下回覆信件时，可以在开头写上“我在最后有回覆”这样的字样。然而，由于现代的邮件程序可以把不同层次的引用用颜色区别看来（如上所示），所以这不再是个大问题。另一个显示后面还有回覆文字的好方法是使用签名作为文本的结束标志，这样读者就会知道需要一直读到看到你的签名为止。在使用交织回覆时，这个方法非常礼貌，并且很有用，因为在你的签名出现时，就相当于告诉读者你的回覆到此结束。 |
||
| 第130行： | 第130行： | ||
..........(從下行往上讀) |
..........(從下行往上讀) |
||
=== 交织回 |
=== 交织回覆 === |
||
在实践中，“下回 |
在实践中，“下回覆”通常被扩展至“交织回覆”（或者叫“逐条反驳”，有的时候也被称作“下回覆”）。被引用的内容和对应的回覆交织在一起，每个回覆针对某个段落或者句子。这使每段讨论都自然的按照时间顺序排列。回帖者无须覆述每个需要解决的问题，因为他可以直接在原贴中相应的位置进行逐条回应，从而产生一个更加结构化、有规则和准确的回覆。 |
||
<div style="border:none; display:table; margin:auto;"> |
<div style="border:none; display:table; margin:auto;"> |
||
2013年4月16日 (二) 11:31的版本
在电子邮件、网络论坛或者Usenet回覆文章时，经常会引用原始文字。在实践中存在着多种回帖风格。
主要的风格包括：上回覆(Top-posting)，即在原文上方攥写回覆；下回覆(Bottom-posting)，即在原文下方回覆；以及交织回覆(Interleaved-posting)。不同的虚拟社区对何种风格是适当的有不同的看法。在一个社区中使用“错误”的风格，可能被视作严重违反网络礼仪，从而遭致社区成员的激烈反应。
由于比较先进的邮件客户端和邮件服务（如Gmail）会按照主题将邮件组织在一起，各种回帖风格的差异就显得不那么重要了。
风格
上回覆
这种方法在回帖里包含被回覆的信息的完整内容，在其前方加上回覆内容。有时这种风格被称作TOFU，即“Text Over, Fullquote Under（文本结束，后附完整引文）”的缩写。这是微软Outlook、Outlook Express、Gmail和其他一些邮件客户端的默认风格，类似在转发消息时将新内容加在顶部：
没问题。那就下午6点吧。 Jim -------- 原始信息 -------- 发件人: Danny <danny@example.com> 发送日期: 2007年10月16日 上午10:01 收件人: Jim <jim@example.com> 主题: RE: 工作 喔！等一下。我有个计划任务在5点半要给技术人员发送邮件。 你能推迟一个小时吗？ Danny -------- 原始信息 -------- 发件人: Jim <jim@example.com> 发送日期: 2007年10月16日 上午9:40 收件人: Danny <danny@example.com> 主题: 工作 我今晚5点要暂停邮件服务，大约半个小时，以便安装升级和一 些重要修正。 Jim
回帖本身是完整的内容，有些类似于传统的书信，不同之处是附带上了原帖。虽然有时不推荐使用上回覆，但是在商业信函中这是一个常见的风格。顾客服务信件往往要求所有的回覆内容要以清晰的方式表达，没有引文。同时可能附上原始邮件，但仅仅作为证据。
这种风格的一个好处是，当新人收到一个之前是私有的讨论时（由于转发或者增加收信人），这个讨论的所有背景信息（即“线索”）对其都是可见的。特别是在商业信函中，可能需要将整个消息线索转发给第三方进行处理。在这种情况下，将处理指示“上回覆”在引文之上更加合适──因为目的仅仅是提供指示，而非进行针对性的回答。（在整个讨论都是公开的的环境下，比如新闻组或者网络论坛，没必要包含过往讨论，裁剪就足已。）
许多流行的e-mail应用程序（如微软Outlook和Gmail）默认的光标放置方式有利于上回覆。由于其软件的广泛使用，微软对上回覆起了很大的影响；它的e-mail和新闻组软件默认把光标放在顶端，在某些情况下甚至难以做到不使用上回覆（这是由于微软Outlook的许多版本都存在一个bug，即在用文本模式回覆一封以HTML/RTF格式发送的邮件时，没有引用符号，再加上微软Outlook的默认设置根本就不生成引用符号──这使得很难区分新加文字和引用文字）；许多用户把这个当作事实标准接受了。另外，手持设备（如黑莓手机）用户倾向于使用上回覆，由于这些设备只下载邮件的开始部分用作显示。邮件的其余部分仅仅在需要的时候才下载，这需要花费额外的下载时间。对黑莓用户来说，把关心的内容放在邮件的开始部分可以节省带宽和时间，也可减少滚屏。
部分由于微软的影响，在邮件列表和私人信件中，上回覆更常见。一般认为上回覆严重破坏了邮件列表的摘要功能，因为很难跳过多层的上回覆。在最坏的情况下，一个上回覆会包含整个摘要作为原始邮件。
一些人认为，上回覆适合人际间的email，而对于像新闻组这样的线索讨论，则应该使用交织回覆。新闻组中对上回覆的形成规则的抵制，看起来主要来自在Usenet早期就上线的人，以及Usenet早期就存在的社区。抵制最激烈的包括Usenet的comp.lang树下的新闻组，特别是comp.lang.c和comp.lang.c++。而在alt树下的社区更能容忍上回覆。新的线上用户，特别是那些没有太多Usenet经验的人，往往对关于回帖风格的争论不敏感。
在邮件列表里，下面的例子偶尔被用来嘲弄和劝阻上回覆的行为：[1][2][3]
答：因为它把人们正常的阅读顺序打乱了。 问：为什么上回覆不好呢？ 答：上回覆。 问：E-mail中最让人讨厌的是什么？
下回覆
另一种回覆信息的风格是“下回覆”。回覆内容放在引用内容的下面，以保持回覆的逻辑顺序，符合从上向下的阅读习惯。
通常只有需要回覆的内容才被引用，其余无关信息均被删除。
> Jim在周三上午9:40写道: > > 我今晚5点要暂停邮件服务，大约半个小时，以便安装升 > > 级和一些重要修正。 Danny在周三上午10:01写道: > 喔！等一下。我有个计划任务在5点半要给技术人员发送邮 > 件。你能推迟一个小时吗？ 没问题。那就下午6点吧。
向下滚动翻过整篇文章才能看到回覆，特别是在原始文章很长而回覆很短的情况下，这是非常不方便的。很多没有经验的计算机使用者甚至可能不知道需要滚动以看到他们想要找的回覆。当发送一封未经剪裁的下回覆信件时，可以在开头写上“我在最后有回覆”这样的字样。然而，由于现代的邮件程序可以把不同层次的引用用颜色区别看来（如上所示），所以这不再是个大问题。另一个显示后面还有回覆文字的好方法是使用签名作为文本的结束标志，这样读者就会知道需要一直读到看到你的签名为止。在使用交织回覆时，这个方法非常礼貌，并且很有用，因为在你的签名出现时，就相当于告诉读者你的回覆到此结束。
老板：萬分歡迎，沒有你我們的公司肯定大不一樣！
職員：如果工作太累，搞不好我會辭職的
老板：放心，我不會讓這樣的事情發生的！
職員：我雙休日可以休息嗎？
老板：當然了！這是底線！
職員：平時會天天加班到凌晨嗎？
老板：不可能，誰告訴你的？
職員：有餐費補貼嗎？
老板：還用說嗎，絕對比同行都高！
職員：有沒有工作猝死的風險？
老板：不會！你怎麼會有這種念頭？
職員：公司會定期組織旅遊嗎？
老板：這是我們的明文規定！
職員：那我需要準時上班嗎？
老板：不，看情況吧
職員：工資呢？會準時發嗎？
老板：一向如此！
職員：事情全是新員工做嗎？
老板：怎麼可能，你上頭還有很多資深同事！
職員：如果領導職位有空缺，我可以參與競爭嗎啊？
老板：毫無疑問，這是我們公司賴以生存的機制！
職員：你不會是在騙我吧？ ↓↓
當進入公司後，看真實的一幕!
..........(從下行往上讀)
交织回覆
在实践中，“下回覆”通常被扩展至“交织回覆”（或者叫“逐条反驳”，有的时候也被称作“下回覆”）。被引用的内容和对应的回覆交织在一起，每个回覆针对某个段落或者句子。这使每段讨论都自然的按照时间顺序排列。回帖者无须覆述每个需要解决的问题，因为他可以直接在原贴中相应的位置进行逐条回应，从而产生一个更加结构化、有规则和准确的回覆。
Jim在周四写道: > 当考虑到原小说和改编的电影的风格差异时，可以很容易 > 看出， [删节...] 是的，但书和电影之间隔了有20年。 > 电影显然增加了一种恐怖气氛，而这在原书中是不存在的。 > 这是不可接受的 [黑暗诠释的优缺点，删去...] 我不同意。如果有人能够理解这两者是面向不同的受众的话， 就会发现这种更黑暗的调调很不错。