六星经典CSAPP-笔记(12)并发编程(上)
1.并发(Concurrency)
我们经常在不知不觉间就说到或使用并发，但从未深入思考并发。我们经常能“遇见”并发，因为并发不仅仅是操作系统内核的“绝招”，它也是应用开发中必不可少的技巧：
访问慢I/O设备：就像当应用程序等待I/O中的数据时内核会切换运行其他进程一样，我们的应用也可以用类似的方式，将I/O请求与其他工作重叠从而挖掘并发的潜能。
推迟工作而减少延迟：我们可以推迟一些耗时工作稍后执行，例如内存分配器不在free时整理碎片，而是将这些琐屑的工作推迟到一个稍后执行的独立“逻辑流”(logical flow)中。
服务多个网络客户端：如果没有并发，一个慢客户端将会阻塞整个Web服务器，这是不现实的！所以我们需要为每个客户端都创建独立的逻辑流，避免某个客户端独占整个服务器。
多核上并行计算：将程序切分成多个逻辑流并发执行，在多核环境中可能被分配到不同的核心上执行，从而实现了并行。
现代操作系统提供三种基本方法构建上述这些并发程序：
进程(Process)：进程由操作系统维护和调度，每个进程都有独立的虚拟地址空间，进程间交互要靠IPC机制。
I/O多路复用(I/O multiplexing)：在进程的上下文中，应用程序“显式地”调度自己的逻辑流。逻辑流被构建为状态机，当文件描述符上有数据到达时，main程序显式地将它从一种状态转移到另一种状态。
线程(Thread)：线程运行在进程的上下文中，由操作系统调度。可以将线程看做是进程和I/O多路复用技术的混合，它既像进程一样被操作系统调度，又能像I/O多路复用一样共享虚拟地址空间。
2.基于进程的并发
构建并发程序的最简单方式就是使用进程。每接收到一个连接，父进程都会fork出一个子进程。因为子进程拷贝了父进程的文件描述符表，所以使用进程构建并发时一定要避免资源泄露，尤其是父进程。子进程一定要关闭监听描述符listenfd，这个描述符在子进程中是没有任何用处的。而同样的，父进程要负责关闭连接描述符connfd，同理，这个描述符在父进程中也是一点用处都没有。
2.1 示例程序
下面是一个使用进程构建并发Web服务器的小例子，用telnet localhost 7777连接上后能看到服务端发送过来的”helloworld”欢迎语。
#include &stdio.h&
#include &stdlib.h&
#include &string.h&
#include &errno.h&
#include &netinet/in.h&
#include &arpa/inet.h&
#include &netdb.h&
#include &sys/types.h&
#include &sys/socket.h&
#include &unistd.h&
#include &signal.h&
#include &sys/wait.h&
void sigchld_handler(int sig);
int open_serverfd(int port);
int main(int argc, char const *argv[])
int listenfd,
socklen_t clientlen = sizeof(struct sockaddr_in);
struct sockaddr_
signal(SIGCHLD, sigchld_handler);
listenfd = open_serverfd(7777);
printf("Main: start...\n");
while(1) {
connfd = accept(listenfd, (struct sockaddr *)&clientaddr, &clientlen);
printf("Main: accept client %s\n", inet_ntoa(clientaddr.sin_addr));
if (fork() == 0) {
close(listenfd);
char buf[11] = "helloworld";
write(connfd, buf, strlen(buf));
close(connfd);
close(connfd);
void sigchld_handler(int sig)
while(waitpid(-1, 0, WNOHANG) & 0)
int open_serverfd(int port)
int listenfd, optval = 1;
struct sockaddr_
memset(&sockaddr, 0, sizeof(sockaddr));
sockaddr.sin_family = AF_INET;
sockaddr.sin_addr.s_addr = htonl(INADDR_ANY);
sockaddr.sin_port = htons(port);
if ((listenfd = socket(AF_INET, SOCK_STREAM, 0)) & 0) {
fprintf(stderr, "Error: %s\n", strerror(errno));
return -1;
if (setsockopt(listenfd, SOL_SOCKET, SO_REUSEADDR,
&optval, sizeof(int)) & 0) {
fprintf(stderr, "Error: %s\n", strerror(errno));
return -2;
if (bind(listenfd, (struct sockaddr *)&sockaddr, sizeof(sockaddr)) & 0) {
fprintf(stderr, "Error: %s\n", strerror(errno));
return -3;
if (listen(listenfd, 10) & 0) {
fprintf(stderr, "Error: %s\n", strerror(errno));
return -4;
2.2 Pros & Cons
基于进程的并发的优点就是模型清晰，子进程的虚拟地址空间独立，不会互相干扰。但这也是它的缺点，如果要共享数据则必须使用IPC(interprocess communication，广义上讲Socket、信号、waitpid()都算，但一般IPC指pipe管道、FIFO队列、System V共享内存、信号量等)机制。此外，由于进程控制和IPC的开销都很高，所以基于进程的方式可能会很慢。
SIGCHLD信号
如果父进程不等待子进程结束，子进程将成为僵尸进程(zombie process)从而占用系统资源，因此上面的例子中我们注册了SIGCHLD信号的处理函数。
“The SIGCHLD signal is sent to the parent of a child process when it exits, is interrupted, or resumes after being interrupted. By default the signal is simply ignored.” - Wikipedia
这里有一个小技巧。如果父进程等待子进程结束，将增加父进程的负担，影响服务器进程的并发性能。Web服务器为了保证高性能，一般会将此信号的处理方式设为忽略，让内核把僵尸子进程转交给init进程去处理。忽略设置方式为：signal(SIGCHLD,SIG_IGN);
3.基于I/O多路复用的并发
现在对我们的Web服务器进行升级，让它不仅能够处理远程客户端的连接请求，写回helloworld欢迎语。同时它还能响应当前命令行中的用户输入。那么，我们应该先等待哪种事件？实际上先等待谁都不是最理想的，因为阻塞地等待一个必然导致无法响应另一个。解决这种困境的技术就是I/O多路复用。
3.1 select()
我们用select()函数请求内核挂起当前进程，只有当我们关心的I/O事件发生时再将控制返回给我们的应用程序。下面就是select()函数的原型及操作描述符集合的宏。我们主要关注的就是select()的前两个参数：基数n(cardinality，集合中最大描述符的值加1)和描述符集合(fdset or read set)。
#include &unistd.h&
#include &sys/types.h&
int select(int n, fd_set *fdset, NULL, NULL, NULL);
FD_ZERO(fd_set *fdset);
FD_CLR(int fd, fd_set *fdset);
FD_SET(int fd, fd_set *fdset);
FD_ISSET(int fd, fd_set *fdset);
select()函数实际很复杂。下面先看一段代码，结合实际代码来理解select()和I/O多路复用是如何使用的。
3.2 示例程序
下面就是升级后的服务端代码，利用I/O多路复用，我们既能响应远程客户端请求，又能响应命令行输入。注意两点：一是使用I/O多路复用后，我们不再直接调用accept()函数，而是阻塞在select()函数的调用上。二是select()返回后我们要用if逐一判断各个描述符，因为可能有多个描述符的事件发生了，所以不能用if-else做判断。
#include &stdio.h&
#include &stdlib.h&
#include &string.h&
#include &errno.h&
#include &netinet/in.h&
#include &arpa/inet.h&
#include &netdb.h&
#include &sys/types.h&
#include &sys/socket.h&
#include &unistd.h&
#include &signal.h&
#include &sys/wait.h&
#include &sys/select.h&
int open_serverfd(int port);
int main(int argc, char const *argv[])
int listenfd,
socklen_t clientlen = sizeof(struct sockaddr_in);
struct sockaddr_
fd_set readset,
listenfd = open_serverfd(7777);
printf("Main: start...\n");
FD_ZERO(&readyset);
FD_SET(STDIN_FILENO, &readset);
FD_SET(listenfd, &readset);
while(1) {
readyset =
select(listenfd+1, &readyset, NULL, NULL, NULL);
if (FD_ISSET(STDIN_FILENO, &readyset)) {
char buf[100];
if (!fgets(buf, 100, stdin))
if (!strncmp(buf, "quit", 4))
printf("%s\n", buf);
if (FD_ISSET(listenfd, &readyset)) {
connfd = accept(listenfd, (struct sockaddr *)&clientaddr, &clientlen);
printf("Main: accept client %s\n", inet_ntoa(clientaddr.sin_addr));
char buf[11] = "helloworld";
write(connfd, buf, strlen(buf));
close(connfd);
int open_serverfd(int port)
int listenfd, optval = 1;
struct sockaddr_
memset(&sockaddr, 0, sizeof(sockaddr));
sockaddr.sin_family = AF_INET;
sockaddr.sin_addr.s_addr = htonl(INADDR_ANY);
sockaddr.sin_port = htons(port);
if ((listenfd = socket(AF_INET, SOCK_STREAM, 0)) & 0) {
fprintf(stderr, "Error: %s\n", strerror(errno));
return -1;
if (setsockopt(listenfd, SOL_SOCKET, SO_REUSEADDR,
&optval, sizeof(int)) & 0) {
fprintf(stderr, "Error: %s\n", strerror(errno));
return -2;
if (bind(listenfd, (struct sockaddr *)&sockaddr, sizeof(sockaddr)) & 0) {
fprintf(stderr, "Error: %s\n", strerror(errno));
return -3;
if (listen(listenfd, 10) & 0) {
fprintf(stderr, "Error: %s\n", strerror(errno));
return -4;
FD_ZERO()清空readset：
FD_SET()设置readset：
假设控制台有输入，则select()“苏醒”并返回readset：
此时我们用FD_ISSET()就能检测到stdin已准备好读。
一切看起来都很完美，但仔细看一下select()的循环就会发现问题。如果远程客户端发送连接请求，select()返回进入客户端处理逻辑。因为这段逻辑是同步执行的，所以 在select()函数返回到处理完客户端请求的这段时间内，我们没有再次调用select()，因此这段时间内我们是无法响应的。
3.3 更好的并发
解决上面问题的方法就是在更细的粒度上多路复用I/O。基本思想是：将I/O多路复用作为事件驱动程序的基础框架，将程序的整个执行流程划分为不同的事件，在多路复用机制上构建起状态机。我们通常用有向图代表状态机，用结点代表状态，用有向弧代表状态的迁移，用弧上标签文字代表促使迁移的输入事件。每个输入事件都触发了从当前状态到下一状态的迁移。
以下面例子为例，当接收到新客户端连接时，为其创建一个状态机，并关联到已连接的描述符connfd上。当connfd准备好读写时，我们写回欢迎语，完成状态的转换。所以与前面第一版的例子有些区别，当我们用telnet连接上时，要敲入一个字符才能看到欢迎语。
#include &stdio.h&
#include &stdlib.h&
#include &string.h&
#include &errno.h&
#include &netinet/in.h&
#include &arpa/inet.h&
#include &netdb.h&
#include &sys/types.h&
#include &sys/socket.h&
#include &unistd.h&
#include &signal.h&
#include &sys/wait.h&
#include &sys/select.h&
typedef struct {
clientfd[FD_SETSIZE];
void init_pool(int listenfd, pool *p);
void add_client(int connfd, pool *p);
void check_clients(pool *p);
int open_serverfd(int port);
int main(int argc, char const *argv[])
int listenfd,
socklen_t clientlen = sizeof(struct sockaddr_in);
struct sockaddr_
listenfd = open_serverfd(7777);
init_pool(listenfd, &pool);
printf("Main: start...\n");
while(1) {
pool.readyset = pool.
pool.nready = select(pool.maxfd+1, &pool.readyset, NULL, NULL, NULL);
if (FD_ISSET(listenfd, &pool.readyset)) {
connfd = accept(listenfd, (struct sockaddr *)&clientaddr, &clientlen);
add_client(connfd, &pool);
check_clients(&pool);
void init_pool(int listenfd, pool *p)
p-&maxi = -1;
for (i = 0; i & FD_SETSIZE; ++i)
p-&clientfd[i] = -1;
p-&maxfd =
FD_ZERO(&p-&readset);
FD_SET(listenfd, &p-&readset);
void add_client(int connfd, pool *p)
p-&nready--;
for (i = 0; i & FD_SETSIZE; ++i) {
if (p-&clientfd[i] & 0) {
p-&clientfd[i] =
FD_SET(connfd, &p-&readset);
if (connfd & p-&maxfd)
p-&maxfd =
if (i & p-&maxi)
void check_clients(pool *p)
for (i = 0; i &= p-&maxi && p-&nready & 0; ++i) {
connfd = p-&clientfd[i];
if (connfd & 0 && FD_ISSET(connfd, &p-&readyset)) {
p-&nready--;
char buf[11] = "helloworld";
write(connfd, buf, strlen(buf));
close(connfd);
FD_CLR(connfd, &p-&readset);
p-&clientfd[i] = -1;
int open_serverfd(int port) { ... }
3.4 高级知识
下面扩展一下知识面，围绕I/O多路复用，介绍一些周边的、但很重要的知识。主要参考资料有：
3.5.1 select vs. poll vs. epoll
select最早出现于1983年的BSD 4.2中。其优点是跨平台性比较好，几乎所有平台都支持它。而其缺点是：select轮询（线性扫描）所有Socket描述符，检查是否有事件发生。当描述符很多时，select的耗时也会增加。因此select能够监视的描述符数目是有上限的，上限就是FD_SETSIZE常量。此外，select每次都会在内核态和用户态之间复制整个描述符数组，而不管这里面是只有一个还是几个描述符有事件发生。
poll诞生于System V 3，它与select没有本质上区别，只不过poll没有描述符最大数量的限制。
Linux 2.6后提供了更加高效的epoll机制，被公认为目前性能最好的多路I/O就绪通知方法。它有两项本质上的改进：
epoll采用基于事件的就绪通知方式。在select/poll中，进程只有在调用select()和poll()后，内核才对所有监视的文件描述符进行扫描。而epoll事先通过epoll_ctl()注册一个文件描述符，一旦基于某个文件描述符就绪时，内核会采用类似callback的回调机制，迅速激活这个文件描述符，当进程调用epoll_wait()时便得到通知。
epoll采用内存映射避免复制开销。当我们调用epoll_wait()获得就绪文件描述符时，返回的不是实际的描述符，而是一个代表就绪描述符数量的值。你只需要去epoll指定的一个数组中依次取得相应数量的文件描述符即可。这里也使用了内存映射(mmap)技术，这样便彻底省掉了这些文件描述符在系统调用时复制的开销。
kqueue是BSD系统中的事件通知机制，不在这里讨论了。”Kqueue is a scalable event notification interface introduced in FreeBSD 4.1”.
3.5.2 水平触发和边际触发
我们知道，select()和poll()函数会将准备就绪的文件描述符通知给进程，如果进程没有对其进行处理（I/O操作），那么下次调用select()和poll()时将再次报告这些文件描述符。所以select和poll机制一般不会丢失就绪的描述符消息，这种方式称为 水平触发(Level Triggered)。
epoll可以同时支持水平触发和边际触发，所谓 边际触发(Edge Triggered)是指：只告诉进程哪些文件描述符刚刚变为就绪状态，并且只说一遍，如果我们没有采取行动，那么它将不会再次告知。理论上边缘触发的性能要更高一些，但是代码实现起来要非常小心。
3.5.3 Proactor和Reactor模式
3.5.4 事件通知库
目前比较流行的事件通知库有libevent、libev、libuv：
独立于操作系统平台，它支持poll，kqueue，POSIX/Windows select，epoll机制。它采用Reactor模型，将这些内部机制完全隐藏在它暴露的API之后。libevent被广泛应用于很多程序，如Chromium、Memcached、Transmision、Vomit等等。
与libevent类似，但开销更低。
是node.js作者做的一个封装库。
像Nginx、Redis等高性能中间件，出于简洁、性能、以及作者的“代码洁癖”方面的考虑，没有使用libevent等第三方事件通知库，而是自己动手实现了类似的简化版。
3.5 Pros & Cons
因为没有上下文切换，所以基于I/O多路复用的并发要比基于进程的高效得多。而且因为是单线程执行的，所以调试起来也很方便，直接用GDB等工具就能调错。
I/O多路复用的确很好很高效，但它不是没有缺点：
I/O多路复用的最大缺点就是编码复杂度。而且多路复用的粒度越低，编码的复杂度越高。因为粒度越低说明我们将主流程拆分出更多的事件，使得代码流程变得支离破碎。
第二个缺点就是某一事件处理的阻塞或长时间运行将会导致整个流程都无法响应其他事件，因为整个程序都是单线程运行的。例如上面的例子，如果我们花很多时间读取某个客户端故意发送来的大量数据的话，整个Web服务器将停在那里。
最后一个缺点就是无法充分利用多核处理器的优势，这一缺点也是显而易见的。
版权声明：本文为博主原创文章，未经博主允许不得转载。
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：682289次
积分：9960
积分：9960
排名：第687名
原创：255篇
转载：55篇
评论：662条
文章：18篇
阅读：28160
(4)(7)(9)(3)(15)(4)(12)(11)(12)(3)(1)(3)(1)(2)(1)(9)(8)(12)(2)(7)(7)(13)(7)(20)(4)(11)(3)(4)(6)(19)(3)(4)(5)(9)(9)(13)(5)(26)(20)我们公司设计的稿,cdr文件版权是属于客户的吗？客户要求我发原文件（CDR）给他，可是我们老板说公司规定，_百度知道
我们公司设计的稿,cdr文件版权是属于客户的吗？客户要求我发原文件（CDR）给他，可是我们老板说公司规定，
主要是看客户跟你们的合作时是怎么谈的1.如果客户当时是拿1000给你，要求做一个LOGO给他那当然是要原文件给他了，2.就是印刷类的开版费，如果客户付了钱的，他有权让你发原文件给他3.如果客户是说，要类似于这种图片，而你也是发了图片给他，达成协议，那就不用给他总体而言，就是客户有给开版费用，那这个版就是他所有！
其他类似问题
为您推荐：
提问者采纳
只能跟他说有公司规定可以明说。修改定稿必要时，最多是给预览图JPG格式的。如果客户硬是要求要原文件，而且专门为设计图稿出了钱，原文件不能给。除非客户设计时有说明，为的就是能有以后的合作，请他跟老板谈。我们通常是不会给客户原文件的，图稿是我们设计的
提问者评价
我也是这样处理的，可是，老板说你又事情推到我头上来，他只能给客户了。他也不想给的。
其他2条回答
是要公司法定代表也就是你老板决策的这是个敏感问题，这关系到客户和老板的利益。不是我们操心的，你就应该说制作文件和设计文件不是由你说了算的，我们是给老板打工的，但老板要不要给客户源文件是老板的问题
给！！！你们是设计公司对吧！客户给了钱叫你设计就是要你的东西要不然怎么会给你设计呢，再说了，你不给人家文件，人家怎么拿印刷？？拿图片去印刷？还非到你那印刷吗？？？
您可能关注的推广
cdr的相关知识
等待您来回答
下载知道APP
随时随地咨询
出门在外也不愁5607人阅读
早在2007年的时候，我曾写过一篇名为“”（YouTube：关于版权的弥天大谎）的文章，表达了我对YouTube又爱又恨的情感纠结：
现在回想一下你在YouTube上看过的所有视频。它们当中有多少包含原始内容？
那可能是“认知失调”的极端情况：根据YouTube自己定下的规则——禁止传播受版权保护的内容——YouTube根本无法生存。然而，YouTube现在还活得好好的！
认知失调（Cognitive Dissonance）又名认知不和谐，指的是一个人的行为与自己先前一贯的对自我的认知（而且通常是正面的、积极的自我）产生分歧，从一个认知推断出另一个对立的认知时而产生的不舒适感、不愉快的情绪。——译者注
YouTube网站上90%的内容都是有版权的，而且很显然在这些内容的使用上并没有得到授权——基于这个现实，我们该怎样去理解YouTube在版权保护方面的官方立场呢？看起来，YouTube在奉行“不问，不说”的宽容政策——他们不会费劲去检验用户上传的内容是原始内容或者是合理使用（Fair
Use）。受版权保护的内容会一直留存在YouTube上，除非内容所有人投诉，到那时，也只有到那时候，那些内容才会从YouTube被删除。
“不问，不说”（Don’t ask, don’t tell）原本是美国针对在军队里服役的同性恋者的一项政策，该政策禁止在军队里区分或骚扰保持秘密关系的同性恋或双性恋的服役人员，从而把公开关系的同性恋者排除在军队之外，因为同性恋被认为会伤害军队的士气、纪律和凝聚力。这项政策于2011年被废止。——译者注
今天要讲的是，请谨慎行事！
在以前，我一直认为YouTube不可能通过技术手段来解决这个问题。若是将用户上传的每一个视频都抽取出某种指纹信息，然后再与所有的版权内容一一比对，这种做法在我看来是相当可笑的，简直是不可能完成的任务。
就在几天前，我往YouTube上传了电影《Better Off Dead》（再见人生）中的一小段视频，为的只是在“一路向前冲”这篇博文中引用一下。这是典型的“合理使用”——从电影里摘录出来一小段，放在一篇博客文章中进行相关的论述。到目前为止，一切都还好。
随后，我又上传了另外一部电影中的一小段视频，打算在将来的一篇博文中使用。然而，在上传之后的一小时内，我收到了这样一封邮件，大致意思为：
亲爱的某某用户，
您的某某视频可能含有某某公司所属的内容。
您无需采取任何措施。然而，如果您有兴趣了解这会对您的视频产生什么影响，请访问您的账号信息里的“内容标识匹配”部分。
YouTube团队
这段时长90秒钟的小视频摘自最近的一部电影。请注意，其实这也并不是什么很热门的电影，但也许你听说过它的名字。那封邮件让我心醉神迷，同时也带给我些许恐惧：他们是怎么做到的？那段视频是我（使用Windows Movie Maker软件）从一部小制作电影里随机裁剪出来的，他们竟然能在我上传后的一小时内发现了……他们必定有一套自动化系统，能够将用户上传的内容与所有版权内容（或者是最流行的一部分内容）作比对——这也正是我之前认为的“不可能完成的任务”。
哦，哦……我开始研究这事。我很快发现了“Fun with YouTube's Audio Content ID System”（有趣的YouTube音频内容标识系统）这篇文章。虽然它没有提到视频，但这事肯定是相关的：
有一天，我很意外地收到YouTube自动发来的一封邮件，声称我的视频有音乐版权问题，因此从网站上删除了。但我之前没有意识到会有这样的问题。
于是，我制作的那个汽车广告（做得相当不错哦）因为使用了一首未经授权的歌曲而被“拿下”了。真是气死我了！为了剔除那首歌，我得回过头去重新编辑视频，这可不是件容易事，因为源盘已经不知塞到哪个鞋盒里去了。编辑完之后，我还不能只是简单地重新上传，因为这个视频已经被标记过了，每次上传都会被“拿下”。我必须想个办法摆平指纹识别系统。当时我很气愤，但又无计可施。
我挖空心思，尝试了每一种可能通过指纹识别系统的音频处理方法。我想出了一个几乎很科学的方法来测试每一次修改，最后总算搞定了。
我做了更进一步的研究，然后发现了这个简短的：“HowYouTube thinks about
copyright”（YouTube如何看待版权问题）。
我们将用户上传的每一个视频跟我们数据库里的所有参考文件进行对比。下面的热图展示了我们的核心系统是如何工作的。
我们看到，一个参考文件正被用于与用户生成的内容进行比对。系统会把一个文件的每个时间点跟另一个文件比较，以发现两者之间存在的匹配。这也意味着，即使用户只是从原始文件里抽取了一部分，或者以慢动作播放，甚至损失了音频或视频的质量，我们照样能匹配出来。
这个系统的规模和执行速度是很惊人的——我们可不是只需处理几个视频，而是每天要处理大约100多年时长的新上传视频；除此之外，我们还会定期地对网站上留存的所有视频进行全面的扫描。在比较那些100年长度的视频时，我们实际上是在将它们与数据库里的几百万个参考文件作比较。就像每天有36000个人紧紧盯着36000个显示器一样，没有一丝一毫的停歇。
不得不承认，我被YouTube这套新的版权检测系统震惊了，它的范畴、规模以及效力都深深打动了我——而这些，我以前认为是不可能做到的！我强烈建议大家看看上面提到的那个TED演讲。它并不长。我对YouTube的视频识别工具研究得越多，我就越觉得：抵抗是徒劳的。这个系统是如此之棒，以致于你如果想要通过它，唯一的办法就是大大地牺牲你的音视频内容的质量，但这样的话，你的内容也就毁了。至于版权保护，如果你能准确地摧毁侵权内容，你也就胜利了。没什么讨价还价的，这是绝对的胜利！
这就是我至今都不敢相信的研究结果。但我上传的视频被自动禁掉这件事就是很好的证明。
声明一下，我绝对不是建议大家突破或绕开版权保护。我只是习惯了YouTube以前的“放任”政策，现在突然来了一个这么有效的视频版权检测系统，难免有些不适应。我须向做出这套系统的谷歌工程师们致敬！他们不是纯粹的捣蛋鬼；他们在发现有版权匹配的时候，也会提供一些相当体贴的应对方案：
如果在用户上传的内容和参考库里的资料之间发现有匹配，由版权所有人指定的“使用政策”就会生效。这个“使用政策”会告诉系统如何处置用户的视频。所谓“匹配”，可能只发生在用户所上传文件的音频部分，或者只是视频部分，或者两者兼有。
目前有3种“使用政策”，分别是“禁止”、“跟踪”和“货币化”。如果版权所有人指定了“禁止”政策，用户上传的视频在YouTube网站上就不会被别人看到。如果版权所有人指定了“跟踪”政策，用户上传的视频会出现在YouTube上，但版权所有人会收到关于这个视频的统计信息，比如这个视频被看了多少次。如果是“货币化”政策，用户上传的视频也会出现在YouTube上，只不过视频播放时会插入广告。这些政策是可以根据地理区域设定的，因此版权所有人可以控制某些内容在一个国家可见，而让其他国家的用户看不到。
至于我上传的那个视频，它的版权所有人恰好选择了苛刻的“禁止”政策。这当然不是谷歌的问题，只能说我的运气不好！
尽管我上传的那个时长90秒钟的视频是受版权保护的——我不想为此争辩——但我的初衷绝不是为了促进非法使用，而只是想在一篇博客中就电影的某个场景加以“引用”。YouTube确实给用户提供了申诉渠道；一旦你的内容被认定是受版权保护的，提出申诉也是很容易的。因此我老老实实地填写了申诉表，说明我有理由相信自己是在“合理使用”。
遗憾的是，我的申诉被版权所有人否决了，而且没有得到任何解释。
让我们回顾一下我在2007年的那篇博文中提出的关于“合理使用”的4条指导原则吧：
你的使用有变革性吗？ 原始内容符合公众利益吗？ 你抽取了多少内容？ 对市场有什么影响？
尽管我们在第3点和第4点上没有问题，但在前两点上有些说不清。我做的事情肯定是有变革性的，因为我情愿认为，我是为了自己和别人的学识而写作的，并不只是娱乐大众。我上传视频的目的，是让它可以在我的博客网站上播放，而YouTube只是为我存储内容之用。然而，这段90秒钟的电影确实可以被YouTube上的任何人看到，但在那里没有任何上下文说明。
结果，我只能心碎了……
一方面，这是一个令人印象深刻的技术创举。YouTube可以真正地对用户上传视频的每一分钟进行检验，把它跟所有主流的版权内容进行分分秒秒的比对，这种做法对于我来说是高深莫测的。当YouTube对版权所有人承诺这些措施时，我曾经认为他们只是在拖延时间。但是从我遭遇的沮丧来看，他们实际上说到做到了，而且还干得挺漂亮！
也许，YouTube做得有点过头了。我想要那种能够保护“合理使用”的视频分享服务；如今的我，依然在寻寻觅觅……
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：752625次
积分：10610
积分：10610
排名：第602名
原创：43篇
译文：103篇
评论：1423条
(1)(2)(1)(3)(2)(4)(3)(2)(3)(3)(4)(2)(9)(16)(12)(16)(4)(1)(5)(5)(2)(4)(6)(8)(2)(4)(7)(1)(1)(2)(2)(1)(2)(1)(2)(1)(2)(1)(1)(1)(1)(2)(1)(3)(1)(1)(3)(1)(1)(1)(4)