stanford-oval/wikipedia huggingface dataset:
柯蒂斯飞机与发动机公司
歷史 > 柯蒂斯飛机与發動机公司（Curtiss Aeroplane and Motor Company）

柯蒂斯飛机与發動机公司是由Curtiss Aeroplane Company of Hammondsport, New York及Curtiss Motor Company of Bath, New York於1916年1月13日合併而來。1916年2月Burgess Company of Marblehead, Massachusetts也成為公司的子公司。
柯蒂斯通過訓練飛行員並提供飛機開展了美國海軍航空業務。第一單主要的合同是為其製造144架Model F水上教練機的衍生型。1914年寇帝斯引進了來自於Sopwith公司的B. Douglas Thomas設計了Model J教練機，這就是後來的JN-4。 由於一戰的開始，軍用合同急速增長，柯蒂斯也需要快速擴張。1916年公司將總部及大部分製造工序都搬遷至紐約州的布法罗，在那裡有更便捷的運輸、人力、製造業，而且還有公司急需的資本。公司在多倫多、安大略開始了產品及教練的配套經營，1915年，公司在加拿大開辦了第一個飛行學校。
柯蒂斯飛机与發動机公司與英國及加拿大合作。当时其最著名的产品JN4型双座双翼飞机就是在加拿大製造而在英格蘭大量用作教練機。為了完成Curtiss Jenny双座双翼教練飞机的大量軍方合約。生產被分給多達5個其他的製造商。HS-2L水上飛機在戰爭中被廣泛地用於反潛巡邏。為了完成合約，其主要部件分散在加拿大的新斯科舍、法國和葡萄牙生產。 皇家海軍也與寇帝斯合作製造水上飛機，尤其表現在1919年柯蒂斯公司制造的NC-4型水上飞机完成了第一次跨大西洋飞行上。柯蒂斯飛机与發動机公司在一戰期間成為了世界上最大的飛機製造商。它在布法罗有18000名雇员，在格伦·柯蒂斯盛产葡萄酒的家乡Hammondsport有3000名雇员。在第一次世界大战期间，柯蒂斯公司共生产了10000架飞机，最多的一个星期制造了超过一百架的飞机。
和平的到來帶來了戰時合同的取消，1920年9月柯蒂斯飛机与發動机公司遭遇了財務重組，Glenn Curtiss兌現了其在公司裡的股份，合三千兩佰萬美元，並在佛羅里達州退休。 他繼續在公司裡擔任director，但僅為設計做顧問。Clement M. Keys控制了公司，公司成為一個大型航空製造集團的核心。
Curtiss seaplanes在1923年及1925年连续两次比赛中贏得了Schneider Cup。1923年的比赛是由美国海军中校（Lieutenant）David Rittenhouse使用Curtiss C.R.3赢得的，速度为177.266英里每小時（285.282每小時）。
由美国陆军中校Cyrus K. Bettis駕駛的Curtiss R3C於1925年10月12日贏得了Pulitzer Trophy Race，時速達248.9英里每小時（400.6每小時）。13天以後, Jimmy Doolittle使用同一架飛機裝上浮筒後贏得了Schneider。Doolittle達到的最高時速是232.573英里每小時（374.290每小時）.
歷史 > 柯蒂斯-萊特公司

1929年7月5日柯蒂斯公司同莱特航空及其各自下属的11家子公司和并成为柯蒂斯-莱特公司。由柯蒂斯飛機與發動機公司最後提出的項目之一是一架極具野心的Curtiss-Bleecker SX-5-1 Helicopter。
第二次世界大战期间，柯蒂斯公司制造了逾3000架C-46型运输机，逾7000架SB2C型飞机，以及飞虎队使用的P-40型战斗机。
產品 > 飛機

Curtiss Carrier Pigeon
Curtiss CT-1
Curtiss Model D
Curtiss HS
Curtiss Hawk
Curtiss J
Curtiss Model N
Curtiss JN-4 "Jenny"
Curtiss Lark
Curtiss K-12
Curtiss Model H
Curtiss Oriole
Curtiss Robin
Curtiss Tanager
產品 > 航空引擎

Curtiss C-6
Curtiss D-12
Curtiss OX-5
Curtiss OXX
Curtiss V-1570
Curtiss V-2
外部連結

The Curtiss Company: U.S. Centennial of Flight Commemoration
History of the Aerospace Industry in Buffalo, NY （页面存档备份，存于）
Curtiss Aeroplane and Motor Company, Virtual Aircraft Museum
參見

航空主题
美国主题
柯蒂斯-萊特公司
Alfred V. Verville
John Porte
Long Branch Aerodrome, Mississauga, Ontario was home of the Curtiss Flying School from 1915 to 1919.
| 0 | 1 | 2 |
| --- | --- | --- |
| 前任： 柯蒂斯飛机公司 Curtiss Aeroplane Company | 柯蒂斯飛机与發動机公司 Curtiss Aeroplane and Motor Company 1916–1929 | 繼任： 柯蒂斯-萊特公司 Curtiss-Wright Corporation  |
柯蒂斯軍用飛機在測試中，攝於College Park, Maryland circa 1912
JN-4，該公司的產品之一
丹妮亚·拉米雷兹

| 丹妮亚·拉米雷兹 |
| --- | --- |

女艺人
英文名: Dania Ramirez
国籍:  美国
出生:  (1979-11-08) 1979年11月8日（44歲）  圣多明各
职业: 演员、模特、歌手
教育程度: 蒙特克莱尔州立大学
代表作品: 《X战警3：最后之战》  《美国派4：美国重逢》 《我家也有大明星》
活跃年代: 1997年至今

丹妮亚·拉米雷兹（英語：，1979年11月8日—）出生于多明尼加共和国的首都圣多明各，是一个多明尼加共和国女演员。
生平

1979年，拉米雷兹出生于多明尼加共和国的首都圣多明各。
早年，拉米雷兹立志成为一个演员，在美国加利福尼亚州洛杉矶被一个星探发掘，成为一个模特儿。
15岁时，拉米雷兹在洛杉矶的一个便利店打工。
1999年，拉米雷兹毕业于蒙特克莱尔州立大学，在学校期间，她是排球队的一员战将。
大学毕业之后，拉米雷兹搬迁到洛杉矶开始从事演艺生涯。
作品 > 电影

