ads.txt 规范是否反对空格？
Does the ads.txt specification take a stand against spaces?
ads.txt 是每个支持广告的网站都应该放在其根文件夹中的文件。 IAB ads.txt specification 指示它看起来像：
<FIELD #1>, <FIELD #2>, <FIELD #3>, <FIELD #4>
Data should be liberal in accepting files with varying whitespace or field
separation characters.
但同时它也提到：
The consumer systems should ignore any sequence of whitespace or tabs. No field should contain tabs, commas or whitespace, otherwise it should be escaped with URL encoding [13].
我的问题是：如果 "no field should contain whitespace"，为什么规范在自己的示例中使用空格 [更新：我的意思是空格 between字段]？接受还是不接受？默认值应该是多少？ Whosebug itself 使用空格，顺便说一句，但这并不意味着它是正确的。
您问的是：
if "no field should contain whitespace", why does the specification use spaces in its own examples?
混淆的根源仅仅是 <FIELD #1>, <FIELD #2>, ... 不是 示例 ，而是要遵循的格式或结构，换句话说 语法。作为一个语法 <FIELD #1>实际上是一个符号，一个stand-in来标记一个位置。您将该位置替换为 greenadexchange.com
等值
规则：
No field should contain ... whitespace
可以更好地理解为：
no field value should contain ... whitespace
这里的field是指某个地点或位置的内容，即field value- 所以它不会指代 IAB 作者决定使用的特定符号，例如
<FIELD #1>。
也就是说，IAB 编写者可能会通过编写不使用 space 的符号来改进，例如第一个字段 <FIELD#1>，第二个字段 <FIELD#2>，以及很快。这将有助于避免潜在的混淆风险，同时仍然传达出这个位置有第一个字段，那个位置有第二个字段，依此类推。
你还想澄清：
But what about the surrounding spaces? Does the specification by default prefer <FIELD#1>,<FIELD#2>,<FIELD#3>,<FIELD#4> or <FIELD#1>, <FIELD#2>, <FIELD#3>, <FIELD#4>?
规范似乎没有偏好，规范只允许围绕space因为它被忽略了。
推荐：
- 在逗号后加一个 space 以帮助表达清楚，并且 human-readable 与只是一长串不间断的行相比。
下面有详细的解释。
语法
当查看您最初引用的 <FIELD... 周围的附加文本时，IAB ads.txt specification，PDF 第 7 页：
... The records consist of a set of
lines of the form:
<FIELD #1>, <FIELD #2>, <FIELD #3>, <FIELD #4>
or
<VARIABLE>=<VALUE>
它说of the form:，这表明它要呈现的是结构，换句话说语法，而不是示例。它也直到后面的页面才使用 example 这个词，所以这个 <FIELD #1>, ... 更好地理解为不是一个文字示例，而是说明语法。
此外，当您看到尖括号 (<、>) 中的内容时，例如 <FIELD #1> 和 <VARIABLE> ，这是技术手册中经常使用的约定或文档表示尖括号和里面的任何内容，在您实际使用它时将 替换为 一个值。
field 限制，例如 PDF 第 8 页： No field should contain tabs, commas or whitespace ，更好地理解为对您最终写入的字段值的限制，与 <FIELD #1> 无关只是一种约定，一种与您交流的方式，即在该位置或 "position".
处有第一个字段
示例 4.1
本节后面：4. EXAMPLES
我们可以看到我们之前看到的语法是怎样的：
<FIELD #1>, <FIELD #2>, <FIELD #3>, <FIELD #4>
是这样应用的：
greenadexchange.com, XF7342, DIRECT, 5jyxf8k54
我们可以像这样比较语法和它的实现：
| SYNTAX | EXAMPLE | WHAT |
| --- | --- | --- |
| <FIELD #1> | greenadexchange.com | Domain value |
| , | , | Delimiter |
| | | Ignorable whitespace |
| <FIELD #2> | XF7342 | Publisher's Account ID value |
| , | , | Delimiter |
| | | Ignorable whitespace |
| <FIELD #3> | DIRECT | Type of account value |
| , | , | Delimiter |
| | | Ignorable whitespace |
| <FIELD #4> | 5jyxf8k54 | Certification Authority ID value |
<FIELD #1>的语法，替换为greenadexchange.com，而greenadexchange.com里面没有space- 逗号 (
,) 是分隔符，因为规范，PDF 第 7 页：a comma separated format 所以它是分隔符或分隔符
- whitespace (
</code>) 将被忽略，因为通常所有 whitespace 都应该被忽略：<code>The consumer systems should ignore any sequence of whitespace or tabs.
- 这就是为什么对于你的字段值，规范强调你不应该有白色space，可能是因为它可能会混淆事情，因为它应该忽略白色space
同样的理解适用于此示例中的其余部分
这些是规则，但至于偏好，我找不到任何特别喜欢 space 或逗号后没有 space 的东西。
但我强烈建议写逗号后接 space (,) 因为它比完整的行更清晰，更 human-readable文本。清晰有助于最大限度地减少误解和错误的风险，并且通常使其在长期 运行.
中更易于维护
其他想法
当您阅读更多技术文档时，您可能会看到尖括号 (<...>) 的其他示例，表示您要替换的内容。一个有趣的例子是 The Open Group Base Specifications Issue 7, 2018 edition, 12. Utility Conventions:
4. Frequently, names of parameters that require substitution by actual values are shown with embedded <underscore> characters. Alternatively, parameters are shown as follows:
<parameter name>
- 导致您混淆的
<FIELD 1>似乎是这种替代方法
如果 IAB 作者想提供更多帮助并避免混淆的风险，他们可能会编写没有 spaces
的语法
<FIELD#1>, <FIELD#2>, <FIELD#3>, <FIELD#4>
或 Open Group Base 建议的 "embedded underscore" 个字符：
<FIELD_1>, <FIELD_2>, <FIELD_3>, <FIELD_4>
这可能会更有帮助，因为它进一步强调了关于没有白色的观点space，并避免了潜在的混淆。
ads.txt 是每个支持广告的网站都应该放在其根文件夹中的文件。 IAB ads.txt specification 指示它看起来像：
<FIELD #1>, <FIELD #2>, <FIELD #3>, <FIELD #4>
Data should be liberal in accepting files with varying whitespace or field separation characters.
但同时它也提到：
The consumer systems should ignore any sequence of whitespace or tabs. No field should contain tabs, commas or whitespace, otherwise it should be escaped with URL encoding [13].
我的问题是：如果 "no field should contain whitespace"，为什么规范在自己的示例中使用空格 [更新：我的意思是空格 between字段]？接受还是不接受？默认值应该是多少？ Whosebug itself 使用空格，顺便说一句，但这并不意味着它是正确的。
您问的是：
if "no field should contain whitespace", why does the specification use spaces in its own examples?
混淆的根源仅仅是 <FIELD #1>, <FIELD #2>, ... 不是 示例 ，而是要遵循的格式或结构，换句话说 语法。作为一个语法 <FIELD #1>实际上是一个符号，一个stand-in来标记一个位置。您将该位置替换为 greenadexchange.com
规则：
No field should contain ... whitespace
可以更好地理解为：
no field value should contain ... whitespace
-
这里的
field是指某个地点或位置的内容，即field value- 所以它不会指代 IAB 作者决定使用的特定符号，例如
<FIELD #1>。
也就是说，IAB 编写者可能会通过编写不使用 space 的符号来改进，例如第一个字段 <FIELD#1>，第二个字段 <FIELD#2>，以及很快。这将有助于避免潜在的混淆风险，同时仍然传达出这个位置有第一个字段，那个位置有第二个字段，依此类推。
你还想澄清：
But what about the surrounding spaces? Does the specification by default prefer
<FIELD#1>,<FIELD#2>,<FIELD#3>,<FIELD#4>or<FIELD#1>, <FIELD#2>, <FIELD#3>, <FIELD#4>?
规范似乎没有偏好，规范只允许围绕space因为它被忽略了。
推荐：
- 在逗号后加一个 space 以帮助表达清楚，并且 human-readable 与只是一长串不间断的行相比。
下面有详细的解释。
语法
当查看您最初引用的 <FIELD... 周围的附加文本时，IAB ads.txt specification，PDF 第 7 页：
... The records consist of a set of
lines of the form:
<FIELD #1>, <FIELD #2>, <FIELD #3>, <FIELD #4>
or
<VARIABLE>=<VALUE>
它说of the form:，这表明它要呈现的是结构，换句话说语法，而不是示例。它也直到后面的页面才使用 example 这个词，所以这个 <FIELD #1>, ... 更好地理解为不是一个文字示例，而是说明语法。
此外，当您看到尖括号 (<、>) 中的内容时，例如 <FIELD #1> 和 <VARIABLE> ，这是技术手册中经常使用的约定或文档表示尖括号和里面的任何内容，在您实际使用它时将 替换为 一个值。
field 限制，例如 PDF 第 8 页： No field should contain tabs, commas or whitespace ，更好地理解为对您最终写入的字段值的限制，与 <FIELD #1> 无关只是一种约定，一种与您交流的方式，即在该位置或 "position".
示例 4.1
本节后面：4. EXAMPLES
我们可以看到我们之前看到的语法是怎样的：
<FIELD #1>, <FIELD #2>, <FIELD #3>, <FIELD #4>
是这样应用的：
greenadexchange.com, XF7342, DIRECT, 5jyxf8k54
我们可以像这样比较语法和它的实现：
| SYNTAX | EXAMPLE | WHAT |
| --- | --- | --- |
| <FIELD #1> | greenadexchange.com | Domain value |
| , | , | Delimiter |
| | | Ignorable whitespace |
| <FIELD #2> | XF7342 | Publisher's Account ID value |
| , | , | Delimiter |
| | | Ignorable whitespace |
| <FIELD #3> | DIRECT | Type of account value |
| , | , | Delimiter |
| | | Ignorable whitespace |
| <FIELD #4> | 5jyxf8k54 | Certification Authority ID value |
<FIELD #1>的语法，替换为greenadexchange.com，而greenadexchange.com里面没有space- 逗号 (
,) 是分隔符，因为规范，PDF 第 7 页：a comma separated format所以它是分隔符或分隔符 - whitespace (
</code>) 将被忽略，因为通常所有 whitespace 都应该被忽略：<code>The consumer systems should ignore any sequence of whitespace or tabs. - 这就是为什么对于你的字段值，规范强调你不应该有白色space，可能是因为它可能会混淆事情，因为它应该忽略白色space
同样的理解适用于此示例中的其余部分
这些是规则，但至于偏好，我找不到任何特别喜欢 space 或逗号后没有 space 的东西。
但我强烈建议写逗号后接 space (,) 因为它比完整的行更清晰，更 human-readable文本。清晰有助于最大限度地减少误解和错误的风险，并且通常使其在长期 运行.
其他想法
当您阅读更多技术文档时，您可能会看到尖括号 (<...>) 的其他示例，表示您要替换的内容。一个有趣的例子是 The Open Group Base Specifications Issue 7, 2018 edition, 12. Utility Conventions:
4. Frequently, names of parameters that require substitution by actual values are shown with embedded <underscore> characters. Alternatively, parameters are shown as follows:
<parameter name>
- 导致您混淆的
<FIELD 1>似乎是这种替代方法
如果 IAB 作者想提供更多帮助并避免混淆的风险，他们可能会编写没有 spaces
的语法<FIELD#1>, <FIELD#2>, <FIELD#3>, <FIELD#4>
或 Open Group Base 建议的 "embedded underscore" 个字符：
<FIELD_1>, <FIELD_2>, <FIELD_3>, <FIELD_4>
这可能会更有帮助，因为它进一步强调了关于没有白色的观点space，并避免了潜在的混淆。