我读过几篇文章提到从一种语言到另一种语言的转换器。
我对使用此类工具持怀疑态度。有谁知道或有经验让我们说一下 Visual Basic 到 Java 或 vs 转换器？仅举一个例子
http://www.tvobjects.com/products/products.html，声称在这方面是“世界领导者”左右，但是如果读到这个：
http://dev.mysql.com/tech-resources/articles/active-grid.html
那里作者说：
“MySQL 用户的共识是 MS Access 的自动转换工具不起作用。例如，将现有 Access 应用程序转换为 Java 的工具通常会导致完成 80% 的完整解决方案，其中完成最后 20% 的工作比开始刮。”
好吧，我们知道我们需要 80% 的时间来实现前 80% 的功能，另外 80% 的时间来实现另外 20% 的功能......
那么有没有人尝试过这样的工具并发现它们是值得的？
试过了吗？不，实际上构建了（不止一个）语言转换器。
这是我（和我的同事）为B2 Spirit Stealth Bomber构建的一个，用于将使用旧语言 JOVIAL 编码的任务软件转换为可维护的 C 代码，并实现 100% 的自动转换。其中一项要求是不允许我们查看实际的源代码。可不是闹着玩的。
你是对的：如果你只获得中等高的转化率（例如，70-80%），那么完成转化所付出的努力仍然是非常重要的，如果你确实可以做到的话。我们的目标是 95% 以上，并且在被告知要更加努力时做得更好，就像 B2 的情况一样。人们接受中等高利率转换器的唯一原因是因为他们找不到（或不会资助！）更好的转换器，坚持现在开始，并接受这样一个事实，即以这种方式转换它可能会很痛苦（通常他们不会'不知道多少）但实际上比从头开始重建它更痛苦。（我碰巧同意这个评估：一般来说，尝试从头开始重新编码大型系统的项目通常会失败，而使用中高转换率工具进行转换的失败率没有那么高。）
那里有很多糟糕的转换工具，一些东西与大量的 PERL 代码一起对文本字符串执行正则表达式，或者一些基于 YACC 的解析器，其代码生成本质上是针对编译单元中的每个语句的一对一的。前者是由从天而降的人建造的。后者通常由没有良好编译器背景的好心工程师构建。
对于一个非常糟糕的例子，请参阅我对这个关于 COBOL 迁移的 SO 问题的回答：体验将遗留的 Cobol/PL1 迁移到 Java，这正是一个直接的语句翻译器......产生产生“JOBOL”一词的东西。
要获得如此高精度的转换率，您需要高质量的解析器，以及构建高质量的翻译规则以保留语义，并针对目标语言属性和特殊情况进行优化。本质上，您需要可配置的编译器技术。恕我直言，我们成功的原因是我们的DMS Software Reengineering Toolkit，它旨在完成这项工作。（我是建筑师；查看我的 SO 图标/简历）。
许多仔细的测试也有帮助。
DMS“知道”编译器对代码的了解，因为它拥有类似编译器的感兴趣语言的前端，并且能够构建 AST、符号表、控制和数据流、调用图。它使用了编译器社区在过去半个世纪发明的大部分编译器技术，因为这些东西已被证明在翻译中很有用！
DMS比大多数编译器知道的要多，因为它可以一次读取/分析/转换整个应用程序；大多数编译器都坚持使用单个编译单元。因此，可以编写依赖于整个应用程序的翻译规则，而不仅仅是当前语句。我们经常添加特定于问题或应用程序的知识来改进翻译。这通常在转换语言的特殊功能或库调用时出现，其中必须将库调用识别为特殊习语，并将它们转换为对目标库和语言结构的组合的调用。
此功能用于构建翻译器（例如，JOVIAL 翻译器）或特定领域的代码生成器。
更常见的是，我们构建复杂的自动化软件工程工具来解决特定于客户的问题，例如程序分析工具（死代码、重复代码、样式损坏的代码、指标、架构提取……）和大规模更改工具（平台 [ not langauge] 迁移、数据层插入、API 替换，...）
在我看来，就像 MS-ACCESS 问题几乎总是这样，其标签吸引了更广泛的 StackOverflow 人群，回答的人在这里错过了关键问题，我读为：
是否有任何工具可以成功地将 Access 应用程序转换为任何其他平台？
答案是
绝对不
原因很简单，同一家族中对 UI 对象使用相似模型的工具（例如，VB6）缺少 Access 默认提供的很多东西（如何将 Access 连续子窗体转换为 VB6 而不丢失功能？ ）。其他平台甚至不共享与 VB6 和 Access 相同的核心模型，因此它们需要清除更多的障碍。
引用的 MySQL 文章非常有趣，但它确实混淆了不称职的应用程序所带来的问题与所使用的开发工具所带来的问题。糟糕的数据架构不是 Access 所固有的——它是 [大多数] 新手数据库用户所固有的。但文章似乎将此问题归咎于 Access。
并且完全忽略了修复架构、将其升级为 MySQL 并将前端保留在 Access 中的可能性，这是迄今为止解决该问题的最简单方法。
这正是我对那些没有获得 Access 的人所期望的——他们甚至不认为将 Access 作为安全、大容量服务器数据库引擎的前端可以成为解决问题的最佳解决方案。
那篇文章甚至没有真正考虑转换 Access 应用程序，这是有充分理由的。我见过的所有声称可以转换 Access 应用程序（到任何平台）的工具，要么只转换数据（在这种情况下，它们根本不转换应用程序——白痴！），要么盲目地转换前端结构，在 Access 应用程序和目标应用程序中的 UI 对象之间具有 1:1 的对应关系。
这行不通。
Access 的应用程序设计是特定于它自己的，其他平台不支持相同的一组功能。因此，必须将 Access 功能转换为转换后的应用程序中原始功能的有效替代品。在我看来，这不是可以以自动化方式完成的事情。
其次，当考虑将 Access 应用程序转换为部署在 Web 浏览器中时，整个应用程序模型是不同的，即从有状态到无状态，因此这不仅仅是一些不支持的 Access 功能的问题，而是完全不同的问题。 UI 对象如何与数据交互的基本模型。也许一个 100% 未绑定的 Access 应用程序可以相对容易地转换为基于浏览器的实现，但是有多少呢？这将意味着一个不使用任何子表单的 Access 应用程序（因为它们不能被解除绑定），以及一个仅使用来自丰富事件模型的少数事件的应用程序（其中大部分仅适用于绑定的表单/控件）。简而言之，一个 100% 未绑定的 Access 应用程序将与整个 Access 开发范式作斗争。任何认为他们想在 Access 中构建未绑定应用程序的人真的不应该首先使用 Access，因为 Access 的全部意义在于绑定的表单/控件！如果您消除了这一点，您就放弃了 Access 相对于其他开发平台的大部分 RAD 优势，并且几乎没有获得任何回报（除了巨大的代码复杂性）。
要在 Web 浏览器中构建应用程序以完成与 Access 应用程序相同的任务，需要从头开始重新设计应用程序 UI 和工作流。因为成功的 Access 应用程序模型与成功的 Web 应用程序模型是对立的，所以没有任何转换或翻译会起作用。
当然，所有这些都随着 Access 2010 和带有 Access Services 的 Sharepoint Server 2010 而改变。在这种情况下，您可以在 Access 中构建您的应用程序（使用 Web 对象）并部署在 Sharepoint 上，以便用户在浏览器中运行它。结果在功能上是 100% 等效的（视觉上是 90%），并且可以在所有浏览器上运行（这里没有特定于 IE 的依赖项）。
因此，从今年 6 月开始，将 Access 应用程序转换为在浏览器中部署的最便宜的方法很可能是升级到 A2010，将设计转换为使用所有 Web 对象，然后使用 Sharepoint 进行部署。这不是一个简单的项目，因为 Access Web 对象与客户端对象相比具有有限的一组功能（例如，没有 VBA，因此您必须学习新宏，它们比旧宏更强大和安全，因此，对于那些熟悉 Access 的遗留宏的人来说，这并不是什么可怕的困难），但与在 Web 上部署的全面重新设计相比，它的工作量可能要少得多。
另一件事是它不需要对最终用户进行任何重新培训（只要 Web 对象版本与原始客户端版本相同），因为它在 Access 客户端中与在 Web 浏览器中相同。
所以，简而言之，我会说转换是一种幻想，几乎总是不值得付出努力。事实上，我同意所引用的观点（即使我对该来源的其他评论有很多问题）。但我也警告说，转换的愿望经常被误导，并且错过了不需要从上到下批量更换 Access 应用程序的更便宜、更简单和更好的解决方案。对 Jet/ACE 作为数据存储的不满常常使人们误以为他们也必须更换 Access 应用程序。确实，许多用户开发的 Access 应用程序都充满了可怕的、无法维护的妥协，并且与口香糖和钢丝绳结合在一起。
这并不意味着它很容易——通常情况下并非如此。正如我一直告诉客户的那样，建造新房子通常比改造旧房子更容易。但是我们改造老房子的原因之一是因为它们具有我们不想失去的不可替代的特征。通常情况下，Access 应用程序隐含地包含许多业务规则和工作流建模，这些不应在新应用程序中丢失（旧的 Netscape 难题，步伐 Joel Spolsky）。对于试图移植到不同平台的外部开发人员来说，这些事情可能并不明显，但对于最终用户来说，如果应用程序产生的结果与旧应用程序相比相差一分钱，他们会不高兴（并且可能应该，
无论如何，我已经讨论了太久，但我认为转换永远不会起作用，除非是最琐碎的应用程序（或那些旨在转换的应用程序，例如 100% 未绑定的 Access 应用程序）。我完全赞成修改而不是替换。
但是，当然，这就是我谋生的方式，即修复 Access 应用程序。
影响跨语言转换成功或失败的几个问题是语言的相对语义丰富度及其语义模型。
从 C++ 到 C 的转换应该相对容易，但是将 C 转换为惯用的C++ 几乎是不可能的，因为自动将过程程序转换为 OO 程序几乎是不可能的。
将 Java 转换为 C 会相对简单，尽管处理存储管理会很麻烦。如果 C 程序在整数和不同类型的指针之间进行时髦的指针算术或强制转换，那么将 C 转换为 Java 几乎是不可能的。
将函数式语言翻译成命令式语言会很容易，尽管结果可能是低效的，非惯用的。将命令式语言翻译成函数式语言可能超出了最先进的水平……除非您在函数式语言中实现命令式语言的解释器。
这意味着一些翻译人员在以下方面必然会比其他翻译人员更成功：
你不应该做的事情，第一部分，乔尔·斯波尔斯基
“....他们犯了任何软件公司都会犯的最严重的战略错误：
他们决定从头开始重写代码。”
我的网站上有一个MS Access 转换器列表。在我每天阅读的 Access 相关新闻组中的任何帖子中，我从来没有听说过任何关于它们的好消息。我每天都会阅读很多帖子。
另请注意，Access 中有大量功能，例如绑定的连续表单或子表单，在其他系统中重现的工作量更大。不一定要做很多工作，但需要更多的工作。在分发和安装应用程序时会遇到更多麻烦。
我使用了从 C# 到 Visual Basic.NET 的自动转换器。If True除了添加一些不必要的语句外，它工作得很好。
我也尝试过使用Shed Skin将 Python 转换为 C++，但由于缺乏对新式除法的支持，它没有奏效。
我只尝试过免费和基本付费的转换器。但主要问题是，很难相信转换完全成功。
通常，它们最好用于一次手动转换代码部分，您可以在其中查看每段代码。根据我的经验，重写而不是转换通常是更好的选择。
我使用了将 VB6 项目转换为 VB.Net 的工具——您希望它可能是此类事情中最简单的示例之一。我的经验是，必须仔细检查所有内容，并且有一半的东西丢失/错误。
当然，我会建议手动迁移，或者根据您的目标语言，如果这让您有机会对代码库进行重大改进，我会考虑完全重写。
马丁