| 年份 | 作品> 中文名称 | 作品> 英文名称 | 角色> 角色中文名 | 角色> 角色英文名 | 备注 |
| --- | --- | --- | --- | --- | --- |
| 1997 | 地铁大战 | Subway Series |  | Unknown role |  |
| 2002 |  | 25th Hour |  | Daphne |  |
| 2004 |  | Little Black Boot |  | Laurie Rodriguez |  |
| 2004 |  | Ecology of Love, TheThe·Ecology of Love |  | Alila |  |
| 2004 |  | Cross Bronx |  | Mia |  |
| 2004 |  | She Hate Me |  | Alex Guerrero |  |
| 2004 |  | Fat Albert |  | Lauri |  |
| 2005 |  | Romy and Michelle: In the Beginning |  | Elena | TV movie |
| 2006 | X战警3：最后之战 | X-Men: The Last Stand | 卡利斯托 | Callisto |  |
| 2007 |  | Fort Pit |  | Angela Hardwick |  |
| 2007 |  | Illegal Tender |  | Ana |  |
| 2008 |  | Ball Don't Lie |  | Carmen |  |
| 2008 |  | Fifth Commandment, TheThe·Fifth Commandment |  | Angel |  |
| 2008 | 隔离区 | Quarantine |  | Sadie |  |
| 2009 |  | Solving Charlie |  | Veronica King |  |
| 2010 |  | Brooklyn to Manhattan | 杰西卡 | Jessica |  |
| 2012 | 美国派4：美国重逢 | American Reunion | 赛琳娜 | Selena |  |
| 2012 | 超急快遞 | Premium Rush |  | Vanessa |  |
| 2019 | 逃出魔幻紀：霸氣升呢 | Jumanji: The Next Level |  | Flame | Non-Player Character |
作品 > 电视剧

| 年份 | 作品> 中文名称 | 作品> 英文名称 | 角色> 角色中文名 | 角色> 角色英文名 | 备注 |
| --- | --- | --- | --- | --- | --- |
| 2003 | 吸血鬼猎人巴菲 | Buffy the Vampire Slayer |  | Caridad |  |
| 2003 |  | Run of the House |  | Lucy |  |
| 2004 |  | 10-8: Officers on Duty |  | Inez |  |
| 2005 |  | Dr. Phil |  | Herself/Guest |  |
| 2006–2007 | 黑道家族 | Sopranos, TheThe·Sopranos | 布兰卡 | Blanca Selgado |  |
| 2007–2008 | 英雄 | Heroes | 玛雅 | Maya Herrera |  |
| 2010 | 我家也有大明星 | Entourage | 亚历克斯 | Alex |  |
| 2013 - 2014 | 心機女傭 | Devious Maids | 蘿西 | Rosie Falta |  |
| 2021 | Sweet Tooth：鹿角男孩 | Sweet Tooth | 艾米伊登 | Aimee |  |
奖项荣誉

2011年，拉米雷兹被《美信》评选为“2011年度百大性感女星”。
名字修饰

名字修饰（name decoration），也称为名字重整、名字改编（name mangling），是现代计算机程序设计语言的编译器用于解决由于程序实体的名字必须唯一而导致的问题的一种技术。
它提供了在函数、结构体、类或其它的数据类型的名字中编码附加信息一种方法，用于从编译器中向链接器传递更多语义信息。
该需求产生于程序设计语言允许不同的条目使用相同的标识符，包括它们占据不同的命名空间（典型的命名空间是由一个模块、一个类或显式的namespace指示来定义的）或者有不同的签名（例如函数重载）。
任何由编译器产生的目标代码通常与另一部分的目标代码（产生于同一款或不同款的编译器）通过链接器把它们链接起来。链接器需要一大堆每个程序实体信息。例如正确链接一个函数需要它的名字、参数个数和它们的类型，等等。
C语言的名字修饰

虽然在不支持函数重载的程序设计语言（例如C语言和经典Pascal语言）中基本上不需要名字修饰，但是它们在一些情况下它们还是用了名字修饰来提供了函数的附加信息。
例如，目标于微软Windows平台的编译器支持许多调用约定。这用于决定哪个参数传入子程序的方式和结果返回的方式。因为不同的调用约定彼此不兼容，所以编译器根据的调用约定重整了链接符号。
名字修饰方案由微软公司首创，目前已經被许多其它的编译器非正式采用，例如Digital Mars公司、Borland公司以及Windows移植版的GNU GCC。该方案甚至被其它语言采用，例如Pascal、D语言、Delphi、Fortran和C#。这允许用这此语言写的子程序使用不同于自身默认的调用约定来调用或被调用于已存在的Windows库。
当编译下列C语言代码的的时候：
int _cdecl    f (int x) { return 0; }
int _stdcall  g (int y) { return 0; }
int _fastcall h (int z) { return 0; }
32位编译器对其分别进行名字修饰后的结果是：
_f
_g@4
@h@4
对于stdcall和fastcall调用约定的名字修饰方案中，函数分别被编码为_name@X和@name@X，其中X是形参列表的参数中的十进制的字节数，包括用fastcall传入寄存器的。而对于cdecl调用约定，简单地在函数名前加上一条下划线。
注意Windows的64位Microsoft C的调用约定中没有前导下划线。在一些很罕见的地方，这个差异可能导致代码移植到64位上的时候产生无法解析的外部符号。例如Fortran代码可以使用'alias'（别名）来链接到C方法，如下所示：
SUBROUTINE f()
!DEC$ ATTRIBUTES C, ALIAS:'_f' :: f
END SUBROUTINE
这在32位平台下编译链接得很好，但是在64位的平台将导致无法解析的外部符号'_f'。一个可行的办法是完全不使用'alias'（其中方法名典型的在C语言和Fortran语言中需要大写化），或使用BIND选项：
SUBROUTINE f() BIND(C,NAME="f")
END SUBROUTINE
Visual Basic 6这样的较老的语言，也需要在声明DLL的输出函数时使用Alias，例如：
Public Declare Function test2 Lib "PackingDLL.dll" Alias "_test2@4" (ByVal param As Integer) As Integer
在C语言中，多数编译器还改编在翻译单元中的静态函数和变量（和在C++中的声明为静态或放置在匿名名字空间中的函数和变量），使用与非静态版本相同的修改规则。如果有着相同的名字（和C++中的参数）的函数，也定义和使用在不同的翻译单元中，它也改编为相同的名字，这潜在的会导致冲撞。但是，如果它们分别在自己的翻译单元中被调用，则它们将不是等价的。编译器通常自由的对这些函数施加任意改编，因为直接从其他翻译单元访问这些函数是非法的，所以它们永远不需要在不同的目标代码之间链接。为了防止链接冲突，编译器将使用标准的改编，但使用所谓的'local'符号。在链接很多这种翻译单元的时候，可能出现多个有相同名字的的函数定义，但是结果代码依据调用来自何处而只链接它自己的那个函数。这通常使用重定位（英语：）机制来完成。
C++语言的名字修饰

