Normal view

There are new articles available, click to refresh the page.
Before yesterdayMain stream

Titles

By: fivestone
5 December 2025 at 12:17

在澳洲歌剧网站注册会员时,发现 Title 居然有 136 个。吓到了,虽然我知道这种偏门 title 有很多,但真正在一般网站见到,还是第一次;比 gender 还多。还是你们歌剧佬会装……

把这些 title 扒下来,问 AI 出了一份说明,不保证准确,就看个乐子吧:

  • Miss: 用于未婚女性的称谓。
  • Mr: 用于成年男性的称谓,通常不涉及婚姻状况。
  • Mrs: 用于已婚女性,通常后面跟着丈夫的姓氏。
  • Ms: 用于女性的称谓,不特指婚姻状况,适用于希望避免性别角色的场合。
  • Admiral: 海军的高级军官,通常指海军上将。
  • Air Chief Marshal Sir: 英国皇家空军的高级军官,通常是空军元帅,带有“Sir”的称谓表示荣誉。
  • Air Marshal: 空军的高级军官,通常在军衔上低于空军元帅。
  • Air Vice Marshal: 空军的副军官,通常在军衔上低于空军元帅和空军大将。
  • Ambassador: 大使,代表一个国家在另一个国家进行外交事务的高级官员。
  • Archbishop: 大主教,负责监督多个教区的高级神职人员。
  • Archdeacon: 教区的高级神职人员,通常负责管理教区内的事务。
  • Assoc Prof: 副教授,通常在学术界中担任教学和研究职务。
  • Assoc Prof Dr: 副教授,且拥有博士学位。
  • Aunty: 亲属称谓,通常用于称呼母亲或父亲的姐妹,或作为对女性的亲切称呼。
  • Baron: 男爵,通常是欧洲贵族体系中的一种称谓。
  • Baroness: 女男爵,女性的贵族称谓。
  • Bishop: 主教,负责管理教区的高级神职人员。
  • Brig Gen: 准将,通常是军队中的高级军官。
  • Brigadier: 准将,负责指挥一个旅或类似单位的军官。
  • Brother: 对男性修士或兄弟的称谓,通常用于宗教团体。
  • Canon: 教士,通常指在教会中担任特定职务的神职人员。
  • Captain: 队长,通常是指负责某个团队或单位的领导者。
  • Colonel: 上校,军队中的高级军官。
  • Commander: 指挥官,通常负责指挥某个单位或任务。
  • Commissioner: 委员,通常是负责特定事务或机构的高级官员。
  • Commodore: 海军的军衔,通常在海军中负责指挥多个舰艇。
  • Consul: 领事,负责在外国保护本国公民和促进商业事务的官员。
  • Councillor: 顾问,通常在地方政府中担任职务。
  • Count: 伯爵,欧洲贵族中的一种称谓。
  • Countess: 女伯爵,女性的贵族称谓。
  • Dame: 女爵士,通常是对女性的荣誉称谓。
  • Dean: 院长,通常负责管理学院或学术部门的职务。
  • Deputy Lord Mayor: 副市长,协助市长工作的官员。
  • Dr: 博士,通常指拥有博士学位的人。
  • Emeritus Professor: 名誉教授,通常是退休后仍被认可的教授。
  • Father: 神父,通常用于天主教或东正教的神职人员。
  • Federal Magistrate: 联邦法官,负责处理特定法律事务的法官。
  • First Lieutenant: 一等中尉,军队中的军衔。
  • Flt. Lt.: 飞行中尉,空军中的军衔。
  • Frau: 德语中对已婚女性的称谓,相当于“Mrs”。
  • General: 将军,军队中的高级军官。
  • Governor: 州长或省长,负责管理一个州或省的官员。
  • Her Excellency: 对女性高级官员的尊称,通常用于大使或国家元首。
  • Her Excellency Dr: 对女性博士的尊称,通常是指大使或重要官员。
  • Her Excellency Madam: 对女性高级官员的尊称。
  • Her Excellency Mrs: 对已婚女性高级官员的尊称。
  • Her Excellency Ms: 对女性高级官员的尊称,适用于不特指婚姻状况。
  • Her Excellency Prof The Hon: 对女性教授及荣誉称谓的尊称。
  • Her Excellency Professor: 对女性教授的尊称。
  • Her Excellency The Honourable: 对女性高级官员的尊称,通常用于政治职位。
  • Her Honor Judge: 对女性法官的尊称。
  • Herr: 德语中对男性的称谓,相当于“Mr”。
  • His Excellency: 对男性高级官员的尊称,通常用于大使或国家元首。
  • His Excellency Dr: 对男性博士的尊称,通常是指大使或重要官员。
  • His Excellency Gen the Hon: 对男性将军及荣誉称谓的尊称。
  • His Excellency Gen the Hon Sir: 对男性将军及骑士的尊称。
  • His Excellency Lt General: 对中将的尊称。
  • His Excellency Mr: 对男性高级官员的尊称。
  • His Excellency Professor: 对男性教授的尊称。
  • His Excellency The Hon: 对男性高级官员的尊称,通常用于政治职位。
  • His Hon Act Jus: 对法官的尊称,通常用于法律界。
  • His Hon Justice: 对法官的尊称。
  • His Honor Judge: 对男性法官的尊称。
  • Honorary Consul: 名誉领事,通常是非职业领事,负责促进国家利益。
  • Judge: 法官,负责审理案件的法律官员。
  • Justice: 司法官,通常指高级法官。
  • Lady: 对女性的尊称,通常用于贵族或有地位的女性。
  • Lieutenant: 中尉,军队中的军衔。
  • Lieutenant Colonel: 中校,军队中的军衔。
  • Lieutenant Commander: 海军中的中级军官。
  • Lieutenant General: 中将,军队中的高级军官。
  • Lord: 贵族,通常是指拥有土地或权力的男性。
  • Lord Mayor: 大城市的市长,通常是在某些国家的特定称谓。
  • Madam: 对女性的尊称,通常用于正式场合。
  • Madame: 法语中对女性的尊称,相当于“Mrs”或“Ms”。
  • Maestro: 大师,通常用于音乐领域,指优秀的指挥家或作曲家。
  • Magistrate: 地方法官,负责处理轻微案件的官员。
  • Major: 少校,军队中的军衔。
  • Major General: 少将,军队中的高级军官。
  • Marquis: 侯爵,欧洲贵族中的一种称谓。
  • Master: 小男孩或年轻男性的称谓,或指掌握某种技能的人。
  • Mayor: 市长,负责管理城市的官员。
  • Messeur: 法语中的男性称谓,相当于“Mr”。
  • Messrs: 法语中对多位男性的称谓,相当于“Messieurs”。
  • Min.: 部长,通常指政府部门的负责人。
  • Mister: 男性称谓,通常用于成年男性。
  • Mlle: 法语中对未婚女性的称谓,相当于“Miss”。
  • Mons: 法语中对男性的称谓,相当于“Mr”。
  • Mr Justice: 对法官的尊称,通常用于英国法律系统。
  • Mssrs: 对多位男性的称谓,通常用于正式场合。
  • Mx: 性别中立的称谓,适用于不愿意标明性别的人。
  • Pastor: 牧师,通常指基督教教会的领导者。
  • Premier: 总理,通常指国家或省的首席行政官。
  • Prince: 王子,通常是皇室成员。
  • Professor: 教授,大学或学院的高级教师。
  • Professor Dr: 教授且拥有博士学位的人。
  • Professor The Hon: 教授及荣誉称谓的结合。
  • Rabbi: 拉比,犹太教的宗教领袖。
  • Rear Admiral: 海军的后勤将军,通常负责海军的后勤事务。
  • Rector: 学院或大学的院长或校长。
  • Reverend: 牧师,通常用于基督教教会的神职人员。
  • Reverend Canon: 教区的高级神职人员,通常是主教的助手。
  • Reverend Dr: 拥有博士学位的神职人员。
  • Reverend Father: 天主教的神父称谓。
  • Reverend Professor: 拥有教授职称的神职人员。
  • Second Lieutenant: 二等中尉,军队中的军衔。
  • Sen Dame: 女性的贵族称谓,通常是对已婚女性的尊称。
  • Senator: 参议员,负责立法事务的官员。
  • Senator The Hon: 对获得荣誉的参议员的尊称。
  • Sergeant: 军队中的军衔,通常负责指挥士兵。
  • Signor: 意大利语中对男性的称谓,相当于“Mr”。
  • Signora: 意大利语中对女性的称谓,相当于“Mrs”或“Ms”。
  • Sir: 对男性的尊称,通常用于骑士或有地位的人。
  • Sister: 对女性修女或姐妹的称谓,通常用于宗教团体。
  • Superintendant: 监督者,通常负责管理某个机构或部门。
  • Superintendent: 负责管理学校或其他机构的官员。
  • The Hon: 对获得荣誉的人的尊称,通常用于政治职位。
  • The Hon Dr: 对获得荣誉的博士的称谓。
  • The Hon Justice: 对获得荣誉的法官的称谓。
  • The Hon Mr: 对获得荣誉的男性的称谓。
  • The Hon Mr Justice: 对获得荣誉的法官的称谓。
  • The Hon Mrs: 对获得荣誉的已婚女性的称谓。
  • The Hon Senator: 对获得荣誉的参议员的称谓。
  • The Hon. Dr: 对获得荣誉的博士的称谓。
  • The Honorable Sir: 对获得荣誉的骑士的称谓。
  • The Honourable: 对获得荣誉的人的尊称,通常用于政治职位。
  • The Honourable Dame: 对获得荣誉的女爵士的称谓。
  • The Rev: 牧师的缩写。
  • The Rt Hon: 对获得荣誉的人的尊称,通常用于政治职位。
  • The Rt Hon Baroness: 对获得荣誉的女男爵的称谓。
  • The Rt Hon The Lord: 对获得荣誉的男爵的称谓。
  • The Rt Rev: 对主教的尊称。
  • The Very Reverend Dr: 对高级神职人员的尊称,通常是拥有博士学位的牧师。
  • Uncle: 亲属称谓,通常用于称呼父母的兄弟。
  • Vice Adm: 海军的副上将,通常是负责海军的高级军官。

