CN105025066A - 富文本动态消息发布方法、客户端、服务器和系统 - Google Patents

Abstract

本发明公开了一种富文本动态消息发布方法、客户端、服务器和系统。所述方法包括：将待发布的动态消息中的各多媒体附件分别打包上传到服务器，接收每个多媒体附件上传成功时，服务器返回的回包，该回包中包含上传成功的该多媒体附件的服务器地址，最后将所述待发布的动态消息中的各多媒体附件的回包中的信息打包到最后一个包上传到服务器，使得服务器根据该最后一个包中的信息生成一条富文本动态消息。本发明的技术方案，由于将一条富文本动态消息按照附件拆分成多个包分别上传，提高了弱网状态下的上传成功率，进而提高了富文本动态的发布成功率。

Description

富文本动态消息发布方法、客户端、服务器和系统

技术领域

本发明涉及网络通信技术领域，特别涉及富文本动态消息发布方法、客户端、服务器和系统。

背景技术

动态消息是指在社交网站或者社交软件中，用户在社交圈中分享的带有文字、图片、音乐、视频等的信息，用于分享自己的心情、感悟等。动态消息中的除了纯文本(文字)之外的，图片、音频、视频、GIF动态图片等多媒体内容称为富文本。

当前，用户更习惯于在手机等移动终端上使用社交软件发布动态消息。在移动网络(如2G/3G)环境下发布富文本动态消息时，采用单条信令上传发布动态的方式，即以发布纯文本动态相似的方式，将需要上传的图片、音视频等富文本附件按照一定压缩比例转换成二进制码，然后跟文本动态按照一定协议拼成一个包，上传给服务器，由服务器发布，由于移动终端的很容易处于无信号或弱信号区域(如地铁、地下商场等)时，因此用户发布的动态消息经常由于某段时间网络状况不好导致发布失败。

发明内容

为了解决上述问题，或者至少部分地解决上述问题，本发明提供了富文本动态消息发布方法、客户端、服务器和系统。

为达到上述目的，本发明的技术方案是这样实现的：

本发明公开了一种富文本动态消息发布方法，所述方法包括：

将待发布的动态消息中的各多媒体附件分别打包上传到服务器；

接收每个多媒体附件上传成功时，服务器返回的回包，该回包中包含上传成功的该多媒体附件的服务器地址；

将所述待发布的动态消息中的各多媒体附件的回包中的信息打包到最后一个包中上传到服务器，使得服务器根据该最后一个包中的信息生成一条富文本动态消息并发布。

可选地，所述最后一个包还包括该待发布的动态消息的唯一标识，以使所述服务器根据该唯一标识确定该动态消息是否已经生成并发布。

可选地所述将待发布的动态消息中的各多媒体附件分别打包上传到服务器包括：将打包后的多媒体附件按顺序放入队列中，每次从队列中取第一预设值个数的多媒体附件进行上传；

所述将待发布的动态消息中的各多媒体附件分别打包上传到服务器之后，所述方法还包括：如果一个多媒体附件上传失败，则将该多媒体附件放到队尾等待重新发送；如果一个多媒体附件重发次数达到第二预设值，则判定富文本动态消息发布失败。

可选地，该方法进一步包括：

每次上传前，判断当前是否连接网络，如果连接网络则立刻上传，如果没有连接网络则等收到系统发出的网络连接上的通知时再上传，如果在预设的动态发布非超时时间段内一直没有连接上网络，则判定富文本动态消息发布失败；

其中，所述预设的动态发布非超时时间段，是指以开始向服务器上传该待发布的动态消息中的内容的时间点起始的预设长度的时间段。

可选地，该方法进一步包括：

如果在上传队列中的多媒体附件的过程中，用户退出当前客户端应用，后又重启该客户端应用，则先判断是否在预设的动态发布非超时时间段内，是则继续上传队列中的多媒体附件，否则判定富文本动态消息发布失败；

如果在判定富文本动态消息发布失败后，接收到用户重发该条动态消息的指令，则继续上传队列中未上传成功的多媒体附件。

本发明还公开了一种富文本动态消息发布方法，所述方法包括：

接收客户端上传的待发布的动态消息中各多媒体附件；其中，客户端是将待发布的动态消息中的各多媒体附件分别打包后上传的；

每成功接收一个多媒体附件，向客户端返回回包，该回包中包含成功接收的该多媒体附件的服务器地址；

