音乐发行元数据：艺人名、曲目标题、参与艺人、版本标注，以及怎样写才能完好通过分发链路

先给结论

元数据不是附在音乐旁边的表格，对下游的每一个系统来说，它就是音乐本身——平台永远听不到你的录音，它只读你的报送。对中文目录而言，最贵的一类错误不是拼错字，而是同一个艺人以简体和繁体两串不同的字节存在：简繁不是字形皮肤，是不同码位，机器把它们当成两个人。更麻烦的是简繁映射不是一对一，多个繁体字塌缩到同一个简体字（我用 OpenCC 实测：髮 和 發 都变成 发，後 和 后 都变成 后，鐘 和 鍾 都变成 钟），所以一段名字经过一次"简→繁"的机器还原就可能永久改错——余华 被转成 餘華，姓氏被换掉了。正确的做法是：选定一种字形作为报送主字形，把另一种写进本地化/别名字段，艺人名永远不过转换器。除此之外，中文报送还有三个几乎没人讲的坑：CJK 兼容汉字（U+F900–U+FAFF）造成的隐形重复字符串、拼音罗马化（带调号与不带调号、姓名顺序）造成的分页，以及标题里的全角标点与书名号《》在各家规则下的处理差异。作曲作词字段则是另一条独立的钱路：把一个有名有姓的作曲家填成"传统"或"民歌"，是国风与戏曲改编最常见、也最安静的损失。

为什么中文元数据的错误几乎无法事后修复

发行前十分钟改一个字段，成本是零。发行后再改，成本是不可控的。原因是分发链路是拷贝式的：你的报送通过 DDEX 的 ERN（Electronic Release Notification Message Suite，电子发行通知报文族）送到发行商，发行商送到各家平台，平台入库、建索引、生成艺人页、进榜单、进推荐池，然后第三方数据商、歌词库、社交平台的音乐卡片、车机系统再从平台抓一遍。等你发现名字错了，这一串系统里已经各存了一份。

改动不是"编辑"，而是"申诉"：你的发行商要向每一家平台提交合并请求，每家平台各自排队、各自要证据、各自决定要不要做。各家平台把两个艺人页合并的门槛、以及判断一次报送该并入已有艺人还是新建艺人的匹配逻辑，都没有任何平台公开发布过——业内广泛流传各种说法，但那属于"广泛流传、平台未公开发布"，本文不据此下任何结论。

这就是为什么中文报送要按"一次写对，永不重打"的方式来做。下面所有的规则，本质上都是这一条的展开。

1. 三个层：发行、录音、作品

绝大多数昂贵的元数据错误，是把一个事实填在了错误的层。中文报送尤其容易犯，因为国内很多工单表格把三层压成一张表。

• 发行（Release / 专辑、EP、单曲） 是商品。标识符是 UPC/EAN。
• 录音（Recording / 母带上那一条音轨） 是声音。标识符是 ISRC。
• 作品（Work / 词曲本身） 是版权。标识符是 ISWC，钱从这里走词曲那一侧。

一首《起风了》的翻唱：作品是原词曲作者的，录音是你的，发行是你这张 EP 的。三个层三套权利，三笔钱。

标识符的精确形状。 ISRC 是 12 个字符：2 位国家码 + 3 位登记者码 + 2 位年份参考码 + 5 位记录码。中间的连字符只是显示习惯，不是编码的一部分；ISRC 没有校验位。UPC-A 是 12 位数字，EAN-13 是 13 位；UPC-A 前面补一个 0 就成为 EAN-13，而且校验位不变。校验位算法：从右往左，在校验位之前的各位上交替乘 3 和乘 1，求和，校验位取使总和达到下一个 10 的倍数的那个数。

什么时候要新的 ISRC。 混音版、剪辑版、现场版、伴奏版——只要是实质上不同的录音，都要新的 ISRC；同一条录音换发行商、再上架，不需要新码，ISRC 跟着录音走。"重制版一定要新码"是流传很广的错误说法。 IFPI 的《ISRC Handbook》§A.10.1 写得很窄："A new ISRC shall be assigned if (and only if) the processes applied to a recording during re-mastering involve the application of creative input to the recording itself."（当且仅当重制过程中对录音本身施加了创造性投入时，才应分配新的 ISRC。）该文件明确把下列情形排除在外：单纯的电平调整、不变的 EQ、不变的压缩、降噪、去咔嗒声、速度/音高校正、采样率转换和抖动处理——"A new ISRC shall not be assigned in the context of essentially invariant or technological adjustment processes."（在本质上不变的或纯技术性的调整过程中，不应分配新的 ISRC。）安全的实务补充：如果重制版是作为独立曲目与原版并列售卖的，它就是独立商品，需要自己的码。

如果你说不出一个事实属于哪一层，你就还不能填它。

2. 简体与繁体：中文目录的核心缺陷

这是中文报送里独一无二的问题，其他任何语种都没有对应物。它不是"翻译问题"，也不是"显示问题"，是同一个人合法地拥有两串不同的字节。

2.1 一个人，两串字节

陳綺貞 和 陈绮贞 是同一位艺人。对任何匹配、排序、去重、搜索系统来说，它们是两个完全不相干的字符串——共同字符为零。台湾、香港的商店索引繁体，中国大陆的商店索引简体，同一张专辑在两边可能落在两个艺人页上。