用 Next.js 重构个人网站 (二):核心和通用模块

By: 李瑞东
19 March 2023 at 11:12
封面图:Maxime Bourgeois

一部分我会记录下在重构 LRD.IM 项目中,部分核心或比较通用功能的实现过程,以及一些我花了点巧思来设计的地方。

数据源和循环遍历

我的网站中常常会有字段是能在多个地方复用的,比如作品的标题、描述等信息。

作品集首页字段应用的示意。应用在首页、作品详情页、head 标签、复制链接时的拼接。

这些字段会在多个页面中使用,当文案调整时也需要同步改动,影响到所有相关的地方。所以为了达到「一改全改」的效果,改进网站迭代的效率,这里我会用到数据源和循环遍历来做(以前还真就手动一个个来改的)。

数据源
数据源像是一个专门存储数据的库,里面记载了某个模块会被用到的字段名称及其对应的值。这里面本身没有功能、交互和样式,就像一个仓库。作用就是给到具体的页面或者组件来调用。

循环遍历
有了数据源之后会需要将其逐个安放进统一的容器里面。容器的样式是一致的,布局和适配也通过 CSS 来统一处理好,只是里面的文本、配图、跳转链接等这些属于数据源的内容有差异,所以这里会用到map()来遍历数据,将数据逐一安放进容器里。

