在默认的界面中，Discourse 将会按照下面的方式进行显示主题和回复的时间。 显示的内容不是非常多，让人有点迷糊，其实这也是 Discourse 简约化显示的表现。 如果你希望了解更详细的内容，你需要将鼠标放到时间上，上面的时间将会显示发布的具体的时间，包括是几点钟发布的。     在进入主题或者回复的具体页面后，将鼠标移动到时间上，你也可以看到当前主题发布的具体时间。     简单来说，Discourse 的设计逻辑就是将鼠标移动到特定的位置后才能查看时间有关的详细信息。 https://www.ossez.com/t/discourse/13200

针对一个主题的查看数量，在 Discourse 的首页上就可以看到了。     但是进入主题内的话，发帖数量是没有办法看到的。 这个原因是你的主题上面没有回复。 如果某一个主题至少有一个回复的话，那么在主题的下面将会看到一个长方形的对话框。 在这个对话框中有一些主题的基本参数，在这里你可以看到当前主题的的发帖数量。     要显示这个框，主题必须要至少有一个回复才可以。 https://www.ossez.com/t/discourse/13199

都知道可以对 Confluence 的页面进行删除，那么在删除 Confluence 的页面后，页面会被完全删除吗？ 说明 在删除 Confluence 页面后，Confluence 的删除页面是不会删除的，会被放到一个类似回收站的地方。 Confluence 的站点管理员可以查看删除的页面，然后选择是否完全清理或者回复。 在 Confluence 的空间中选择左下角的内容工具。 然后在内容工具中找到 Trash，在 Trash 中可以看到所有已经删除的页面。     在这个页面上有一根 Purge All。 如果你不想保留这些页面的话，你可以选择 Purge All，单击后所有 Trash 中的页面将会被永久从空间中删除。 在 Confluence 中，这个就等于是一个回收站的性质。 所以，当在页面删除的时候 Confluence 的页面是没有完全删除的，只是在页面上打了一个标记而已。 https://www.ossez.com/t/confluence/13198

在一些 Confluence 的页面中，一般来说，你可以选定一个页面中，然后选择页面上面的删除。   如果你的页面中还有子页面的话，Confluence 会提示你是否删除子页面。 可以在这里选择后删除子页面。 需要注意的是，如果你不选择这个选项，那么 Confluence 将不会删除这个页面下面的所有子页面。 那么这样操作会产生什么问题呢？ 可能的问题 如果不选择删除子页面，Confluence 将会只删除当前页面，所有的子页面将会被提升到对上面一级目录中。 并且所有子页面的顺序 和层级结构都会被打乱。 如果你还需要按照层级结构来的话，那么你需要重新调整，如果页面不多还好。如果页面比较多的话，这个工作量非常大。 建议在删除之前，先调整好页面顺序和层级结构，然后再删除，以避免这个问题。 https://www.ossez.com/t/confluence-7/13197

最近在整理历史的研究文档的时候发现了还保有了一些有关 DITA 的文档。 随着技术的发展，DITA 显得非常臃肿了，并且编译处理并不是非常友好。 查询了下官方的版本历史：   已经有差不多 2 年没有更新了，由此看来 DITA 作为文档交付应该已经是日薄西山了。应该没有什么人通过写 XML 的方式来写文档了。 相反，MD 和 AsciiDoc 格式的文档却大行其道。 其主要原因是能够随意部署，并且文档结构少，约束少，更加容易写作和阅读。 作为文档来说，内容是最主要的，格式相对来说没有那么重要，如果有漂亮的格式，但是内容一团糟，又怎么会有人去看和使用呢。 回想一下曾经用过的 DITA，编译太复杂，PDF 生成问题太多，CHM 格式的文档很多时候大家都不愿意用，更多的都在使用 Github 上来写 MD 格式。 DITA 已死，就此留念。 超级复杂的文档格式。 因为是基于 XML 的，每一个段落的创作都非常复杂，你还需要考虑复杂的 XML 标签。让写作不是一种享受，简直是一种折磨。 相对 MD 格式就让人舒服多了，你只需要关注一些常用的标记，其他的都是以内容为主。 比如说 Discourse 这个社区使用的 MD 格式就非常简单，能够让所有人更多的关注内容而不是标记。 不管怎么样， DITA 也代表了人类文明出版中的小缩影。 https://www.ossez.com/t/dita-docbook/10050/2