C++编译器是名字修饰使用得出名的编译器。第一个C++编译器的是翻译成C语言源代码，以便于让C编译器编译成目标代码。正因如此，符号名必须遵守C语言的标识符规则。直至后来，能直接产生机器语言或的编译器出现了以后，系统的链接器也是基本上不支持C++的符号的，所以仍然需要名字修饰。
C++语言并没有规定一个标准的名字修饰方式，所以各款编译器都使用各自的名字修饰方式。C++还有一套复杂的语言特性，例如类、模板、命名空间和运算符重载。这改变了基于上下文或用法的特定符号的意义。关于这些特性的元数据能够用改编（修饰）调试符号的名字来消除二义性。正因为这些特性的名字修饰系统并没有跨编译器标准化，所以几乎没有链接器可以链接不同编译器产生的目标代码。
C++语言的名字修饰 > 简单样例

考虑一个下面的C++程序中的两个f()的定义：
int  f (void) { return 1; }
int  f (int)  { return 0; }
void g (void) { int i = f(), j = f(0); }
这些是不同的函数，除了函数名相同以外没有任何关系。如果不做任何改变直接把它们当成C代码，结果将导致一个错误——C语言不允许两个函数同名。所以，C++编译器将会把它们的类型信息编码成符号名，结果类似下面的的代码：
int  __f_v (void) { return 1; }
int  __f_i (int)  { return 0; }
void __g_v (void) { int i = __f_v(), j = __f_i(0); }
注意g()也被名字修饰了，虽然没有任何名字冲突。名字修饰应用于C++的任何符号。
C++语言的名字修饰 > 复杂样例

一个更复杂一点的样例，下面考虑一个现实生活中的例子，该例子被GNU GCC 3.x的名字修饰规则实现过。改编下列的示例类，改编过的符号在各自的标识符名字下面显示。
namespace wikipedia 
{
   class article 
   {
   public:
      std::string format (void); 
         /* = _ZN9wikipedia7article6formatEv */

      bool print_to (std::ostream&); 
         /* = _ZN9wikipedia7article8print_toERSo */

      class wikilink 
      {
      public:
         wikilink (std::string const& name);
            /* = _ZN9wikipedia7article8wikilinkC1ERKSs */
      };
   };
}
全部被改编过的符号由_Z开头（注意用下划线加大写英文字母是C语言的保留标识符），所以与用户标识符的冲突可以被避免）。嵌套的名字（包括命名空间和类），后面再接一个N，最后一个E。例如wikipedia::article::format将成为：
_ZN·9wikipedia·7article·6format·E
函数后面接形参的类型信息，例如format()是一个形参为void的函数，于是就接一个v，结果是：
_ZN·9wikipedia·7article·6format·E·v
对于print_to，使用了一个标准类型std::ostream（或更准确地说是std::basic_ostream<char, char_traits<char> >），有着特殊的别名So，所以，这个类型的一个引用类型就是RSo，这个函数的完整名字是：
_ZN·9wikipedia·7article·8print_to·E·RSo
C++语言的名字修饰 > 不同编译器如何名字修饰相同的函数

无论多么平凡的C++标识符，名字修饰规则都没有标准方式，所以不同的编译器产商（甚至相同编译器的不同版本，或相同编译器在不同平台上）的名字修饰规则都截然不同，也就意味着基本上都不兼容。看看C++编译器是怎么名字修饰相同的函数的：
| 编译器   | void h(int)  | void h(int, char)  | void h(void)  |
| --- | --- | --- | --- |
| GCC 3.x及更高   | _Z1hi  | _Z1hic  | _Z1hv  |
| Clang  1.x及更高  | _Z1hi  | _Z1hic  | _Z1hv  |
| Intel C++ 8.0 for Linux   | _Z1hi  | _Z1hic  | _Z1hv  |
| HP aC++ A.05.55 IA-64   | _Z1hi  | _Z1hic  | _Z1hv  |
| IAR EWARM C++ 5.4 ARM   | _Z1hi  | _Z1hic  | _Z1hv  |
| IAR EWARM C++ 7.4 ARM   | _Z<number>hi  | _Z<number>hic  | _Z<number>hv  |
| GCC 2.9.x   | h__Fi  | h__Fic  | h__Fv  |
| HP aC++ A.03.45 PA-RISC   | h__Fi  | h__Fic  | h__Fv  |
| Microsoft Visual C++ v6-v10 (修饰详情)   | ?h@@YAXH@Z  | ?h@@YAXHD@Z  | ?h@@YAXXZ  |
| Digital Mars C++   | ?h@@YAXH@Z  | ?h@@YAXHD@Z  | ?h@@YAXXZ  |
| Borland C++ v3.1   | @h$qi  | @h$qizc  | @h$qv  |
| OpenVMS C++ v6.5 (ARM mode)   | H__XI  | H__XIC  | H__XV  |
| OpenVMS C++ v6.5 (ANSI mode)   |   | CXX$__7H__FIC26CDH77  | CXX$__7H__FV2CB06E8  |
| OpenVMS C++ X7.1 IA-64   | CXX$_Z1HI2DSQ26A  | CXX$_Z1HIC2NP3LI4  | CXX$_Z1HV0BCA19V  |
| SunPro CC   | __1cBh6Fi_v_  | __1cBh6Fic_v_  | __1cBh6F_v_  |
| Tru64 C++ v6.5 (ARM mode)   | h__Xi  | h__Xic  | h__Xv  |
| Tru64 C++ v6.5 (ANSI mode)   | __7h__Fi  | __7h__Fic  | __7h__Fv  |
| Watcom C++ 10.6   | W?h$n(i)v  | W?h$n(ia)v  | W?h$n()v  |
注:
在OpenVMS VAX和Alpha（但不是IA-64）和Tru64上的Compaq C++编译器有两套不同的名字修饰方式。原始的，标准前的方式是ARM模式，基于描述于《C++ Annotated Reference Manual (ARM)》中的名字修饰规则。伴随着C++98标准的新特性的到来，尤其是模板，ARM方式变得越来越不合适——它不能编码确定的函数类型，或者对不同函数产生了相同的改编符号。所以它就被新的ANSI模型取代，该模型支持全部的ANSI模板，但是并不能向后兼容。
在IA-64中，存在一种标准的ABI（见外部链接）。它规定了一种标准的名字修饰方式，并且被全部的IA-64编译器使用。此外，GNU GCC 3.x也在其它非Intel架构上采用了在这个标准中规定的名字修饰方式。
Visual Studio和Windows SDK包含了能给定一个已被名字修饰过的符号就能输出C风格函数声明的undname程序。
在Microsoft Windows中，Intel编译器和Clang为了兼容性使用了Visual C++的名字修饰规则。
C++语言的名字修饰 > 从C++中链接时的C符号的处理