接收客户端上传的所述待发布的动态消息的最后一个包；其中客户端是所述待发布的动态消息中的各多媒体附件的回包中的信息打包到最后一个包中后上传的；

根据该最后一个包中的信息生成一条富文本动态消息并发布。

可选地，在所述根据该最后一个包中的信息生成一条富文本动态消息并发布之前，该方法进一步包括：

根据该最后一个包中的动态消息的唯一标识判断，该动态消息是否已经发布过，是则不再发布该动态消息。

本发明公开了一种富文本动态消息发布客户端，该客户端包括：

附件上传单元，用于将待发布的动态消息中的各多媒体附件分别打包上传到服务器；

回包接收单元，用于接收每个多媒体附件上传成功时，服务器返回的回包，该回包中包含上传成功的该多媒体附件的服务器地址；

发布单元，用于所述待发布的动态消息中的各多媒体附件的回包中的信息打包到最后一个包中上传到服务器，使得服务器根据该最后一个包中的信息生成一条富文本动态消息并发布。

本发明公开了一种富文本动态消息发布服务器，该服务器包括：

附件接收单元，用于接收客户端上传的待发布的动态消息中各多媒体附件，每成功接收一个多媒体附件，向客户端返回回包，该回包中包含成功接收的该多媒体附件的服务器地址；其中，客户端是将待发布的动态消息中的各多媒体附件分别打包后上传的；

动态消息发布单元，用于接收客户端上传的所述待发布的动态消息的最后一个包，根据该最后一个包中的信息生成一条富文本动态消息并发布；其中客户端是所述待发布的动态消息中的各多媒体附件的回包中的信息打包到最后一个包中后上传的。

本发明公开了一种富文本动态消息发布系统，该系统包括：如上所述的客户端和如上所述的服务器。

本发明这种将待发布的动态消息中的各多媒体附件分别打包上传到服务器，接收每个多媒体附件上传成功时，服务器返回的回包，该回包中包含上传成功的该多媒体附件的服务器地址，最后将所述待发布的动态消息中的各多媒体附件的回包中的信息打包到最后一个包中上传到服务器，使得服务器根据该最后一个包中的信息生成一条富文本动态消息的技术方案，由于将一条富文本动态消息按照附件拆分成多个包分别上传，提高了弱网状态下的上传成功率，进而提高了富文本动态的发布成功率。

附图说明

图1是本发明实施例中的一种富文本动态消息发布方法的流程图；

图2是本发明实施例中的一种富文本动态消息发布客户端的结构示意图；

图3是本发明实施例中的又一种富文本动态消息发布方法的流程图；

图4是本发明实施例中的一种富文本动态消息发布服务器的结构图；

图5是本发明实施例中的一种富文本动态消息发布系统的示意图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚，下面将结合附图对本发明实施方式作进一步地详细描述。

图1是本发明实施例中的一种富文本动态消息发布方法的流程图。如图1所示，所述方法包括：

步骤S110，将待发布的动态消息中的各多媒体附件分别打包上传到服务器。

步骤S120，接收每个多媒体附件上传成功时，服务器返回的回包，该回包中包含上传成功的该多媒体附件的服务器地址。

在本发明的实施例中，服务器收到客户端通过当前客户端应用上传的多媒体附件后，存储附件，并根据存储位置生成各附件的服务器地址。回包包括上传附件的信息，比如该附件对应的服务器地址。还可以包括附件的大小、附件的缩略图地址等。客户端将每次一上传成功后服务器返回的回包保存起来。

步骤S130，将所述待发布的动态消息中的各多媒体附件的回包中的信息打包到最后一个包中上传到服务器，使得服务器根据该最后一个包中的信息生成一条富文本动态消息并发布。

本步骤中，如果所述待发布的动态消息还包括文本信息以及一些发布动态消息需要的其他信息，则将文本信息、各多媒体附件的回包中的信息以及一些发布动态消息需要的其他信息打包成最后一个包上传到服务器。

在本步骤中，客户端在附件都上传成功后，在给服务器发送一个最终创建动态的信令(即这里所述的最后一个包)，这个信令里面包括所有附件的回包信息，还有用户发布的文字信息、以及动态需要的一些其他信息等。这样，服务器就可以把每一条富文本动态和相应的富文本附件对应上，以创建该条富文本动态消息。即服务器端可以根据最后一个包中的各回包信息找到对应的富文本附件，进而结合文字、所找到的附件以及一些其他信息生成富文本动态消息。