在我们处理 API 调用的时候，API 在很多时候可能不会允许你无限制的执行。 这个时候在 Java 有一个代码就比较好用了，就是： Thread.sleep(6000); 上面的代码的意思就是暂停线程 6 秒钟，为什么是 6000，因为这个参数使用的是毫秒。1 秒等于 1000 毫秒。 需要注意的是，你在这里需要捕获异常，或者向上抛出 InterruptedException 这个异常。 Thread.sleep() 是Thread类的一个静态方法，使当前线程休眠，进入阻塞状态（暂停执行），如果线程在睡眠状态被中断，将会抛出IterruptedException中断异常。 https://www.ossez.com/t/java/9081

登录 Discourse 后台后，然后访问 API 标签。 在标签页中可以看到当前正在使用的 Key。 你可以单击创建新的 API Key 进行配置 在描述部分，你可以输入任何你需要的描述。 在用户级别部分，你可以为这个 API Key 设置为全局访问还是只能是针对一个特定的用户使用这个 key。 我们是比较建议针对特定的用户使用这个 Key ，以避免因为用户分享 Key 导致的很多安全性问题。 在随后的页面中就是对这个 key 进行授权了。 一般来说，你可以使用这个 Key 来创建主题，对用户进行管理等。 针对数据迁移的情况来看，我们使用了主要是对主题来进行操作和控制。 当完成上面的配置后，将会提示创建的 Key 的字符串。 请注意你需要马上拷贝创建的字符串，因为这个字符串只出现一次。 如果这个 key 字符串丢了的话，你需要重新进行创建。 https://www.ossez.com/t/discourse-api-key/8945

在默认情况下 CloseableHttpClient 调用会使用 StringEntity 来设置字符串。 在设置好字符串后，我们会发送到远程 API 上进行执行。 比如说，我们可以先初始化 HttpPost 对象，然后设置 setEntity HttpPost httpPost = new HttpPost("https://www.ossez.com/posts.json"); httpPost.setHeader(HttpHeaders.CONTENT_TYPE, "application/json; charset=UTF-8"); 下一步是初始化发送的 JSON 数据内容： StringEntity postingString = new StringEntity(new Gson().toJson(topicRequest), StandardCharsets.UTF_8); 然后将 JSON 数据内容设置到 HttpPost 实体中 httpPost.setEntity(postingString); 在这里有一个地方是需要注意的就是在设置 StringEntity 字符集的时候需要使用 UTF_8。 如果你不设置这个参数，默认是使用 ISO-8859-1 字符集的。     很多时候针对中文的环境都会使用到中文，ISO-8859-1 字符集是不能支持中文的，一般来说我们只要确保所有的发送数据都使用 UTF-8 就可以了。 https://www.ossez.com/t/closeablehttpclient-post-stringentity/8401

使用 Discourse API 进行从其他站点导入数据的时候，如果你是站点管理员或者拥有者的话，在运行 API 一段时间后，你的调用可能会返回错误： 2021-01-16 08:34:30.871 DEBUG --- [ main] com.ossez.edtestbank.tests.PostTest : >>>{"errors":["You’ve performed this action too many times. Please wait a few seconds before trying again."],"error_type":"rate_limit","extras":{"wait_seconds":1}}     这是因为 API 有连接和行为限制以保证系统不被恶意攻击。 但是管理员在导入大量数据的时候可能是希望取消这个限制的。 其实你是可以在控制台中设置，并且取消的。 解决办法 访问 Discourse 的控制台，然后搜索关键字：Rate Limit 将 rate limit create topic 设置为 0。 这个的意思是用户可以无限制的创建 rate limit create topic。     然后再尝试使用你 API 的调用，这时候应该不会提示上面的错误了。 https://www.ossez.com/t/discourse-api-many-times/4047

希望这部分提供的内容能够帮助开始使用 Spring Boot 来构建你自己的应用程序。 如果你是一个任务驱动型的开发者，你可能希望进一步访问 spring.io 页面中的内容来获得有关 开始使用 的相关指南。 通过这些指南能够有效的帮助你理解 Spring Boot 可以做什么的问题。同时，你还可以访问 “[如何使用]” 的参考文档。 否则的话，按照 Spring Boot 的官方逻辑，下一步请阅读有关 [Using Spring Boot] 的相关文档。 如果你没有兴趣继续了解使用 Spring Boot ，或者你就想使用 Spring Boot 构建相关文档的话，你可以访问 [Spring Boot 特性（features）] 页面中的内容来了解有关 Spring Boot 的相关特性。     整体来说 Spring Boot 的文档组织结构是比较松散的，你可以随时开始任何你希望阅读的部分。 https://www.ossez.com/t/spring-boot/1112