ToolDeck 的在线文本工具可让您直接在浏览器中统计字数、转换字母大小写、排序行、删除重复项并生成占位文本。Word Counter 可报告单词数、字符数、句子数、段落数及预计阅读时间。Case Converter 支持大写（ UPPERCASE ）、小写（ lowercase ）、标题格式（ Title Case ）、camelCase、snake_case、kebab-case 等多种格式。Lorem Ipsum Generator 可生成可配置的占位文本（ placeholder text ），用于原型设计（ prototype ）。Line Sorter 支持按字母顺序（ alphabetical sort ）、按长度（ sort by length ）、逆序（ reverse sort ）或随机方式（ random shuffle ）重新排列行。Duplicate Line Remover 可在保留原始顺序（ original order ）的同时去除重复行。所有工具完全在客户端运行（ client-side processing ）——您的文本由设备上的 JavaScript 处理，不会发送到服务器或存储在任何地方——因此可安全用于生产日志（ production log ）、内部文档及其他敏感内容。无需注册账号。无 API 调用，无速率限制（ rate limit ），无遥测（ telemetry ）。
什么是文本工具？
文本工具是对纯文本执行结构化操作的实用程序：统计、转换、排序、去重和生成。这些任务在软件开发、技术写作、数据清洗和内容编辑中频繁出现。尽管大多数编程语言都内置了字符串方法，但基于浏览器的工具无需编写脚本、打开终端或安装包，即可在数秒内得出结果。
当任务太小不值得编写脚本，但手动操作又过于繁琐时，开发者往往会借助文本工具。将 50 个 CSS 类名从 camelCase 转换为 kebab-case、统计 pull request 描述中的字数、按行内容对日志文件排序，或从 CSV 列中删除重复条目，这些都是专用工具比一次性 regex 或 shell 管道更高效的典型场景。例如，处理 REST API 返回的 JSON 数据时，需要将 camelCase 字段名批量转换为 snake_case 的数据库列名；或者在 TypeScript 接口定义中将 PascalCase 的类型名转换为 kebab-case 的 CSS 类名。使用大小写转换器，只需粘贴标识符列表并选择目标格式，无需编写 Python 脚本或 sed 命令，即可在一步内完成所有转换，然后将结果直接粘贴回 VS Code 或任何编辑器中。npm 包名遵循 kebab-case 规范，而 JavaScript 变量通常使用 camelCase——这类跨命名规范的转换在日常开发中极为常见。
文本处理也是切换操作系统或编辑器时最容易出问题的环节之一。Windows (CRLF) 和 Unix (LF) 的行尾符不同。区域敏感排序会因系统的排序规则设置不同而产生不同结果。基于浏览器的文本工具通过使用相同的 JavaScript 引擎绕过这些不一致性，不受本地环境影响。此外，UTF-8 与 UTF-16 编码之间的差异也会影响字符数统计。JavaScript 的 string.length 返回 UTF-16 代码单元数，对于某些 Unicode 字符（如emoji或某些亚洲文字的补充平面字符），这与实际显示的字形数量不同。字数统计器同时报告 UTF-16 代码单元数和 Unicode 字素簇数，帮助开发者正确处理国际化 (i18n) 场景中的字符串长度限制，例如数据库字段的 VARCHAR 长度约束或 API 接口的字符限制。
文本工具在原型设计或验证最终将在 CI/CD 管道或 shell 脚本中运行的逻辑时同样有用。在向管道添加排序步骤之前，可以将输入粘贴到行排序器中确认预期输出。在编写 sed 模式规范化大小写之前，可以在大小写转换器中验证转换效果。这种以浏览器为先的工作流程缩短了开发过程中的反馈循环，降低了提交错误自动化步骤的风险。
为什么在 ToolDeck 上使用文本工具？
ToolDeck 的文本工具在您的浏览器标签页中处理一切内容。您的文本不会离开您的设备，这在处理生产日志、用户数据或专有内容时尤为重要。没有 API 调用、没有速率限制、没有遥测数据。
⚡即时出结果，零配置
粘贴文本，获取输出。无需 npm install，无需 Python 虚拟环境（ virtual environment ），无需记忆命令行参数（ command-line flag ）。每个工具在一秒内加载完成，页面缓存后可离线使用（ offline-capable ）。无需任何环境配置（ environment setup ），开箱即用（ zero setup ）。
🔒隐私优先设计
所有处理均使用标准 JavaScript API（ standard JavaScript API ）在浏览器中完成。没有文本发送到服务器（ server ）、存储到数据库（ database ）或记录在任何地方。适合处理生产数据（ production data ）、内部文档（ internal document ）和个人内容（ personal content ）。符合 GDPR 和企业数据安全策略（ data security policy ）的要求，无需担心数据泄露（ data leak ）风险。
🧰五个工具，统一界面
字数统计（ Word Counter ）、大小写转换（ Case Converter ）、行排序（ Line Sorter ）、去重（ Duplicate Line Remover ）和占位文本生成（ Lorem Ipsum Generator ）采用一致的布局（ consistent layout ）。学会一个工具，其余工具使用方式相同（ learn once, use everywhere ）。复制（ copy ）和清除（ clear ）按钮在每个页面的位置相同，减少操作摩擦（ friction ）。Monaco editor 界面对熟悉 VS Code 的开发者来说非常直观，支持 keyboard shortcut 和 syntax highlighting。
📋支持大文件输入
这些工具使用 Monaco editor 组件（与 VS Code 相同的编辑器引擎），可流畅处理数万行的文档。行排序器（ Line Sorter ）和重复行删除器（ Duplicate Line Remover ）可在浏览器中高效处理大型日志文件（ large log file ）和数据导出文件（ data export ）。Monaco editor 采用虚拟渲染（ virtual rendering ）技术，只渲染可见区域，保持高性能的同时支持大规模文本处理（ large-scale text processing ）。
文本工具使用场景
文本处理涉及开发工作流程的各个环节。以下是这些工具节省时间的常见场景：
内容编辑与质量检查
技术写作者和编辑将草稿文本粘贴到
Word Counter 中，检查博客文章、文档页面或 commit 信息（ commit message ）是否符合字数限制（ word count limit ）。以每分钟 200 词计算的阅读时间估算（ estimated reading time ）有助于判断文章对于 changelog 条目或 release note 是否过长。该工具还可一次性报告字符数（ character count ）、句子数（ sentence count ）和段落数（ paragraph count ）。对于 npm、PyPI 等包注册表（ package registry ）的项目描述，以及 GitHub README、Confluence 文档和 Notion 页面的内容长度管理，Word Counter 都能提供快速、准确的统计数据。
代码重构
在文件中批量重命名变量时，
大小写转换器可将标识符列表在 camelCase、snake_case、PascalCase 和 kebab-case 之间相互转换，比为每条转换规则编写 regex 更快。
日志文件分析
DevOps 工程师将日志输出（ log output ）粘贴到行排序器中，将相似条目归组，或粘贴到重复行删除器中，找出崩溃日志（ crash log ）中出现了多少条不同的错误信息。Kubernetes pod log、AWS CloudWatch 日志、Nginx / Apache 访问日志（ access log ）的快速分析均适用。结合 stack trace 分析，可以快速定位 production incident 中的根因（ root cause ）。
UI/UX 原型设计
设计师和前端开发者使用 Lorem Ipsum 生成器为原型图、Storybook 组件和 Figma 框架填充符合实际长度的占位文本。可配置的段落数和字数与预期内容尺寸相匹配。
数据清洗
数据工程师将 CSV 列或换行符分隔的列表粘贴到
Duplicate Line Remover 中，在导入数据库（ database ）之前提取唯一值（ unique value ）。结合行排序器，两步即可生成整洁、有序的数据集（ clean sorted dataset ）。等效于 SQL 的 SELECT DISTINCT 操作，适合在将数据导入 PostgreSQL、MySQL、SQLite 或 MongoDB 之前进行快速预处理（ preprocessing ）。对于 ETL pipeline（ extract, transform, load ）的数据清洗环节，这是一个零配置的快速验证工具。
文档与 README 格式化
在为 README 或更新日志（ changelog ）整理列表时，行排序器可按字母顺序排列条目以保持一致性。字数统计器检查项目描述是否在许多包注册表（ package registry，如 npm、PyPI、crates.io ）强制执行的 200 字符限制之内。GitHub 仓库描述（ repository description ）、VS Code 扩展描述（ extension description ）、Homebrew formula 描述的字数限制检查也适用。此外，遵循 Conventional Commits 规范的 commit message header 行建议不超过 72 个字符，Word Counter 可用于快速验证。
文本操作参考
下表将常见文本操作映射到执行该操作的 ToolDeck 工具，并附有示例输入和输出。使用它可快速确定哪个工具适合您的任务。
| 操作 | 工具 | 示例输入 | 示例输出 | 相关标准 / API |
|---|
| 字数统计 | 字数统计器 | "Hello world" | 2 个单词，11 个字符 | Unicode UAX #29（词边界） |
| 字符统计 | 字数统计器 | "cafe\u0301"（4 个字符 + 组合重音符） | 5 个码元 / 4 个字素簇 | Unicode UAX #29（字素簇） |
| 大小写转换 | 大小写转换器 | "hello world" | "helloWorld" (camelCase) | 区域感知：String.prototype.toLocaleUpperCase() |
| 占位文本生成 | Lorem Ipsum 生成器 | 3 段，每段 50 词 | 150 个拉丁派生填充词 | De Finibus Bonorum et Malorum (Cicero, 45 BC) |
| 字母顺序排序 | 行排序器 | "banana\napple\ncherry" | "apple\nbanana\ncherry" | String.prototype.localeCompare() / Intl.Collator |
| 逆序排序 | 行排序器 | "apple\nbanana\ncherry" | "cherry\nbanana\napple" | Array.prototype.reverse() |
| 去重 | 重复行删除器 | "a\nb\na\nc\nb" | "a\nb\nc"（3 行唯一行） | Set 数据结构 (ES6) |
字符统计行为取决于您是统计 UTF-16 码元（ JavaScript 的 string.length ）还是 Unicode 字素簇（ grapheme cluster ）。当两者不同时，字数统计器会同时报告。这在处理包含 emoji、CJK 补充平面字符（ supplementary plane characters ）或组合字符序列（ combining character sequence ）的文本时尤为重要，例如 UTF-16 代理对（ surrogate pair ）字符的 string.length 为 2 但视觉上只有 1 个字符。
如何选择合适的文本工具
每个文本工具针对不同的操作。将您的任务与合适的工具匹配：
- 1
如果 您需要检查文章、README 或 commit 信息的字数、字符数或阅读时间 → 字数统计器 - 2
如果 您需要在 camelCase、snake_case、UPPERCASE、标题格式或 kebab-case 之间转换变量名或文本 → 大小写转换器 - 3
如果 您需要为 UI 原型图、Storybook 组件或设计原型提供占位文本 → Lorem Ipsum 生成器 - 4
如果 您需要按字母顺序、按长度、逆序排序行，或随机打乱顺序 → 行排序器 - 5
如果 您需要从日志文件、CSV 列或任何换行符分隔列表中删除重复行 → 重复行删除器
这些工具可按顺序配合使用。例如，将原始日志文件粘贴到重复行删除器中提取唯一条目，再将结果移到行排序器按字母顺序排列，最后使用字数统计器检查行数。每个工具接受纯文本输入并产生纯文本输出，因此在工具间复制粘贴非常便捷。在实际开发工作流中，您可以将这些工具与 GitHub、GitLab 或 Bitbucket 的工作流结合使用：在提交 pull request 之前，用行排序器对 CHANGELOG 条目排序，用字数统计器确认 commit message 不超过约定的字符上限。对于 CI/CD pipeline 的配置，将 GitHub Actions workflow 中的环境变量列表或 Kubernetes ConfigMap 的键粘贴到行排序器，按字母顺序整理后再更新配置文件，可以让后续的 git diff 更加整洁。对于数据工程任务，在将 CSV 数据导入 PostgreSQL 或 MySQL 之前，先用重复行删除器去除重复的主键值，再用行排序器对数据排序，可以减少数据库导入时的约束冲突。这种工具链组合（pipeline of tools）的思路与 Unix 哲学一脉相承：每个工具做好一件事，通过组合来解决复杂问题。
常见问题
字数统计器如何统计字数？
字数统计器按空白边界（空格、制表符、换行符）拆分文本，并统计非空片段的数量。这与 Unix 的 'wc -w' 命令和大多数文本编辑器的行为一致。带连字符的词（如 "well-known"）计为一个单词。该工具还报告字符数（含空格和不含空格）、句子数（以句号、感叹号和问号后跟空格或字符串结尾为分隔）以及段落数（以空行分隔的块）。在技术实现上，分词使用 JavaScript 的正则表达式（ regex ）匹配空白字符边界，遵循 Unicode UAX #29 词边界规范（ word boundary specification ）。对于 JSON、YAML 或 TOML 格式的配置文件内容，每个以空格分隔的 token（包括键名（ key ）、值（ value ）、括号等）都会被计入总词数。对于包含 camelCase 或 snake_case 标识符（ identifier ）的代码片段，整个标识符作为一个 token 计数。字符统计同时提供 UTF-16 代码单元数（即 JavaScript 的 string.length 属性值）和 Unicode 字素簇数（ grapheme cluster count ），当处理包含 emoji、CJK 扩展字符（ supplementary plane characters ）或组合字符序列（ combining character sequences ）的文本时，两者可能存在差异，工具会同时显示两个数值供参考。这对于需要严格控制数据库 VARCHAR 字段长度或 API 请求体大小（ payload size ）的开发场景尤为重要。在 TypeScript 或 JavaScript 代码中使用 string.length 时需注意：对于包含 UTF-16 代理对（ surrogate pair ）的字符，string.length 返回的是代码单元数而非可见字符数。例如某些 emoji 字符的 string.length 为 2，但实际只显示为 1 个字符，Word Counter 会清楚地显示这种差异，帮助开发者做出正确的长度判断。对于 i18n 国际化项目，正确处理 UTF-8 和 UTF-16 编码之间的差异对于避免数据截断（ data truncation ）问题至关重要。
大小写转换器支持哪些格式？
大小写转换器支持：UPPERCASE、lowercase、Title Case、Sentence case、camelCase、PascalCase、snake_case、CONSTANT_CASE、kebab-case、dot.case 和 path/case。它从空格、连字符、下划线、点、斜杠和 camelCase 转换（小写到大写）中检测词边界。这意味着您可以粘贴 "myVariableName" 并直接转换为 "my_variable_name" 或 "my-variable-name"，无需手动预处理。该工具在批量重命名标识符时也很有用：粘贴一组 API 响应键，一步将它们全部转换为 snake_case，再更新代码库。这避免了为简单的机械转换编写一次性 sed 或 Python 脚本。在实际开发中，常见的应用场景包括：将 GraphQL schema 中的 camelCase 字段名转换为 PostgreSQL 的 snake_case 列名；将 Java 或 C# 中 PascalCase 的类名转换为 Python 风格的 snake_case 模块名；将 CSS 的 kebab-case 属性名转换为 JavaScript 的 camelCase DOM style 属性名（如 background-color 转为 backgroundColor）。对于 Go 语言的 struct 字段名（PascalCase）与 JSON 序列化标签（snake_case 或 camelCase）之间的转换，以及 Rust 语言 snake_case 变量名与 SCREAMING_SNAKE_CASE 常量名之间的转换，此工具都能高效处理。支持的格式涵盖了主流编程语言、框架和工具链中最常用的命名规范，包括 npm 包名（kebab-case）、Python 变量（snake_case）、TypeScript 接口（PascalCase）、环境变量（CONSTANT_CASE）等。
Lorem Ipsum 文本是真正的拉丁语吗？
Lorem ipsum 文本来源于 Cicero 于公元前 45 年所著《De Finibus Bonorum et Malorum》的第 1.10.32 和 1.10.33 节。这段标准文本自 16 世纪以来一直被用作排版填充文字（ typographic filler ）。该文本是经过打乱的拉丁语，并非语法正确的句子。ToolDeck 的 Lorem Ipsum Generator 使用传统词库（ traditional word pool ），将单词排列成可配置长度的句子和段落。在原型设计期间使用占位文本（ placeholder text ）而非真实内容，可避免过早决定文案长度（ copy length ），并防止在截图或设计评审（ design review ）中展示敏感数据。在前端开发工作流中，Lorem Ipsum 占位文本常用于 React、Vue 或 Angular 组件的开发阶段，在真实 API 数据尚未就绪时填充 UI 布局（ layout ）。在 Storybook 组件文档、Figma 设计稿和 Adobe XD 原型图中使用标准 Lorem Ipsum 文本，可以让团队成员聚焦于布局和视觉设计，而不是被具体的文案内容分散注意力。生成的文本按段落（ paragraph ）和单词数量（ word count ）灵活配置，适合填充短标题（ title ）、摘要（ excerpt ）、正文（ body text ）、工具提示（ tooltip ）、卡片描述（ card description ）等各种 UI 元素（ UI element ），满足不同内容密度（ content density ）的设计需求。对于使用 Tailwind CSS 或 Bootstrap 构建的响应式布局（ responsive layout ），Lorem Ipsum Generator 可以快速生成不同长度的测试文本，帮助验证各种屏幕尺寸（ breakpoint ）下的排版效果。在 component-driven development（ CDD ）或 design system 建设中，使用 Lorem Ipsum 而非真实数据可以更清晰地展示组件的纯视觉特性，避免内容与样式的耦合。
行排序器能处理不区分大小写的排序吗？
可以。行排序器提供不区分大小写的字母排序（ case-insensitive alphabetical sort ）作为其模式之一。在此模式下，"Apple" 和 "apple" 在排序时视为相同。该工具还支持自然排序（ natural sort order，其中 "file2" 排在 "file10" 之前）、逆序排序（ reverse sort ）、按行长度排序（ sort by line length ）和随机打乱（ random shuffle ）。排序后的输出在 CI/CD pipeline 和配置文件中特别有用，确定性的排序顺序（ deterministic ordering ）使 git diff 更清晰，并避免 commit 之间出现无关更改（ spurious changes ）。您可以在向构建脚本（ build script ）或代码检查规则（ linting rules ）添加排序步骤之前，使用行排序器交互式地验证预期的排序顺序。在实际的 DevOps 工作流中，保持配置文件中键的字母顺序是一种常见的团队规范。例如，GitHub Actions workflow YAML 文件中的 env 块、Kubernetes Deployment manifest 中的 env 列表、Terraform variable 块，以及 package.json 中的 dependencies 和 devDependencies 对象，都可以通过行排序器快速整理为字母顺序，从而在 git diff 中更容易发现实质性的变更。ESLint 配置文件（ .eslintrc ）中的规则列表、Prettier 配置中的选项键、tsconfig.json 中的 compilerOptions 键，也适合保持字母顺序以提高可维护性。自然排序模式（ natural sort ）在处理带版本号的文件名（如 release-1.2.0、release-1.10.0）或带序号的日志文件名（ log-1、log-2、log-10）时特别有用，避免了普通字典序（ lexicographic order ）排序将 "10" 排在 "2" 之前的问题。底层实现使用 JavaScript 的 String.prototype.localeCompare() 方法配合 Intl.Collator API 来实现语言感知的正确排序，这与直接使用 Array.prototype.sort() 的字节序排序不同，能正确处理多语言字符。
重复行删除器会保留原始行顺序吗？
会。重复行删除器（ Duplicate Line Remover ）保留每行的第一次出现，并删除后续重复项。输出保留首次出现的原始顺序（ original order of first appearances ）。它还支持不区分大小写匹配（ case-insensitive matching，其中 "Error" 和 "error" 视为同一行）和空白修剪（ whitespace trimming，比较时忽略前导和尾随空格）。在技术实现层面，去重操作使用 JavaScript ES6 的 Set 数据结构（ Set data structure ），时间复杂度为 O(n)，能够高效处理大规模数据集（ large dataset ）。对于包含数万行的应用程序日志（ application log ），去重后可快速获得不重复的错误类型列表，便于故障排查（ debugging ）和根因分析（ root cause analysis ）。在数据工程（ data engineering ）场景中，将 CSV 文件的某一列（每行一个值）粘贴到重复行删除器，可以提取唯一值集合，等效于 SQL 中的 SELECT DISTINCT 操作，然后将结果用于构建查找表（ lookup table ）或枚举类型（ enum ）定义。结合不区分大小写选项，可以规范化（ normalize ）来自不同数据源（ data source ）的字段值（例如将 "ERROR"、"Error"、"error" 统一视为同一个值进行去重）。whitespace trimming 选项则解决了从 Excel 或 Google Sheets 复制数据时常见的前导/尾随空格问题，无需额外的数据清洗（ data cleaning ）步骤。在 pipeline 预处理中，先用 Duplicate Line Remover 去重再用 Line Sorter 排序的组合，相当于对数据执行了类似 sort -u 命令（ Unix sort with unique flag ）的操作，整个过程无需打开 terminal 或安装任何 npm package。这对于 data analyst 和 backend developer 在快速验证数据清洗逻辑时非常实用。
使用这些工具时，我的文本会发送到服务器吗？
不会。所有 ToolDeck 文本工具完全在您的浏览器中运行（ client-side processing only ）。您粘贴的文本保留在浏览器标签页的内存中，由您设备上的 JavaScript 处理。不会向任何地方发送包含您内容的网络请求（ network request ）。您可以通过打开浏览器开发者工具（ browser developer tools ）并在使用任何工具时查看「网络」标签页（ Network tab ）来验证这一点。这种设计对于处理生产日志（ production log ）、用户个人信息（ PII ）、API 密钥（ API key ）、JWT token、数据库连接字符串（ database connection string ）或其他敏感配置数据的场景尤为重要。由于没有服务器端 API 调用，也不存在速率限制（ rate limit ）或配额（ quota ）问题。工具在网页缓存后还可以完全离线使用（ offline-capable ），适合网络受限的企业内网环境或安全审计（ security audit ）要求严格的场景。
这些工具能处理的最大文本量是多少？
这些工具使用 Monaco 编辑器（与 VS Code 相同的编辑器引擎）作为输入，可处理数万行的文件。实际限制取决于浏览器的可用内存。对于 100,000 行以下的大多数任务，处理是即时的。非常大的文件（500,000 行以上）可能会导致浏览器标签页占用大量内存。如果需要处理多 GB 的文件，命令行工具（如 sort、uniq 或 wc）更为合适。
这些工具能正确处理 Windows (CRLF) 和 Unix (LF) 行尾符吗？
可以。行排序器和重复行删除器在处理前会在内部规范化行尾符（ normalize line endings ），因此带有 Windows 风格 CRLF 行尾（ \r\n ）的文件与 Unix LF 文件（ \n ）产生相同的结果。字数统计器在统计句子和段落时也能正确处理两种格式。大小写转换器和 Lorem Ipsum Generator 对字符序列（ character sequence ）进行操作，不受行尾符（ line ending ）样式影响。如果您从这些工具复制输出并粘贴到 Windows 应用程序中，输出将使用 LF 行尾符——如果目标系统需要 CRLF，可以使用专用的行尾符转换工具进行转换。行尾符问题在跨平台团队中非常常见，通常通过 Git 的 core.autocrlf 设置或 .gitattributes 文件来管理。在 Windows 上使用 WSL（ Windows Subsystem for Linux ）或 Docker 容器进行开发时，CRLF 和 LF 的混用可能导致 shell script（ bash / sh ）执行失败，出现 "bad interpreter" 或 "command not found" 错误。通过在这些文本工具中预先处理文件内容，可以避免将错误的行尾符带入 CI/CD pipeline 或生产环境（ production environment ）。