图1所示的方法中采取了将富文本动态消息中的每个附件分别上传的策略，这样能有效的将原本需要将几个附件合并在一起的较大包拆开，每个附件单独成为一个包上传，等每个附件上传成功后，再将文本信息(如果有的话)、所有的附件的服务器地址和一些其他信息(如果有的话)合成最后一个包上传到服务器。这样每个包都比原来的一个大包小了很多，每个包的上传成功率也会相应增加，尤其是在弱网条件下。

在本发明的一个实施例中，步骤S130中发送的最后一个包还包括该待发布的动态消息的唯一标识，以使所述服务器根据该唯一标识确定该动态消息是否已经生成并发布过，服务器接收到最后一个包时缓存该唯一标识，当由于网络故障或延时等原因，可能会导致重复发送最后一个包到服务器，服务器通过该唯一标识可以确认该条富文本动态消息是否已经生成过，从而不会重复生成该富文本动态消息。该唯一标识具体可以根据用户ID及时间戳生成。

在本实施例中，最后一个包的内容还包括：动态消息附件类型，例如类型为文本、图片、视频和/或音频等、各附件对应的回包内容，若发布的状态信息还包括文本信息，则最好一个包中还包括该文本信息。各个回包中信息包括对应附件类型、附件的服务器地址、较小尺寸缩略图URI、较大尺寸缩略图URI等信息，若附件为视频或音频时，还可以包括音视频文件的长度等信息。服务器接收到最后一个包后，根据最后一个包中的信息，生成动态信息并发布。

在上面的方案中，由于将整条富文本动态进行按附件多次上传，减少了一次上传的包的大小，所以每一次上传的成功率也就提高了。遇到多媒体文件个数很多(比如用户分享了很多张图片)的时候，也不会出现由于多媒体文件过多导致最终包过大而上传失败的问题。此外，由于每个附件单独打包上传，相对于现有技术中将需要上传的图片、音视频等富文本附件按照一定压缩比例转换成二进制码，然后跟文本动态按照一定协议拼成一个包上传的方式，降低了富文本附件的失真率，提高了上传附件的清晰度和附件的展示效果。

但是在实际情况中，在某个时间段，由于网络不好导致某个附件上传失败，其他附件即使都上传成功，整条动态也将发布失败。因此，本发明的发明人在上述方案的基础上，引入了如下重发机制以提高发布动态的成功率：

对于每一个附件，如果上传失败，就再重发预设次数，如三次。也就是说，只有四次上传，每一次都失败的时候，才判定整条动态发送失败。为了节省流量，如果有附件上传四次都失败，其他图片也停止上传，整个动态才会被判定发布失败。为了保证每一个附件的上传的成功率，采用队列机制。每个附件上传失败后，如果在重发次数之内，那么重新上传的时候，就把这个待重新上传的附件放在附件上传队列的队尾。这样可以使得每个附件的每一次上传，都有一定的时间间隔，在信号不稳定的情况下，能最大程度的保证发布的成功率。这样，由于某一个图片发布失败而导致整个动态发布失败的问题，就可以得到解决。

但是，在实际情况中，如果是在地铁里发布这条富文本动态消息，可能经过某一站的时候手机没有信号，如果某个附件总共4次的上传，都赶在手机没信号的这一刻上传，4次重发机会很快就会用完，达不到提高发布成功率的效果。针对这种情况，本申请中还采用了如果当前环境无法检测到网络，附件就不进行上传的策略。但是，这种解决方案，也只针对无网的情况才能有效。还有一种情况是弱网。弱网的情况是，手机有时候能检测到网络，但是时断时续。或者打个比方，当前这个手机能连上自家的wifi路由器，但是这个无线路由器并没有连接到外网。这一时刻，我们也是能检测到wifi网络信号存在的，但是却无法真正连接到网络。数据包也就发不出去。