这和罗马字转写不一样。罗马字转写是"第二个名字"，大家至少知道它是另一种写法；简繁是"同一个名字的两种正字法"，报送的人往往根本不觉得自己换了字符。于是发行 A 用简体报，发行 B 因为送台湾发行方而用繁体报，第三张又混着报——一个艺人变成两个或三个，粉丝数不跟着走，第二个身份的算法历史从零开始。

2.2 映射不是一对一——我实际验证的结果

很多人以为"反正有转换器，转一下就行"。这个假设在繁→简方向大体成立，在简→繁方向是错的，而这正是名字被永久改坏的地方。

我用 OpenCC（opencc-python-reimplemented 0.1.7）在本地实测，用它的 t2s（繁→简）配置逐字转换，以下每一对两个不同的繁体字都塌缩到同一个简体字：

信息在这一步就丢了。反向转换只能靠词典猜。我用同一个库的 s2t（简→繁）实测了几个短字符串——短字符串正是艺人名的形状，因为它没有句子上下文可供词典判断：

'余华'  --s2t-->  '餘華'      姓氏"余"被改成了"餘"
'干'    --s2t-->  '幹'
'钟'    --s2t-->  '鍾'
'云'    --s2t-->  '雲'
'后'    --s2t-->  '後'
'发'    --s2t-->  '發'
'丑'    --s2t-->  '醜'
'征'    --s2t-->  '徵'

余华（一个真实存在、姓余的名字）被转成 餘華，姓氏没了。这不是 OpenCC 写得不好——这个信息在简体里客观上不存在，任何转换器都只能赌。有上下文时它赌得相当准（余生乐队 → 餘生樂隊 是对的，小云 → 小云 也是对的，因为词典认得），但一个两三个字的艺名恰好是它最没有把握的输入。

往返一次就可能改字。 同一个库，繁→简→繁：

'拉麵' -> '拉面' -> '拉麪'      麵 变成了异体字 麪
'麵條' -> '面条' -> '麪條'
'裡面' -> '里面' -> '裏面'      裡 变成了 裏

字形对了，码位换了。对搜索和匹配来说，拉麵 和 拉麪 是两个词。

还有一层：同一个库的不同配置给出不同答案。 简体 里 用 s2t 转出 裏，用 s2tw（面向台湾正字）转出 裡。两者都"对"，但它们是两个码位。也就是说，你的发行商用哪个配置、哪个词库版本，会决定你艺人名的繁体形态——而你无法控制、通常也不会被告知。

2.3 纪律

结论只有一条：艺人名永远不过转换器。

具体做法：

1. 选定一种字形作为报送主字形。 判断依据是艺人现有的公开足迹——社交账号名、上一张专辑封面、官方网站——而不是发行方向。已经存在的写法比"语言上更正确"的写法重要。
2. 把另一种字形人工写定一次，存进主表。 由懂这个名字的人写，不是由脚本写。姓氏、地名、双关、艺名里刻意用的异体字，都只有人知道。
3. 把它填进本地化/别名字段，而不是新开一个艺人。 苹果的《Apple Music Style Guide》12.1 明确要求这件事，原文是：

"Chinese content must always have the Traditional and Simplified Chinese name of the artist listed: one in the native field, and the other one in the localization field." （中文内容必须始终同时列出艺人的繁体与简体中文名：一个放在原生字段，另一个放在本地化字段。）

同一份文件 12.3 把这条扩展到全部元数据：

"Chinese language content must be submitted with both Traditional Chinese and Simplified Chinese metadata, with one language being used in the primary language field and the other in the localization field." （中文语言的内容必须同时以繁体中文和简体中文元数据报送，其中一种用于主语言字段，另一种用于本地化字段。）

注意苹果这里说的是 must，而且要求的是"两种都给"，不是"选一种"。如果你的发行商暴露了本地化字段，请填满它；如果没有暴露，就选定主字形并且此后永不更改。

1. 专辑名和曲目名与艺人名分开决策。 艺人名是键，必须冻结；标题是内容，可以在两个本地化版本里各自正确书写。把两者混在一个"简繁一键切换"的批处理里，是事故的常见起点。
2. 别名不是备注。 "顺便在简介里写一下繁体名"没有任何机器可读的效果。它必须进结构化字段。

3. CJK 兼容汉字（U+F900–U+FAFF）：几乎没人写过的重复字符串来源

这一节讲的问题，在中文发行里真实存在，但几乎没有中文资料提过。

3.1 它是什么

Unicode 在统一汉字区（CJK Unified Ideographs）之外，还有一个 CJK 兼容汉字区 U+F900–U+FAFF。它的存在理由是往返兼容：为了让韩国、日本、台湾的旧有字符集能无损地转成 Unicode 再转回去，Unicode 给一批字形与统一汉字完全相同的字另开了码位。绝大多数来自 KS X 1001（韩文标准）里同一个汉字有多个读音而重复收录的条目，还有一批来自日本的 JIS 补充集。

也就是说：屏幕上一模一样的字，内存里可能是两个不同的码位、不同的字节长度、不同的比较结果。