功能实现

构建数据源
举个例子,「作品」页面包含了好几个字段:

  1. 公司名称
  2. 公司 LOGO 图片链接
  3. 公司官网网址
  4. 公司相关作品
  5. 作品名称
  6. 作品描述
  7. 作品缩略图链接
  8. 作品跳转链接

这其中「公司」和「作品」是一对多的关系,一个公司可以对应有多个作品。所以这里据源的结构是:

const ProjectItemData = [
{
name: "公司名称",
img: "公司 LOGO 图片链接",
url: "公司官网网址",
projects: [
{
title: "作品名称",
desc: "作品描述",
img: "作品缩略图链接",
url: "作品跳转链接",
},
],
},
];
export default ProjectItemData;

应用在实际页面中

数据源在我的网站里有两种使用方式:直接引用数据源里的某一个字段,或者通过遍历循环来填充进容器里面。

直接引用字段
比如作品详情页里面的 <head> 标签,需要将作品标题,siteMetadata 里的一个字段拼接,我会直接将他们引用到页面当中。

// 导入数据:
import siteMetadata from "/data/siteMetadata";
import ProjectItemData from "/data/ProjectItemData";

// 使用数据:
const title = ProjectItemData[2].projects[0].title; // 指定获取某个字段
<title>{title} - {siteMetadata.title}</title> // 应用在页面中