针对上述比较复杂的情况，本申请中提出了延时重发方案。也就是，当同时上传多个附件的时候，对附件进行分组，每3个附件为一组进行发送，其他的待发送的附件处于等待状态。如果其中一组附件上传成功，才在等待队列中取出下一组待发送的附件进行上传。如果之前上传的附件中，有一个附件已经上传失败达到一定次数(小于等于重发预设次数，例如两次)，整体网络情况就被定义为弱网。弱网环境下，我们对每一条动态消息，都设置动态发布非超时时间段(可以为30分钟，即以开始向服务器上传该动态消息的内容起始的30分钟时间段是该动态消息的动态发布非超时时间段)。每一个附件的每一次重发，我们都设置了一定的间隔时间。间隔时间内，如果收到了系统网络连接成功的通知，就立刻进行发送。如果间隔时间内没有网络连接成功通知(针对于上面所说的，能连接到路由器，但是连不到外网的情况)，到达了间隔时间，就重新发送。每一次发送数据包之前，都判断一下当前网络状况，如果连不上网，就不进行发送。直到有了连网成功通知，而且在动态发布非超时时间段内(离开始上传不超过30分钟)，才继续进行发送。

如果发送过程中，用户退出当前客户端应用，那么当用户下一次启动该客户端应用的时候，如果下次启动时间仍在动态发布非超时时间段内，那么该条动态将自动重新发送。如果已经超过动态发布非超时时间段，那么该条动态显示为发布失败。

发布失败的动态，用户可以手动点击该条动态进行重新发送。重新发送的时候，已经上传的成功的图片，不需要进行重新上传，只需要上传之前上传失败的图片和未来得及上传的图片就可以了。

在本发明的一个实施例中，上传成功定义为接收到服务器的回包。为此，可以用三个数组来分别存储以下三个内容：未上传成功的图片信息、已经上传成功的图片信息(此处是临时数组，上传成功之后的内容未排序，存储的是服务器回包中的内容，见上传协议的回包)、还有一个存储全部附件上传完毕，按照发布者选择图片顺序排好序的数组。

当一个附件上传成功时，就把这个附件从未上传成功的数组中删除，然后把回包信息保存在已经上传成功的临时数组里面。当所有附件都上传完成，会根据发布者选择图片的顺序进行重新排序，重新排好序的回包信息，存到另一个数组里面。排序完成也就意味着，上传的过程正式结束，可以将这些回包信息打包进行发送了。

归纳上述方案，可得到基于图1所示的方法的如下方案：

1)步骤110中所述将待发布的动态消息中的各多媒体附件分别打包上传到服务器包括：将打包后的多媒体附件按顺序放入队列中，每次从队列中取第一预设值个数(如3个)的多媒体附件进行上传；图1所示的方法在所述将待发布的动态消息中的各多媒体附件分别打包上传到服务器之后，进一步包括：如果一个多媒体附件上传失败，则将该多媒体附件放到队尾等待重新发送；如果一个多媒体附件重发次数达到第二预设值(如3次，即共上传4次)，则判定富文本动态消息发布失败。

2)每次上传多媒体附件前，判断当前是否连接网络，如果连接网络则立刻上传，如果没有连接网络则等收到系统发出的网络连接上的通知时再上传，如果在预设的动态发布非超时时间段(如30分钟)内一直没有网络，则判定富文本动态消息发布失败。其中，预设的动态发布非超时时间段，是指以开始向服务器上传该待发布的动态消息中的内容的时间点起始的预设长度的时间段。

具体地，在本实施例中，具体可以在确定当前网络为弱网环境时(即当某一附件上传次数达到一定次数时)，才在每次上传多媒体附件前判断是否连接网络。

3)如果在上传队列中的多媒体附件的过程中，用户退出当前客户端应用，后又重启该客户端应用，则先判断是否在预设的动态发布非超时时间段(如30分钟)内，是则继续上传队列中的多媒体附件，否则判定富文本动态消息发布失败；如果在判定富文本动态消息发布失败后，接收到用户重发该条动态消息的指令，则继续上传队列中的未上传成功的多媒体附件。

图2是本发明实施例中的一种富文本动态消息发布客户端的结构示意图。如图2所示，该客户端200包括：附件上传单元201、回包接收单元202和发布单元203。其中：

附件上传单元201，用于将待发布的动态消息中的各多媒体附件分别打包上传到服务器。

回包接收单元202，用于接收每个多媒体附件上传成功时，服务器返回的回包，该回包中包含上传成功的该多媒体附件的服务器地址。在本发明的实施例中，回包包括上传附件的信息，比如该附件对应的服务器地址。还可以包括附件的大小、附件的缩略图地址等。

发布单元203，用于所述待发布的动态消息中的各多媒体附件的回包中的信息打包到最后一个包中上传到服务器，使得服务器根据该最后一个包中的信息生成一条富文本动态消息并发布。

