css样式兼容、注释_CSS中的伪注释(或者,浏览器如何解析样式)

2023-11-02

css样式兼容、注释

The CSS spec does not mention it, but you can mimic C-style and/or Unix-style line comments in CSS files (with some caveats). Others have written about them before (see in particular, SitePoint’s Web Foundations post covering CSS Comments). The present post examines them in further detail.

CSS规范没有提及它,但是您可以模仿CSS文件中的C风格和/或Unix风格的行注释(带有一些警告)。 其他人以前也写过关于它们的文章(特别是,参见SitePoint的Web Foundations文章,内容涉及CSS注释 )。 本职位将对它们进行更详细的研究。

CSS注释 (CSS Comments)

CSS parsers, per the spec, officially bless one style for comments, the multi-line comment from C-style languages, which uses a start token, /*, and an end token, */, as follows:

根据规范 ,CSS解析器正式为一种注释提供了一种样式,即来自C样式语言的多行注释,该注释使用开始标记/*和结束标记*/ ,如下所示:

/*
  characters between, and including, the start and
  end tokens are ignored by the parser,
*/

And so a rule declaration in comments will be ignored:

因此,注释中的规则声明将被忽略:

body {
  background: red;
  /*
  background: white;
  */
}

A block declaration in comments will be ignored:

注释中的块声明将被忽略:

/*
body {
  background: red;
}
*/

In each of those examples, we are using the comment syntax intentionally to instruct the parser to ignore the content.

在每个示例中,我们有意使用注释语法来指示解析器忽略内容。

However, we can do that by accident, as with malformed declarations, such as

但是,我们可以偶然地这样做,例如使用格式错误的声明,例如

body {
  background: red    /* missing semi-colon */
  background: blue;      
}

In this example, neither background declaration is applied because of the missing semi-colon. The parser scans for the next semi-colon, determines the entire two-line statement is malformed, and so ignores the entire lexed content. The same thing happens if we leave out the property value altogether:

在此示例中,由于缺少分号,因此均未应用任何后台声明。 解析器扫描下一个分号,确定整个两行语句的格式不正确,因此忽略整个词法化的内容。 如果我们完全忽略属性值,则会发生相同的事情:

body {
  background:
  background: blue; /* this declaration is not applied */
}

And that shows that we can use malformed declarations as…

表明我们可以将格式错误的声明用作…

伪注释 (Pseudo-comments)

We’ll refer to these as “pseudo-comments” because, properly speaking, these are not comments that terminate at an end-of-line character. Instead they work by malforming the input that follows them, even on subsequent lines. And this is due to the error handling process for Rule sets, declaration blocks, and selectors:

我们将这些称为“伪注释”,因为正确地说,这些注释不是以行尾字符结尾的注释。 取而代之的是,它们的工作方式是畸形的跟随它们的输入,即使在随后的行也是如此。 这是由于规则集,声明块和选择器的错误处理过程所致:

“the whole statement should be ignored if there is an error anywhere in the selector, even though the rest of the selector may look reasonable in CSS 2.1.”

“即使选择器的其余部分在CSS 2.1中看起来很合理,如果选择器中的任何地方出现错误,也应忽略整个语句。”

In the following example, taken from the spec, the second ruleset is ignored due to the presence of the invalid “&” character in the selector:

在以下示例(摘自规范)中,由于选择器中存在无效的“&”字符,因此将忽略第二个规则集:

h1, h2 {color: green }
h3, h4 & h5 {color: red } /* <= ignored */
h6 {color: black }

Again, in the following, the second and third declarations are ignored due to the presence of extra characters in the background property name:

同样,在下面的内容中,由于背景属性名称中存在多余的字符,因此将忽略第二个和第三个声明:

body {
  background: red;
  xbackground: white;    /* property name is not recognized */
  y background: blue;    /* property name is not well-formed */
}

A quick tour around the English language keyboard shows the following special characters will act as single-line declaration comments:

快速浏览英文键盘,显示以下特殊字符将用作单行声明注释:

selector {
  ~ property-name: ignored;
  ` property-name: ignored;
  ! property-name: ignored;
  @ property-name: ignored;
  # property-name: ignored;
  $ property-name: ignored;
  % property-name: ignored;
  ^ property-name: ignored;
  & property-name: ignored;
  * property-name: ignored;
  _ property-name: ignored;
  - property-name: ignored;
  + property-name: ignored;
  = property-name: ignored;
  | property-name: ignored;
  \ property-name: ignored;
  : property-name: ignored;
  < property-name: ignored;
  . property-name: ignored;
  > property-name: ignored;
  , property-name: ignored;
  ? property-name: ignored;
  / property-name: ignored;
}

Rather than use just any character, though, stick with C and Unix convention, and use either # or //:

但是,不要只使用任何字符,而要遵循C和Unix约定,并使用#//

// background: ignored;
  # background: ignored;

分号 (Semi-colons)

Semi-colons are the end tokens of rule declarations. Thus, they cannot “comment” text that follows them. In spec-speak, the parser treats a dangling semi-colon as a malformed declaration (a declaration missing a name, colon, or value).

分号是规则声明的结束标记。 因此,他们无法“注释”其后的文本。 用规范的话来说,解析器将悬挂的分号视为格式错误的声明 (缺少名称,冒号或值的声明)。

As shown earlier, when regular multi-line comments are malformed, that is, when start and end tokens are not balanced around a ruleset or declaration, the subsequent declaration or ruleset is ignored by the parser. The following will in effect “comment” out both background declarations because the parser will search for the next end-of-declaration token (the semi-colon) for the affected declaration:

如前所述,当规则的多行注释格式错误时,即,开始和结束标记在规则集或声明周围不平衡时,后续的声明或规则集将被解析器忽略。 以下内容将有效地“注释” 这两个后台声明,因为解析器将为受影响的声明搜索下一个声明结束标记(分号):

body {
  background:
  background: blue;      /* both lines ignored */
}

That’s fixed by adding a semi-colon after the comment, before the next declaration (thus the background blue declaration will be applied):

通过在评论后的下一个声明之前添加分号来解决此问题(因此将应用背景蓝色声明):

body {
  background: ;          /* ignored */
  background: blue;      /* processed */
}

The effect is the same with a pseudo-comment on a line missing its semi-colon:

对于缺少分号的行,伪注释的效果相同:

body {
  background: # red   /* ignored */
  background: blue;   /* also ignored */
}

and corrected by restoring the semi-colon:

并通过恢复分号进行了更正:

body {
  background: # red;  /* ignored */
  background: blue;   /* processed */
}

内联与下一行放置 (Inline vs. next-line placement)

This is where the “pseudo” enters into the term “pseudo-comment.” It may be reason enough not to call these “comments” at all as they break from the end-of-line convention of C or Unix-style line comments.

这是“伪”输入术语“伪注释”的地方。 完全有理由不调用这些“注释”,因为它们与C或Unix样式的行注释的行尾约定不符。

A pseudo-comment placed on its own line will suppress a declaration on the next line. In the following, the background will be blue:

放在其自己行上的伪注释将禁止在下一行声明。 在下面,背景将是蓝色的:

body { 
  //
  background: white !important;  /* ignored */
  background: blue;
}

A pseudo-comment placed after a valid declaration on the same line will suppress a declaration on the next line. In the following, the background will be white rather than blue:

在同一行上的有效声明之后放置的伪注释将禁止在下一行声明。 在下面的背景将是白色而不是蓝色:

body {
  background: white; // next line is ignored... 
  background: blue !important;
}

Even a “minified” version of a CSS selector with an inline pseudo-comment will behave as a single-declaration comment. In the following, the first background declaration is ignored due to the presence of the comment token, #, recognized by the parser as terminating at the next semi-colon, and the second background declaration is recognized as well-formed and therefore applied (in this case, blue will be applied to the body background):

甚至带有嵌入式伪注释CSS选择器的“精简”版本也将充当单声明注释。 在下文中,由于注释令牌#的存在,第一个背景声明被忽略,解析器将其识别为终止于下一个分号,并且第二个背景声明被识别为格式正确并因此被应用(在在这种情况下,蓝色将应用于主体背景):

body { // background: red !important; background: blue; }

选择器 (Selectors)

The same rule-based behavior applies to selectors.

相同的基于规则的行为适用于选择器。

An entire selector ruleset is ignored when the selector is preceded by a pseudo-comment, whether inline

当选择器前面带有伪注释时,无论是否内联,都会忽略整个选择器规则集

// body {
  background: white !important;
}

or next-line:

或下一行:

//
body {
  background: white !important;
}

伪注释作为目标畸形 (Pseudo-comments as targeted malformed-ness)

Pseudo-comments work by taking advantage of the spec’s Rules for handling parsing errors. In effect, they work by exploiting their malformed-ness.

伪注释通过利用规范的规则来处理解析错误而起作用。 实际上,他们通过利用畸形来工作。

未知值 (Unknown values)

“User agents must ignore a declaration with an unknown property.”

“用户代理必须忽略具有未知属性的声明。”

A declaration containing an unrecognized property name will not be evaluated, as, for example, the comment property in the following body ruleset:

包含无法识别的属性名称的声明将不会被评估,例如,以下body规则集中的comment属性:

body {
  comment: 'could be text or a value';
}

非法值 (Illegal values)

“User agents must ignore a declaration with an illegal value.”

“用户代理必须忽略具有非法值的声明。”

The color property defined below is ignored because the value is a string rather than a value or color keyword:

下面定义的color属性将被忽略,因为该值是字符串而不是value或color关键字:

body {
  color: "red";
}

声明和陈述格式错误 (Malformed declarations and statements)

“User agents must handle unexpected tokens encountered while parsing a declaration [or statement] by reading until the end of the declaration [or statement], while observing the rules for matching pairs of (), [], {}, “”, and ”, and correctly handling escapes.”

“用户代理必须通过解析直到声明[或声明]的末尾,同时遵守匹配(),[],{},“”和“ ”,并正确处理转义符。”

body {
  -color: red;
}

Declarations malformed by unmatched pairs of (), [], {}, "", and '' are more comprehensively ignored (and therefore more dangerous) than others. And the quoting characters "", and '' are processed differently than the grouping characters (), [], {}.

()[]{}""''不匹配对组成的声明格式不正确,比其他声明更全面地被忽略(因此更加危险)。 并且引号字符""''与分组字符()[]{}处理方式不同。

引用字符 (Quoting characters)

The unpaired apostrophe in the second declaration below will prevent the subsequent declaration in the ruleset from being processed (thus, the background will be red):

以下第二个声明中不成对的撇号将阻止处理规则集中的后续声明(因此,背景为红色):

body {
  background: red;
  'background: white;  /* ignored */
  background: blue;    /* also ignored */
}

However, a third declaration after the apostrophe will be processed (thus the background will be gold):

但是, 处理撇号后的第三个声明(因此背景为金色):

body {
  background: red;
  'background: white;  /* ignored */
  background: blue;    /* also ignored */
  background: gold;    /* processed */
}

In sum, you can’t terminate a single quoting character on its own line.

总而言之,您不能在其自己的行上终止单个引号字符。

分组字符 (Grouping characters)

In general, grouping characters (), [], {} should be avoided as pseudo-comments because they have more drastic effects in that they interfere more extensively with the parser’s block recognition rules, and so will “comment” out more than single declarations. For the sake of completeness, we’ll examine a few of these.

通常,应避免将字符()[]{}分组为伪注释,因为它们具有更大的影响,因为它们会更广泛地干扰解析器的块识别规则,因此将“注释”多于单个声明。 为了完整起见,我们将研究其中一些。

For example, the appearance of unmatched starting group characters suppresses all subsequent declarations to the end of the stylesheet (not just the ruleset). This is true of commas, brackets, and braces.

例如,出现不匹配的起始组字符会抑制所有后续声明到样式表的末尾(而不仅仅是规则集)。 逗号,方括号和花括号也是如此。

In the following, only the background: red; declaration is processed; all declarations and selectors after that in the entire stylesheet will be ignored:

在下面,只有background: red; 声明已处理; 整个样式表中的所有声明和选择器都将被忽略:

body {
  background: red;

  {  /* *every* declaration that follows will be ignored, 
        including all subsequent selectors, to the 
        end of the stylesheet. */

  background: white;
  color: aqua;
  margin: 5px;

  ...
}

When grouping characters are matched, the grouped and subsequent ungrouped declarations in the ruleset will be suppressed. In the following, the background will be red, not gold:

当分组字符匹配时规则集中的分组和后续未分组声明将被禁止。 在下面的背景将是红色,而不是金色:

body {
  background: red;

  (
  background: white;
  background: blue;
  background: fuchsia;
  )

  background: gold;
}

A closing comma or bracket will suppress only the next declaration that appears. In the following, the background will be gold:

一个封闭逗号或支架将只抑制出现的下一个声明。 在下面,背景将是金色的:

body {
  background: red;

  ]
  background: white;  
  background: blue;
}

A closing brace, }, however, will suppress all declarations to the end of the ruleset. In the following, the background will be red:

但是, 右括号 }将禁止所有声明到规则集的末尾。 在下面,背景将是红色的:

body {
  background: red;

  }
  background: white;
  background: blue;
}

规则 (At-rules)

At-rules have two forms:

规则有两种形式:

  • a body declaration denoted by braces, { ... } (such as @media),

    用大括号{ ... }表示的主体声明(例如@media ),

  • a rule declaration closed with a semi-colon ; (such as @charset).

    用分号封闭的规则声明; (例如@charset )。

Pseudo-comments on body-block at-rules behave the same as for selectors (i.e., the entire at-rule is ignored).

主体块规则上的伪注释与选择器的行为相同(即,整个规则被忽略)。

伪注释适用于带有正文块的规则 (Pseudo-comments applied to at-rules with body blocks)

For at-rules containing body blocks, such as @keyframes, @media, @page. and @font-face, the entire at-rule ruleset is ignored when the at-rule is preceded by a pseudo-comment, whether inline

在规则容纳体块,例如@keyframes@media@page 。 和@font-face ,如果规则前面带有伪注释(无论是否内联),则会忽略整个规则规则集

// @media (min-width: 0) {
  body {
    background: white !important;
  }
}

or next-line:

或下一行:

//
@media (min-width: 0) {
  body {
    background: white !important;
  }
}

伪注释适用于无正文规则的规则 (Pseudo-comments applied to at-rules without body blocks)

At-rules without blocks, such as @charset and @import, provide a fascinating exception to inline pseudo-comment behavior.

不带规则的规则,例如@charset@import ,为内联伪注释行为提供了一个引人入胜的异常。

An at-rule with a pseudo-comment after the keyword will be ignored:

关键字带有伪注释的规则将被忽略:

/* the pseudo-comment before url()
   suppresses the entire @import */
@import // url('libs/normalize.css');

But a pseudo-comment that precedes an at-rule suppresses both the import and the first rule or selector after the import. This is because the parser treats a pseudo-commented @import as a malformed statement, and looks for the next matching braces in order to complete the next ruleset.

但是在规则之前的伪注释会同时抑制导入导入后的第一个规则或选择器。 这是因为解析器将伪注释的@import视为格式错误的语句,并查找下一个匹配的括号以完成下一个规则集。

Thus, a pseudo-comment before one @import in a series of @import rules will suppress all subsequent @import rules and the first declaration or selector after the last import:

因此,在一系列@import规则中的一个@import之前的伪注释将禁止所有后续@import规则以及最后一次导入之后的第一个声明或选择器:

// @import url('libs/normalize.css');

/* NONE of these loads because previous statement is
   processed as a malformed statement, and the parser
  looks for the next matching braces. */
@import url('libs/normalize.css');
@import url('libs/example.css');
@import url('libs/other.css');
@import url('libs/more.css');
@import url('libs/another.css');
@import url('libs/yetmore.css');

The fix for this is surprisingly simple: just add an empty body block after the comment @import

解决方法非常简单:只需在@import注释后添加一个空的body块

// @import url('libs/normalize.css');

{}  /* now, the next import will load */

@import url('libs/normalize.css');

This is fun for debugging, but that behavior is peculiar enough that you should avoid the pseudo-comments approach to at-rules without body blocks, and use the multi-line syntax instead.

这对于调试很有趣,但是这种行为非常独特,您应该避免对没有正文块的规则使用伪注释方法,而应使用多行语法。

规则和未知关键字 (At-rules and Unknown at-keywords)

“User agents must ignore an invalid at-keyword together with everything following it, up to the end of the block that contains the invalid at-keyword, or up to and including the next semicolon (;), or up to and including the next block ({…}), whichever comes first”

“用户代理必须忽略无效的关键字及其后面的所有内容,直到包含无效关键字的代码块的末尾,或者直到并包括下一个分号(;),或者直到并包括下一个分号。区块({…}),以先到者为准”

We can illustrate all that by using an unknown at-keyword, @comment, as a custom at-rule alternative to the multi-line syntax. For example, the following at-rule is parsed to the closing brace, }, determined to be malformed, and then ignored:

我们可以通过使用未知的@comment关键字@comment作为多行语法的自定义规则替代品来说明所有这些。 例如,以下规则被解析为右大括号} ,被确定为格式错误,然后被忽略:

@comment { 
  I'm not processed in any way.
}

That looks harmless and readable at first, but due to the presence of the apostrophe in I'm, we’ve reintroduced the quoting character problem (i.e., you can’t terminate the single quoting character on its own line). That means, a subsequent at-rule or selector will also be ignored if our custom @comment’s body is closed on its own line, because the rule’s declaration is malformed by the presence of the apostrophe in I'm:

乍一看,这看起来无害且可读,但是由于I'm存在撇号,因此我们重新引入了引号字符问题(即,您不能在其行上终止单个引号字符)。 这意味着,如果我们的自定义@comment的主体在其自己的行上关闭,则随后的规则或选择器也将被忽略,因为规则的声明由于I'm '中的撇号的存在而格式错误:

@comment { 
  I'm not processed in any way. }

body { background: blue; }   /* this whole block will not be processed either! */

That can be rescued with outer quotes, either inside the braces

大括号内可以使用外部引号将其保存

@comment { 
  "I'm not processed in any way."  }  /* fixed */

body { background: blue; }   /* this block will work */

Or by leaving off the braces and instead terminating the pseudo-comment with a semi-colon, either inline:

或通过省去大括号,而用分号终止伪注释,可以内联:

@comment "I'm not processed in any way.";

body { background: blue; }   /* this works */

or next-line

或下一行

@comment 
"I'm not processed in any way.";

body { background: blue; }   /* this works */

预处理器 (Pre-processors)

The various CSS pre-processors support similar multiline and single-line comments.

各种CSS预处理器支持类似的多行和单行注释。

萨斯 (Sass)

Sass supports standard multiline CSS comments with /* */, as well as single-line comments with //. The multiline comments are preserved in the CSS output where possible, while the single-line comments are removed.

Sass支持带/ * * /的标准多行CSS注释以及带//的单行注释。 多行注释将尽可能保留在CSS输出中,而单行注释将被删除。

source

资源

Compressed mode will normally strip out all comments, unless the comment is preceded by /*!.

除非注释以/*!开头,否则压缩模式通常会删除所有注释/*!

However, you can use a single-character pseudo-comment, such as # and the output will contain the commented line.

但是,您可以使用单字符伪注释,例如# ,并且输出将包含注释行。

body {
   # background: red; 
}

(Less)

Both block-style and inline comments may be used.

块样式和内联注释都可以使用。

source

资源

It is not clear (to me, at least) whether Less will suppress these comments or print them to the output. From StackOverflow posts, it appears Less will aggregate line-comments at block level.

尚不清楚(至少对我而言),Less是否会取消这些注释或将其打印到输出中。 在StackOverflow帖子中,“更少”将在块级别聚合行注释。

触控笔 (Stylus)

Stylus also supports multiline /* */ and single-line comments //, but suppresses these from the output if the compress directive is enabled. If you always want multiline comments to print to the output, use Multi-line buffered comments.

手写笔还支持多行/* */和单行注释// ,但是如果启用了compress指令,则会从输出中取消注释。 如果您始终希望将多行注释打印到输出,请使用多行缓冲注释。

Multi-line comments which are not suppressed start with /*!. This tells Stylus to output the comment regardless of compression.

未抑制的多行注释以/ *!开头。 这告诉触控笔不管压缩如何都输出注释。

/*!
 * This will appear in the output.
 */

source

资源

最佳实践 (Best Practice)

“Readability counts.” https://www.python.org/dev/peps/pep-0020/‘>Zen of Python

“可读性很重要。” https://www.python.org/dev/peps/pep-0020/ '> Python的禅宗

Comments can make obscure code more readable, but readability depends on more than one convention. Pseudo-comments in CSS are less about readability than about playing against convention (aka, the parser).

注释可以使晦涩难懂的代码更具可读性,但是可读性取决于多个约定。 CSS中的伪注释与可读性相比,与约定俗成(也就是解析器)的冲突要少。

If you find you need to use pseudo-comments:

如果发现需要使用伪注释:

  • Stick to the C and Unix convention and use either // or # for the pseudo-comment delimiter.

    坚持使用C和Unix约定,并使用//#作为伪注释定界符。

  • Place pseudo-comments on the same line before the item to be ignored.

    将伪注释放在要忽略的项目之前的同一行上。
  • Use whitespace to separate the pseudo-comment delimiter from the intended rule ~ e.g. # background: ignored;.

    使用空格将伪注释定界符与预期规则分开,例如# background: ignored;

Use pseudo-comments:

使用伪注释:

  • Use pseudo-comments for debugging, notably when using an interactive CSS edit panel, such as Chris Pederick’s Web Developer extension (chrome, firefox, opera).

    使用伪注释进行调试 ,尤其是在使用交互式CSS编辑面板时,例如Chris Pederick的Web Developer扩展 (chrome,firefox,opera)。

  • Use pseudo-comments to prevent individual declarations, selectors, or at-rules with bodies from being processed.

    使用伪注释可防止处理带有主体的单个声明,选择器或规则。

Avoid pseudo-comments:

避免伪注释:

  • Avoid pseudo-comments for use with textual descriptions and at-rules without bodies (e.g., @import) ~ use multi-line /* ... */ comments instead.

    避免将伪注释用于文本描述和不带正文的规则(例如@import)〜改用多行 /* ... */注释代替。

  • Avoid the quoting characters '', "" ~ they are hard for human eyes to scan and cannot be terminated on their own line.

    避免使用引号'', "" 〜来使人眼难以扫描,并且不能将其终止。

  • Avoid the grouping characters (), [], {} ~ they introduce more complicated scanning (and cannot be terminated on their own line).

    避免对字符(), [], {}进行分组(), [], {}因为它们会引入更复杂的扫描(并且不能在自己的行上终止)。

  • Avoid pseudo-comments in production code ~ though not “harmful”, they are merely extra bytes at that point.

    避免在生产代码中使用伪注释-尽管不是“有害”,但在那时它们只是多余的字节。

翻译自: https://www.sitepoint.com/pseudo-comments-in-css-or-how-browsers-parse-styles/

css样式兼容、注释

本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系:hwhale#tublm.com(使用前将#替换为@)

css样式兼容、注释_CSS中的伪注释(或者,浏览器如何解析样式) 的相关文章

随机推荐

  • centertrack

    模型70多m 有torch版dla 此外 CenterTrack 很容易扩展到单目 3D 跟踪 只需恢复额外的 3D 属性即可 以单目视频作为输入 以 28 FPS 运行 CenterTrack 在新发布的 nuScenes 3D 跟踪基准
  • Linux 用户和用户组管理

    Linux 用户和用户组管理 Linux系统是一个多用户多任务的分时操作系统 任何一个要使用系统资源的用户 都必须首先向系统管理员申请一个账号 然后以这个账号的身份进入系统 用户的账号一方面可以帮助系统管理员对使用系统的用户进行跟踪 并控制
  • 年度收官饕餮盛宴2010 SD2.0大会即将开幕

    2010年 海量和实时数据处理 丰富极致的用户体验等需求 不断涌现的新技术和新平台 无不对软件研发提出了严峻挑战 面对这十年一遇的技术大变革 技术人员应该如何面对 12月9日 10日 中国IT界公认最高水平 最具实战价值和技术前瞻性 规模最
  • osgEarth的Rex引擎原理分析(一零三)着色器如何绘制文字

    目标 一零一 中的问题184 1 利用着色器直接绘制文字是一种理想但不贴合实际的做法 文字是一个非常高深的问题 Opengl作为一个底层API已经不适合提供对应的接口 2 正确的做法是把文字生成纹理 再由glsl采样绘制 为了避免文字模糊或
  • 怎么调整字体大小_[Citespace]如何调整图谱之节点篇(一)

    Citespace图谱的作用是什么 便于读取信息 什么样的图谱可以做到便于读取信息呢 美观 简洁 清晰 为了更容易从图谱中获取相关信息 便于读者理解 同时也为了论文排版的美观 调整图谱是不可避免的 但是citespace过高的门槛使得众多朋
  • 恒玄BES调试笔记-BES2500如何制作OTA升级包

    进入工程 Shift 鼠标右键 打开Powershell窗口 输入命令即可 PS D best2300a 2500i ibrt gt python generate crc32 of image py best2300a ibrt anc
  • 重新学javaweb----jsp标签

    jsp标签 sun原生提供的标签直接在jsp页面中就可以使用 lt jsp include gt 实现页面包含 动态包含 lt jsp forward gt 实现请求转发 lt jsp param gt 配合上面的两个标签使用 在请求包含和
  • React Native开发之——Webstorm开发RN配置

    前言 前文React Native开发之 Webstorm快捷开发介绍了使用Webstorm快捷开发React Native 本文介绍Webstorm开发RN配置 Webstorm开发RN配置 配置文件编码格式 注 为避免莫名其妙的问题 本
  • R语言(四) -- 获取与读写数据

    获取 访问数据库 install packages RODBC install packages RMYSQL 读取 查看文件头尾 num是一次显示的行号 head x n num tail x n num 参数 header TRUE F
  • hihoCoder 1582 Territorial Dispute

    Problem hihocoder com problemset problem 1582 vjudge net problem HihoCoder 1582 Reference hihocoder 1582 Territorial Dis
  • 【华为OD机试】叠积木【2023 B卷

    题目描述 有一堆长方体积木 它们的长度和宽度都相同 但长度不一 小橙想把这堆积木叠成一面墙 墙的每层可以放一个积木 也可以将拼接多个积木 要求每层的长度相同 最少2层 若必须用完这些积木 叠成的墙最多为多少层 输入描述 输入为一行 为各个积
  • jinfo详解

    目录 前言 一 查看JVM参数 二 修改JVM参数 前言 jinfo是为了查看和修改 支持动态修改的 JVM参数 特别好用 一 查看JVM参数 格式非常简单 如下 jinfo flag name 具体参数名称 pid 比如 查看最大堆内存
  • 【springCloud】服务提供者构建(3)

    1 概述 流程还是和建立注册中心一样 区别主要在配置文件和注释 2 具体配置信息 pom xml
  • spark设置日志级别的4种方式

    修改spark配置文件 修改 Spark HOME conf下的log4j properties 2 spark sumbit设置 spark submit conf spark driver extraJavaOptions Dlog4j
  • 浅聊矢量场 —— 4. 关于 Navier-Stokes方程的一些简单认识

    Navier Stokes 方程 作为千禧年七大数学难题 以我的能力 顶多做到对它有一些浅薄的理解 谈不上有多深入的研究 文中如果有错 还望指出海涵 此外 现在的我没能力证明或者推导这个公式 有能力证明或推到公式的人属于有能力拿诺贝尔物理奖
  • 时序数据预测实现——基于卷积神经网络结合BiLSTM附matlab代码

    时序数据预测实现 基于卷积神经网络结合BiLSTM附matlab代码 时序数据分析是对时间序列相关问题进行建模 预测和描述的一个领域 这个领域在金融 医疗 气象等众多领域都有着广泛的应用 在本次任务中 我们将介绍如何使用卷积神经网络结合双向
  • 服务注册中心etcd

    etcd简介 etcd官方描述 A distributed reliable key value store for the most critical data of a distributed system etcd is a stro
  • QTCN注册之一个小问题

    qtcn的注册会让你生无可恋 QPrinter类在哪个模块中 正确答案 printsupport Qt线程类是 正确答案 QThread QGuiApplication的父类是 正确答案 QCoreApplication QWidget在哪
  • protobuf反射

    C 本身是不支持反射的 但protobuf可以 下面介绍反射的两种主要的用途 通过proto对象的名字来创建一个对象 google protobuf Message ProtoHelp createMessage const std str
  • css样式兼容、注释_CSS中的伪注释(或者,浏览器如何解析样式)

    css样式兼容 注释 The CSS spec does not mention it but you can mimic C style and or Unix style line comments in CSS files with