// 输出:
// <title>SHOPLINE App 组件库构建 - 李瑞东 LRD.IM</title>

循环遍历,将内容逐一填进容器
LRD.IM 的首页会列出我之前任职公司时的实际项目,实际上这就可以将一组数据按顺序地填入设定好样式和交互的容器当中。

我使用 Array.prototype.map() 来实现这个循环遍历。

import ProjectItemData from "/data/ProjectItemData";  //导入数据源
<>
{ProjectItemData.map((company) => ( //查找数据源中的一级数据
<div>
<Image src={company.img} /> //公司 LOGO 图片
<Link href={company.url}> {company.name} </Link> //公司名称,点击跳转到公司官网网址
</div>
<div>
{company.projects.map((project) => ( //查找数据源中的二级数据
<Link href={project.url}> //作品跳转链接
<Image src={project.img} /> //作品缩略图
<h3>{project.title}</h3> //作品名称
<p>{project.desc}</p> // 作品描述
</Link>
))}
</div>
))}
</>

影响范围

数据源循环遍历这个做法频繁出现在重构后的个人网站里。除了上面提到的首页作品列表,还有比如网站的 Header 导航栏、作品详情页平铺图片的模块、以及 What’s New 页面的内容等等。

map 遍历用在Header 导航栏、作品详情页平铺图片的模块、以及 What’s New 页面的内容的示意图

如果后续某一个模块的内容需要增删改,我只要修改数据源里面的内容,操作完之后在具体页面中检查一遍就可以了。再也不用在编辑器里打开数十个 html 文件逐个修改了。也不用在一堆代码高亮后的标签内寻找内容了。

一个模块或组件对应一个数据源,然后数据也和页面分离,👍🏻。

不得不接受的局限性

这个看似完美的功能实际上也会有一个令我有点难受局限性。前文提到一句话:

有了数据源之后会需要将其逐个安放进统一的容器里面…

这种按部就班,放进「统一的容器」里的做法会丧失灵活性,比如在:一组容器里面我想要特意给某一个容器添加样式,或者某个字段的值是字符串,我想给里面的某个词语设定一个样式。这似乎不容易办到。

具体来说,在我前年写的一篇「Apple 官网里三个令我惊叹的中文排版细节」里,我学会了给标题或重要文本的最后一个词语和标点设置一个不换行的样式white-space: nowrap;来防止出现孤字,这是需要在 HTML 内对单独每一句话来设定的样式。

重构前避免出现孤字的做法

而通过数据源来填充文本内容,我似乎没法进行这样的操作了。所以重构后的网站,一些地方可能会出现无法避免的孤字。

后续我会继续关注这个问题,尝试找到低成本的解决办法。这并非毫无希望,起码最近有了解到 React Wrap Balancer 这个组件似乎能改善孤字的现象,后续我会继续跟进。有新进展也会在博客里更新。