最常见的C++惯常的做法：
#ifdef __cplusplus 
extern "C" {
#endif
    /* ... */
#ifdef __cplusplus
}
#endif
这种写法用于确保下符号是未被C++编译器名字修饰过的——这种代码能使得C++编译器编译出的二进制目标代码中的链接符号是未经过C++名字修饰过的，就像C编译器一样。就像C语言定义是未名字修饰过的一样，C++编译器需要防止名字修饰这些标识符。
例如，C标准字符串库<string.h>通常包含了类似这样子的
#ifdef __cplusplus
extern "C" {
#endif

void *memset (void *, int, size_t);
char *strcat (char *, const char *);
int   strcmp (const char *, const char *);
char *strcpy (char *, const char *);

#ifdef __cplusplus
}
#endif
于是，例如这样的代码
if (strcmp(argv[1], "-x") == 0) 
    strcpy(a, argv[2]);
else 
    memset (a, 0, sizeof(a));
就能使用正确的、未经名字修饰过的strcmp和memset。如果没有使用extern "C"，那么SunPro C++编译器会产生等价于下面的C代码：
if (__1cGstrcmp6Fpkc1_i_(argv[1], "-x") == 0) 
    __1cGstrcpy6Fpcpkc_0_(a, argv[2]);
else 
    __1cGmemset6FpviI_0_ (a, 0, sizeof(a));
而这些链接符号并不存在于C运行库中（例如 libc）。因此将导致链接错误。
C++语言的名字修饰 > C++标准化的名字修饰

标准化的C++名字修饰规则似乎能够在编译器实现之间带来更大的互操作性，但是事实上，这样的标准化自身并不能保证C++编译器的互操作性，并且它甚至能制造互操作性是可能的并且是安全的一种错觉。名字修饰仅仅是需要C++实现决定的许多ABI细节之一。其它ABI方面例如异常处理、虚表的设计、结构体和栈帧填充等等，也导致了不同的互不兼容的C++实现。再者，规定一个特定的名字修饰规则会导致在实现限制（例如：符号长度限制）指挥的名字修饰方式的系统上的一些问题。名字修饰的一个标准化的需求，也会阻碍不完全不需要名字修饰的实现——例如明白C++语言的链接器。
所以，C++标准并没有尝去标准化名字修饰。相反地，《Annotated C++ Reference Manual》（又叫做ARM， ISBN 0-201-51459-1, 第7.2.1c节）主动提倡使用截然不同的名字修饰方式来防止ABI层面不兼容的链接，例如异常处理和虚表设计。
虽然如此，在一些平台上，全部C++ ABI都被标准化了，包括名字修饰。
C++语言的名字修饰 > C++名字修饰的现实影响

当C++符号从动态链接库和共享对象文件中导出时，名字修饰方式就不再是一个编译器内部的事情的。不同的编译器（或者同一款编译器的不同版本）将产生不同的名字修饰方式的二进制文件。这意味着如果编译器使用了不同方式创建了库和程序经常将导致无法解决的符号。例如，如果一个系统中有多个C++编译器（例如GNU GCC编译器和操作系统供应商的编译器）并且想安装Boost C++ Libraries，那么它需要编译两次——为操作系统供应商的编译器编译一次，为GCC再编译一次。
为了安全目的，产生不兼容的目标代码（基于不同的ABI，例如类和异常）的编译器最好使用不同的名字修饰方式。这保证了这些不兼容性能够在链接的时候被检测出来，而不是一运行软件的时候被发现（这会导致隐藏的bug和严重的稳定性问题）。
正因如此，名字修饰是对于任何C++相关的ABI都是一个要点。
C++语言的名字修饰 > 通过c++filt去修饰

$ c++filt -n _ZNK3MapI10StringName3RefI8GDScriptE10ComparatorIS0_E16DefaultAllocatorE3hasERKS0_
Map<StringName, Ref<GDScript>, Comparator<StringName>, DefaultAllocator>::has(StringName const&) const
C++语言的名字修饰 > 通过内建GCC ABI去修饰

#include <stdio.h>
#include <stdlib.h>
#include <cxxabi.h>

int main() {
	const char *mangled_name = "_ZNK3MapI10StringName3RefI8GDScriptE10ComparatorIS0_E16DefaultAllocatorE3hasERKS0_";
	int status = -1;
	char *demangled_name = abi::__cxa_demangle(mangled_name, NULL, NULL, &status);
	printf("Demangled: %s\n", demangled_name);
	free(demangled_name);
	return 0;
}
输出：
Demangled: Map<StringName, Ref<GDScript>, Comparator<StringName>, DefaultAllocator>::has(StringName const&) const
Java的名字修饰

在Java语言中，方法或类的签名包含了它的名字以及它的参数和可适用的返回值类型。签名的格式是有文档说明的，因为Java语言、编译器和.class文件的格式都是全部一起设计的（并且一开始就是面向对象和互操作性的）。
Java的名字修饰 > 为内部和匿名类创建唯一的名字

匿名类的作用域局限于它们的父类，所以编译器必须为内部类产生一个“合格”的公开名字，来避免与其它相同命名空间的同名类类冲突。类似的，匿名类必须有“假的”公开名字（因为匿名类的概念仅存在于编译器内，而不存在于运行时）。所以，编译下列的Java程序：
public class foo {
    class bar {
        public int x;
    }

    public void zark () {
        Object f = new Object () {
            public String toString() {
                return "hello";
            }
        };
    }
}
将产生如下三个.class文件：
foo.class，包含了主类（外面的类）foo
foo$bar.class，包含了命名的内部类foo.bar
foo$1.class，包含了内部的匿名类（局部于foo.zark方法）
这些类名全是合法的（因为$符号允许用于JVM规范）并且这些名字对编译器的产生来说是“安全”的，因为Java语言的定义禁止$符号出现在常规的Java类定义中。
Java的名字解析在运行时更为复杂，因为完全合格的类名在特定的Java类加载器的实例中是唯一的。类加载器是分级次序的，并且JVM的每个编程都有一个所谓的上下文类加载器，用来预防两个不同的类加载器实例包含同名的类。系统首先尝试使用根加载器（或系统加载器）来加载类，然后往下针对上下文类加载器分级加载。
Java的名字修饰 > Java本地接口（JNI）