3.2 NFC / NFKC 对它做什么——实测

我用 Python 的 unicodedata（UCD 14.0.0）把整个 U+F900–U+FAFF 区扫了一遍，结果如下，供你直接引用：

• 该区已分配 472 个字符。
• 其中 460 个具有规范单例分解（canonical singleton decomposition），也就是说 NFC、NFD、NFKC、NFKD 四种规范化形式都会把它们替换成对应的统一汉字。
• 剩下 12 个没有规范分解，规范化不会动它们：U+FA0E、U+FA0F、U+FA11、U+FA13、U+FA14、U+FA1F、U+FA21、U+FA23、U+FA24、U+FA27、U+FA28、U+FA29。这 12 个是真正的统一汉字，只是坐在兼容区里。

实测样例：

U+F9B5 例  --NFC-->  U+4F8B 例      变了
U+F929 朗  --NFC-->  U+6717 朗      变了
U+FA10 塚  --NFC-->  U+585A 塚      变了
U+FA0E 﨎  --NFC-->  U+FA0E         没变（属于那 12 个）

两个"例"字放在一起比较：'例' == '例' 返回 False，UTF-8 字节分别是 ef a6 b5 和 e4 be 8b。三字节对三字节，长度都不变，肉眼、字体、放大都看不出任何差别。

关键点是：这里的"规范化会修好它"是一件好事，但只有在你真的做了规范化的时候才成立。 兼容汉字进入你的文件的路径通常是：从某个繁体网页复制歌名、从旧的 KTV 曲库导出的表格、从一个用韩文或日文编码转过来的 CSV、或者某个 macOS/Windows 上的旧输入法。你不会知道它进来了。

3.3 对音乐目录最要命的一个例子

繁体的"樂"字有三个兼容码位：U+F914、U+F95C、U+F9BF，加上统一码位 U+6A02，一共 四个不同的字节串对应同一个字形。

对一个音乐目录来说这几乎是黑色幽默——樂團、音樂、快樂、搖滾樂 全部命中它。同区里还有 U+F90A「金」、U+F9E1「李」，都是极常见的姓氏；龜 更极端，有 U+F907、U+F908、U+FACE 三个兼容码位。全区共有 32 个统一汉字被一个以上的兼容码位指向。

3.4 兼容汉字 + 简繁转换器 = 半转换的残骸

这是我实测里最有价值的一条，也是最容易在真实工单里出现的：

输入（"樂"为 U+F914 兼容码位，"團"为正常统一汉字）：樂團
直接做繁→简：            樂团      ← 只转了一半
先 NFC 再做繁→简：        乐团      ← 正确

转换器的词典里只有统一汉字 U+6A02，它不认识 U+F914，于是把这个字原样留下，只把后面那个字转了。你得到 樂团——一个简繁混排、任何人一眼看去都觉得"这怎么回事"，但没人能解释的字符串。它会通过校验，会入库，会成为你的第三个艺人页。

3.5 规则

在做任何简繁处理之前，先把字符串规范化为 NFC。 顺序反过来就会产生上面那种残骸。NFC 是正确的目标形式；不要用 NFKC 去"顺便清理"，Unicode 标准附件 #15 自己就警告过兼容形式："NFKC 会抹去许多格式区分"，并且"可能移除对语义重要的区分"——对中文来说，NFKC 会把全角标点、全角字母数字一起改掉（见 §5.4），那不是你在这一步想要的。

同时记住规范化的边界：它不会替你做简繁转换，不会替你补上缺失的别名，也不会替你统一拼音写法。它只解决码位重复这一件事。

4. 拼音罗马化：一个人，三到六个拼法

中文艺人在全球系统里有两个名字：汉字名和罗马字名。两个都必须是单值的。汉字名的问题是简繁，罗马字名的问题是拼音本身没有一个大家都遵守的落地形式。

4.1 调号：一个字符还是三个字符

带调号的拼音在 Unicode 里是有预组合码位的，但也可以由基字母加组合符构成。实测（unicodedata，UCD 14.0.0）：

ā  U+0101   NFD → U+0061 U+0304        （2 个码位）
ǎ  U+01CE   NFD → U+0061 U+030C        （2 个码位）
ǚ  U+01DA   NFD → U+0075 U+0308 U+030C （3 个码位！）
ǜ  U+01DC   NFD → U+0075 U+0308 U+0300 （3 个码位）

ǚ（吕、绿、女的三声）分解成三个码位：u + 分音符 + 抬升符。也就是说 Lǚ 这个两字符的串，NFD 之后长度是 4。一个从 macOS 的表格里复制出来的字符串很可能已经是分解形式，而你在网页表单里敲的是组合形式；两者显示完全一样，比较结果不同。统一 NFC，同上。

4.2 有调号、无调号、还是 ASCII

吕晓明 至少有这些合法写法：

• Lǚ Xiǎomíng —— 完整调号，学术正确，没有听众会这样搜
• Lü Xiaoming —— 保留 ü，去掉声调
• Lyu Xiaoming —— 中国大陆护照的现行拼写规则
• Lv Xiaoming —— 输入法习惯，中国境内最常见的 ASCII 写法
• Lu Xiaoming —— 机器"去掉变音符"的结果

