问题标签 [parsing-error]

这是一个常见问题，我已经研究了谷歌可以提供的所有答案，所以我很抱歉再次问这个问题。

Firebug 将响应显示为

jsonlint.com 说 json 是有效的，但为什么 apache 将 Doctype 放在响应前面？这是导致错误吗？

Firebug 还将标题报告为：

我正在使用来自 DataTables 的 server_processing.php 脚本

我的 php 的相关部分是：

我已经浪费了很多时间来解决这个问题，所以非常感谢任何帮助。

我想在服务器上发布我的网站，但我收到了这种类型的错误。

不知道这是怎么回事？我该如何解决这个错误。

我在最近的三个项目中遇到了无法调试的问题。在每个项目中创建每两三个活动后我得到的相同错误是：-

此错误出现在 AndroidManifest.xml 文件中。

为此，我正在使用 Google 提供的 ADT Eclipse。

这个错误是可调试的，还是我必须删除项目并重新开始，直到错误再次出现？

我有一个世界地图的正交投影，在 D3 中并使用 TopoJSON。我通过调用此代码为每次加载数据的国家/地区着色。地球在不停地旋转。

我的问题是，在旋转过程中我收到错误消息：

错误

>> 错误：在 d3.v3.min.js:1 中解析 d="" >> 时出现问题

对于每个：

首先，我认为它取决于 topojson 脚本，因为有不同的版本。但它没有。

javascript代码：

初始化地球/投影的属性：

从 json 和 tsv 读取数据并附加土地和国家：

地球自转：

我无法让网络资源与 activemerchant 合作。Activemerchant 与 authorize.net 和 paypal 配合得很好。我正在尝试从控制台对其进行测试，因为它在站点中失败了。

这是我回来的错误：

任何建议在这里将不胜感激！！！

谢谢，

抢。

-------这是假的抄送信息------

这里也是生成的 XML：（编辑了私人信息）

新信息：

有趣的是，如果我使用上面的 XML（使用正确的商家 ID 等）并使用 curl 通过生产网关处理它，我会得到：

Roberts-MacBook-Air:documents rlittle$ curl --header "content-type: application/soap+xml" --data @testxml2.xml https://ics2ws.ic3.com/commerce/1.x/transactionProcessor

所以一定是gem中的xml解析问题？？？

我正在研究 Gerrit。我知道它具有在提交消息的页脚消息中查找更改 ID 的默认行为。现在我的问题是可以更改此更改此行为。如果是，请向我提供有关此的想法。我希望 gerrit 解析所有消息以检查更改 Id 不仅是页脚。

我的语法显然是错误的，因为解析简单文件会产生奇怪的错误消息。

我在不改变错误的情况下尽可能地简化了以下语法（如果您删除'this'ANTLRWorks 的树 gui 输出，int则示例文件的标记会以不同的方式着色，尽管结构似乎是相同的）。

演示代码：

ANTLRWorks 2 给了我以下错误信息：

我在用 JK 触发器编码 3 位计数器时遇到了这个问题，我碰巧在 XILINX VHDL 自动编写的 34 行中有一个错误，所以我对实际错误感到困惑。

所以，错误说：

错误：HDLParsers：164 - 第 34 行。解析错误，意外 INTEGER_LITERAL，期待 IDENTIFIER 解析“3bitBrojacTest_vhd_stx.prj”：1.27

如果有人知道如何解决这个问题，我会很高兴得到这个答案。多谢你们！

Grammar:

Input:

Question: Which error message correct at position 2 for given input?

P.S.

I write parser and I have choice (dilemma) take into account that "b" expected at position or not take.

The #1 error (expected "b", "c") want to say that input "a b" expected but because it optional it may not expected but possible.

I don't know possible is the same as expected or not?

Which error message better and correct #1 or #2?

Thanks for answers.

P.S.

In first case I define marker of testing as limit of position.

Limit moved in optional expressions:

The "b" expression move _inputPos above the testing pos and add failure at _inputPos.

In second case I can define marker of testing as boolean flag.

The "b" expression in this case not add failure because it tested (inner for optional expression).

What you think what is better and correct?

1. Testing defined as specific position and if expression above this position (_inputPos > testing) it add failure (even it inside optional expression).

2. Testing defined as flag and if this flag set that the failures not takes into account. After executing optional expression it restore (not reset!) previous value of testing (true or false).

Also failures not takes into account if rule not fails. They only reported if parsing fails.

P.S.

Changes at 06 Jan 2014

This question raised because it related to two different problems.

First problem:

Parsing expression grammar (PEG) describe only three atomic items of input:

• terminal symbol
• nonterminal symbol
• empty string

This grammar does not provide such operation as lexical preprocessing an thus it does not provide such element as the token.

Second problem:

What is a grammar? Are two grammars can be considred equal if they accept the same input but produce different result?

Assume we have two grammar:

Grammar 1

rule <- type? identifier

Grammar 2

rule <- type identifier / identifier

They both accept the same input but produce (in PEG) different result.

Grammar 1 results:

• {type : type, identifier : identifier}
• {type : null, identifier : identifier}

Grammar 2 results:

• {type : type, identifier : identifier}
• {identifier : identifier}

Quetions:

• Both grammar equal?
• It is painless to do optimization of grammars?

My answer on both questions is negative. No equal, Not painless.

But you may ask. "But why this happens?".

I can answer to you. "Because this is not a problem. This is a feature".

In PEG parser expression ALWAYS consists from these parts.

ORDERED_CHOICE => SEQUENCE => EXPRESSION

And this explanation is the my answer on question "But why this happens?".

Another problem.

PEG parser does not recognize WHITESPACES because it does not have tokens and tokens separators.

Now look at this grammar (in short):

program <- WHITESPACE expr EOF

expr <- ruleX

ruleX <- 'X' WHITESPACE

WHITESPACE < ' '?

EOF <- ! .

All PEG grammar desribed in this manner.

First WHITESPACE at begin and other WHITESPACE (often) at the end of rule.

In this case in PEG optional WHITESPACE must be assumed as expected.

But WHITESPACE not means only space. It may be more complex [\t\n\r] and even comments.

But the main rule of error messages is the following.

If not possible to display all expected elements (or not possible to display at least one from all set of expected elements) in this case is more correct do not display anything.

More precisely required to display "unexpected" error mesage.

How you in PEG will display expected WHITESPACE?

• Parser error: expected WHITESPACE
• Parser error: expected ' ', '\t', '\n' , 'r'

What about start charcters of comments? They also may be part of WHITESPACE in some grammars.

In this case optional WHITESPACE will be reject all other potential expected elements because not possible correctly to display WHITESPACE in error message because WHITESPACE is too complex to display.

Is this good or bad?

I think this is not bad and required some tricks to hide this nature of PEG parsers.

And in my PEG parser I not assume that the inner expression at first position of optional (optional & zero_or_more) expression must be treated as expected. But all other inner (except at the first position) must treated as expected.

Example 1:

This failure take into account and report as "expected '>'" This is because we not skip "type" but enter into "type" and after really optional "List" we move position from first to next real "expected" (that already outside of testing position) element.

"List" was in "testing" position.

If inner expression (inside optional expression) "fits in the limitation" not continue at next position then it not assumed as the expected input.

From this assumption has been asked main question.

You must just take into account that we are talking about PEG parsers and their error messages.

PHP 新手。遇到“解析错误：语法错误，意外的 T_CONSTANT_ENCAPSED_STRING”问题

这是代码：

任何帮助将不胜感激。谢谢。-马特