fbpx
维基百科

回帖风格

电子邮件网络论坛或者Usenet回覆文章时,经常会引用原始文字。在实践中存在着多种回帖风格

主要的风格包括:上回覆(Top-posting),即在原文上方攥写回覆;下回覆(Bottom-posting),即在原文下方回覆;以及交织回覆(Interleaved-posting)。不同的虚拟社区对何种风格是适当的有不同的看法。在一个社区中使用“错误”的风格,可能被视作严重违反网络礼仪,从而遭致社区成员的激烈反应。

由于比较先进的邮件客户端和邮件服务(如Gmail)会按照主题将邮件组织在一起,各种回帖风格的差异就显得不那么重要了。

风格

上回覆

这种方法在回帖裡包含被回覆的信息的完整内容,在其前方加上回覆内容。有时这种风格被称作TOFU,即“Text Over, Fullquote Under(文本结束,后附完整引文)”的缩写。这是微软OutlookOutlook ExpressGmail和其他一些邮件客户端的默认风格,类似在转发消息时将新内容加在顶部:

没问题。那就下午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应用程序(如微软OutlookGmail)默认的光标放置方式有利于上回覆。由于其软件的广泛使用,微软对上回覆起了很大的影响;它的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年。  > 电影显然增加了一种恐怖气氛,而这在原书中是不存在的。 > 这是不可接受的 [黑暗诠释的优缺点,删去...] 我不同意。如果有人能够理解这两者是面向不同的受众的话, 就会发现这种更黑暗的调调很不错。 

参考文献

  1. ^ ARM Linux — Mailing Lists — Etiquette. [2008-09-15]. (原始内容于2008-09-05). 
  2. ^ Top Posting and Bottom Posting. [2008-09-15]. (原始内容于2008-05-09). 
  3. ^ What is Top Posting?. [2008-09-15]. (原始内容于2008-07-04). 

回帖风格, 在电子邮件, 网络论坛或者usenet回覆文章时, 经常会引用原始文字, 在实践中存在着多种, 主要的风格包括, 上回覆, posting, 即在原文上方攥写回覆, 下回覆, bottom, posting, 即在原文下方回覆, 以及交织回覆, interleaved, posting, 不同的虚拟社区对何种风格是适当的有不同的看法, 在一个社区中使用, 错误, 的风格, 可能被视作严重违反网络礼仪, 从而遭致社区成员的激烈反应, 由于比较先进的邮件客户端和邮件服务, 如gmail, 会按照主题将邮件组. 在电子邮件 网络论坛或者Usenet回覆文章时 经常会引用原始文字 在实践中存在着多种回帖风格 主要的风格包括 上回覆 Top posting 即在原文上方攥写回覆 下回覆 Bottom posting 即在原文下方回覆 以及交织回覆 Interleaved posting 不同的虚拟社区对何种风格是适当的有不同的看法 在一个社区中使用 错误 的风格 可能被视作严重违反网络礼仪 从而遭致社区成员的激烈反应 由于比较先进的邮件客户端和邮件服务 如Gmail 会按照主题将邮件组织在一起 各种回帖风格的差异就显得不那么重要了 目录 1 风格 1 1 上回覆 1 2 下回覆 1 3 交织回覆 2 参考文献风格 编辑上回覆 编辑 这种方法在回帖裡包含被回覆的信息的完整内容 在其前方加上回覆内容 有时这种风格被称作TOFU 即 Text Over Fullquote Under 文本结束 后附完整引文 的缩写 这是微软Outlook Outlook Express Gmail和其他一些邮件客户端的默认风格 类似在转发消息时将新内容加在顶部 没问题 那就下午6点吧 Jim 原始信息 发件人 Danny lt danny example com gt 发送日期 2007年10月16日 上午10 01 收件人 Jim lt jim example com gt 主题 RE 工作 喔 等一下 我有个计划任务在5点半要给技术人员发送邮件 你能推迟一个小时吗 Danny 原始信息 发件人 Jim lt jim example com gt 发送日期 2007年10月16日 上午9 40 收件人 Danny lt danny example com gt 主题 工作 我今晚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中最让人讨厌的是什么 下回覆 编辑 另一种回覆信息的风格是 下回覆 回覆内容放在引用内容的下面 以保持回覆的逻辑顺序 符合从上向下的阅读习惯 通常只有需要回覆的内容才被引用 其余无关信息均被删除 gt Jim在周三上午9 40写道 gt gt 我今晚5点要暂停邮件服务 大约半个小时 以便安装升 gt gt 级和一些重要修正 Danny在周三上午10 01写道 gt 喔 等一下 我有个计划任务在5点半要给技术人员发送邮 gt 件 你能推迟一个小时吗 没问题 那就下午6点吧 向下滚动翻过整篇文章才能看到回覆 特别是在原始文章很长而回覆很短的情况下 这是非常不方便的 很多没有经验的计算机使用者甚至可能不知道需要滚动以看到他们想要找的回覆 当发送一封未经剪裁的下回覆信件时 可以在开头写上 我在最后有回覆 这样的字样 然而 由于现代的邮件程序可以把不同层次的引用用颜色区别看来 如上所示 所以这不再是个大问题 另一个显示后面还有回覆文字的好方法是使用签名作为文本的结束标志 这样读者就会知道需要一直读到看到你的签名为止 在使用交织回覆时 这个方法非常礼貌 并且很有用 因为在你的签名出现时 就相当于告诉读者你的回覆到此结束 交织回覆 编辑 在实践中 下回覆 通常被扩展至 交织回覆 或者叫 逐条反驳 有的时候也被称作 下回覆 被引用的内容和对应的回覆交织在一起 每个回覆针对某个段落或者句子 这使每段讨论都自然的按照时间顺序排列 回帖者无须覆述每个需要解决的问题 因为他可以直接在原贴中相应的位置进行逐条回应 从而产生一个更加结构化 有规则和准确的回覆 Jim在周四写道 gt 当考虑到原小说和改编的电影的风格差异时 可以很容易 gt 看出 删节 是的 但书和电影之间隔了有20年 gt 电影显然增加了一种恐怖气氛 而这在原书中是不存在的 gt 这是不可接受的 黑暗诠释的优缺点 删去 我不同意 如果有人能够理解这两者是面向不同的受众的话 就会发现这种更黑暗的调调很不错 参考文献 编辑 ARM Linux Mailing Lists Etiquette 2008 09 15 原始内容存档于2008 09 05 Top Posting and Bottom Posting 2008 09 15 原始内容存档于2008 05 09 What is Top Posting 2008 09 15 原始内容存档于2008 07 04 取自 https zh wikipedia org w index php title 回帖风格 amp oldid 73124427, 维基百科,wiki,书籍,书籍,图书馆,

文章

,阅读,下载,免费,免费下载,mp3,视频,mp4,3gp, jpg,jpeg,gif,png,图片,音乐,歌曲,电影,书籍,游戏,游戏。