Java本地接口（JNI）允许Java语言的程序调用其它语言写的程序（通常是C或C++）。有两个名称解析与此有关，这两种都没有标准化的实现方式：
从Java到本地名字的翻译
常规的C++名字修饰
Python的名字修饰

Python语言的名字修饰用于类的“私有”（private）成员。这种类成员的名字由前导双下划线开头，并且后缀下划线不能多于一个。例如__thing将被名字修饰，___thing和__thing_同样也会被名字修饰，但是__thing__和__thing___就不会被名字修饰。Python运行时库不限制访问这些成员，名字修饰只是用来避免拥有同名成员的派生类发生名字冲突。
遇到需要名字修饰的时候，Python把这些名字改成单下划线加上封闭类的名字，例如：
>>> class Test(object):
...     def __mangled_name(self):
...         pass
...     def normal_name(self):
...         pass
... 
>>> [*Test.__dict__]
['__module__', '_Test__mangled_name', 'normal_name', '__dict__', '__weakref__', '__doc__']
Objective-C的名字修饰

本质上，Objective-C存在两种形式的方法，类方法（静态方法）和实例化方法。Objective-C的方法声明如下：
+ method name: argument name1:parameter1 ...
– method name: argument name1:parameter1 ...
类方法用+表示，实例化方法用-表示。一个典型的类方法声明是这样子的：
+ (id) initWithX: (int) number andY: (int) number;
 + (id) new;
实例化方法是这样子的：
– (id) value;
 – (id) setValue: (id) new_value;
这样方法声明都有一个特定的内部表示法。当编译的时候，任何一个方法都会按照下列类方法的方式来命名：
_c_Class_methodname_name1_name2_ ...
这是实例化方法：
_i_Class_methodname_name1_name2_ ...
Objective-C语法中的冒号被翻译成下划线。所以Objective-C的属于Point类的类方法 + (id) initWithX: (int) number andY: (int) number;将会被翻译成_c_Point_initWithX_andY_，并且实例化方法（属于同一个类） - (id) value;将会被翻译成_i_Point_value。
类的每一种方法都用这种方式标出。但是，为了在全部方法都用这种方式来表示的时候，能够查找到一个类能够回应的方法是很繁琐的。每个方法都赋予了唯一的符号（例如整型）。这样的符号一般叫做选择器。在Objective-C中，选择器可以被直接管理——它们在Objective-C中有特定类型——SEL。
在编译期间，建立了一个把文字表述（例如_i_Point_value）映射到选择器（类型为SEL）的表。管理选择器比操作方法的文字表述更有效。注意一个选择器只能匹配一个方法名，而不是它属于的类——不同的类对同名方法可以有不同的实现。因此，方法的实现也给定了一个特定的标识符——这就叫实现指针，当然也给定了类型IMP。
信息发送由编译器编码，调用id objc_msgSend (id receiver, SEL selector, ...)函数，或者它的表亲，其中receiver是信息的接收者，并且SEL决定需要调用的方法。每个类都有各自的从选择器映射到它们实现的表——实现指针指定实际方法实现的内存地址。类和实现的表是分开的。除了储存在SEL中来用IMP查找表，函数是本质上是匿名的。
选择器的SEL值在类间没有变化。这使得多态成为可能。
Objective-C运行时库负责维护方法的参数和返回值的信息。但是，这信息不是方法名的一部分，不同的类可能有很大的不同。
因为Objective-C不支持命名空间，所以没有必要对类名进行名字修饰（这个在产生的二进制文件中确实发生过）。
Fortran的名字修饰

名字修饰对于Fortran编译器也是必要的，因为原先这个语言是大小写不敏感的。随着语言的发展，产生了更多的名字修饰需求，这是因为Fortran 90标准附加的模块和其它特性。名字修饰就成为了需要解决的一个特别常见的问题，因为需要调用来自其它语言（例如C语言）的Fortran库（例如LAPACK）。
由于Fortran编译器大小写不敏感，子程序或函数的名字"FOO"必须被转换成规范的大小写方式，而且要由Fortran编译器来格式化，这样它才能无视大小写地用相同方式被链接。不同的编译器用不同的方式来实现了，没有发生过标准化。AIX和HP-UX的Fortran编译器把标识符全转成小写（"foo"），而克雷Unicos（英语：）的Fortran编译器把标识符全转成大写（"FOO"）。GNU的g77编译器把标识符转成小写后接一个下划线（"foo_"），例外情况是：原先已经有下划线的标识符（"FOO_BAR"）转成后接两个下划线（"foo_bar__"），这是f2c（英语：）设的约定。许多其它的编译器，包括SGI的IRIX编译器、gfortran和Intel的Fortran编译器（不包括在Microsoft Windows上），都把标识符全部转成小写后接一个下划线（"foo_"和"foo_bar_"）。在Microsoft Windows上，Intel Fortran编译器缺省为大写不带下划线。
Fortran 90模块中的标识符必须被进一步名字修饰，因为相同的子程序同可能在不同的模块提供给不同的例程。
Pascal的名字修饰 > Borland的Turbo Pascal/Delphi系列

为了避免Pascal的名字修饰，可以使用：
exports
  myFunc name 'myFunc',
  myProc name 'myProc';
Pascal的名字修饰 > Free Pascal

Free Pascal支持函数重载和运算符重载，所以它也使用名字修饰来支持这些特性。另外，Free Pascal能够调用由其它语言写的的外部模块定义的符号，也能导出自己的符号供其它语言调用。更多信息，详见Free Pascal Programmer's Guide（页面存档备份，存于）的子页面Chapter 6.2（页面存档备份，存于）和Chapter 7.1（页面存档备份，存于）。
参考资料

↑  , 15 April 2013  [2020-09-22], （原始内容存档于2011-10-02）
↑  JBIntel_deleted_06032015. . software.intel.com.   [2020-09-22]. （原始内容存档于2019-03-29）.
↑  .   [13 May 2016]. （原始内容存档于2020-11-06）.
↑  .   [16 May 2016]. （原始内容存档于2021-01-01）.
↑  . docs.oracle.com.   [2020-09-22]. （原始内容存档于2020-08-04）.
↑  . User and Reference Guide for the Intel Fortran Compiler 15.0. Intel Corporation.   [17 November 2014]. （原始内容存档于2016-08-17）.
王氏擬鱨