React Wrap Balancer 的效果预览动图。
当前的解决方案:关键内容/复用较少的内容会写在 JSX 中,而不使用数据源,给到最大的灵活性。而像大标题或副标题,则是使用了 word-break: keep-all; 的方式减少孤字出现的可能性(参考此处)。其他更细的情况无处理。

深色模式

重构前的 LRD.IM,网页的深色和浅色模式是只会跟随用户系统设置的,而这次做到的效果是:

  1. 默认颜色主题跟随用户系统设置;
  2. 允许有一个按钮来切换深色或浅色模式;
  3. 手动更改过颜色主题后,访问网站内其他页面也会受到影响;
  4. 页面加载、跳转时没有背景色闪烁。

深色模式在 Next.js 和 Tailwind CSS 结合使用的时候会变得无比简单。

功能实现

功能上我是跟着 Danilo Leal 博客里的这篇文章,一步一步实现适配到深色模式的。主要是使用了 next-themes 提供的能力。没什么难度和卡点。

样式支持

标题是 Tailwind CSS 3.2 的配图,使用科技风格的蓝紫色渐变作为背景,图片来自 Tailwind CSS 官方。
图片来自 Tailwind CSS

使用 Tailwind CSS 之后,设计深色模式的样式也变得简单很多了。只要在类名前加上dark:,比如这样:text-neutral-800 dark:text-neutral-100,dark:后面的内容就是当切换成深色模式后的样式。

而且在与媒体查询、:hover、:active 等效果配合使用时候,也可以直接叠加,不需要在 CSS 内过多的声明或嵌套。

比如一个按钮的背景色,在不同的颜色主题和状态(默认或 :hover)下色值会不同。同时我也希望在移动端设备尺寸下,不要有 :hover 改变背景色的效果。那么类名大概会是这样:

<Button
className="
bg-neutral-100 //浅色模式时,按钮的默认背景色
dark:bg-neutral-900 //深色模式时,按钮的默认背景色
sm:hover:bg-neutral-200 //视窗宽度是移动端以上时,:hover 状态的背景色
dark:sm:hover:bg-neutral-800 //深色模式且视窗宽度是移动端以上时,:hover 状态的背景色
">...
</Button>

在我看来,这种做法比传统的 CSS 做法更直观,不用专门语义化一个颜色,或者在冗长的 CSS 里维护两套主题色。所以得益于使用了 Tailwind CSS,我在写样式的时候效率提升了很多。

使用外部组件/图标库

这里可以记录一个我做成了响应式适配的组件:Header。在宽度足够时会将各页面入口平铺展示;而在移动端尺寸下,会收起在一个按钮中,点击后展开一个菜单,在里面提供页面和功能的入口。

拖动右侧手柄,缩小容器宽度来查看 Header 组件的适配的效果。默认是按钮平铺展示,容器宽度小到一定程度后将按钮收在汉堡包菜单中,点击图标出现相应的按钮。

组件

实际上我是通过媒体查询视窗宽度来实现的响应式适配。Header 操作区会分成两部分,一部分是平铺的按钮,另一部分是菜单功能。即:

  1. 当视窗宽度 > 移动端尺寸时,菜单功能的按钮被隐藏;
  2. 而视窗宽度 ≤ 移动端尺寸时,平铺的按钮被隐藏。
<>
<div className="hidden sm:block"> // 平铺的按钮,视窗宽度 > 移动端尺寸时出现
<Link>作品</Link>
<Link>博客</Link>
<Link>关于我</Link>
</div>
<div className="sm:hidden"> // Headless UI 的菜单组件,视窗宽度 ≤ 移动端尺寸时出现
<Menu> ... </Menu>
</div>
</>

至于展开的菜单,我是用了 Headless UI 的 Menu 组件来实现的(经过轻微改造),这里面内置了展开收起的动画,以及无障碍访问相关的特点。组件挺好使的,而且文档也很完善,提供了很多功能和描述。

Headless UI 的 Menu 组件界面截图

