编译原理action表如何求

① 如何产生action表和goto表

首先，action指的是响应FORM提交事件的页面，如：
<form name="form1" method="post" action="act.asp">
<input type="text" name="txt1">
</form>
则：act.asp就是接收FORM内容的页面。
在act.asp中写：
txt2=request("txt1")
即可以act.asp页面中，将文本框“txt1”中的内容赋值给变量txt2

② LR分析法的LALR(1)分析表的构造

上述每个LR(1)项目均由两部分组成： 第一部分是一个LR(0)项目，称为LR(1)项目的核；第二部分则是一个向前搜索符号集。对于移进项目而言，搜索符号对分析表的构造无影响；但对归约项目而言，则仅在当前输入符号属于该搜索符号集时，才能用相应的产生式进行归约。LR(1)分析表的这种机理，较圆满地解决了SLR(1)分析所难以解决的某些“移进归约”或“归约归约”冲突，从而使LR(1)的分析能力比SLR(1)分析有明显的提高。然而，LR(1)分析的主要缺点在于，对同一个文法而言，LR(1)分析表的规模将远远大于相应的SLR(1)或LR(0)分析表。例如，为一个C语言构造LR(0)分析表，一般大约设置300个状态即可，而构造LR(1)分析表则需上千个状态，即后者将导致时间和内存空间开销的急剧上升。因此，就有必要寻求一种其分析表的规模与SLR(1)相当，但其分析能力又不比LR(1)相差太大的LR分析方法，这就是下面我们要介绍的LALR(1)分析技术。
下面，我们首先对造成LR(1)项目集族规模大幅度上升的原因进行分析，然后再设法从中找出构造高效LR分析表 (即LALR(1)分析表)的方法。为此，试看下面的例子。
再考察文法G[E]：
0?S→E4?T→F
1?E→E+T5?F→(E)
2?E→T6?F→ID
3?T→T*F
利用上面所给算法，为G[E]构造的LR(1)项目集族和识别活前缀的DFA如图420(a)，(b)所示 (请注意，由于图幅较大，这里将其划分为(a)，(b)两部分)。对比这两幅图我们立即就会发现，除其中的状态0和状态3之外，对于(a)中的每一状态 (LR(1)项目集)，在(b)中都有一个状态 (LR(1)项目集)与其相似。例如，比较状态7和16：在这两个项目集中，除搜索符号集不同外，各个LR(1)项目的核都彼此相同 (即产生式相同，且产生式中圆点的位置也相同)，我们把具有这种特点的两个LR(1)项目集称为同心集。所以，在图420(a)和(b)中，7/16，5/12，10/17，4/13，8/18，2/14，11/19，6/20，1/15和9/21都是同心集。显然，在LR(0)分析器中，每个“心”仅对应一个LR(0)项目集；但在LR(1)分析器中，由于向前搜索符号的不同，同一个“心”将会派生出多个同心集。这就是对同一文法而言，LR(1)项目集族远大于LR(0)项目集规范族的原因。
7E→E+·T[]#+T→·T*F
T→·F
F→·(E)
F→·ID〖〗#+*
#+*
#+*
#+*[][]16E→E+·T[]+)T→·T*F
T→·F
F→·(E)
F→·ID〖〗+)*
+)*
+)*
+)*
为解决上述问题，F?DeRemer提出了LALR(1)分析法。这种方法的基本思想是将LR(1)项目集族中的同心项目集加以合并，以削减项目集的个数。所谓合并同心集，实际上也就是将其中的每个LR(1)项目的向前搜索符集对应地合并在一起。例如，对于文法G[E]的同心项目集4和13，设合并后的新项目集为4/13，则有
4E→T·
T→T·*F〖〗#+
#+*[][]13E→T·
T→T·*F〖〗+)
+)*[][]4/13E→T·
T→T·*F〖〗#+)
#+)*
由于同心集的合并，对原来识别活前缀的DFA也须作相应的修改。
对于LALR(1)项目集族，我们须着重指出如下几点：
(1) 合并同心集也就是将同心集中每个LR(1)项目的两个组成部分 (核及向前搜索符号集)分别、对应地合并在一起。设I1,I2,…,Im为同心项目集，J是合并之后的新的项目集，显然J与Ii同心；再设X∈V∪{#}，则GO(I1,X),GO(I2,X)，…，GO(Im,X)也必然同心，若把这m个同心项目集合并后的新项目集记为K，则有GOTO(J，X)=K。可见前面定义的GOTO函数在这里仍然适用。
(2) 尽管原来各LR(1)项目集均不存在冲突，但合并同心集后就有可能出现冲突。换言之，即LR(1)文法未必总是LALR(1)文法。不过，由此引入的冲突只能是“归约归约”冲突，而决不会是“移进归约”冲突。事实上，设原LR(1)项目集族中有如下两个项目集
Ik：
[A→α·，W1]
[B→β·aγ,b]Ij:
[A→α·,W2]
[B→β·aγ，c]
并设Ik与Ij均无冲突，故有
W1∩{a}=?W2∩{a}=?
从而
(W1∪W2)∩{a}=?
现将Ik与Ij合并，有
Ik/j:
[A→α·,W1∪W2]
[B→β·aγ，{b}∪{c}]
若此时Ik/j有“移进归约”冲突，则必有
(W1∪W2)∩{a}≠?
这就与Ik与Ij无冲突的假设相矛盾。因此，合并同心集不会引入新的“移进归约”冲突。
(3) 对同一个语法上正确的输入符号串而言，不论用LALR(1)分析表还是用LR(1)分析表进行分析，所经历的移进、归约序列总是相同的 (仅状态名可能不同)。然而，当输入符号串有错时，LALR分析器可能会比LR(1)分析器多进行几步归约才能报错，但决不会比LR分析器多移进输入符号。也就是说，LALR分析器虽然可能延迟了发现出错的时间，但对错误的准确定位不产生影响。
(4) LALR(1)项目集族总是与同一文法的SLR(1)项目集族有同样个数的项目集。但是构造LALR项目集族的开销比SLR大。实现LALR分析对文法的要求比LR(1)严、比SLR(1)宽，但开销远小于LR(1)。权衡利弊的结果，LALR堪称为当前实现自底向上语法分析，特别是构造分析器自动生成工具的最为适用的技术。
综上所述，可给出构造LALR(1)分析表的算法如下。
1? 对已给的拓广文法G′，构造相应的LR(1)项目集族C={I0,I1,…,In}。
2? 对于C，将各LR(1)项目集按同心关系进行分组，并将同组的同心集加以合并，设所得的新项目集族为C′={J0,J1,…,Jm}，其中含有项目[S′→·S,#]的项目集对应于初态。
3? 若C′中的项目集含有冲突项目，则G′不是LALR(1)文法。否则，可按如下法则构造LALR(1)分析表：
(1) 用构造LR(1)分析表类似的方法构造ACTION表；
(2) 对于某个X∈VN，若有GO(Jk,X)=Jt，则置GOTO(k,X)=t。
上述通过构造LR(1)项目集族和合并同心集来构造LALR分析表的方式仅有理论意义而无实用价值。因为构造完整的LR(1)项目集族的时间和空间开销都很大，故应首先设法予以解决。
迄今已有多种高效构造LALR分析表的算法，其共同的特点都是不从直接构造完整的LR(1)项目集入手，而是通过构造LR(0)项目集并添加相应的向前搜索符号来形成LALR(1)项目集 (请注意，对同一个文法而言，LALR(1)项目集与同心的LR(0)项目集一一对应)。例如，OCCS/YACC构造LALR(1)项目集所采用的策略是，每当创建一新的项目集时，就检查目前是否已存在与之同心的项目集，若有这样的项目集，则只需将向前搜索符号加入其中，而不再建立新的项目集。一种更为有效的方法甚至无需构造完整的LALR(1)项目集，而仅通过各个项目集中的“核心项目”便能构造相应的LALR(1)分析表。这里所说的核心项目是指形如[S′→·S，#]的项目 (其中，S′→S是拓广文法的第1个产生式)，或者是形如[A→α·Xβ,a]的项目 (其中，α≠ε，即圆点不出现在产生式右部的最左位置)，亦即那些用于构造本项目集闭包的“基本项目”。例如，对于文法G[E]，各项目集的核心项目如图422所示。
下面，我们对利用项目集的核心项目构造LALR分析表的原理进行说明。 构造ACTION表的关键在于确定“归约”和“移进”两种动作。
(1) 归约动作的确定
由核心项目的定义可知，任何归约项目都必然会出现在某个项目集的核心项目之中，现设项目集I的核心为K，若[A→α·,a]∈K (其中α≠ε，搜索符号如何配置下面再介绍)，我们立即可以确定： 在当前状态下所面临的输入符号为a时，应按产生式A→α进行归约，即有
ACTION[I,a]=rj
若α=ε，则当且仅当
[B→γ·Cδ， b]∈KC?*[]rAη
且a∈FIRST(ηδb)时，才能确定面临输入符号a时用产生式A→ε进行归约。由于对任何C∈VN，满足C?*[]rAη的所有非终结符号A预先能完全确定，故项目集I所引发的归约动作，仅由其核心K即能完全确定。
(2) 移进动作的确定
若
[A→α·Xβ,b]∈KX?*[]raη(a∈VT)
且上述推导的最后一步未使用ε产生式，则可确定： 状态I面临输入符号a时的动作为“移进”。其中，终结符号a可通过预先计算FIRST(X)加以确定。 对于任何项目[B→γ·Xδ,b]∈K，相应的项目[B→γX·δ,b]显然必属于某个项目集J=GO(I，X)的核心L。另外，若
[B→γ·Cδ,b]∈KC?*[]rAη
且A→Xβ是文法中的一个产生式，则对于任何
a∈FIRST(ηδb)[A→X·β,a]∈L
由于对每一对非终结符号(C，A)，是否存在关系C?*[]rAη，可采用类似于计算FIRST集的方法预先求出，故仅从I的核心同样可构造出GOTO表。 上面的讨论，是在假定每个核心项目都已配置了搜索符号的情况下进行的。现在，再回头讨论： 如何为每个LR(0)项目集的核心项目配置搜索符号，使之成为LALR项目集的核心项目。为此，我们首先考察搜索符号从项目集I传播到项目集GO(I，X)的规律。
再设项目集I的核心为K，若有
[B→γ·Cδ,b]∈KC?*[]rAη
且A→Xβ是文法中的一个产生式，则根据上面的讨论有
[A→X·β,a]∈La∈FIRST(ηδb)
其中L是项目集J的核心，且J=GO(I,X)。现分如下两种情况讨论搜索符号a和b间的关系。
(1) 当ηδ?*ε时，显然也有[A→X·β,b]∈L。此时，我们就说项目[A→X·β,b]中的搜索符号b是从项目[B→γ·Cδ,b]中传递过来的 (propagate)。
(2) 当ηδ不能推导出ε时，a仅取决于η或δ，而与b无关，此时我们就说搜索符号a是自生的 (spotaneous)。
无论a是传递的还是自生的，它总能根据项目[B→γ·Cδ,b]中的有关信息，通过上述计算获得，这便是搜索符号从项目集I传播到项目集J的规律。
其次，在同一项目集中，核心项目中的搜索符号向非核心项目传播的规律与上述规律极为相似。事实上，设[B→γ·Cδ,b]∈K，而C→α是文法中的一个产生式，则[C→·α，c]是I的一个非核心项目。其中，搜索符c∈FIRST(δb)，且按如下方法确定： 若δ不能推出ε，则c是自生的；否则，c=b，即c是从上面的项目传递下来的。
类似地，也可讨论搜索符号在非核心项目间的传播规律。例如，对于文法G[E]，从核心项目[S→·E，#]开始，向前搜索符号在I0中的传递和自生的情况如图423所示。
设K是LR(0)项目集I的核心，X是某个文法符号，则对GO(I，X)的核心中的每一项目A→αX·β，通过程序47描述的操作 (请注意，这里使用了一个虚拟搜索符号lookahead)，可由I中的项目确定其全部自生的搜索符号，并能确定K中的哪些项目将其搜索符号传递给GO(I，X)中的项目A→αX·β。
程序47确定自生搜索符号和传递搜索符号的项目
for (K中的每个项目B→γ·δ)
{
J′=CLOSURE ([B→γ·δ,lookahead]);
/*计算GO函数之值 */
for (J′中的每一项目[A→α·Xβ,a])
{
if(a!=lookahead)
确定GO(I，X)核心项目[A→αX·β,a]
之搜索符号a是自生的
if(a==lookahead)
确定GO(I，X)核心项目[A→αX·β，a]之搜索符号a是从K中项目
B→γ·δ传递过来的；
}
}
最后，我们再考虑如何给每个LR(0)项目集的核心中的各个项目都配置一个搜索符号集，以获得各个LALR(1)项目集的核心。完成此项任务的大致过程如下。
(1) 为拓广文法G′构造全部LR(0)项目集的核心。
(2) 首先从初始项目集I0惟一的核心项目S′→·S (其搜索符号显然为#)开始，对每个LR(0)项目集的核心和每个文法符号X，利用上面的算法，确定GO(I，X)各核心项目的自生搜索符号集，并确定从I的哪些项目将搜索符号传递到GO(I，X)的核心项目。
(3) 按某种便于操作的结构，建立一张核心项目表，此项目表记录了每个项目集的各个核心项目及其相应的搜索符号集。开始时，这些搜索符号集仅是由第(2)步所确定的自生搜索符号集 (若该核心项目无自生向前搜索符号则为空)。
(4) 传递每个核心项目中的自生搜索符号，直到无法再进行传递为止。即反复扫视各项目集的每个核心项目，每当访问一个核心项目i时，便根据第(2)步所获的信息，将i当前要传递的搜索符号添加到承接它的那个核心项目之中，直至没有新的搜索符号要传递为止。
对一个给定的文法G而言，当它的各个LALR(1)项目集的核心构造出来之后，就能根据上面所描述的原理，为G构造相应的LALR(1)分析表。不过，尽管上述构造LALR分析表的方法效率较高，但对于常见的程序设计语言，企图用手工的方式来建立LALR分析表仍几乎是不可能的。所幸的是，目前已有一些自动生成LALR分析表的工具可资使用(如YACC)。
还应当指出，在构造LR语法分析器时，尚有若干技术问题需予以考虑，如二义性文法的处理，避免按单产生式的归约，等等。前者我们将在第5章介绍语法分析器自动生成工具时再进行讨论；至于后者，由于需涉及一些语义处理及其信息传递的细节，故就不再讨论了。
在结束本章时，我们还要给出如下的结论，这些结论的证明读者可参阅有关的文献(1，2，8，15)。
(1) 任何LR(K)，LL(K)及简单优先文法类都是无二义性的；对于算符优先文法，如果不考虑归约所得非终结符号的名字，也可认为是无二义性的。
(2) 任何二义性的文法都不可能是LR(1)(或LL(1))文法，但可借助于其它因素，如算符的优先级和结合规则以及某些语义解释等等，来构造无冲突的分析表。
(3) 每个SLR(K)文法都是LR(K)文法，但却存在这样的LR(1)文法，它对任何K而言均不是SLR(K)文法。

③ 急急急，编译原理

using namespace std;

struct BiNode
{
char data;
BiNode *lchild, *rchild;
};
typedef BiNode *BiTree;

int CreateBiTree(BiTree &T, const char *s1, const char *s2, int len)
{
if (len<=0)
{
T = NULL;
return 1;
}
else
{
T = new BiNode;
T->data = *s1;
int i;
for ( i=0; i<len; i++) if (s2[i]==*s1) break;
CreateBiTree(T->lchild, s1+1, s2, i);
CreateBiTree(T->rchild, s1+i+1, s2+i+1, len-(i+1));
}
return 1;
}

int DestroyBiTree(BiTree &T)
{
if (T==NULL) return 1;
DestroyBiTree(T->lchild);
DestroyBiTree(T->rchild);
delete T;
T = NULL;
return 1;
}

int ATraverse(BiTree &T)
{
if (T==NULL) return 1;
ATraverse(T->lchild);
ATraverse(T->rchild);
cout<<T->data;
return 1;
}

main()
{
char a[2000],b[2000];
while(cin>>a>>b)
{
BiTree T;
int count=0;
int n;
for(n=0;a[n]!='\0';n++);
CreateBiTree(T,a,b,n);
ATraverse(T);
cout<<" ";

cout<<endl;
DestroyBiTree(T);

④ 求 编译原理 语法分析程序

可以参考我的空间，我在三年前写过类似代码。
http://hi..com/逄韶华/ihome/myblog

⑤ 有关编译原理

⑴拓广文法 1 分
G[S ′ ]: S ′→ S ⑴
S → SaA ⑵ S → a ⑶ A → AbS ⑷ A → b ⑸
该文法的以 LR(0) 项目集为状态的识别规范句型活前缀的 DFA ：

⑵ 该文法的 LR(0) 分析表：
状态 ACTION GOTO
a b # S A
0 S 2 1
1 S 3 acc
2 r 3 r 3 r 3
3 S 5 4
4 r 2 r 2 /S 6 r 2
5 r 5 r 5 r 5
6 S 2 7
7 r 4 /S 3 r 4 r 4
⑶ LR(0) 文法：该文法的以 LR(0) 项目集为状态的识别规范句型活前缀的 DFA 中没有冲突状态。
该文法不是 LR(0) 文法
因为存在冲突状态： I 4 和 I 7
⑷ SLR(1) 文法：该文法的以 LR(0) 项目集为状态的识别规范句型活前缀的 DFA 中有冲突状态，冲突可用 FOLLOW 集解决。
该文法不是 SLR(1) 文法。
因为 FOLLOW(S)={a,b,#} ，所以无法解决冲突

⑥ 编译原理 有文法G（S）这道题怎么做

首先扩展文法为：

1)S1->S

2)S->aS

3)S->bS

4)S->a

则：

I0=Closure({S1->.S})={S1->.S,S->.aS,S->.bS,S->.a}

go(I0,S)=Closure({S1->S.})={S1->S.}=I1

go(I0,a)=Closure({S->a.S,S->a.})={S->a.S,S->.aS,S->.bS,S->.a,S->a.}=I2

go(I0,b)=Closure({S->b.S})={S->b.S,S->.aS,S->.bS,S->.a}=I3

go(I2,S)=closure({S->aS.})={S->aS.}=I4

go(I2,a)=Closure({S->a.S,S->a.})=I2

go(I2,b)=Closure({S->b.S})=I3

go(I3,S)=Closure({S->bS.})={S->bS.}=I5

go(I3,a)=Closure({S->a.S,S->a.})=I2

go(I3,b)=Closure({S->b.S})=I3

由图所示，状态I2,既有归约项目(S->a.)又有移近项目(S->.aS,S->.bS,S->.a)，产生冲突。当用SRL分析法时，需向前看一步，即求出：

Follow(S)=Follow(S1)={#}

则，Follow(S)∩{a,b}=∮

故而Action(I2,a)=s2

Action(I2,b)=s3

Action(I2,#)=r4

则构造出srl分析表如下所示：

ActionGoto

ab# S

I0 s2s3 1

I1 acc

I2s2s3 r4 4

I3s2s3 5

I4 r2r2r2

I5 r3r3 r3

⑦ 编译原理——LR分析表

自底向上的语法分析

LR分析表的结构如上，其分为两个部分 Action Goto

两个参数状态i，终结符号a（s(i)代表第i个状态，r(i)代表第i条表达式）

Goto[i,A]=j

文法

容易得知这个文法可以推出 0 1 00 01 等的字符串。因为它是 左递归 。不适用于 LL 文法分析，只能使用 LR 分析。

因为本题入口有两个—— S → L·L S → L ，所以需要构造额外的产生式 S'->S

2.1 第一次遍历

我们从 [S -> . L·L] 开始，构造这个状态的闭包，也就是加上所有能从这个产生式推出的表项。

首先，判断 . 后面是否为 非终结符号A 。如果是，那我们就得找所有由 A-> 推出的产生式，并将它们添加进入 闭包 里(也就是State包里)。循环做即可。

因此我们可以得到 State 0 有

下一步，就是我的 . 往下一位移动。对每个符号X后有个 . 的项，都可以从 State 0 过渡到其他状态。

由以上6条式子可以得知下一位符号可以是 S L B 0 1 。所以自然可以得到5个状态。

State 1 是由 State 0 通过 S 转移到这里的，所以我们找出所有 State 0 中在 S 前有 . 的项。

此状态作为结束状态 Accept ，不需要继续状态转移了。

State 2 是由 State 0 通过 L 转移到这里的，所以我们找出所有 State 0 中在 L 前有 . 的项。

S -> . L·L S -> . L L -> . LB

有3条式子，现在我们将 . 向后推一格，就得到 State 1 的项了。

但是 . 之后的符号分别是 · $ B ， B 为非终结符号，我们得包含 B -> 的项

State 3 是由 State 0 通过 B 转移到这里的，所以我们找出所有 State 0 中在 B 前有 . 的项。

因为 . 后没有其他符号了，因此这个状态不需要继续转移了。

State 4 是由 State 0 通过 0 转移到这里的，所以我们找出所有 State 0 中在 0 前有 . 的项。

因为 . 后没有其他符号了，因此这个状态不需要继续转移了。

很简单，同样的道理找 State 5

State 5 是由 State 0 通过 1 转移到这里的，所以我们找出所有 State 0 中在 1 前有 . 的项。

因为 . 后没有其他符号了，因此这个状态不需要继续转移了。

好的，现在我们第一次遍历完成。

2.2 第二次遍历

第二次遍历自然从 State 2 开始。

我们回到 State2 ，可以看出 . 之后的符号有 · B 0 1 。

State 6 是由 State 2 通过 · 转移到这里的，所以我们找出所有 State 2 中在 · 前有 . 的项。

S -> L. ·L 只有1条，我们往后移发现 L 又为非终结符号，参考 State 0 做的操作，我们得找出所有的式子。

共有5条式子，共同组成 State 6 ，由上面的式子可以看出我们还得继续下一次遍历。先不管着，我们进行下一次状态查找。

State 7 是由 State 2 通过 B 转移到这里的，所以我们找出所有 State 2 中在 B 前有 . 的项。

L -> L. B 也是只有1条，我们往后移发现没有非终结符号了，那就不需要再继续添加其他式子了。

这个状态也不需要继续进行转移了。

接下来很关键，因为我们通过 State2 的 . 后的符号找出了 State 6 State 7 ，接下来还差符号 0 1 ，那么是否像之前一样按例添加状态呢， 答案是不是的 ，因为我们发现通过 0 1 找到的闭包集分别是 B -> 0 B -> 1 ，这与我们的之前的 State 4 State 5 相同。所以我们得将其整合起来，相当于 State 2 通过 0 1 符号找到了 State 4 State 5 状态。

2.3 第三次遍历

回头看第二次遍历，可以看出只有 State 6 可以进行状态转移了。

那么就将 State 6 作为第三次遍历的源头，可以看出 . 之后的符号有 L B 0 1 。

State 8 是由 State 6 通过 L 转移到这里的，所以我们找出所有 State 6 在 L 前有 . 的项。

S -> L· .L L -> . LB 有两条式子，往后移发现有非终结符号 B ，所以经过整合可以得到

可以看出 . 的后面还有一个符号，所以这里我们还得再进行一次遍历。

接下来，又是遇到重复的包的情况，可以看出我们由 State 6 通过 B 0 1 得到的闭包分别是 L->B B->0 B->1 ，很明显，这分别对应于 State 3 State 4 State 5 。

第三次遍历也就结束了。

2.4 第四次遍历

回看第三次遍历，可以看出只有 State 8 可以进行状态转移，其 . 之后的符号分别是 B 0 1 。

诶，感觉很熟悉，就是上面几行刚说的情况，也就是说通过这三个符号找到的闭包是我们之前遇到的状态，分别是 State 3 State 4 State 5 。

做到这里，我们发现我们已经全部遍历完毕！

总共有8个状态，通过以上流程做成个图是什么样子的？来看看！

这么一看就很清晰明了了，我们就可以通过这个图做出我们的 LR分析表

其实就是我们之前呈现的表

在状态 I2 和 I8 中，既有 移入 项目，也有 规约 项目，存在 移入 - 规约的冲突 ，所以不是 LR(0) 文法，但是因为 FOLLOW(S) ∩ {0, 1} = ∅，所以可以用 FOLLOW 集解决冲突，所以该文法是 SLR(1) 文法。

上表我们发现还有 r1，r2，r3 等。这个其实就是代表状态停止转移时为 第几条表达式 ，r3代表第三条表达式 L -> LB 。

当我们构建了表之后，我们如何运用起来呢？

下面我们通过一个例子来说明

以上字符串是如何被SLR分析器识别的呢？

⑧ [高分,急!]编译原理LR(1)分析表题目

I0： S->.T,# T->.T(T),#
I1: S->T.,# T->T.(T),#
I2: S->T(.T),# T->.T(T),) T->.ε,)
I3: S->T(T.),# T->T.(T),)

(1,() 是s2
(1,#) 是acc (就是接受)
T下1 是1
T下3 是3

⑨ 如何用post的方式请求一个action

方法1：根据【成功控件】定义，我们设置按钮的name，在服务端用name来区分哪个按钮的提交：
HTML代码
<form action="Handler1.ashx" method="post">
<p>客户名称: <input type="text" name="CustomerName" style="width: 300px" /></p>
<p>客户电话: <input type="text" name="CustomerTel" style="width: 300px" /></p>
<p><input type="submit" name="btnSave" value="保存" />
<input type="submit" name="btnQuery" value="查询" />
</p>
</form>

服务端处理代码
// 注意：我们只要判断指定的name是否存在就可以了。
if( string.IsNullOrEmpty(context.Request.Form["btnSave"]) == false ) {
// 保存的处理逻辑
}
if( string.IsNullOrEmpty(context.Request.Form["btnQuery"]) == false ) {
// 查询的处理逻辑
}

方法2：我将二个按钮的name设置为相同的值（根据前面的成功控件规则，只有被点击的按钮才会提交），在服务端判断value，示例代码如下：
<form action="Handler1.ashx" method="post">
<p>客户名称: <input type="text" name="CustomerName" style="width: 300px" /></p>
<p>客户电话: <input type="text" name="CustomerTel" style="width: 300px" /></p>
<p><input type="submit" name="submit" value="保存" />
<input type="submit" name="submit" value="查询" />
</p>
</form>

string action = context.Request.Form["submit"];
if( action == "保存" ) {
// 保存的处理逻辑
}
if( action == "查询" ) {
// 查询的处理逻辑
}

当然了，解决这个问题的方法很多，我们还可以在提交前修改form.action属性。 对于MVC来说，可能有些人会选择使用Filter的方式来处理。最终选择哪种方法，可根据各自喜好来选择。

⑩ html表单的action如何定义

?号代表当前页，，就是Post到到前页

action是跟的是地址
?代表当前页
xxx.html或者xxx.asp，或者xxx.php，，，这些代表，跟当前面同级下的文件。
action="/xxx.php" 代表是根目录下的xxx.php
顺便说一下，txt是文本格式，不是超文本，，，建议你在还没有了解网页的基础的时候先不要去了解这些，，，如果有书，你先把最前面介绍那几页先看了先。