图2所示的客户端，采取了将富文本动态消息中的每个附件分别上传的策略，这样能有效的将原本需要将几个附件合并在一起的较大包拆开，每个附件单独成为一个包上传，等每个附件上传成功后，再将文本信息、所有的附件的服务器地址和一些其他信息合成最后一个包上传到服务器。这样每个包都比原来的一个大包小了很多，每个包的上传成功率也会相应增加，尤其是在弱网条件下。

在本发明的一个实施例中，图2中的发布单元201，还用于在所述最后一个包中设置该待发布的动态消息的唯一标识，以避免该最后一个包被重复上传时，服务器重复生成并发布该条动态消息。该动态消息的唯一标识可以采用用户ID+时间戳。

在图2中，附件上传单元201，用于将打包后的多媒体附件按顺序放入队列中，每次从队列中取第一预设值个数的多媒体附件进行上传；如果一个多媒体附件上传失败，则将该多媒体附件放到队尾等待重新发送；如果一个多媒体附件重发次数达到第二预设值，则判定富文本动态消息发布失败。

在本发明的一个实施例中，图2中的附件上传单元201，还用于在每次上传多媒体附件前，判断当前是否连接网络，如果连接网络则立刻上传，如果没有连接网络则等收到系统发出的网络连接上的通知时再上传，如果在预设的动态发布非超时时间段内一直没有连接网络，则判定富文本动态消息发布失败。

在本发明的一个实施例中，图2中的附件上传单元201，还用于如果在上传队列中的多媒体附件的过程中，用户退出当前客户端应用，后又重启该客户端应用时，先判断是否在预设的动态发布非超时时间段内，是则继续上传队列中的多媒体附件，否则判定富文本动态消息发布失败；如果在判定富文本动态消息发布失败后，接收到用户重发该条动态消息的指令，则继续上传队列中未上传成功的多媒体附件。

图3是本发明实施例中的又一种富文本动态消息发布方法的流程图。如图3所示，该方法包括：

步骤S310，接收客户端上传的待发布的动态消息中各多媒体附件；其中，客户端是将待发布的动态消息中的各多媒体附件分别打包后上传的；

步骤S320，每成功接收一个多媒体附件，向客户端返回回包，该回包中包含成功接收的该多媒体附件的服务器地址；

步骤S330，接收客户端上传的所述待发布的动态消息的最后一个包；其中客户端是所述待发布的动态消息中的各多媒体附件的回包中的信息打包到最后一个包中后上传的；

步骤S340，根据该最后一个包中的信息生成一条富文本动态消息并发布。

在本发明的一个实施例中，图3所示的方法，在所述根据该最后一个包中的信息生成一条富文本动态消息并发布之前，进一步包括：

根据该最后一个包中的动态消息的唯一标识判断，该动态消息是否已经发布过，是则不再发布该动态消息。

图4是本发明实施例中的一种富文本动态消息发布服务器的结构图。如图4所示，该服务器400包括：

附件接收单元401，用于接收客户端上传的待发布的动态消息中各多媒体附件，每成功接收一个多媒体附件，向客户端返回回包，该回包中包含成功接收的该多媒体附件的服务器地址；其中，客户端是将待发布的动态消息中的各多媒体附件分别打包后上传的；

动态消息发布单元402，用于接收客户端上传的所述待发布的动态消息的最后一个包，根据该最后一个包中的信息生成一条富文本动态消息并发布；其中客户端是所述待发布的动态消息中的各多媒体附件的回包中的信息打包到最后一个包中后上传的。

图5是本发明实施例中的一种富文本动态消息发布系统的示意图。如图5所示，该系统包括：如图2所示的客户端200和如图4所示的服务器400。

综上所述，本发明这种将待发布的动态消息中的各多媒体附件分别打包上传到服务器，接收每个多媒体附件上传成功时，服务器返回的回包，该回包中包含上传成功的该多媒体附件的服务器地址，最后将所述待发布的动态消息中的各多媒体附件的回包中的信息打包到最后一个包上传到服务器，使得服务器根据该最后一个包中的信息生成一条富文本动态消息的技术方案，由于将一条富文本动态消息按照附件拆分成多个包分别上传，提高了弱网状态下的上传成功率，进而提高了富文本动态的发布成功率。并且本申请中还给出了针对无网状态的重发机制，进一步提高的富文本动态发布的效率。

以上所述仅为本发明的较佳实施例而已，并非用于限定本发明的保护范围。凡在本发明的精神和原则之内所作的任何修改、等同替换、改进等，均包含在本发明的保护范围内。