重构后博客文章里的目录,我也是用类似的方法来做响应式适配的。这部分的内容在下一篇文章中呈现。

图标

虽然说在工作上我做过不少图标,也负责过图标库的管理和迭代。但在这次重构 LRD.IM 的项目中,我没有自己去设计图标,用的都是外部资源。

因为在我看来图标只要能辅助表达出意思就行了,没有必要在这上面花太多功夫。把时间和精力放在其他更有意义的地方。

网站中我主要依赖外部的图标库 React-Icons。里面包含了很多主流图标库的内容,比如:Ant Design、Boostrape、Remix 等等。

React-Icons 网站界面截图

而我主要使用了 Ionicons 5 系列的图标,比较符合设计风格。用起来很简单快捷:

import { IoLink, IoList } from "react-icons/io5"; // 加载图标库

<IoLink /> //直接使用图标
<IoList className="text-xl" /> //为图标添加样式
使用框架来构建网站的好处是:能够很方便地用上各种插件和库。这是在旧版网站里不敢想象的事情。

The Joy of React 课程的收获

上一篇文章中提到在项目后期我参加了 The Joy of React 课程,在系统地学习了一些 React 的知识后对代码做了些改进,比如对图片展示组件的改进。

设计图片组件

在我的作品详情页面中,「图片」是一个会被频繁用到的媒体。而图片的呈现又有多种方式。

用三张截图分别展示图片组件的多种变量。从上至下分别是图片尺寸、图片描述、长图滚动和图片放大。

上图中能看到,我的图片组件会有六个属性允许配置或填写。

  1. src:填入图片的路径(必须)
  2. alt 文本
  3. 图片尺寸:大 / 小
  4. 图片滚动:允许 / 禁止
  5. 点击放大:允许 / 禁止
  6. 图片描述:内容 / 为空

而其中这几种属性可以互相组合,比如:

  1. 大尺寸图片 + 允许滚动 + 禁止点击放大 + 有图片描述
  2. 小尺寸图片 + 禁止滚动 + 允许点击放大 + 无图片描述
  3. 小尺寸图片 + 允许滚动 + 禁止点击放大 + 无图片描述

所以我在设计的图片组件时,开放了这些属性,允许在页面中自由配置某一张图片的样式和功能。同时将常被用到的属性会被设定为默认值,尽量减少在页面中的代码量。得出这样的一个 API:

export default function ProjectImage({ src, alt, size, scroll, zoom, children }) {
return (
<>
<figure className={scroll === true ? "scroll" : ""}> //scroll 为 true 则添加允许图片滚动的样式
<div className={`${size === "small" ? "max-w-2xl" : ""}`}> //scroll 为 small 则添加限制图片容器宽度的样式
{zoom === false ? ( //zoom 被设置为 false 时,使用不能点击放大的图片组件
<Image
src={src} //读取外部填写的图片路径
alt={alt} //读取外部填写的图片 alt 文本
/>
) : (<Zoom //zoom 被设置为 true (默认值)时,使用允许点击放大的图片组件
src={src}
alt={alt}
></Zoom>
)}
</div>
</figure>
{children && <figcaption>{children}</figcaption>} //children 非空时,将其渲染出来
</>
);
}

同时又存在着一个互斥关系,比如:允许滚动的图片,禁止点击放大;禁止滚动的图片,允许点击放大。(因为当下我用到的图片放大组件对长图片的支持并没有很完美),补充相应代码:

export default function ProjectImage({ src, alt, size, scroll, zoom, children
}) {
zoom = !scroll;
return (
<>...</>
);
}

最后在页面中使用该组件时,只需要填上必填的src,如果有其他尺寸或滚动上的属性配置,也传递进去就好了。

//默认:大尺寸图片 + 禁止滚动 + 允许点击放大 + 无图片描述
<ProjectImage src="01.png" />

//配置为:大尺寸图片 + 允许滚动 + 禁止点击放大 + 有图片描述
<ProjectImage src="02.png" scroll={true}>
一个文本示例。
</ProjectImage>

