Gabriel Furstenheim's questions

根据 UUID 标准RFC 4122，UUID 应被视为无符号整数 128，并且应按以下方式进行比较：

Rules for Lexical Equivalence:
      Consider each field of the UUID to be an unsigned integer as shown
      in the table in section Section 4.1.2.  Then, to compare a pair of
      UUIDs, arithmetically compare the corresponding fields from each
      UUID in order of significance and according to their data type.
      Two UUIDs are equal if and only if all the corresponding fields
      are equal.

 UUIDs, as defined in this document, can also be ordered
      lexicographically.  For a pair of UUIDs, the first one follows the
      second if the most significant field in which the UUIDs differ is
      greater for the first UUID.  The second precedes the first if the
      most significant field in which the UUIDs differ is greater for
      the second UUID.

意思是 println(UUID.fromString("b533260f-6479-4014-a007-818481bd98c6") < UUID.fromString("131f0ada-6b6a-4e75-a6a0-4149958664e3"))应该打印 false。

然而，它打印的是真的！！

查看 compareTo 的实现（我在这里使用 temurin）

@Override
    public int compareTo(UUID val) {
        // The ordering is intentionally set up so that the UUIDs
        // can simply be numerically compared as two numbers
        int mostSigBits = Long.compare(this.mostSigBits, val.mostSigBits);
        return mostSigBits != 0 ? mostSigBits : Long.compare(this.leastSigBits, val.leastSigBits);
    }

对于这种特殊情况，最高有效位是

-5389922481480318956
1377831944219938421

分别表示。这意味着比较是错误的，因为 long 溢出了。

json 的一个巧妙的特性是可以防止部分读取。

如果客户端发送如下的 json：

[ {"someProperty": 1, "otherProperty": 2}, {"someProperty": 2, "otherProperty": 3}]

不知什么原因，连接中途关闭，我只收到

[ {"someProperty": 1, "otherProperty": 2}

我知道我会遇到 json 解码异常并且永远不会处理该有效负载。

protobuf 可以进行部分读取吗？

意思是，我有一些字节数组，a[0: n]在n != len(a)同一个模型中有效但显然缺少数据？

我在 Ubuntu 中有一个不起作用的文件source，我不知道发生了什么。

$ cat .broken_file
export D='222'
$ cat .working_file_1
export D='88'
$ D=5
$ echo $D
5
$ source .working_file_1
$ echo $D
88
$ source .broken_file
$ ## What is happening here? It should be 222
$ echo $D
88

现在，两个文件具有相同的权限：

$ ll .working_file_1 .broken_file
-rw-rw-r-- 1 my_user my_user
-rw-rw-r-- 1 my_user my_user 

此外，如果我复制损坏的文件，新文件就可以工作：

$ cp .broken_file .broken_file_copy
$ source .broken_file_copy
$ echo $D
222

所以它也不是文件的内容。

我可以修改我的 .broken_file （更改变量和值的名称），但它仍然失败。

$ echo $SHELL
/bin/bash
$ echo $BASH_VERSION
5.1.16(1)-release
$ uname -srv
Linux 6.2.0-26-generic #26~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Thu Jul 13 16:27:29 UTC 2

知道这是什么吗？

更新：type返回一些奇怪的信息（我不知道如何解释这一点）：

$ type .broken_file
.broken_file is DIFFERENT_FOLDER/.broken_file
$ type .broken_file_copy
bash: type: .broken_file_copy: not found