| 王氏擬鱨> 保护状况 |
| --- | --- |
 未予评估（IUCN 3.1）
科学分类 
界：: 动物界 Animalia
门：: 脊索动物门 Chordata
纲：: 綱 Actinopteri
目：: 形目 Siluriformes
科：: 鱨科 Bagridae
属：: 拟鲿属 Pseudobagrus
种：: 王氏擬鱨 P. wangi
二名法
Pseudobagrus wangi Miao, 1934

異名
 Pelteobagrus wangi ,Miao, 1934
王氏擬鱨，為輻鰭魚綱鯰形目鱨科的其中一種，為亞熱帶淡水魚類，分布於亞洲中國鎮江淡水流域，棲息在底層水域，生活習性不明。
扩展阅读

維基物種上的相關：王氏擬鱨
瑪麗亞·瑪希米蓮諾芙娜

瑪麗亞·瑪希米蓮諾芙娜（德語：Maria Maximilianowna，1841年10月16日—1914年2月16日），洛伊希滕貝格公爵馬克西米利安·德·博阿爾內的女兒，母親是俄羅斯沙皇尼古拉一世的女兒瑪麗亞女大公。
家庭

1863年，瑪麗亞和巴登的威廉王子結婚，兩人共有1子1女：
瑪麗（1865年—1939年）
馬克斯（1867年—1929年）
王悦 (1962年)

与「」標題相近或相同的条目页，請見「」。
王悦 (1962年12月—)，吉林大学超分子结构与材料国家重点实验室教授，主要从事有机光电材料的非共价制备等方面的研究工作。入选中华人民共和国教育部2007年度"长江学者"特聘教授，中国国家杰出青年基金获得者。
参考资料

↑  . www.chemsoc.org.cn.   [2022-05-11].
阿拉·纳贾尔

| 阿拉·納賈爾  |
| --- | --- |
2019年的纳贾尔
教育程度: 亚历山大大学医学系（MB Bch）
职业: 医生、学者、维基人
奖项: 年度維基人（2021）
阿拉·纳贾尔（阿拉伯语：‎，羅馬化：Alaa Najjar）是一名医生、维基人和互联网活动家。他在2021年8月的維基媒體國際會議上被维基百科联合创始人吉米·威爾斯评为年度維基人，以表彰他在阿拉伯和医学社群发展和COVID-19专题发展中的突出贡献。
纳贾尔的维基百科用户名是علاء（阿拉伯语：‎），他是维基项目医学的积极贡献者，也是阿拉伯語維基百科的志愿管理员。 同时，他也是黎凡特地区维基媒体的董事会成员和维基医学杂志的编委会成员。
教育和职业

纳贾尔于2021年1月毕业于亚历山大大学医学系，获得医学学士、外科学士（MB Bch）学位。 他在2021年接受《國家報》采访时称，他目前受雇于“一家非常繁忙的公立医院”。
维基百科与维基媒体活动

纳贾尔自2014年以来一直是活跃的贡献者，他的大部分编辑都集中在与医学有关的条目上。他还担任阿拉伯语维基百科的管理员和阿拉伯语维基百科官方社交网络团队的成员，并在维基媒体基金会的不同项目中担任若干其他角色。 他也是维基媒体集团在黎凡特的董事会成员，并自2018年12月起担任《维基医学杂志》的编委会成员。
他率先在阿拉伯语百科全书上开拓了COVID-19专题，并对医学专题做出了重要贡献。阿拉的工作有助于打击医学上的错误信息，并以可靠的、经过事实检验的信息对抗这种流行病。
2021年8月15日，他被维基百科联合创始人吉米·威爾斯评为“年度維基人”。 纳贾尔因其在阿拉伯和医学界发展中的先锋作用以及他在COVID-19主题发展中的作用而受到赞扬。 由于旅行限制，威尔士无法按照惯例亲自将奖项交给纳贾尔，而是在Google Meet上与他进行了一次“惊喜通话”。
纳贾尔在2019年WikiArabia上介绍维基项目医学
王徵吉

王徵吉（1946年—），台灣知名生態攝影家、保育人士，出生於台南市安南區，以拍攝黑面琵鷺而聞名，人稱黑琵先生、Mr.HAPPY。
自1992年起致力於保護黑面琵鷺，長期奔波於中國大陸、日本、朝韩交界處等拍攝黑面琵鷺的影像。曾獲頒2006年韓國環境運動聯盟保護黑面琵鷺貢獻獎、2009年帝亞吉歐《Keep Walking》夢想資助計畫首獎、2010年金鼎獎、2012年中華藝術攝影家學會終身成就貢獻獎等。
參考文獻

↑  . 【開眼電影網】. 2023-03-24  [2024-01-23]. （原始内容存档于2024-01-23） （中文）.
↑  . CTWANT. 2023-05-12  [2024-01-23]. （原始内容存档于2024-01-23） （中文）.
↑  . 商業周刊 - 商周.com. 2023-03-16  [2024-01-23]. （原始内容存档于2024-01-23） （中文）.
↑  . NOWnews今日新聞. 2023-02-28  [2024-01-23]. （原始内容存档于2024-01-23） （中文）.
格謙

格謙（?—?），隋朝河间郡（今河北河间）人，隋末民变早期领袖。隋炀帝大业九年（613年），格谦在渤海郡的厌次县豆子䴚（今山东惠民）起兵，自称燕王，署高开道为将军。大业十二年（616年），格谦被隋朝大将杨义臣所击败（在《隋书》中记载隋将是王世充），格谦被杀，高开道与其党百余人亡匿海曲。
参考资料

《隋书·王充传》
《旧唐书·高开道传》
阿力得尔苏木

| 阿力得尔苏木 |
| --- | --- |
苏木
坐标：46°15′58″N 121°02′01″E﻿ / ﻿46.26617°N 121.0337°E﻿ / 46.26617; 121.0337
国家:  中华人民共和国
上级行政区: 科尔沁右翼前旗
村级区划单位数:  19 0社区 19行政村 0嘎查 
时区: 北京时间（UTC+8）
行政区划代码: 15 22 21 202
电话区号: +86 
阿力得尔苏木，是中华人民共和国内蒙古自治区兴安盟科尔沁右翼前旗下辖的一个乡镇级行政单位（苏木）。
行政区划

阿力得尔苏木下辖以下地区：
海力森嘎查、​拉斯嘎嘎查、​太平庄嘎查、​杨家屯嘎查、​敖包嘎查、​光明嘎查、​西合力木嘎查、​混都冷嘎查、​赛音嘎查、​沙布台嘎查、​翁胡拉嘎查、​树木沟村、​红光村、​新立村、​永安村、​双发村、​复兴村、​大窝堡村和兴隆村。
参考资料