//配置为:小尺寸图片 + 禁止滚动 + 允许点击放大 + 有图片描述
<ProjectImage src="03.png" size="small">
另一个文本示例。
</ProjectImage>

可以对比一下在使用组件前后,源文件的对比。代码可读性提高了许多,同时也更方便管理和迭代了。

后如果我想有什么调整或者新功能,只要改动组件就好,再也不用在编辑器里打开数十个 html 文件逐个修改了。也不用在一堆代码高亮后的标签内寻找内容了。

用两张在代码编辑器里的截图展示使用组件前后,源文件代码量的对比。左侧是使用前,用红框标记代码量,一共 43 行代码;右侧是使用后,用绿框标记代码量,一共是 11 行代码。

图片组件比较常用,后面也会根据具体用途的变动和个人能力的长进来不断优化。

预告

下一篇文章将会介绍我是如何使用 mdx-bundler 来重构整个博客功能模块,包括 mdx-remark 插件、内容生成方式、目录组件、RSS 生成等内容。以及我为了增强阅读体验所做的工作。敬请期待吧~(自说自话 🙄)

本文于 2023 年 03 月 12 日首发于 LRD.IM

图床

By: fivestone
10 September 2023 at 13:31

趁着服务器搬家,打算把死掉很多年的摄影网站,重新恢复起来。把如今流行的自建图库程序看了一圈:piwigo、lychee……仍然没有哪个很靠谱。

其实我在浏览这些程序之前,并没有太多具体的需求,只是期待,快 10 年没看这类东西了,会不会有什么让我惊艳的产品。——并没有。而且,在体验每个程序时,都迅速地发现一些,让我觉得很不爽的点。于是,所谓自己的需求,就是在这个不断吐槽的过程中形成的。

除了最基本的

  • 便捷的上传
  • 并不是难看到很离谱的展示界面

之外,

如果,我要的是一个图床,那么我需要——

照片的 url 和我本地储存的目录结构和文件名是一致的,类似于

https://..../blog/20230909_1.jpg
https://..../blog/20230910_cat.jpg

而不是

https://..../21/27/4c1b46114f8.jpg

这样的东西。前者的文件名,在编辑文章时便于管理。而且,以后迁移图床时,可以统一替换图片 url 的前缀,实现无缝迁移。

如果,我要的是一个摄影作品的展示网站,那么我需要——

!!!不要在网页的任何地方,显示多余的 exif 信息!!!

感觉这十年来,所有的图库程序,都把心思花在,如何去识别各种图片格式的内嵌 exif,然后把它们各种花式归档、搜索、展示……展示在网页边角、在动态的弹出菜单、甚至悬浮在照片上面。——我不需要啊!谁要在摄影作品上,标明照片的 exif 是哪天拍的,甚至是哪天上传的啊!!我连标题都不想展示啊!

甚至,各路图库程序比拼的重点,已经变成了如何调用外部地图软件,然后把照片根据 GPS 信息显示在地图上。(翻白眼

如果,我要的是一个管理图片的工具,能够便捷地挑出一些照片来展示。那么我需要——

在一个相册里,可以便捷地拖动更改,照片之间的顺序。而不是靠手动修改文件名这种粗糙的排序方式。


没有。能够满足这些需求的哪怕其中之一的,都没有。有一些静态网站生成程序,能够把已经彻底整理好的照片,生成看着还行的展示网站。但与其一个个试过来,再试着根据自己需求去魔改各种瑕疵;我觉得我还是在 wordpress 上慢慢拼吧……

于是又变成了

打算做点啥 → 考察相关的工具 → 做不成,开始吐槽各种工具……


以及,在这些干扰下,想趁此机会整理从前照片的希望,大概又落空了……不仅仅是在一些照片里的人,我不想去回顾。也包括,在翻看以前照片时,仍然能够识别出的,自己当年用摄影的视角,去凝视世界的方式,以及对这种方式本身的思考和改变。——我现在是否适合,把这种方式,重新调用起来?

❌
❌