java如何将所有要入库的数据全部转为大写？

Posted 2023-05-02

项目进行到一半时，需求变化，要求将所有保存到数据库的数据全部用大写的形式保存，现在如何才能最小限度的修改，来实现功能（不可能将以前所有javaBean一个一个拿出来转）。前台使用Spring MVC，后台是hibernate
后台是ibates

参考技术A 如果只是希望输入的内容自动变大写，那么spring mvc 可以使用initbinder功能。可以自动将输入进行大写转换。 如果要在写数据前处理的话，需要aop来控制一下，快速的将bean中所有字段转换成大写，有个java工具叫 Dozer。功能很强。

后台IBATIS，那么可以typehandle来实现。 参考技术B 1、改sql语句，UPPER('Test')，oracle这个方法可以把小写变大写

2、改前端，往后台传参的时候，写个js 参考技术C 看一下这个帖子的7楼回答 http://bbs.csdn.net/topics/330026588

C++ 小型与全部大写数据类型

【中文标题】C++ 小型与全部大写数据类型

【英文标题】：C++ small vs all caps datatype

【发布时间】：2018-03-08 20:44:55

【问题描述】：

为什么在 C++ (MSVS) 中，定义了所有大写的数据类型（并且大多数都是相同的）？

这些完全一样。为什么要定义所有大写版本？

double 和 typedef double DOUBLE

char 和 typedef char CHAR

bool和BOOL（typedef int BOOL），这里都是小写全大写代表布尔状态，为什么后者用int？

通过这些额外的数据类型获得了哪些额外的能力？

【问题讨论】：

额外的头痛而不是额外的能力。

【参考方案1】：

ALLCAPS 类型定义始于 Windows 编程的最初几天（1.0 及之前）。例如，当时还没有 bool 类型这样的东西。 Windows API 和标头是为老式 C 定义的。C++ 在开发时甚至都不存在。

因此，为了帮助更好地记录 API，引入了像 BOOL 这样的编译器宏。即使BOOL 和INT 都是相同底层类型（int）的宏，这让您可以查看函数的类型签名以了解参数或返回值是否打算作为布尔值（定义为“ 0 表示 false，任何非零值表示 true") 或任意整数。

作为另一个例子，考虑LPCSTR。在 16 位 Windows 中，有两种指针：near 指针是 16 位指针，far 指针使用 16 位“段”值和该段的 16 位偏移量。实际内存地址在硬件中计算为( segment << 4 ) + offset。

每种类型的指针都有宏或类型定义。 NPSTR 是 near 指向字符串的指针，LPSTR 是 far 指向字符串的指针。如果是const 字符串，那么C 将被添加到：NPCSTR 或LPCSTR。

您可以在“小”模型（默认使用 near 指针）或“大”模型（默认使用 far 指针）中编译代码。各种NPxxx 和LPxxx“类型”将明确指定指针大小，但您也可以省略L 或N，只使用PSTR 或PCSTR 来声明一个可写或常量指针匹配您当前的编译模式。

大多数 Windows API 函数使用 far 指针，因此您通常会在那里看到 LPxxx 指针。

BOOL 与 INT 并不是两个名称是同一基础类型的同义词的唯一情况。考虑一个例子，你有一个指向单个字符的指针，而不是一个以零结尾的字符串。也有一个名字。您可以使用 PCH 作为指向字符的指针，以将其与指向零终止字符串的 PSTR 区分开来。

即使底层指针类型完全相同，这也有助于记录代码的意图。当然有所有相同的变体：PCCH 用于指向常量字符的指针，NPCH 和 LPCH 用于显式近和远，当然 NPCCH 和 LPCCH 用于近和远指针一个恒定的字符。是的，在这些名称中使用C 来表示“const”和“char”令人困惑！

当 Windows 使用“平面”内存模型迁移到 32 位时，不再有 near 或 far 指针，只有平面 32 位指针用于所有内容。但是所有这些类型名称都被保留下来，以使旧代码可以继续编译，它们都被合并为一个。所以NPSTR、LPSTR、普通PSTR，以及上面提到的所有其他变体都成为相同指针类型的同义词（有或没有const修饰符）。

Unicode 大约在同一时间出现，最不幸的是，UTF-8 还没有被发明出来。因此，Windows 中的 Unicode 支持采用 ANSI 的 8 位字符和 Unicode 的 16 位字符（UCS-2，后来的 UTF-16）的形式。是的，当时人们认为 16 位字符应该对任何人都足够了。世界上怎么可能有超过 65,536 个不同的角色？！ （著名的遗言……）

你可以猜到这里发生了什么。 Windows 应用程序可以在 ANSI 或 Unicode（“宽字符”）模式下编译，这意味着它们的默认字符指针将是 8 位或 16 位。您可以使用上面的所有类型名称，它们将与编译您的应用程序的模式相匹配。几乎所有采用字符串或字符指针的 Windows API 都有 ANSI 和 Unicode 版本，带有 A 或 W 后缀实际的函数名。例如，SetWindowText( HWND hwnd, LPCSTR lpString) 变成了两个函数：SetWindowTextA( HWND hwnd, LPCSTR lpString ) 或 SetWindowTextW( HWND hwnd, LPCWSTR lpString )。而SetWindowText 本身变成了一个宏定义为其中一个或另一个，这取决于你是为 ANSI 还是为 Unicode 编译的。

那时，您可能真的想编写代码，以便可以在 ANSI 或 Unicode 模式下编译它。所以除了宏化的函数名之外，还有一个问题是你的窗口标题是使用"Howdy"还是L"Howdy"。 TEXT() 宏（现在更常见的是 _T()）修复了这个问题。你可以写：