↑  . 中华人民共和国国家统计局. 2023-06-30 （中文（中国大陆））.
↑  . 中华人民共和国国家统计局. 2023-06-30 （中文（中国大陆））.
桑园镇

桑园镇可以指：
桑园镇 (蠡县)，中华人民共和国河北省保定市蠡县下辖的镇
桑园镇 (怀来县)，中华人民共和国河北省张家口怀来县下辖的镇
桑园镇 (吴桥县)，中华人民共和国河北省沧州市吴桥县下辖的镇
桑园镇 (莒县)，中华人民共和国山東省日照市莒县下辖的镇
桑园镇 (邛崃市)，中华人民共和国四川省成都市邛崃市下辖的镇
桑园镇 (西乡县)，中华人民共和国陕西省汉中市西乡县下辖的镇
代县钟楼

| 代县钟楼> 山西省文物保护单位 |
| --- | --- |
地址: 山西省忻州市代县
分类: 古建筑
时代: 明
编号: 4-169
认定时间: 2004年6月10日
代县钟楼，位于山西省忻州市代县城内东大街，钟楼街，是中华人民共和国山西省文物保护单位之一。
历史

代州钟楼建于明成化十四年(1478)。
建筑

代州钟楼为三檐十字歇山顶木结构建筑。高18.5米。砖台高5米，宽15米。木结构楼三檐，高二层14米，面宽、进深均为五间11米。二层悬大铁钟，钟口直径1.66米，铭文"金大定八年岁次戊申八月十三日造"。
保护

2004年6月10日，代州钟楼授予山西省文物保护单位，属于古建筑类，编号4-169。
参考

↑  《边靖楼记》：“翼七载，春三月，侯夏卜卫之右隙地，筑台建楼，设钟楼，为兵民之警焉”“鸟革罢飞，光彩炫目，洵足与城楼、鼓楼后先辉映已”
↑  . 今日山西网.   [2012-05-12]. （原始内容存档于2013-10-14）.
查令十字車站

关于地鐵車站，请见「」。
查令十字站（英語：），又被稱作倫敦查令十字站，是位於倫敦西敏市河岸街和亨格福德橋之間的一座英國國鐵鐵路總站，屬於倫敦車站群的一部分。本站是東南主線的起迄站，列車服務全數由東南列車有限公司提供。該公司於本站提供前往倫敦東南部、肯特郡及東薩塞克斯郡的通勤、城際列車服務。
本站連接同名地鐵站、堤岸站和堤岸碼頭，是倫敦重要的交通樞紐，其繁忙程度居大倫敦火車站第14位，站名取自附近的查令十字。
地理位置

查令十字站位於西敏市河岸街的西端、特拉法加廣場以東及白廳東北方，亦靠近為泰晤士河兩岸提供渡輪服務的堤岸碼頭。進出本站的鐵路均直接架在亨格福德橋上，以跨越泰晤士河，對岸為蘭貝斯區。
查令十字站編號為CHX。本站是英國鐵路網公司直接管理的20個車站之一，在2020-2021年度是英國第15繁忙的車站。
历史

查令十字站原始的車站大樓由東南鐵路公司（South Eastern Railway，1836-1922年）建在亨格福市場邊，於1864年1月11日啟用，以單跨度的鍛鐵製拱形屋頂橫跨六作月台，查令十字酒店則在格年5月15日開幕，為車站的門面增添了些許法式文藝復興風。然而到了1905年12月5日，車站原先雅緻的屋頂崩塌了，造成六人失蹤，所幸當時正值離鋒時段，尚及撤出站內人員。事後以一個俗氣許多的縱樑結構以支撐佈滿溝壑的新屋頂，至1906年3月19日才重新開幕。後來經過二戰期間不列顛空戰的炸彈洗禮後，相關單位才以新喬治亞式（Neo-Georgian）風格重建查令十字酒店上方的複斜式屋頂。到了1990年，查令十字站月台的大部分區域都被一座後現代主義風格的辦公室及購物中心綜合建築群覆蓋，其中大多為英國著名專業服務公司——普华永道会计师事务所所有。
2021年10月17日起，英國運輸部持有的東南列車有限公司取代東南鐵路，提供本站的列車服務。
列車服務及班次

本站設有六個月台，所有由本站出發的列車均會停靠滑鐵盧東站和倫敦橋站。
東南列車有限公司目前使用英國鐵路375、376、465、466和707型電聯車為本站服務。
於非繁忙時段自本站發車的列車班次每小時為：
2班 往達特福德，經貝克斯利希斯
2班 往達特福德，經劉易舍姆及伍利奇兵工廠
2班 往格雷夫森德，經席德卡普
2班 往海耶斯（Hayes，倫敦布羅姆利區），經卡特福德橋
2班 往七橡樹，經樹叢公園（Grove Park，倫敦劉易舍姆區）
2班 往黑斯廷斯，經唐橋井（1班半快速、1班各站停車）
2班 往阿什福德國際車站，其中一班續駛至多佛小修道院站（Dover Priory）
| 前一站 |  英國國家鐵路 |  英國國家鐵路 |  英國國家鐵路 | 後一站 |
| --- | --- | --- | --- | --- |
|  |  | 東南主線 倫敦至多佛 |  | 滑鐵盧東站 |
|  |  | 東南主線 倫敦至唐橋井 |  | 滑鐵盧東站 |
|  |  | 東南主線 倫敦至七橡樹 |  | 滑鐵盧東站 |
|  |  | 北肯特線 倫敦至達特福德，經伍利奇兵工廠 |  | 滑鐵盧東站 |
|  |  | 東南主線—黑斯廷斯線 倫敦至黑斯廷斯 |  | 滑鐵盧東站 |
|  |  | 貝克斯利希斯線 倫敦至達特福德，經貝克斯利希斯 |  | 滑鐵盧東站 |
|  |  | 席德卡普線 倫敦至格雷夫森德，經席德卡普 |  | 滑鐵盧東站 |
接駁交通