Claims (10)

1.一种富文本动态消息发布方法，其特征在于，所述方法包括：

将待发布的动态消息中的各多媒体附件分别打包上传到服务器；

接收每个多媒体附件上传成功时，服务器返回的回包，该回包中包含上传成功的该多媒体附件的服务器地址；

将所述待发布的动态消息中的各多媒体附件的回包中的信息打包到最后一个包中上传到服务器，使得服务器根据该最后一个包中的信息生成一条富文本动态消息并发布。

2.如权利要求1所述的方法，其特征在于，所述最后一个包还包括该待发布的动态消息的唯一标识，以使所述服务器根据该唯一标识确定该动态消息是否已经生成并发布过。

3.如权利要求1或2所述的方法，其特征在于，

所述将待发布的动态消息中的各多媒体附件分别打包上传到服务器包括：

将打包后的多媒体附件按顺序放入队列中，每次从队列中取第一预设值个数的多媒体附件进行上传；

所述将待发布的动态消息中的各多媒体附件分别打包上传到服务器之后，所述方法还包括：

如果一个多媒体附件上传失败，则将该多媒体附件放到队尾等待重新发送；如果一个多媒体附件重发次数达到第二预设值，则判定富文本动态消息发布失败。

4.如权利要求3所述的方法，其特征在于，该方法进一步包括：

每次上传前，判断当前是否连接网络，如果连接网络则立刻上传，如果没有连接网络则等收到系统发出的网络连接上的通知时再上传，如果在预设的动态发布非超时时间段内一直没有连接网络，则判定富文本动态消息发布失败；

其中，所述预设的动态发布非超时时间段，是指以开始向服务器上传该待发布的动态消息中的内容的时间点起始的预设长度的时间段。

5.如权利要求3所述的方法，其特征在于，该方法进一步包括：

如果在上传队列中的多媒体附件的过程中，用户退出当前客户端应用，后又重启该客户端应用，则先判断是否在预设的动态发布非超时时间段内，是则继续上传队列中的多媒体附件，否则判定富文本动态消息发布失败；

如果在判定富文本动态消息发布失败后，接收到用户重发该条动态消息的指令，则继续上传队列中未上传成功的多媒体附件。

6.一种富文本动态消息发布方法，其特征在于，所述方法包括：

接收客户端上传的待发布的动态消息中各多媒体附件；其中，客户端是将待发布的动态消息中的各多媒体附件分别打包后上传的；

每成功接收一个多媒体附件，向客户端返回回包，该回包中包含成功接收的该多媒体附件的服务器地址；

接收客户端上传的所述待发布的动态消息的最后一个包；其中客户端是所述待发布的动态消息中的各多媒体附件的回包中的信息打包到最后一个包中后上传的；

根据该最后一个包中的信息生成一条富文本动态消息并发布。

7.如权利要求6所述的方法，其特征在于，在所述根据该最后一个包中的信息生成一条富文本动态消息并发布之前，该方法进一步包括：

根据该最后一个包中的动态消息的唯一标识判断，该动态消息是否已经发布过，是则不再发布该动态消息。

8.一种富文本动态消息发布客户端，其特征在于，该客户端包括：

附件上传单元，用于将待发布的动态消息中的各多媒体附件分别打包上传到服务器；

回包接收单元，用于接收每个多媒体附件上传成功时，服务器返回的回包，该回包中包含上传成功的该多媒体附件的服务器地址；

发布单元，用于所述待发布的动态消息中的各多媒体附件的回包中的信息打包到最后一个包中上传到服务器，使得服务器根据该最后一个包中的信息生成一条富文本动态消息并发布。

9.一种富文本动态消息发布服务器，其特征在于，该服务器包括：

附件接收单元，用于接收客户端上传的待发布的动态消息中各多媒体附件，每成功接收一个多媒体附件，向客户端返回回包，该回包中包含成功接收的该多媒体附件的服务器地址；其中，客户端是将待发布的动态消息中的各多媒体附件分别打包后上传的；

动态消息发布单元，用于接收客户端上传的所述待发布的动态消息的最后一个包，根据该最后一个包中的信息生成一条富文本动态消息并发布；其中客户端是所述待发布的动态消息中的各多媒体附件的回包中的信息打包到最后一个包中后上传的。

10.一种富文本动态消息发布系统，其特征在于，该系统包括：如权利要求8所述的客户端和如权利要求9所述的服务器。