SetWindowText( hwnd, TEXT("Howdy") );

它会根据你的编译模式编译成其中任何一个：

SetWindowTextA( hwnd, "Howdy" );

SetWindowTextW( hwnd, L"Howdy" );

当然，今天大部分内容都没有实际意义。几乎每个人都在 Unicode 模式下编译他们的 Windows 应用程序。这是所有现代版本的 Windows 上的本机模式，API 函数的 ...A 版本是本机 Unicode ...W 版本的垫片/包装器。通过为 Unicode 编译，您可以避免执行所有这些 shim 调用。但是您仍然可以根据需要在 ANSI（或“多字节字符集”）模式下编译您的应用程序，因此所有这些宏仍然存在。

【讨论】：

我记得那些日子：绿色活页夹中的 alpha 版本带有三个 5 和 1/4 英寸软盘和带有绿色按钮的鼠标和一个闪亮的钢球……我怀疑最终的起源是C 宏的约定为大写，特别是对于 TRUE 和 FALSE 等常量，以及所有大写汇编语言实践的长期习惯，无论如何，在这种情况下，大多数情况下都会忽略大小写。

IIRC，至少是 16 位系统的 Windows 3.x，在保护模式下运行。这意味着，段地址不是按段

【参考方案2】：

Microsoft 决定在 Windows 代码中为所有这些类型创建宏或类型别名。他们可能会寻求与全大写 WinAPI 类型别名的“一致性”，例如 LPCSTR。

但它有什么真正的好处呢？没有。

BOOL 的情况特别令人头疼。尽管一些老式 C 有这样做的惯例（在实际的 bool 进入该语言之前），但现在它真的只是令人困惑……尤其是在将 WinAPI 与 C++ 一起使用时。

【讨论】：

你确定吗？参考？我怀疑这也与他们的内部代码样式有关...

@EugeneSh.：我确信这很愚蠢，我希望他们没有这样做。至于实际的参考资料，您可能必须等待员工来。

@EugeneSh.：我不能完全反对，但这里也有客观性：OP 询问添加了什么能力，据我所知，答案实际上是“无” .

我想知道这是否可能是一些误导性的面向未来的尝试，但无法真正找到一种合乎逻辑的方法。

@EugeneSh。你可以参考我。 :-) 在 1.0 时代，我正在积极地编写 Windows。 LRiO 的回答是正确的，我在自己的回答中发表了其他一些想法。随意询问有关这段奇怪历史的任何问题。

【参考方案3】：

这个惯例可以追溯到 30 多年前的 Windows 操作系统。

70 年代和 80 年代初的当前实践仍然是在各种汇编语言和当时的高级语言、Fortran、Cobol 以及命令行解释器和文件系统默认值中使用全部大写进行编程。一种可能植根于打孔卡编码的习惯可以追溯到更远的地方，可以追溯到 20 世纪初。

当我在 1975 年开始编程时，我们使用的打卡器甚至不支持小写字母 as you can see on the pictures, it did not even have a shift key。

MS/DOS 是用汇编语言编写的，就像 80 年代早期最成功的 PC 软件包，如 Lotus 1-2-3、MS Word 等。C 是贝尔实验室为 Unix 系统发明的，并在在 PC 世界中获得动力的时间很长。

在新兴的微处理器世界中，实际上有 2 个独立的学校：英特尔小端世界，提供所有大写汇编文档和大端摩托罗拉替代品，包括小写汇编、C 和 Unix 操作系统和克隆以及其他奇怪的语言，例如作为 lisp。

Windows 是前者的创意，所有大写类型和修饰符的这种扩散在当时并不难看，它看起来一致且令人放心。 Microsoft 尝试了指针修饰符的各种替代方案：far、_far、__far、FAR，最终完全摆脱了这些，但出于兼容性目的保留了原始的全大写 typedef，导致了愚蠢的妥协，例如 32 位LONG 即使在 64 位系统上。

这个答案并不公正，但重温这些记忆很有趣。

【参考方案4】：

只有 MS 知道。

我能想到的唯一好处是某些类型（例如int）的大小取决于操作系统（请参阅the table here）。这将允许在 64 位操作系统上使用 16 位类型，还有更多 typedefs 或 #defines。该代码将更容易移植到其他操作系统版本。

现在，如果这个“可移植”的东西是真的，那么其余类型将遵循相同的约定，即使它们的大小在所有机器上都是相同的。

【讨论】：

但代码实际上是针对特定操作系统的。这种事情使移植变得更难，而不是更容易。

@LightnessRacesinOrbit 它旨在更容易移植到同一操作系统中的不同 CPU 架构。

@immibis：有点意思。所以在不同的架构上，INT 的定义会从int 变为，什么，固定宽度类型之一？让它成为参考架构上的样子？但是为什么不首先使用固定宽度类型呢？或者至少让INT 解决这个问题

@LightnessRacesinOrbit 尚未发明固定宽度类型。我不确定C是否已经标准化。 BYTE、WORD、DWORD、（后来的QWORD）是 Windows 固定宽度类型。不确定将INT 设为大写的原因是什么——但可能只是一致性。一些编译器还没有void，所以他们会在这些编译器上使用typedef int VOID;。也许有一个不寻常的int，其中INT 不一定是int。 （例如，可能默认情况下 int 未签名，所以他们使用 typedef signed int INT;？）

@immibis：好的，这有点道理。