最后一个是陷阱。把 Lǚ Xiǎomíng 做 NFD 再剥掉组合符，得到的正是 Lu Xiaoming——而 Lu 对应的是陆、卢、鲁，是另外的姓。一个天真的"去变音符"步骤会把吕变成陆。 很多平台的搜索层、很多 CSV 导出工具都会做这一步。

选择顺序：艺人已经在用的公开写法优先（社交账号、域名、已发行封面）；其次是现有目录里体量最大的那张发行上的写法；再次是目标市场的听众实际会输入的写法。定下来之后，它就是第二个法定名。

4.3 姓在前还是名在前

中文是姓在前的语言，大多数商店的艺人字段是按"名在前"设计的。两种顺序都会出现在真实目录里，而且它们是两个不同的字符串，会各自建页。

苹果给了一条可引用的规则，《Apple Music Style Guide》12.2：

"If the artist does not have a Western name, the phonetic artist name may be listed in localizations in the order of 'Family Name Given Name.'" （如果艺人没有西文名，注音艺人名可以按"姓 名"的顺序列在本地化字段中。）

同一节 12.4 规定注音字段该用什么文字：

"Use Katakana or Hiragana for Japanese, and Roman characters for the other languages." （日语用片假名或平假名，其他语言用罗马字符。）

并明确 "Chinese - Roman characters"（中文——罗马字符），且 "Symbols (stars, hearts, and so on) must not be used in any phonetic fields."（任何注音字段中都不得使用符号，如星形、心形等。）

实务上：汉字名进主字段，拼音进注音/本地化字段，姓在前，不要把拼音塞进主艺人名字段。 如果你的发行商没有注音字段而你必须二选一，就选你的听众实际会搜的那一个，然后永不更改。

顺带一提，如果艺人有约定俗成的西文名（例如 Faye Wong 之于 王菲），那它就是既有足迹的一部分，优先级高于任何按规则生成的拼音。规则生成的 Wang Fei 是正确的，也是没人搜的。

5. 中文标题里的标点

中文标点是全角的、有自己的语义分工的，而分发链路上的很多环节是按英文标点写的。这一节只讲中文特有的部分。

5.1 顿号 、 与全角逗号 ，

这是中文独有的一对，日文里没有对应的区分（日文的 、 就是普通逗号）。《标点符号用法》GB/T 15834—2011 对顿号的定义是：

"句内点号的一种，表示语段中并列词语之间或某些序次语之后的停顿。"

也就是说：并列的词之间用顿号 、（U+3001），句子内部的一般停顿用全角逗号 ，（U+FF0C）。 在曲目标题里这条区别有实际后果，因为标题里出现的通常是并列结构：

• 《春夏、秋冬》 —— 两个并列的词，顿号
• 《我很好，你呢》 —— 一个停顿，全角逗号

把两者互换不会被系统拒绝，但会被读中文的人一眼看出是机器生成的或者是从英文模板里套出来的。更实际的风险是：如果你在同一张专辑里两种都用，同一首歌在不同渠道被人手工重打时就会出现两个版本的标题。

同一份国标还有一条对多曲目专辑很有用：并列的书名号之间通常不加顿号——《春》《夏》《秋》《冬》 而不是 《春》、《夏》……。

5.2 全角冒号 ： 与副标题

中文副标题用全角冒号 ：（U+FF1A），后面不加空格。《长安：一封没寄出的信》，不是 《长安： 一封没寄出的信》，也不是 《长安: 一封没寄出的信》（半角冒号加空格是英文习惯）。

同样的原则适用于全角括号 （）（U+FF08/U+FF09）：中文内容里用全角括号，前后不加空格；但版本标注例外——见 §6.3，版本标注按各家商店的英文规则走半角括号。这是中文报送里少数需要在一个标题里混用两套标点的地方，值得单独记一条。

5.3 书名号《》：苹果有一条明文规定

书名号是中文独有的标号。GB/T 15834—2011 的定义是：

"标号的一种，标示语段中出现的各种作品的名称。"

标准规定双书名号 《》（U+300A/U+300B）为主，单书名号 〈〉（U+3008/U+3009）用于书名号内部再套一层。

对发行来说更重要的是：苹果对中文影视原声带的书名号用法有一条公开的明文规则，《Apple Music Style Guide》12.5：

"When indicating the soundtrack in Chinese, the title of movie or TV drama must be enclosed in Chinese guillemets《》, irrespective of the album or track level." （在中文中标示原声带时，电影或电视剧的名称必须用中文书名号《》括起，无论是专辑层还是曲目层。）

该节给出的示例（原文照录）：