条目：查令十字地铁站和堤岸站
倫敦地鐵的查令十字站和堤岸站均與此站連接。查令十字地鐵站是貝克盧線和北線的轉乘站，堤岸站則是環線、區域線、北線和貝克盧線四線交匯的車站。位於本站北部附近的萊斯特廣場站是皮卡迪利線及北線的轉乘站。
此外，本站亦鄰近倫敦水上交通的堤岸碼頭。該碼頭提供三條航線服務：
|  | 航線編號 | 航線 | 參考資料 |
| --- | --- | --- | --- |
|  | RB1 | 巴特錫發電站碼頭/西敏碼頭 ↔ 北格林尼治碼頭/巴金河畔碼頭 |  |
|  | RB2 | 巴特錫發電站碼頭 ↔ 北格林尼治碼頭/格林尼治碼頭 |  |
|  | RB6 | 匹尼碼頭 ↔ 金絲雀碼頭 |  |
註：RB1航線只有部分班次途經堤岸碼頭，RB6航線於週末不設服務。
三條航線均以雙體船行走，並於繁忙時間提供更頻密的班次。
鄰近地標

海軍部拱門
特拉法加廣場
國家美術館
特拉法加工作室
科利瑟姆劇院
加里克劇院
阿德爾菲劇院
克婁巴特拉方尖碑
白廳
舊英國陸軍部大樓
新蘇格蘭場
國宴廳
騎兵衛隊總部
騎兵衛隊閱兵場
聖詹姆斯公園
戰爭紀念碑
車站相片

自查令十字站駛出，跨越泰晤士河的列車
19世紀查令十字站前的繪畫
站前的愛琳諾十字碑（Eleanor Cross）複製品
2002年的車站大廳
2014年時的查令十字站大堂
參考來源

↑   (Microsoft Excel). Transport for London. 2011-05  [2011-08-07].
↑   (PDF). National Rail Enquiries. National Rail. 2006-09-26. （原始内容 (pdf)存档于2010-01-01）.
1 2 3 4 5 6 7 8  . Rail statistics. Office of Rail Regulation（英语：）.  注意：各年度之間的統計方法可能不盡相同。
1 2  . Office of Rail and Road data portal. Office of Rail and Road.   [2022-01-13]. （原始内容存档于2020-11-30）.
↑  . Google Maps.   [14 July 2017]. （原始内容存档于2022-10-06）.
↑  Matters, Transport for London. . tfl.gov.uk.   [1 May 2022]. （原始内容存档于2021-11-22）.
↑  Matters, Transport for London. . tfl.gov.uk.   [16 September 2020]. （原始内容存档于2021-08-17）.
↑  Matters, Transport for London. . tfl.gov.uk.   [16 September 2020]. （原始内容存档于2021-11-22）.
外部連結

TFP Farrells | 倫敦查靈交叉路口河堤廣場二次開發專案
狐狸、鹅、豆子问题

狐狸、鹅、豆子问题〔又称狼、羊、菜问题〕是一则古老的智力游戏题。
问题

有一个农民到集市买了一只狐狸、一只鹅和一袋豆子，回家时要渡过一条河。河中有一条船，但是只能装一样东西。而且，如果没有人看管，狐狸会吃掉鹅，而鹅又很喜欢吃豆子。问：怎样才能让这些东西都安全过河？
解答

第一步、带鹅过河；
第二步、空手回来；
第三步、带狐狸〔或豆子〕过河；
第四步、带鹅回来；
第五步、带豆子〔或狐狸〕过河；
第六步、空手回来；
第七步、带鹅过河。
格氏連鰭䲗

| 格氏連鰭䲗> 保护状况 |
| --- | --- |
 未予评估（IUCN 3.1）
科学分类 
界：: 动物界 Animalia
门：: 脊索动物门 Chordata
纲：: 綱 Actinopteri
目：: 海龙鱼目 Syngnathiformes
科：: 䲗科 Callionymidae
属：: 連鰭䲗屬 Synchiropus
种：: 格氏連鰭䲗 S. grinnelli
二名法
Synchiropus grinnelli Fowler, 1941

格氏連鰭䲗（学名：），又名老鼠、狗圻，为䲗科連鰭䲗屬下的一个种。
周朴 (唐朝)

周朴（？—878年），字見素，一作太朴，福州长乐县人。
生年不詳。生于釣台，早年隐居嵩山，后避難福州，常与山僧钓叟往來。有詩才，歐陽脩謂其“構思尤艱，每有所得，必極其雕琢，故時人稱朴詩‘月鍛季煉，未及成篇，已播人口’”。乾符五年（878年），黃巢陷閩，逼他投降，周朴不從，終被殺害。僧人浩集其詩百餘篇，與林嵩編成《周朴詩集》二卷，林嵩為之序。
注釋

↑  《全唐詩》作湖州人；嘉定《赤城志》作泉州人。
↑  林嵩《周朴詩集序》：“先生名朴，字見素。生於釣台，而長於甌閩。與李建州頻方處士幹為詩友，一篇一詠，膾炙人口。”
↑  歐陽修：《六一詩話》
↑  《新唐书》卷二二五《黄巢传》记载黄巢攻下福州后，“又求處士周朴，得之，謂曰:‘能從我乎？’答曰:‘我尚不仕天子，安能從賊？’巢怒斬朴。”
↑  《全唐文》卷八二九录林嵩《周朴詩集序》云：“僧浩，高人也。與先生善，捃拾先生遺文，得詩一百首。中和二年冬十月，攜來訪餘。且驚且喜，余欲先生之文與方干齊，集畢遂為之序。”
格氏銹牙脂鯉

| 格氏銹牙脂鯉> 保护状况 |
| --- | --- |
 未予评估（IUCN 3.1）
科学分类 
界：: 动物界 Animalia
门：: 脊索动物门 Chordata
纲：: 綱 Actinopteri
目：: 脂鯉目 Characiformes
科：: 脂鲤科 Characidae
属：: 锯齿脂鲤属 Priocharax
种：: 格氏銹牙脂鯉 P. geryi
二名法
Priocharax geryi Myers, 1960

格氏銹牙脂鯉，為輻鰭魚綱脂鯉目脂鯉亞目脂鯉科的其中一個種。分布於南美洲巴西托坎廷斯河、亞馬遜河、鑫谷河及塔帕洛斯河流域，體長可達15公分，棲息在森林覆蓋且靜止的水域，生活習性不明。
格里科消除反应

格里科消除反应（Grieco elimination），又称格里科硒醚合成，指脂肪族伯醇经过硒醚中间体，消除为末端烯烃。
格里科消除
首先醇与邻硝基苯硒腈和三丁基膦在缺电子的硒原子上发生亲核取代，生成一个硒醚。然后用过氧化氢将硒醚氧化为硒亚砜（selenoxide）。最后硒亚砜发生类似于科普消除反应的消除反应，放出硒醇，生成烯。