注意示例里两件事：书名号在曲目层也照用；以及外层的版本括号仍然是半角 ( [，书名号在括号内部。这正是 §5.2 说的混排情形。

一条延伸提醒：书名号是给作品名用的（电影、剧集、书、乐曲），不是给专辑名自己用的。把自己的专辑名整个包在《》里报送——《我的专辑》——是把标号写进了内容，商店会原样显示这两个符号。除非它确实是在引用一部同名作品，否则不要包。

5.4 规范化会吃掉哪些标点——实测

一句提醒即可，因为这是交付链路上的风险而不是你要主动做的事。同样用 unicodedata 实测，NFKC 之后：

、 U+3001  → 、   不变
。 U+3002  → 。   不变
《 U+300A  → 《   不变
》 U+300B  → 》   不变
· U+00B7  → ·    不变
， U+FF0C  → ,    变成半角
： U+FF1A  → :    变成半角
（ U+FF08  → (    变成半角
！ U+FF01  → !    变成半角
？ U+FF1F  → ?    变成半角
　 U+3000  → 空格  变成半角空格

规律是清楚的：顿号、句号、书名号、间隔号是"表意标点"，NFKC 不动它们；全角逗号、冒号、括号、感叹号、问号、全角空格是兼容字符，NFKC 会把它们折成 ASCII。 所以如果链路上某一环偷偷做了 NFKC，你的《春夏、秋冬（Live）》会变成《春夏、秋冬(Live)》——顿号和书名号活着，括号被换了。这不会毁掉你的发行，但会让不同渠道显示出不同的标题，而你找不到是哪一环做的。报送前把标题固定成 NFC，并且在拿到各渠道上线页面后逐一比对一次。

5.5 间隔号 ·

外文人名的中译、以及某些组合艺名，用间隔号 ·（U+00B7 MIDDLE DOT）。它常被误打成 U+30FB（日文片假名中点 ・）或 U+2022（项目符号 •）。三个都长得像，都是不同的字符串。中文用 U+00B7。

6. 参与艺人与版本标注

6.1 演出者的名字不进标题字段

独立发行里最常见、最伤的一条错误，是把 曲名 feat. 某某 或 曲名（与某某合唱） 打进标题字段，而参与艺人的角色字段留空。

标题字段是显示字符串，不携带身份。这样做的结果是：被 feat. 的那位拿不到任何署名链接，不出现在自己的艺人页上，没有回流路径，数据后台里什么也看不到；而商店可能把 "feat. 某某" 当成歌名的一部分，于是这首歌永远叫《曲名 feat. 某某》。

平台文档说得很直白。Spotify 的元数据规范：

"You shouldn't include any artists' names in your track or release titles." （不要在曲目或发行标题中包含任何艺人的名字。）

Spotify 的发行商支持文档：

"Spotify strongly recommends against including additional information, such as references to 'Featured Artists' in track and product titles." （Spotify 强烈建议不要在曲目和商品标题中包含额外信息，例如对"参与艺人"的提及。）

Music Business Association 的《Music Metadata Style Guide》建议在艺人角色层署名参与艺人，而不要把这个数据加进曲目或专辑标题。

正确结构：标题字段只放歌名；每一位参与者各自进自己的角色字段（主艺人 Primary / 参与艺人 Featuring / 混音师 Remixer / 制作人 Producer）。商店会从角色字段自己生成 "(feat. X)" 的显示串——你想要的那个显示，是它给你的，不是你打进去的。

苹果对角色的要求也是明文的：参与艺人在曲目层用 Featuring 或 With 角色，"not as Primary"（不作为主艺人）；混音曲目 "must list the original artist as Primary with the remixer assigned the remixer role"（必须把原艺人列为主艺人，混音师赋予 remixer 角色）。把混音师填成主艺人，是电子/说唱目录污染原艺人页最常见的方式。

6.2 如果合同就是要求写进标题

那就按机器可读的形式写，而且不要翻译。苹果：

"Formatting of 'feat.' and 'with' must be lowercase, in English, not localized, and in parentheses or brackets." （"feat." 和 "with" 必须小写、用英文、不作本地化，并置于圆括号或方括号内。）

Music Biz 的说法一致：这些词"when included in the title are generally lowercase and in English"（若写入标题，一般为小写且用英文）。

对中文报送，这条的含义是具体的：不要写 （与 某某）、（某某 合唱）、（featuring 某某）、（合作：某某）。 写 (feat. 某某)。feat. 在这里不是一个词，是一个记号。而它的形状——小写、有点、半角括号——就是各家系统认它的依据。

6.3 版本字段

版本字段的唯一职责是区分共用同一个标题的两条不同录音。这也是判断要不要填它的唯一标准：如果这张发行上只有一个版本，就留空。

苹果给的词表（原文）："To differentiate multiple versions of the same track title, use terms in parentheses or brackets such as: Alternate Take...Live, Instrumental, Single Version, Radio Edit."（为区分同一曲目标题的多个版本，在圆括号或方括号中使用诸如 Alternate Take……Live、Instrumental、Single Version、Radio Edit 之类的词。）

中文目录的实际做法是英文词表与中文表述并存，两者都出现在主流平台上：(Live) 与 (现场版)、(Instrumental) 与 (伴奏版)、(Acoustic) 与 (不插电)。两种都可以，但一张发行里只能有一套，并且此后一直用同一套。 混用的后果是同一位艺人的目录里出现 《晚风 (Live)》 和 《晚风（现场版）》，两首歌，两条 ISRC，听众以为是两个不同的录音。

• Radio Edit 不等于"干净版"。 Music Biz 把 Radio Edit 保留给真正为电台准备的版本，把去除脏词的版本叫 Edited Version。Radio Edit 通常是长度上的剪辑，Edited Version 是内容上的剪辑。中文里"电台版"和"净化版"对应的正是这两个不同的东西。
• Original Mix 是一处真实的平台分歧。 苹果公开的规范把它列为禁用词：标准的原始版本 "must not include any additional information in the title unless it is needed to identify the content"，被点名的禁用词里包括 "Exclusive, Limited Edition, Album Version, Original Mix, Tone, Alert Tone...Dolby Atmos, lossless, high-resolution audio"。Spotify 公开的元数据文档没有任何一条点名 "Original Mix"，它公开的立场只是标题不应携带额外信息。而在电子音乐零售里，原版与若干 remix 并列时标 Original Mix 仍是根深蒂固的行规。苹果的公开文件点名禁止；其他平台没有公开任何点名它的规则，实际处理因商店和你的发行商预校验而异。 如果原版是这张发行上唯一的版本，留空——各处都对。
• 不要手打进标题。 有版本字段就用版本字段。会自己拼显示串的商店否则会给你 晚风 (Live) (Live)。

6.4 合辑与"群星"

多位不同艺人的合辑，专辑层主艺人应使用 Various Artists 而不是把七个人堆在一起。苹果给出了各语言的对应译法，中文的是简体和繁体都作 群星。写 V.A.、Various、各位歌手、合辑 都不符合它公开的规则。

7. 作曲、作词，以及"传统／民歌"的代价

录音和作品是两套权利、两条收入。你的发行商收的是录音那一侧；词曲那一侧的机械复制权和表演权收入，是沿着作曲、作词字段以及后续登记追溯的。

这两个字段是独立发行里最薄弱的一环，原因是结构性的：它们不出现在商店前台。听众听不出来，你也看不出来。一张作曲字段为空的发行看上去完美无缺，正常播放，同时它的词曲收入在某处躺着无人认领。

• 作曲、作词填法定姓名，不填艺名。 著作权集体管理组织是按登记的作者姓名匹配的。"DJ 阿凯"不是一个作者，站在后面的那个人才是。
• 每一位作者都要列，包括只写了一句词的那位。 漏掉一个作者不是漏掉一个署名，是漏掉一份未匹配的份额。
• 份额之和必须是 100%，并且在发行之前有书面约定。 元数据表达的是一份协议；没有协议，它就是一个日后会被争议的猜测。

7.1 中国内地的集体管理格局（只讲可查证的事实）

• 中国音乐著作权协会（MCSC，音著协） 成立于 1992 年 12 月 17 日，由国家版权局和中国音乐家协会共同发起成立，是目前中国大陆唯一的音乐著作权集体管理组织，管理词曲作者的表演权、复制权、广播权及信息网络传播权等。（来源：国家版权局网站集体管理栏目页）
• 中国音像著作权集体管理协会（CAVCA，音集协） 面向的是音像节目和录音制品一侧，其公开业务栏目包括卡拉OK、广播电台和电视台、公共场所、互联网等使用者的许可，以及录音制作者获酬权的相关工作。（来源：cavca.org 官网栏目与公告页）

再往下的东西——入会条件的具体审核尺度、分配周期、某一首歌的分配金额、平台向哪一家结算多少——我无法从公开来源核实，因此不在这里断言。行业里流传的说法很多，但那属于"广泛流传、机构未公开发布"。你需要确切答案时，去问这两家机构本身，以及你的发行商在报送单上具体把作品登记信息送到了哪里。

同样要说清楚的是：报送给流媒体平台的元数据字段，本身不构成任何著作权登记。 它是让平台知道谁写了这首歌；向集体管理组织登记作品是另一件事，需要你另外去做。把作曲字段填好但从不登记，和登记了但作曲字段填错，都会让钱停在半路。

7.2 把作曲家填成"传统／民歌"的代价

这是国风、戏曲和民谣改编最常见的一种损失，而且它的形状很具体：

一位艺人把一首民歌改编成新的编曲——加了和声进行，重写了间奏，配了古筝和二胡，改了调式。报送时作曲字段填 传统（或 民歌、Traditional、佚名）。

结果是：公有领域的旋律确实没有作者，但你的改编有。 编曲者对这个新版本享有的权利，被你亲手填成了"没有人"。这一条录音在词曲那一侧从此匹配不到任何人，收入无处可去。

具体到中文目录，最常出现的几类：

• 民歌改编——《茉莉花》《康定情歌》《小河淌水》这类。旋律是公有领域的，你的编曲不是。作曲填 传统 是正确的，但编曲者必须填进 Arranger 字段，而且如果你重写了旋律或加了新段落，那部分是新的作曲，应当据实署名。
• 戏曲与京剧素材——用了某个曲牌、某段唱腔的框架。曲牌本身通常是公有领域的，但你的配器、结构和唱词往往不是。唱词只要有一句是新写的，作词字段就不能空着。
• 古曲改编——《春江花月夜》《渔舟唱晚》这类古筝、琵琶曲目。同样：曲是公有领域，谱本的版本、你的改编和演奏版本的编排不是。
• 说唱采样——采样来自哪里、清了没有，是另一个问题；但你自己写的 verse 是你自己的作品，必须署名。

一条实用的判断：如果你花了时间在这首歌上做了创作性的决定，那么那些决定的作者就是某个人，而"传统"不是任何人的名字。 把它填对花三十秒，填错之后追回来要几年，或者根本追不回来。

同样的原则适用于翻唱：混音和翻唱不改变作品。 原词曲作者仍然是词曲作者，除非改编真的加了新的创作成分——那是要谈的份额，不是可以默认的假设。

8. 流派与乐器字段：路由信号，不是自我介绍

流派字段不是描述你的品味，它是路由信号，决定你的发行有资格进入哪些编辑和算法语境。

中文目录的常见错误是把它当成风格自述："这是一张融合了国风、后摇、氛围和一点点戏曲的专辑"——填出来七个标签，实际效果是七个都不强。

• 选一个主流派，一个次流派，到此为止。 民谣、摇滚、说唱、流行、电子、爵士 这些在各家平台的分类体系里都有明确对应。
• 国风 是一个近年成型的中文本土标签，各家平台的支持程度不一致；如果你的发行商的下拉框里没有它，退到最接近的一档（多数情况是 流行 或 民谣），把"国风"放到关键词或简介里，而不是硬塞进流派字段。
• 戏曲、京剧、民乐 属于中国传统音乐，在多数国际平台的分类树里落在"世界音乐/中国传统"一支。这一档的编辑语境和流行完全不同，填错会让一张认真的古筝专辑掉进错误的推荐池。
• 乐器要填在乐器/贡献者角色字段，不要填进标题。 古筝、二胡、琵琶、笛子、唢呐、扬琴、三弦、箫——这些是有对应角色的。演奏者应当作为 Performer 出现在贡献者列表里，而不是变成 《大鱼（古筝版）》 里的四个字。真正需要在标题里出现的只有一种情况：这是同一首歌的另一个版本，那就用版本字段填 (Instrumental) 或 (古筝版)，并且遵守 §6.3 的"一套用到底"。

关于工具：mazufa.com 上有一个免费的元数据检查器，完全在你自己的设备上运行、不上传任何文件，可以标出本文讲到的几类隐形问题——简繁字形不一致、CJK 兼容汉字、全角与半角标点混用、以及拼音变体与非 NFC 字符串。

9. 实际被退回的原因，以及出稿前检查清单

按发生频率排，中文发行被退回或被静默改写的原因：

1. 艺人名出现在标题字段里——"feat."、"与"、"合唱"、混音师名字打进标题，而角色字段空着。
2. explicit 用文字表示——（脏话版）、(Explicit)、(Clean)。这是一个布尔标记，不是一个词。Music Biz 同样禁止反向写法，不要写 (净化版) 到标题里。
3. 标题里有宣传性文字——独家、限量、专辑版、Original Mix，以及格式声明如 Dolby Atmos、无损、高解析。苹果的规范逐条点名了这些。
4. 简繁混排——一个标题里既有简体又有繁体字符。最常见的成因就是 §3.4 那种半转换残骸。
5. 元数据与封面不一致——封面上写繁体，字段里填简体（或反过来），标题、艺人名、版本标注三项都要和封面逐字对得上。
6. 语言字段错误或缺失——作品语言（唱的是什么）和标题语言（标题字符串是哪种语言、哪种字形）是两个字段，可以合法地不同：一首标题为中文的纯器乐作品没有歌词语言，但有中文标题语言。中文发行还要区分 zh-Hans 与 zh-Hant，填错会影响商店的排序与索引方式。
7. 作曲或作词缺失——部分渠道直接拒收。
8. 禁用字符——emoji、装饰符号、连续两个空格、全角空格 U+3000 混在半角空格中间、以及从网页复制带进来的零宽字符。
9. 标识符错误——同一个 ISRC 用在了实质不同的录音上，或者 UPC 校验位算错。
10. 艺人名与既有目录不一致——这一条通常根本不会被退回，所以它是这份清单上最贵的一条。

出稿前例行程序

• 艺人名从主表里粘贴，绝不重打。主表里同时存好简体、繁体、拼音三种写法，各自冻结。
• 所有字符串在报送前统一为 NFC。如果要做简繁处理，先 NFC，再转换，顺序不能反。
• 用一段三行的脚本扫一遍所有字段，检查 U+F900–U+FAFF 区间的字符是否存在（any(0xF900 <= ord(c) <= 0xFAFF for c in s)）。
• 检查每个字符串是否简繁混排（一个字符串里同时出现只在简体表里的字和只在繁体表里的字）。
• 确认每个标题字段里只有歌名——没有演出者、没有版本词、没有 explicit 标注。
• 确认每个角色都有字段，每个字段都有角色。
• 标点检查：顿号与全角逗号是否用对；全角冒号后无空格；书名号是否只包住真正的作品名；间隔号是不是 U+00B7。
• 版本词表在整张发行里是否统一（中文一套或英文一套，不混）。
• 作曲、作词填的是法定姓名；改编作品的编曲者已填入 Arranger；份额之和为 100% 且有书面约定。
• 语言字段两个都填（作品语言 + 标题语言，含 zh-Hans/zh-Hant 区分）。
• P 线（录音的首次发行年份 + 录音权利人）与 C 线（美术与包装的年份 + 权利人）分别填，不要互相复制。
• 如果不是首次发行，填原始发行日期。把一条 2016 年的录音配上 2026 年的原始发行日期，等于告诉整条链路它是新的。
• 封面与字段逐字比对。

每一次被退回都是便宜的；通过了校验的错误才是贵的。

10. 小结

• 元数据分三层：发行、录音、作品。大多数昂贵的错误是把一个事实填在了错误的层。艺人名是键，不是标签；角色是身份，标题是显示。
• 简体与繁体是中文目录的核心缺陷：同一个人两串字节，而映射不是一对一。髮/發 → 发、後/后 → 后、鐘/鍾 → 钟 是实测确认的塌缩；余华 经过简→繁会变成 餘華。选一种作为主字形，另一种人工写定后进别名字段，艺人名永不过转换器。
• CJK 兼容汉字（U+F900–U+FAFF，472 个字符，其中 460 个有规范单例分解，12 个没有）会造成完全看不见的重复字符串。繁体"樂"有四个字节形态。先 NFC，再做任何简繁处理，否则会得到 樂团 这样的残骸。
• 拼音是第二个法定名：调号形式、ASCII 形式、姓名顺序各选定一次。注意"去变音符"会把 Lǚ 变成 Lu，把吕变成陆。
• 中文标点有自己的分工：顿号 、 用于并列，全角逗号 ， 用于停顿，书名号《》只包作品名——苹果对中文原声带的《》用法有明文强制规则。
• 作曲、作词字段没有前台症状，出错时不会有任何提示。把一位有名有姓的作曲家或编曲者填成"传统／民歌"，是国风与戏曲改编最常见的一笔损失。

Mazufa 的发行是免费的（没有上传费、没有订阅费、没有单张发行费），唯一的扣减是所收到版税的 5%，并且每一份完整的申请都由人工审核。

来源

• Apple Music Style Guide 2.4（第 12 节 Other Asia-Pacific Countries and Regions：12.1 Chinese Artist Localizations、12.2、12.3 Chinese Localizations、12.4 Phonetics、12.5 Format of Title Version Information for Chinese Soundtracks and Scores；第 2、3 节：Various Artists 译名表、版本信息、禁用词）—— https://help.apple.com/itc/musicstyleguide/en.lproj/static.html
• Spotify for Artists,《Music metadata guidelines》—— https://support.spotify.com/us/artists/article/metadata-formatting-guidelines/
• Spotify Provider Support,《Featured artist in a product or track title》—— https://providersupport.spotify.com/article/featured-artist-in-a-product-or-track-title
• Music Business Association,《Music Metadata Style Guide》v2.1 —— https://www.musicbiz.org/wp-content/uploads/2016/04/MusicMetadataStyleGuide_V2.1.pdf
• IFPI,《International Standard Recording Code (ISRC) Handbook》（§A.10.1 重制与创造性投入）—— https://www.ifpi.org/wp-content/uploads/2021/02/ISRC_Handbook.pdf
• DDEX,《Standards》（含 Electronic Release Notification Message Suite, ERN）—— https://ddex.net/standards/
• Unicode Standard Annex #15,《Unicode Normalization Forms》—— https://www.unicode.org/reports/tr15/
• Unicode Character Database（字符属性：规范分解映射；CJK Compatibility Ideographs 区块）—— https://www.unicode.org/ucd/
• Unicode 15.1 及以后版本的《CJK Compatibility Ideographs》区块说明 —— https://www.unicode.org/charts/PDF/UF900.pdf
• 国家标准 GB/T 15834—2011《标点符号用法》（顿号、书名号定义）—— https://archive.org/details/GB-T15834-2011
• 国家版权局，集体管理栏目·中国音乐著作权协会 —— https://www.ncac.gov.cn/xxfb/bqshfw/jtgl/201202/t20120217_54065.html
• 中国音像著作权集体管理协会（音集协）官网 —— https://www.cavca.org/
• OpenCC 简繁转换词库（本文的简繁塌缩与往返实测使用 opencc-python-reimplemented 0.1.7 的 t2s／s2t／s2tw 配置）—— https://github.com/BYVoid/OpenCC

关于本文实测部分。 §2.2 的简繁塌缩表、往返改字示例，§3.2 的 U+F900–U+FAFF 区块统计（472／460／12）、§3.3 的"樂"四码位、§3.4 的半转换示例，§4.1 的拼音分解结果，以及 §5.4 的 NFKC 标点表，均为在本机用 Python unicodedata（UCD 14.0.0）与 OpenCC 0.1.7 实际运行得出，可按上述条件复现。不同的 Unicode 版本与不同的 OpenCC 词库版本可能给出略有差异的结果，请以你的实际链路为准。

关于未公开的部分。 本文引用的每一条平台规则都出自该平台自己的公开文档。有三件事艺人经常被当成事实告知，但没有任何平台公开发布过，本文不作断言：艺人页合并所需的门槛与证据；判断一次报送并入既有艺人还是新建艺人的匹配逻辑；以及除苹果明文点名之外，各商店对 "Original Mix" 的实际处理。同样地，中国内地两家集体管理组织的内部审核尺度、分配周期与具体分配金额，本文亦未作断言。